The following process may take some time, depending on the number of server you connect to and where your public keys are stored. It is advisable to make a backup of both your id_rsa and id_rsa.pub files right now.
Generate a new ECDSA key
ssh-keygen -t ecdsa -b 521 -C "[email protected]"
- The -t ecdsa part tells the ssh-keygen function (which is part of OpenSSL), which algorithm to use. In contrast to ecdsa you may also use ed25519 for using Curve25519, but for better compatibility, stay at ECDSA.
- Notice, that despite being located in the binary world, we do not use 512 as the key length, but 521, specified by -b 521. Reason is the mathematical structure of the key, which does not adhere to the power of two.
- Optionally, you can add a comment with the -C flag. An email address can be a useful piece of information to add.
Saving the key and setting a passphrase
After hitting enter the program will ask you for the location of the newly generated key. If you have no previous ECDSA key in your .ssh folder, you may skip this because the keygen will name the new key id_ecdsa in contrast to id_rsa for RSA keys.
The next thing you do is specifying a passphrase. If you set your passphrase, the keygen will do its magic. The output should look similar to this:
Generating public/private ecdsa key pair.
Enter file in which to save the key (/Users/kg/.ssh/id_ecdsa): ./id_ecdsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./id_ecdsa.
Your public key has been saved in ./id_ecdsa.pub.
The key fingerprint is:
SHA256:Hp34bIvFV1lpCLkjnkganWYIqDGUtCgbvwLb/1K+6oU [email protected]
The key's randomart image is:
+---[ECDSA 521]---+
|ooo .. |
|+o.. .. . .|
|=+ . o . .. o.|
|o+ o * + + .o |
|o . * S = . o |
|.o . o.o B . |
|o o Eo. . * . |
| . .... + o |
| .++o.. . |
+----[SHA256]-----+
Pushing the new key to your servers
The command to push your new SSH key to your server comes pre-installed with OpenSSH:
ssh-copy-id -i ~/.ssh/id_ecdsa [username]@[hostname]
Specify the used key (-i ~/.ssh/id_ecdsa
) and your SSH credentials ([username]@[hostname]
), and the command should automatically copy the public key to the server. Try to login to the server using the new key to check if it's working correctly: ssh -i ~/.ssh/id_ecdsa [username]@[hostname]
A more manual way, of course, is to manually login to the server and past the content of the public key into the authorized key file.
Configure SSH to use your new key
We want to tell SSH that it should use the new key by default. The main problem here is, that SSH assumes that you have an RSA key set and uses it if one was found.
The most suitable way to do this, is to use the standard SSH config. It’s usually located at ~/.ssh/config
. In that file you can specify either global settings which will then be applied to all SSH connections, or settings per host. You can also create aliases for your connections, to reduce something like [email protected]
to companyssh
.
At the very top, if not present already, add the following lines:
Host *
IdentityFile ~/.ssh/id_ecdsa
The first line tells SSH to apply the next settings to all hosts, hence the wildcard *. The second line then sets the newly generated key ~/.ssh/id_ecdsa
as the new identity. When connecting to an old server that does not yet have the new key, add the -i ~/.ssh/id_ecdsa
flag to your SSH command: ssh ~/.ssh/id_ecdsa [username]@[some-old-server]
.
PS for all macOS users: to prevent macOS asking for the key passphrase every time you use the key, add UseKeychain yes
to the global settings in your SSH config. Linux users may use ssh-agent.
Conclusion
Despite being a pretty long blog post, you essentially have to run only a couple commands to create your new key, push it to your servers and then configure SSH to use the new key.