You know how it goes. SSH is something that nearly every developer uses every day, however, they only set it up a couple of times and then forget about it. And whenever you need to authenticate with SSH again, you just look up how to do it, never remembering how to do it because why would you?
SSH, which stands for Secure Shell, is a network protocol that enables a client to securely connect to a remote server. All user authentication, commands, outputs, and file transfers are encrypted to protect against attacks in the network. It is a more secure alternative to non-protected login protocols such as FTP.
- Providing secure access for users and automated processes
- Issuing remote commands
- Interactive and automated file transfers (e.g.,
scp(Secure Copy) uses SSH)
SSH uses the client-server model. When attempting to login to a remote server using SSH, this is roughly what happens:
- The remote server has your public key on file, more than likely located at
.ssh/authorized_keys, within the user account you will be logging in as. - You (the client) attempt to login to a remote server via
ssh. - The server encrypts a message using your public key on file, which can only be understood by the client with the associated private key, and sends it back to you (the client).
- The associate private key on the client decrypts the message. If you set a passphrase when generating the SSH key-pair, you will be asked to enter in the passphrase. This passphrase is required to decrypt the private key on the local system, which consequently enables the private key to decrypt the message sent from the remote server.
In sum, as long as you hold the private key, which is typically stored in the ~/.ssh directory, you should be able to successfully authenticate with the server.
SSH can work with password authentication, but the more modern way to use SSH makes use of public key cryptography, also known as SSH keys.
The recommended way of authenticating for SSH is to use SSH keys, also known as public key authentication. The main advantage to using SSH keys over password authentication is that SSH keys are not prone to brute-force attacks. Additionally, if the server is compromised, no valid credentials are exposed.
The idea is to have a cryptographic key pair--a public key and a private key. Basically, the client must first generate this key pair and then add the public key that was generated to the server to which they want to connect. The private key is known only to you (the client) and should be safely guarded. By adding their public key to the server, the client has authorized access to the server, and anyone who has the private key that is associated with the public key now has access to that server.
Public keys, also known as authorized keys, are keys that grant access. They are analagous to locks that the corresponding private key can open.
Here is an example of a public key (Note: Not a real public key, taken from this blog post):
ssh-rsa AAAAB3Nz4C1yc2EAAAADAQABAAABAQDG3eIHvpiK2At0G+e3Y0vgo0o3aZHM8rJLXMMsGxC5kCorySKb2qtvsSVVm+3KverdalhhuJdLHf1PmVfd+kGgglAYyos21eKevM6Syub4k1r6qvBe/jqwigI1kwr3cL6mU4ifIpUN1eddrcnRVo3F2zdtBXML5Ty+PZ4Hd2/nQKApzohIHDph9wxUMgRA+cevPQpYslyLsP1Bef5ZOlY7GrFwqxNJV5li0tMG5GI+kQ7lUuySkv5Wjqbu/NqHb1OmH++jWJdAZ8BtNUuKjlD9r7lfvzIInX4CNs7KYY/USfL5ZuL/yOIGjjIiY0UMZJkJebiT/CLN/pXkw8ZlDikz robert@ubuntu
Again, this is the key that is added to remote servers to authenticate clients. This can be shared freely without any negative consequences.
Private keys, also known as identity keys, are keys that authenticate users that connect to SSH servers. They are analogous to physical keys that can open one or more locks.
Here is an example of a private key (Note: Not a real private key, taken from this blog post):
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAxt3iB76YitgLdBvnt2NL4KNKN2mRzPKyS1zDLBsQuZAqK8ki
m9qrb7ElVZvtyr3q3WpYYbiXSx39T5lX3fpBoIJQGMqLNtXinrzOksrm+JNa+qrw
Xv46sIoCNZMK93C+plOInyKVDdXnXa3J0VaNxds3bQVzC+U8vj2eB3dv50CgKc6I
SBw6YfcMVDIEQPnHrz0KWLJci7D9QXn+WTpWOxqxcKsTSVeZYtLTBuRiPpEO5VLs
kpL+Vo6m7vzKh29Tph/vo1iXQGfAbTVLio5Q/a+5X78yCJ1+AjbOymGP70ny+Wbi
/8jiCo4yImNFDGSZCXm4k/wizf6V5MPGZQ4pMwIDAQABAoIBAGavS3cUQ0/uHnvl
rNBUxWlI55mVOWPKLaYcT+sGTqyCdEQHp4cycjNKFS0PRsnZJt0NfHV5CyYOZi4j
z+sevaRJpWgnrZqy9kFg3ImPm5PfAqtMeLGUNFnT6TAgrRj3bnoTyAfjo3Nxb/Y/
NmaResMfXo88sRsDU0ooJuFUGsQdAxEYSDJ0wKkuCytW05hYx/sQS8fElhKg3c0f
CG/MQwBxOYWOelLBwE76D1RIWDAA9l4+Ol48lE+b5Ltv2dZFVKZht/oFNa/egvMw
YTikekakwfkg5MTaDyldD/idet2ZRoLllyObLsEH8c6y9oXVhkZsu6aQ02KEWx0W
iD0+IQECgYEA7RzbS3YbJ/Ds+zrf/Czy1j3B+h7x+w67kojpD2kxpS9BWB6957ST
ozCGx8ysdJ9kwtGTOe+MTykG0JHyQhV5qv2zIols/2EA2HIQFXUZDNqbfr9Hvekc
vRctd60H/jMAMR5DLHu0OorNoY0AA/HATAYQsovkDnlL8IRr3V17uAsCgYEA1rUf
pVFcjgoLPon+Zp3rV+9rwrMo8hOZ6EE+lX9uWBtPaKQNXiqkls+xIA8R8sNqdrB2
CkvyFpMz7HVV5rBsMhIqe8ti8Ot5Z2xp7cErxc7XpMuJBTTvmJX5Sti9R7I14CUf
4oFHeSdWJiOS55a85sPXZYHjHA1YuycUNWCcBHkCgYA6yBeZaosq6LBnS94xTxdY
g3DuR+PJoIphtm1Is8Rp9gAWD3D22y5qm2IecCAkvUsmfPwptbgr+7jDxhqvxVEn
UcOyAS2zVeH2xrg0CZaPODaqQlNPwlWsju1nqM69dvlKM/1lLrmsdbKqpSDm2WzZ
q/tBuCpuaBWqV7nB5CYCpwKBgHT2BAA1uzqxJAD0gT57ZnnntgdBO9vra5sG98XO
vliGwBJb0+BpUHHLQE0biIZ7h6KSbCsdxgogNFfqb1oU30vDc5suZ36gd+ksOORI
p8TA8d4W9lR8ysyPXlc0jJ/i59BryNvF2x6XnCl4lY1NIyh+pPbp88MTTjPdjPeq
4jLZAoGAVuHcLyNV0ZUxTmFZovXfxisc+zdJV3eSaVD7/c7v/sA35cQyojFZEi/l
JDJYIq5T4Mo5NnKb+mms3n34ehH50i8BTGeJfnlg63MIrd5fE7jZeFYX2cvx6jD5
mvPGakcGN6ftUaCbEfJfDjf85WjKwiVi52oY1wb/91OrIpoP3io=
-----END RSA PRIVATE KEY-----
The private key is retained by you (the client) and should be kept absolutely secret. If someone with malicious intent were to gain access to your private key, they could then log into servers that are configured with the associated public key without additional authentication.
An SSH key pair can be generated by running the ssh-keygen command:
$ ssh-keygen
The default signing algorithm is 3072-bit RSA, however, a different type can be specified using the -t option. The Linux man page for ssh-keygen says "Generally, 3072 bits is considered sufficient."
Upon running the above command, you will be prompted for the desired name and location of your private key:
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
If you press enter, by default, the private key will be stored at /home/username/.ssh/id_rsa where id is the name
of the key and rsa is the type of encryption used.
Next, you will be prompted to enter in a passphrase:
Enter passphrase (empty for no passphrase):
The passphrase is not required, however, it is recommended. Without a passphrase, your private key will be stored on disk in an unencrypted form. If you choose to provide a passphrase, make it as strong as a password.
Finally, you will be prompted to enter in the passphrase a second time:
Enter same passphrase again:
Here is an example of the output of ssh-keygen (Note: not a real output, taken from this blog post):
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 (identification) is now located in /home/demo/.ssh/id_rsa.
To place the recently generated public key on the server that you want to connect to, use ssh-copy-id. This is not installed on Mac, so you need to use Homebrew.
If you see a message that looks like this:
The authenticity of host '198.51.100.0 (198.51.100.0)' can't be established.
RSA key fingerprint is b1:2d:38:67:ce:35:4d:5f:d3:a8:cd:c0:c4:48:55:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '198.51.100.0' (RSA) to the list of known hosts.
The above message implies one of the following:
- This is the first time you are attempting to SSH into the server using the key-pair.
- The server has been configured with a new key.
- The server's identity is being spoofed (a Man-in-the-middle attack)
The RSA fingerprint above can be shared freely because it is simply a short version of the server's public key.
The contents of this Gist originate from the following sources: