Hacker News new | ask | show | jobs
by apage43 6331 days ago
To fix constantly re-logging in to ssh: - set up key authentication and run ssh user@host with your favorite parameters in a loop (shell script) so it reconnects when disconnected. - in fact, have it run screen when connected, so you get right back to where you were effortlessy.

As for port forwarding, you will still be disconnected from everything on connectivity blips when ssh has to reconnect if you use ssh port forwarding. Try a VPN setup instead. You might have to fiddle with the host to keep it from sending RST's/FIN's as soon as you drop (though it shouldn't unless a packet for you comes in during the blip, I think). When you come back, if you come back soon enough, the connections should be restored without having been disconnected. (AS LONG as you have the same IP address on the VPN, so use a static IP setup)

Also, if you run your SSH -through- the VPN connection and recover quickly enough SSH shouldn't disconnect at all either.

More Edit: For long connectivity lapses (changing locations) all your TCP connections -will- drop. This is not something you can work around.

2 comments

Thanks for your response. Just to clarify, I don't care if my forwarded TCP connections drop when my internet connection drops, just that they are re-established automatically. I also don't care about the actual TCP connection dropping, I just want all my SSH terminals to automatically pick up where I left off. Of course screen factors into this, but it has to be more than just screen.

Regarding the VPN, could this connection be automatically established upon joining a wireless network? (i think you see where i'm going with this question)

I don't think it's any more complex than running screen on the server, using SSH keys to allow you to connect to the server without a password, and possibly orchestrated with a small script that checks network connectivity and re-establishes your session after it's broken. Your 5 shells are running in one screen session on the server, so you don't have to restart all of them. It's just a simple "screen -D -R". If there is no existing screen session to attach to, you can have screen automatically create your sessions via the config file.

This is pretty much what I do already, except that I don't switch connections as frequently as you. But when I go to a new place, it's just connect with ssh and reattach with screen.

If you don't care about connection dropping, indeed just set up key authentication and run ssh in a loop as described above, instead of a complicated VPN, which will only really partially mitigate dropping of -forwarded- connections.

Secondly, you should be able to set scripts to trigger when a network interface comes up in most linux distros, but how to do it varies, for example /etc/network/ifup.d/ in ubuntu.

I do something of this sort. I have a shell alias called 'irc' that will connect to my remote server using the following local command, 'kepler' being an SSH connection alias defined in .ssh/config:

    ssh -t kepler bin/irc -D 1083 -L 3128:localhost:3128
This provides me with a single three-letter command to log in to the remote machine, set up appropriate port-forwarding, and automatically run a script, which itself contains:

    #!/bin/sh

    if [ -f /tmp/jreese.agent.pid -a -f /tmp/jreese.agent.sock ]; then
            echo "Socket and PID files found; loading..."

            export SSH_AGENT_PID=`cat /tmp/jreese.agent.pid`
            export SSH_AUTH_SOCK=`cat /tmp/jreese.agent.sock`
    else
            echo "Socket and PID files not found; starting SSH agent..."

            UMASK=`umask`
            umask 077

            eval `ssh-agent`;
            ssh-add $HOME/.ssh/id_rsa

            echo "Agent PID: $SSH_AGENT_PID"
            echo "Agent Socket: $SSH_AUTH_SOCK"

            echo $SSH_AGENT_PID > /tmp/jreese.agent.pid
            echo $SSH_AUTH_SOCK > /tmp/jreese.agent.sock

            umask $UMASK
    fi

    screen -Rd irssi -c ~/.screenrc.irssi -p 1
EDIT: do note that this script is not completely secure, because it relies on my knowledge that I am the only person with login access to my server. Otherwise, you should be adding some extra checks to the script to ensure that you are using files actually created by your own uid. I don't know the full potential of problem if someone created those files from a different UID knowing that you'd be using them. Anyways...

This script sets up a persistent, "secure" SSH key agent on the remote machine that can be reused for as many disconnects and reconnects as I feel like making until the server (if ever) needs a reboot. Then it starts or reconnects to a named screen session that I can continue using as if nothing ever happened.

Combine this method with a few different aliases as needed, and a local session key agent to only input your key's passphrase once, and then after a disconnect, press up-enter in each terminal as necessary, and boom, you're back in business.

--

On a related note, a drop of network connectivity should not be killing your SSH connection, especially for as short a time span as one second. SSH is designed to stay connected through at least 30 seconds of network loss; after the connection is regained, it should automatically reconnect to the SSH server and continue the session where it left off, even maintaining a buffer of unsent input during the connection loss.

I've personally suspended and then unsuspended my laptop within a one-or-two minute period without losing my SSH session, althought that's likely stretching things.

What's certain is that a 1-2 second lapse in your connection should most certainly not be dropping your SSH connection; you should definitely be investigating that to figure out what the problem is.