One very useful feature of SSH are passwordless keys. They are especially useful when you’re writing scripts that need to run commands on a remote hosts. Since those will run unattended, you don’t want them to prompt for a password.

You can generate passwordless keys using the ssh-keygen tool. Simply press enter when asked for the password:

This generates a normal public key and a private key without a password. We can add the public key to a remote machine’s list of authorized keys using the ssh-copy-id tool:

We specify which public key to transport using the -i /home/user/passwordless_rsa.pub option.

Now we can ssh to the remote_host without using a password. If the private key has been placed in the current user’s .ssh directory, ssh will automatically detect it when trying to connect. If you want to be sure it finds the private key to connect with, you can once again specify the -i path_to_private_key option:

When using passwordless keys, you may provide the -q and -o "BatchMode=yes" options to SSH in order to make it quiet. Otherwise, errors related to SSH might be interpreted as errors from remote commands.

The SSH Agent is a tool which can keep your private keys in memory. When connecting to a remote machine, any SSH session (including scp and sftp) will try to contact a running agent on the machine to see if the required private key is already loaded. If it is, it will be used to connect to the remote machine. This way you only have to enter your password for a private key once, instead of each time you want to connect.

You can test if an SSH Agent is already running with the following command:

As you can see, no agent is currently running. We can start one with the following command:

The above command runs the ssh-agent program, which will output some other commands, which are then run by the current shell. This is the actual output of the ssh-agent program:

As you can see, the ssh-agent is started. It then creates a socket in the /tmp directory and sets that location as an environment variable so that SSH clients (ssh, scp, sftp) know where to contact the agent.

We can add keys to the agent using the ssh-add tool:

We can now connect to any remote machine that has the public key counterpart in its authorized_keys file without having to enter our password again.

The ssh_agent program generates a random name for the socket. One frequent problem with starting the SSH agent like we did just now is that only the current shell knows about the socket location. If we open another terminal, it won’t know about the running SSH agent, since the environment variable isn’t set in the new terminal. We can work around this by specifying our own path to a socket with the -a option.

Combining this knowledge, we can add a few lines to our .profile (or .bashrc) startup script to start an agent if none is running yet. We also check for a forwarded agent and don’t do anything if a forwarded agent is found (more on forwarding agents later on).

With this script in your .profile, you will only have to start one agent ever for a given user as long as that machine doesn’t reboot (or the agent is killed in some other way). If you log out, the agent is not killed, and will be re-used the next time you log in.

Perhaps the most useful feature of SSH is Agent Forwarding. We can tell ssh it should do Agent Forwarding by supplying the -A commandline option when we ssh to remote machine. For this to work, you have to have an SSH agent running locally, or agent forwarding had to be enabled when you SSHed into your current session. (Use ssh-add -l to see if an agent is avaiable).

When enabling Agent Forwarding with the -A switch, ssh will automatically create a socket at the remote host and set some environment variables (SSH_AUTH_SOCK, most notably) when you connect to a remote machine. If an ssh session needs to perform authentication, it will first try to reach the SSH agent through the socket. All requests will be sent back to the original SSH agent. This works for as many nested sessions as you’d like.

Using Agent forwarding, you can start a single agent on, say, your desktop machine. Every authentication request made by any SSH session will be sent back to the agent running on your desktop machine, without the need to start additional SSH agents on remote machines and loading keys there. As you can imagine, this is a much better method of keeping private keys secure than storing them on every machine you need to SSH from.

You can enable SSH agent forwarding for all the hosts you SSH to automatically (without the need to specify the -A switch) by putting the following in your ~/.ssh/config:

You can restrict which command can be run by someone logging in with a public/private key in the authorized_keys file. For instance, to restrict a certain public/private key to running the df -h command (to view avaiable diskspace), you add a line to the authorized_keys file like this (Public key shortened for brevity):

Now when we SSH to that machine (and we have that key loaded):

Its not possible for a single key to run multiple commands via any normal SSH configuration mechanism. However, SSH will set an environment variable $SSH_ORIGINAL_COMMAND with the command the user tried to run. We can take advantage of that by writing a shellscript. For example, we can create a script called commands.sh on the remote host:

Then we restrict the user to running that shellscript:

The user can now run multiple commands by specifying as an argument after the ssh command (The -q+ option makes ssh quiet, so it doesn’t show any output other than that of the remote command):

By default, SSH puts the authorized_keys files in the user’s home directory. This allows users to add other keys themselves; a situation you might want to avoid. You can change the location where the key files are kept in the /etc/ssh/sshd_config file, using the AuthorizedKeysFile option:

The %u will expand to the username. The location of the authorized_keys file for a user named “john” will become /etc/ssh/authorized_keys/john. %h expands to the users homedirectory.

Make sure users can’t write to the files in question.

You can restrict which users are allowed to use SSH with the AllowUsers option in /etc/ssh/sshd_config:

Like every other Unix tool, SSH can use input and output redirection. When running a command on a remote machine using SSH, it will redirect any input given to it locally to the remote command. Any output from the remote command is redirected back to your local machine. This allows for some very useful time-savers.

For instance, we can run the command du (diskusage) on the remote machine, and locally pipe it into xdu to get a graphical representation on our local X11 desktop of the remote disk usage:

Or suppose we want to transfer a remote directory’s contents to the local machine without using scp (for whatever reason). We can remotely create a tar archive of the directory, and instruct tar to write it to the standard output (using the minus as the filename) instead of a file. SSH will transfer the remote standard output of tar to our local machine, where we can untar it in the same manner:

Perhaps we need to create a local copy of a MySQL database on a remote machine. Unfortunatelly, MySQL access is not remotely allowed and the harddisk on the remote machine is full, so we can’t create a dump there, transport it to our local machine and read it in. No worry, SSH to the rescue:

Or we can just import it directly:

Likewise we can locally pipe data into ssh and use it at the remote host. Again, we use the minus-sign to indicate reading from standard in:

This will put “hello world” in a file called foo.txt on the remote host. We need to quote the parts that contain the redirection on the host ("cat >foo.txt") or it will be picked up by the local shell.

Sometimes you may need to use a certain service on a network, but the network has been firewalled against external connections on ports other than the SSH port. SSH allows us to create a tunnel into the remote network. Suppose we are on a network 192.168.1.x and we want to connect to port 80 on a machine with 192.168.56.3. But the 192.168.56.x network is firewalled, and we can only access it through a bastion host at 192.168.56.1. Here’s what we do:

SSH will now create a tunnel to 192.168.56.3 port 80 through 192.168.56.1. The -L option takes three arguments, separated with colons: local_port:remote_host:remote_port. The local_port is where SSH will listen for incoming connections on the machine where you issued this command. remote_host:remote_port is the machine/port to which you wish to create the tunnel. It is important to remember that this is as you’d view it from the server you’re ssh-ing too (192.168.56.1 in this case), not as you’d view it from your local machine.

You can additionally specify the -N switch to prevent SSH from actually logging in to 192.168.56.1.

We can use SSH as a SOCKS5 proxy. An SOCKS5 proxy works much like a normal tunnel, but works with multiple clients at the same time, and is not restricted to forwarding of a single port. We can start a SOCKS5 using the -D option:

Socks5 is pretty neat, as it allows you to proxy stuff without the server having to know anything about the way the client works. For instance, if we give the following command:

Now we can configure local clients (such as Firefox, Pidgin Instant Messanger, Chrome, etc) to use the proxy. All network traffic (with the exception of DNS, possibly!) will go through the SOCKS5 proxy. For instance:

Many networks require you to SSH to a bastion (firewall/gateway) server before you’re able to SSH to any machine on the network. This becomes tedious quickly, as you have to SSH twice each time. The ProxyCommand is a setting in your ssh configuration file which can do this for you automatically.

