New answers tagged ssh-tunneling
You can add a user without a valid login shell: # useradd -s /sbin/nologin dbuser Set their password: # passwd dbuser Or leave it unset and make SSH keys: (on local machine) $ ssh-keygen (on remote machine) # su -s /bin/bash - dbuser $ cat local_id_rsa.pub >>~/.ssh/authorized_keys At this point, you can use SSH to create the tunnel: ssh ...
You don't need netcat on your bridge. As DanSut proposed in the comments you can use the ssh -W command line option instead, this configuration should work for you: Host axp User remote_userid HostName remoteserver.com IdentityFile ~/.ssh/id_rsa.eric ProxyCommand ssh -AW %h:%p bridge_userid@bridge_userid.com
You have the quoting such that STDIN of the ssh command is being fed by findPassword. You want the STDIN of the sudo command to be fed by findPassword. ssh -p $tunnel_port $me@localhost -t "echo $(findPassword) | sudo -S -u $_remoteUser -i" or ssh -p $tunnel_port $me@localhost -t "sudo -S -u $_remoteUser -i < $(findPassword)"
The shell's $! variable only knows the pid of the process started by the shell. As you suspected, the ssh call using -f forks its own process so it can go to background, so the overall process tree looks like : shell | +--ssh<1> (pid is $!) | +--ssh<2> (pid is different) ssh<1> exits very shortly after invocation; therefore, the ...
This error means that the server sent an unrequested forwarded port that the client didn't expect. In short, the dropbear SSH client doesn't know how to handle the dynamically allocated port forward which the remote server has allocated for it. It is unsupported by dropbear. The relevant code: Where the dropbear client parses the remote forward request and ...
@Lawrence 's answer was good enough for me to get it all down. But here are the more detailed steps I used. I used this for using my laptops 4g dongle to route internet to a raspberry pi with a fixed line connection to a wifi router. If your host is a mac: install squidman http://squidman.net/squidman/ (not just generic squid, I had too much trouble ...
Thanks for the help and for the responses, it turns out, that basically this issue is pointless. My eyes got opened by a helpful redditor ckozler: https://www.reddit.com/r/linuxadmin/comments/3kdn1r/openssh_server_fatal_too_many_listen_sockets/cuwoo02 But they'll still be connecting to YOU on port 22, the reverse SSH tunnel is a port opened on THEM to ...
You can run sshd using inetd (and optionally tcpd) on as many ports as you like with the following inetd.conf: 10000 stream tcp nowait root /usr/sbin/tcpd sshd -i 10001 stream tcp nowait root /usr/sbin/tcpd sshd -i 10002 stream tcp nowait root /usr/sbin/tcpd sshd -i ... You should also read the caveats on sshd -i in the sshd manual.
Top 50 recent answers are included