[nuclear_eclipse]

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.