Generating Keys with OpenSSH
%25define=note block bgcolor=lightblue color=black margin-right=5em margin-left=5em padding=1em overflow=auto %25
%25define=info block bgcolor=lightgrey color=black margin-right=5em margin-left=5em padding=1em overflow=auto %25
%25define=warn block bgcolor=yellow color=black margin-right=5em margin-left=5em padding=1em overflow=auto %25
%25define=alert block bgcolor=lightpink color=black margin-right=5em margin-left=5em padding=1em overflow=auto %25
%25define=commands block bgcolor=black color=white margin-right=5em margin-left=5em padding=1em overflow=auto %25
%25define=config block bgcolor=darkgrey color=white margin-right=5em margin-left=5em padding=1em overflow=auto %25
%25define=example block bgcolor=lightgrey color=black margin-right=5em margin-left=5em padding=1em overflow=auto %25
Generating Public/Private Keys
For additional security, you can use a public/private key pair to login. If you disable password authentication, your ?sshd setup will be more secure.
Keys can be generated with ssh-keygen. In the next example, we use the ED25519 algorithm:
$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/username/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/ssh/id_ed25519
Your public key has been saved in /home/username/ssh/id_ed25519.pub
The key fingerprint is:
...
The private key will be stored in id_ed25519.
%25warn%25*WARNING*: Never share the private key# You should set a passphrase; especially if your key has wheel access on machines. This is annoying and seems counter intuitive given one of the reasons for using a key for ssh is to avoid needing a password, but the consequences of not setting a passphrase is that a compromise on one account leads to a compromise of every machine that key has access to. Setting a passphrase means you only have one password to remember and its the same for all the machines your key grants you access to.
%25note%25*NOTE*: When you provide a passphrase, make sure to write it down securely. WARNING: If you lose the passphrase, the key becomes worthless# See ?Password.Management for a simple way to manage passwords from a linux/openbsd command line. See ?Password.Schemes for ideas on how to create good passwords that are easy to remember. Passwords you use frequently tend not to be forgotten.
Save the key fingerprint and image art to a file; you will use it for verifying the key later.
NOTE: You can use ssh-keygen for other keys like RSA or ECDSA keys:
$ ssh-keygen -t rsa -b 4096 -o -a 100
$ ssh-keygen -t ecdsa -a 100
For this article, we assume you generated an ED25519 key. Now, read the public key, ~/.ssh/id_ed25519.pub:
$ cat .ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEKKJaexpzvheOmsc+Pv1ekn294Beug2tHgGoYjuXqFk username@example.com
Copy this line.
In another terminal, connect to your server with a password as usual.
On the server, add that ssh public key to the end of ~/.ssh/authorized_keys on the server.
To verify that you can now login by private key, log out by typing ctrl+d, then login again:
$ ssh username@example.com
If your private key has no passphrase, you should login without typing any passphrase.
If your private key has a passphrase, your ssh client will prompt you with:
Enter passphrase for key '/home/username/.ssh/id_ed25519':
Type in the passphrase. Afterwards, you should login without typing your normal user password.
%25note%25*NOTE*: The key passphrase is not the same as the normal user login password for the machine you are connecting to. If your SSH keys have been configured properly, ssh should never ask you for your normal user password. Its best not to use your passphrase as a password anywhere else. A compromise of passwords on another service could lead to a compromise of your certificate also. See ?Password.Schemes for ideas on how to create good passwords that are easy to remember.