Assume we want to SSH to a host ‘web1.example.com’. Before we can SSH to this host we first have to SSH to ‘example.com’. We can SSH directly to ‘web1.example.com’ by putting the following in our ~.ssh/config file:

This requires that the nc (netcat) tool is installed on web1.example.com. If we SSH to web1 now, we are automatically sent to web1.example.com. It’s even possible to use scp and other SSH tricks directly, thus saving us the trouble of having to transfer files to example.com first, then to our local machine (or vice versa).

ProxyCommand can also be used with other things. To SSH through a HTTP proxy at 192.0.2.0 port 8080:

The SSH client configuration lives in the file /home/USER/.ssh/config. It has many useful directives. The basic way it works is we specify a host identifier, and add configuration settings to that host.

For instance, if your local username is john, but on the backup machine backup.example.com it’s always backup, you can tell SSH to automatically use that username to log in:

You can create aliases (much like the /etc/hosts file) to save some typing:

If you want to apply a certain configuration option to every host, use the asterisk wildcard:

Check man ssh_config for more useful options in this configuration file.

This should be obvious, but you can use the scp tool to transfer files between hosts using SSH. To copy a file localhost.txt to your home directory on the remote host:

To put the file in a different path:

and

Transferring an entire directory is possible using the -r switch:

OpenSSH (and most other SSH implementations) offer a secure FTP server. With it you can securely (encrypted) transfer files and authenticate using the default SSH authentication methods such as passwords or public keys. Contrary to ordinary FTP server (unless they run on TLS or some other form of encryption), passwords are not sent in plain-text over the network. SFTP also makes it easier for Windows user to transfer files between hosts, as there are many good free SFTP clients available. I personally recommend Filezilla.

The SFTP server needs to be enabled in the SSH server configuration. Edit /etc/ssh/sshd.config on the server and add the following line:

Restart SSH and you should be able to user the SFTP server:

On the client, issue the sftp command:

You may get an error like this:

This means that either the sftp-server was not properly configurated, or your login shell on the remote server is outputting some text not expected by the SFTP server (perhaps a welcome message or something). Remove the output and try again.

A different way of enabling the SFTP server is in the authorized_keys file:

This will restrict any user that logs in using the public key AAAAC8ghi9ldw== to SFTP. The user cannot login using a normal SSH session. This does not require you to enable the SFTP server in /etc/ssh/sshd.conf.

You’ll have to make sure that the user can’t write to the .ssh directory nor upload any files such as .bashrc, .profile, etc, otherwise the user can overwrite those by uploading their own version, and they can still execute anything they like by just logging in with sftp. You can do this by creating these files and then changing their ownership and rights in such a way that the user can’t write to them. Because it’s hard to guess what files you should create so that the user can’t cause any harm, it’s best to simply create a seperate directory in which they can upload stuff, and lock off write access to their entire home directory.

Unlike the ssh and scp commands, sftp does not have a -i switch with which you can manually give the location of the private key to log in with. Fortunately, we can still provide one through the -o (options) switch:

This can be convenient in the case of automated tasks. The custom key does not have to have a password and can be placed anywhere. Speaking of automated tasks, here’s an example of running sftp in a batch-mode:

Most normal FTP servers support jailing the user in a certain directory, preventing them from wandering around the file system. SFTP does not have this built-in ability, but we can use normal linux chroot/jails to jail a user to certain directory. For more information, see https://www.electricmonk.nl/log/2007/08/09/jailing-sftpscp/

Perhaps the most useful tool in existance: sshfs. SSHfs provides tools to locally mount a directory on a remote server over SSH, much like NFS. SSHfs requires remote support for SFTP. See the previous section on how to enable it. SSHfs is separate from the normal ssh tools, and is implemented as a FUSE (userland) filesystem. On Debian and Ubuntu machines you can easily install it using aptitude:

Once installed, we can mount a remote directory using the sshfs tool:

Unmounting can be done with the fusermount tool: