Gamefox642

Introduction into Ed25519

SSH Key - ed25519 和 主机安全那些事儿 背景. 最近实在受不了测试环境 40 台机器每季度过期密码 着急用测试服务器的时候登上去还要先改密码，有些人改密码也不知道通知一下。就烦死了。 然后打算用 SSH Key 来统一登录测试环境，root 密码每天自动更改一次。. Public key Ed25519 Elliptic Curve Cryptography SSHD (Secure SHell Daemon) is the server-side program for secure remote connections cross-platform developed by none other than the OpenBSD team. However, not all SSH sessions are created equal.

OpenSSH 6.5 added support for Ed25519 as a public key type. It is using an elliptic curve signature scheme, which offers better security than ECDSA and DSA. At the same time, it also has good performance. This type of keys may be used for user and host keys. With this in mind, it is great to be used together with OpenSSH. In this article, we have a look at this new key type.

DSA or RSA

Many forum threads have been created regarding the choice between DSA or RSA. DSA is being limited to 1024 bits, as specified by FIPS 186-2. This is also the default length of ssh-keygen. While the length can be increased, it may not be compatible with all clients. So it is common to see RSA keys, which are often also used for signing. With Ed25519 now available, the usage of both will slowly decrease.

Configuring the server

The first thing to check is if your current OpenSSH package is up-to-date. You will need at least version 6.5 of OpenSSH.

Create SSH host keys

Change SSH configuration (server)

Next step is changing the sshd_config file. Add the new host key type:

HostKey /etc/ssh/ssh_host_ed25519_key

Remove any of the other HostKey settings that are defined.

Client Configuration

After configuring the server, it is time to do the client. We have to create a new key first. Make sure that your ssh-keygen is also up-to-date, to support the new key type. Note: the tilde (~) is an alias for your home directory and expanded by your shell.

Optional step: Check the key before copying it.

ssh-keygen -l -f ~/.ssh/id_ed25519

If that looks good, copy it to the destination host.

ssh-copy-id -i ~/.ssh/id_ed25519.pub michael@192.168.1.251

Then determine if we can log in with it.

$ ssh -i ~/.ssh/id_ed25519 michael@192.168.1.251 Enter passphrase for key ‘~/.ssh/id_ed25519’:

When using this newer type of key, you can configure to use it in your local SSH configuration file (~/.ssh/config). Defining the key file is done with the IdentityFile option.

Host [name]
HostName [hostname]
User [your-username]
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes

Insight: using -o

Normally you can use the -o option to save SSH private keys using the new OpenSSH format. It uses bcrypt/pbkdf2 to hash the private key, which makes it more resilient against brute-force attempts to crack the password. Only newer versions (OpenSSH 6.5+) support it though. For this key type, the -o option is implied and does not have to be provided. Also, a bit size is not needed, as it is always 256 bits for this key type.

Are you already using the new key type? Or other tips for our readers? Leave a comment.

A couple years back we wrote a guide on how to create good OpenPGP/GnuPG keys and now it is time to write a guide on SSH keys for much of the same reasons: SSH key algorithms have evolved in past years and the keys generated by the default OpenSSH settings a few years ago are no longer considered state-of-the-art. This guide is intended both for those completely new to SSH and to those who have already been using it for years and who want to make sure they are following the latest best practices.

Use OpenSSH 7 or later

Related to SSH keys there have been some relevant changes in versions 5.7, 6.5 and 7.0. Latest version is 7.9. You should be running at least 7.0. Current Debian stable (“Stretch”) shipped version 7.4 and for example Ubuntu 16.04 (“Xenial”) shipped 7.2, so nobody should be running on their laptop any later versions than these.

Generate Ed25519 keys

With a recent version of OpenSSH, simply run ssh-keygen -t ed25519. This will create a private and public key pair files at .ssh/id_ed25519 (and .pub) using the Ed25519 algorithm, which is considered state of the art. Elliptic curve algorithms in general are sleek and efficient and unlike the other well known elliptic curve algorithm ECDSA, this Ed25519 does not depend on any suspicious NIST defined constants. If you encounter a server that is very old and does not support Ed25519 keys, you might need to have a more traditinal RSA keypair. A strong 4k RSA key pair can be generated with ssh-keygen -b 4096. Hopefully you won’t need to ever do that.

Ssh Ed25519 Key Size

Running ssh-keygen will prompt for a password. If your laptop is encrypted and well protected you can omit the password and gain some speed and convenience in your SSH commands.

Store the private key securely

Hopefully your laptop is well protected with full disk encryption etc and you can trust that nobody else than yourself has access to your /home/<username>/.ssh directory. Hopefully you also have securely stored encrypted backups of your laptop so that you can recover the .ssh directory if your laptop for any reason is lost or broken.

The SSH keyfiles are stored as armored ASCII, which means that you could even print them on paper and store the printed key in a real vault just to be extra sure you never loose your private key (.ssh/id_ed25519).

The public key is indeed designed to be public

The public key .ssh/id_ed25519.pubon the other hand is meant to be public. Here is mine for example:

You can find a lot of public SSH keys for example on Github using the URL https://github.com/<username>.keys. You may also want to check out the excellent Github SSH usage docs.

This public key is the one you will distribute to remote servers. Place them on the remote server in the .ssh/authorized_keys file. The servers you try to access will use the public key to create a challenge, and only your laptop that has the private key pair can solve that challenge, and thus authenticate that your connection to the server is authorized.

Generate Ssh Key Ed25519

On Linux machines a shorthand to copy your SSH key to a remote server is to run ssh-copy-id remote.example.com. This will ask for a password on the first time, but once the key is in place, a SSH keys will be used instead and no password is asked anymore.

Best practices

Once you are familiar with SSH key usage basics, please adopt these policies:

• Disable password authentication on the SSH servers you control altogether. The less there are passwords, the less there as ones that can leak or be forgotten etc. For passwords less is indeed more. Only use keys for authentication on SSH connections.
• Use a separate key per client you SSH from. So don’t copy the private key from your laptop to another laptop for use in parallel. Each client system should have only one key, so in case a key leaks, you know which client system was compromised. If you stop using your old laptop and start using a new one it is naturally another case and then you can copy the key.
• Avoid chaining SSH connections. Any system that is used for chaining SSH connections incurs a potential man-in-the-middle situation.
• For the same reasons try to avoid X11 forwarding and agent forwarding. Consider putting these in your .ssh/config:

Using ProxyCommand

You shouldn’t forward SSH agent (ssh -A), but it’s ok to use ProxyCommand or ProxyJump. You can permanently configure it in your .ssh/config like this:

Stay vigilant

If running ssh remote.example.comyields some error messages, don’t ignore them! SSH has an opportunistic key model, which is convenient, but it also means that if you are confronted with warnings that the connection might be eavesdropped you should really take note and not proceed.