hosted services

SSH is extremely powerful. It's hard to ignore powerful features, especially when it comes to networking and tunnelling.

pseudo tty

One of the more useful things I've found with ssh is that it's possible to instruct which binary to run once the connection is open. This is done by specifying the -t argument after the host name.

ssh -t user@host /bin/bash

In many cases I find this useful when the shell has been configured to something other than [[bash]] or when there is a mandatory MOTD (message of the day) or banner which can be annoying output where it's not wanted.

There are also times when you may not want a TTY to be allocated at all, in which case you would use the -T argument. Often you'll see the following message

Pseudo-terminal will not be allocated because stdin is not a terminal.

when your script exits immediately after running causing the connection to close, the simplest thing to do to avoid the warning is to not allocate a terminal.

proxy through http

If a proxy server supports the CONNECT method then it's very possible to connect to a remote host via the proxy. The endpoints (yourself and the destination IP) still has the SSL end points, but it's very good to keep a note of the host finger prints if you're planning to use a [[proxys|proxy]] server that's in the wild.

The first thing to do is ensure that you have corkscrew installed:

$ sudo apt-get install corkscrew

(It's not rocket surgery).

If that's available you can do one of two things, either put the proxy details in ~/.ssh/config or define it on the command line:

$ ssh -o 'ProxyCommand=/usr/bin/corkscrew w.x.y.z 80 %h %p'

So, if you can only connect to a remote host on port 80 you have few options available. This might seem like a lot of rigmarole, but if you have only one IP address on the remote host, then you might not want to make that host have port 80 bound to SSH, so it might make sense to use a public proxy to do that in-between work for you.

reverse forwards

There are times when it is convenient to open a port on a remote host that connects a listening port at the remote host to the local system. For example:

In the above example, the ssh connection from the local host to the remote host opens a socket which listens for port number 8080 and forwards these connections to port 80 on the local host. This is incredibly useful when devices on a remote network do not have a route to the local host.

$ ssh -R 8080:0:80 remote_host

controlpath

One of the really cool ''newer'' features of SSH is the ability to allow multiple connections to the same host to share the same TCP connection. So in practice if you're going to connect as user mouse to a host, called tawny then further connections to the host tawny as user mouse should share the same connection.

How this can be achieved in a sensible way so that it applies to all hosts can be done as follows.

~/.ssh/config:

ControlMaster  auto
ControlPath    /tmp/%l.%r@%h:%p

That's it.

Using ControlMaster is handy as it creates the master socket if one does not already exist, or makes use of the master socket if present.

ControlPath configures the store for the socket file. In the above example we're using:

If your ControlPath being used is shared or mounted in a location where you may start other connections from then you should make sure that %l is included in the path name.

Of course, if you have many different version of SSH on the go and not all of them support this, then you may wish to create a bash function, named ssh, which invokes your ssh client for your current environment.

sshpass

There comes a horrid time in everyone's life when they find that they cannot store their public key on a remote system as they don't have a home directory.

Like I said already, this is a horrid situation, one solution is to use sshpass, the other is to engineer the system to do public key authentication.

# apt-get install sshpass

You can use it simply as:

$ sshpass -p mypass ssh -l root remotesystem

If you want to use rsync then it's a little less straight forward:

$ rsync -avP --rsh="sshpass -p mypass ssh -l root" remotesystem:/home .

Bear in mind that you will be exposing passwords in your history file and possibly in the process table, so viewable in ps, top etc.

see also

SOCKS method via tsocks