SSH

More information on ssh can be found at http://www.openssh.org/

Use cases

1. You want to get access to a server that I operate
2. You hired me to do some work and you want to grant me access to your server.

Use case 1. Getting access to my server

1. You generate a key pair in RSA format. Use a passphrase to encrypt your private key.*
2. You send your public key to me in an email.
3. I create your account and install your public key.

Using SSH means we never have to send any secrets over email. As long as your private key is kept private by you and encrypted with a passphrase, everything remains secure. When you connect to my server, all data transmitted over the networks is encrypted. This means you can safely work in any public places or use wireless connections without worrying who is sneaking a look at your traffic.

\* Strictly speaking you don't need to use a passphrase, but if you put the key pair on a portable computer it protects us both if the computer is lost or stolen. No passphrase means you don't have to type your passphrase to connect to my server.

Use case 2. Granting me access to your server

1. You have to run an sshd server on your machine.
2. I generate a key pair in RSA format, creating a passphrase-encrypted private key and a public key.
3. I send you my public key.
4. You add my key to the accounts that you want to allow me to have access to. For example, you can create a personal account for me with the username "bwilson" and add the file in /home/bwilson/.ssh/authorized_keys and optionally also put a copy in /root/.ssh/authorized_keys to give me root level access.

Then I can use an ssh client to connect. I enter my passphrase and the client uses the decrypted private key to authenticate with your system. If the private and public keys match, your system grants me access.

As long as I don't share my passphrase with anyone, even if I lose my laptop, no one can use my private key to access your machine.

If you want to revoke access, you remove or disable access to my public key(s).

You don't have to give me any password information on your machine, so you don't have to change the root password when we are done working together.

This is what an RSA public key looks like

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsfKX946JbxemrYTT55dTk9Bg98tLeH3PAi5/cpQkWdntATz4ISIvqOltXkKrssj3dlK57M5u86RA05mzIOLPel9o52WCiYUdGiCnAOJa7fS9+XBU2rtrsgl0NBttVbC/m1qH1Ff6WKcGEwjlwxZvQAMk6pdSLDf9A4bns1qpS+jdD4nBOsVjx9cF6MD+1H/JqpNfllXDLeFsNNBivQ8ansAMiOj4WwXyU+XgbaZGngl1LYuwc1Lk+5N8Z4wq+33ERokvKOvNl8dAe4/n0oZqMF7LU+rHqIpUiusDRryFF+O2ogb+yTCwz0TYxNwg0tkTFFZN4xqc5hjhFgWrCuOvPQ== [email protected]

Key file installation notes

The file(s) "authorized_keys" are text files containing public keys. You can add new keys from the command line or using a text editor. The ownership and permissions should be set to be owned by the user account and readable only by that user. The typical commands:

# cd /home/username/.ssh                     move to user's directory
# cat /tmp/id_rsa.pub >> authorized_keys     append key to file
# chown username authorized_keys             fix ownership
# chmod 600 authorized_keys                  fix permissions