OpenSSH is a handy tool for logging into other machines to run a remote shell, but it's handy for other things too, giving the same authentication mechanism and encryption.

Passwordless logins

Instead of requiring the entry of a password every time you want to log in, you can use a local password manager, or key based authentication.

I prefer key based authentication. Keys can be generated by running ssh-keygen, then future ssh connections can be made connection-less by running ssh copy-id USER@HOST.

File transfer

The scp command can be used to securely copy files between two machines, or even the same machine if it's a shared computing resource, and sensitive data needs to be transferred between users.

For a less ad-hoc file server, OpenSSH includes an sftp-server, though you generally don't invoke it directly, but via sshd_config.

It's very flexible, you can convert the SSH service into an SFTP server by adding the following to /etc/ssh/sshd_config:

ForceCommand internal-sftp

You can then view files in your home directory with the sftp client, or mount it with sshfs.

Git server

Git supports the ssh protocol. If you have a machine you can ssh to, you can run git init --bare reponame.git to create a repository, then clone it with git clone ssh://USER@HOST/path/to/reponame.git.

However for a shared git server this is cumbersome, as it requires every git user to have an associated login account.

Instead, git servers like gitolite and gitano use one "git" user, and handle authentication by assigning ssh keys to users.

Port forwarding

The -R option to ssh can be used to layer encryption and authentication on top of an existing protocol that supports neither.

Supposing HOST has a service that isn't secure, it can instead bind to a local only port, using the host address, and a port such as 1234.

This port could be made available to your local machine on port 4321 by running ssh -R USER@HOST.

This service can then be connected to by connecting to the address locally.



Corporate firewalls often block all ports not related to web browsing, which limits it to plain HTTP on port 80, and HTTPS on 443.

One way around this is to use sslh, which lets you run both HTTPS and SSH on the same port. To make use of such services, add -p 443 to your ssh command-line.

If you regularly make use of such connections, it may be worthwhile to add something like the following to your ~/.ssh/config file.

    Port 443

Using different keys for different machines

I mentioned earlier that it is possible to do passwordless logins by creating ssh keys.

By default this results in using your one key for authentication to every host. You can generate extra keys by running ssh-keygen -f KEYFILE, and use them instead of the default key by running ssh with ssh -i KEYFILE.

You can specify in your ssh config file to use a different key per host with something like:

    IdentityFile KEYFILE

You might want to do this to avoid the association of a given key to a person, by using different keys per service, and potentially to mitigate the damage of future ssh key reverse engineering attacks, as only the service for the reverse-engineered key is compromised.

Making local resources available remotely

I'm often annoyed that my local configuration is not available on remote machines, so I wrote a script called homely-ssh, which makes the home directory of my local machine available on the remote machine.

I would not recommend its use on shared machines, as it allows other users to access your local machine.