Shane's blog

Having Bash complete hostnames when SSH’ing to a host is very useful. I use the following on my computers that don’t have useful completion support:

KNOWN_HOSTS_LIST=$(echo `sed -e 's/^  *//' -e '/^#/d' -e 's/[, ].*//' -e '/[/d' ~/.ssh/known_hosts | sort -u`)
complete -W "$KNOWN_HOSTS_LIST" ping
complete -W "$KNOWN_HOSTS_LIST" ssh
complete -W "$KNOWN_HOSTS_LIST" telnet
complete -W "$KNOWN_HOSTS_LIST" traceroute
complete -c -f command sudo
complete -o dirnames cd

If running Debian or Ubuntu, install the bash-completion package to pick up more useful completions.

When the only connection I have into a network is SSH, yet I need to do more work than is possible over a single SSH session, I set up a simple VPN-like solution using the following.

I add to my ~/.ssh/config file:

Host sshgw.example.net
DynamicForward 16000

Host *.example.net
User shane
ProxyCommand ~/.bin/nc-ssh-autoproxy.sh %h %p 16000

The first host listed is the machine where I connect using SSH. I set up a SOCKS proxy on port 16000. The second host section is generic for the entire environment. It specifies a ProxyCommand which calls a script that pipes the SSH connections over the SOCKS proxy when the proxy is up.

Here is the nc-ssh-autoproxy.sh script:

#!/bin/sh
# netcat-openbsd needed for -x proxy option
HOST=$1
PORT=$2
PROXY=$3

netstat -an | grep LISTEN | grep -q "$PROXY"
STAT=$?
if [ $STAT = 1 ] ; then
    /bin/nc $HOST $PORT
else
    /bin/nc -x localhost:$PROXY $HOST $PORT
fi

One thing to note is that you need to have the OpenBSD version of Netcat, not the GNU version. The OpenBSD version supports connecting to SOCKS proxies. If you are using Debian or Ubuntu, install the netcat-openbsd package.

The reason for using the nc-ssh-autoproxy.sh script is that if a SOCKS proxy is not up, the SSH connection goes directly to the host. But if the proxy is running, all new SSH connections use the proxy.

I frequently use the initial SSH connection to open an IRC session. That way I’m not likely to accidentally close it thinking it is an unused terminal and stop the proxy.

A SOCKS proxy is a general solution that you can send web, email, and other traffic through it to the machines behind the SSH gateway. You can set your applications to use the SOCKS proxy on localhost:$PORT and everything should work.

I like to take it a step further though for web browsing: I install FoxyProxy in Firefox and configure FoxyProxy to only send requests for *.example.net through the proxy. All other traffic is sent using the normal methods for the machine.

An example FoxyProxy config:

• Create a new proxy, enable SOCKS5
• Add a new pattern
• Name the pattern
• Provide a URL pattern (I prefer regular expression patterns; here’s an example: https?://.*.example.net(:d+)?/.*)

When starting a GNU Screen session, the current SSH agent is passed through to the new virtual terminal.  As long as you do not disconnect from the screen session, SSH agent forwarding should continue to work as normal.

Once you disconnect from the screen session and end the SSH connection, the SSH agent settings in the screen session are no longer valid.  If you reconnect to the screen session using a new SSH connection, the SSH agent socket has changed.

To fix this problem, I added the following bit of code to my ~/.bashrc file:

if ! [ -S $SSH_AUTH_SOCK ] ; then
    # delete old/lingering agent files
    for i in `find /tmp/ssh-* -maxdepth 2 -name agent* -user $USER 2>/dev/null` ; do
        if ! [ -S $i ] ; then
            rm $i
        fi
    done
    unset i
    # set agent string
    SSH_AUTH_SOCK="`find /tmp/ssh-* -maxdepth 2 -name agent* -user $USER 2>/dev/null  | head -n1`"
    echo "Set SSH_AUTH_SOCK to $SSH_AUTH_SOCK"
fi

This code does the following:

1. Checks if the current $SSH_AUTH_SOCK environment variable is a valid socket
2. If not, delete all old SSH agent socket files that may be lingering
3. Set the $SSH_AUTH_SOCK environment variable to the first valid SSH agent socket file found

I normally open new virtual terminals to do work and close them when I’m complete.  That way I always have a current environment for the applications to use.  If you’re someone that uses only one virtual terminal and leaves it running forever, this trick won’t work as well for you.

If you connect to a server using multiple SSH connections, there’s a chance that a new virtual terminal in the screen session could use the SSH agent socket from a different SSH connection.  If you disconnect the other SSH session, you may loose access to the SSH agent and need to open a new virtual terminal (or run source ~/.bashrc) to regain access to an SSH agent.