====== Ubuntu - SSH - Setup SSH Keys ======
===== About SSH Keys =====
SSH keys provide a more secure way of logging into a virtual private server with SSH than using a password alone.
While a password can eventually be cracked with a brute force attack, SSH keys are nearly impossible to decipher by brute force alone.
Generating a key pair provides you with two long string of characters: a public and a private key.
You can place the public key on any server, and then unlock it by connecting to it with a client that already has the private key.
When the two match up, the system unlocks without the need for a password.
You can increase security even more by protecting the private key with a passphrase.
----
===== Create the RSA Key Pair =====
The first step is to create the key pair on the client machine (there is a good chance that this will just be your computer):
ssh-keygen -t rsa
The following syntax specifies the 4096 of bits in the RSA key to creation (default 2048):
ssh-keygen -t rsa -b 4096 -f ~/.ssh/vps-cloud.web-server.key -C "My web-server key"
Where,
* -t rsa : Specifies the type of key to create. The possible values are “rsa1” for protocol version 1 and “dsa”, “ecdsa”, “ed25519”, or “rsa” for protocol version 2.
* -b 4096 : Specifies the number of bits in the key to create
* -f ~/.ssh/vps-cloud.web-server.key : Specifies the filename of the key file.
* -C "My web-server key" : Set a new comment.
**KEY TYPES**:
* **RSA** keys will work everywhere (in practice). An advantage of RSA is that it does not ever need a secure random number generator to create signatures.
* **DSA** keys used to work everywhere, as per the SSH standard ([[http://tools.ietf.org/html/rfc4251|RFC 4251]] and subsequent), but this changed recently. DSA is risky because if you make signatures (and using your key with a ssh client to log in is effectively making signatures) on a box with a bad Random Number Generator (RNG) your key can be compromised. [[http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html|DSA is disabled by default in OpenSSH 7.0 and higher]].
* **ECDSA** support is newer, so some old client or server may have trouble with ECDSA keys. ECDSA is computationally lighter, but you'll need a really small client or server (say 50 MHz embedded ARM processor) to notice the difference. To generate a signature, (EC)DSA needs a value that has to be random, secret/unpredictable and can never be used again. If one of those properties is violated, it's possible to trivially recover the private key from one or two signatures. This has happened before and is pretty hard to completely prevent.
* **EC25519** is probably the strongest mathematically (and also the fastest), but not yet widely supported. As a bonus, it has stronger encryption (password-protection) of the private key by default than other key types; with the advantage of being able to use the same key for signing for key agreement; and it is immune to several side channel attacks.
It's important to use large enough keys (2048 bits for RSA or DSA, 256 bits for ECDSA); key size is specified with the -b parameter. However, some ssh-keygen versions may reject DSA keys of size other than 1024 bits, which is currently unbroken, but arguably not as robust as could be wished for.
The bottom line is:
* Never use DSA or ECDSA.
* Use Ed25519 if you can.
* RSA is the best bet if you can't use Ed25519.
**DANGER**: Documents leaked by former NSA contractor Edward Snowden show that the NSA created and promulgated a flawed formula for generating random numbers to create a "back door" in encryption products, the New York Times reported in September 2013. Reuters later reported that RSA became the most important distributor of that formula by rolling it into their software.
Undisclosed until now was that RSA received a large cash sum in a deal that set the NSA formula as the preferred, or default, method for number generation. So RSA could potentially be broken, but seems the best option to use at this time.
The RSA algorithm (with big enough keys) still cannot be easily broken.
To sum up, do **ssh-keygen -t rsa -b 4096** and you will be happy.
----
===== Store the Keys and Passphrase =====
Once you have entered the Gen Key command, you will get a few more questions:
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
You can press enter here, saving the file to the user home (in this case, my example user is called demo).
Enter passphrase (empty for no passphrase):
It's up to you whether you want to use a passphrase. Entering a passphrase does have its benefits: the security of a key, no matter how encrypted, still depends on the fact that it is not visible to anyone else. Should a passphrase-protected private key fall into an unauthorized users possession, they will be unable to log in to its associated accounts until they figure out the passphrase, buying the hacked user some extra time. The only downside, of course, to having a passphrase, is then having to type it in each time you use the Key Pair.
The entire key generation process looks like this:
ssh-keygen -t rsa
displays:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/demo/.ssh/id_rsa.
Your public key has been saved in /home/demo/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 demo@a
The key's randomart image is:
+--[ RSA 2048]----+
| .oo. |
| . o.E |
| + . o |
| . = = . |
| = S = . |
| o + = + |
| . o + o . |
| . o |
| |
+-----------------+
The public key is now located in /home/demo/.ssh/id_rsa.pub.
The private key is now located in /home/demo/.ssh/id_rsa.
----
===== Copy the Public Key =====
Once the key pair is generated, it's time to place the public key on the virtual server that we want to use.
This should be placed into the user's **"~/.ssh/authorized_keys"** file.
You can copy the public key into the new machine's authorized_keys file with the **ssh-copy-id** command. Make sure to replace the example username and IP address below.
ssh-copy-id user@123.45.56.78
Alternatively, you can paste in the keys using SSH:
cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
No matter which command you chose, you should see something like:
The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '12.34.56.78' (RSA) to the list of known hosts.
user@12.34.56.78's password:
Now try logging into the machine, with "ssh 'user@12.34.56.78'", and check in ~/.ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
Now you can go ahead and log into user@12.34.56.78 and you will not be prompted for a password. However, if you set a passphrase, you will be asked to enter the passphrase at that time (and whenever else you log in in the future).
Ensure the SSH permissions are set correctly:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown $administrator:administrator ~/.ssh -R
----
===== Disable the Password for Root Login (Optional) =====
Once you have copied your SSH keys unto your server and ensured that you can log in with the SSH keys alone, you can go ahead and restrict the root login to only be permitted via SSH keys.
In order to do this, open up the SSH config file:
sudo vi /etc/ssh/sshd_config
Within that file, find the line that includes **PermitRootLogin** and modify it to ensure that users can only connect with their SSH key:
PermitRootLogin without-password
Put the changes into effect:
reload ssh