Enable ed25519 SSH Keys Auth on Ubuntu 18.04

By now, you probably know you should be using keys instead of passwords. This article details how to setup password login using ED25519 instead of RSA for Ubuntu 18.04 LTS.

Why SSH Keys Are Needed

A key is a physical (digital version of physical) access token that is harder to steal/share. We use keys in ssh servers to help increase security. Keys also make brute force attacks much more difficult.

Why ED25519 instead of RSA

ED25519 has been around for several years now, but it’s quite common for people to use older variants of RSA that have been proven to be weak. It is generally considered that an RSA key length of less than 2048 is weak (as of this writing). ED25519 is a better, faster, algorithim that uses a smaller key length to get the job done.

By upgrading to better security now, you are more prepared for future security threats.

Check the Strength of Existing Keys

To check the key length, you need to use the ssh-keygen command as follows:

If you see RSA “1024” instead of RSA “2048” you should regenerate your keys to at least RSA 2048. Hopefully your organization will also upgrade all the way to ED25519 and fall back to RSA 2048 or RSA 4096 for compatibility.

What Could Break if you Upgrade SSH Keys

SSH Login

Your logins could simply stop working if you do the upgrade wrong. For this reason, make sure you have local access and backup any files you edit. You can also add ED25519 and continue to use RSA as you upgrade your clients.

Incompatible SSH Key Exchanges

In some legacy systems, you simply cannot use the updated technology. If you are doing production work on systems this old though, you have other security concerns to worry about as well!

Basics of SSH KEY on the Client

Here is a simplified overview of what the rest of the article will cover:

• Generate Keys on the client
• Copy the PUblic Key to Server
• Use Private Key to Encrypt Login to Server
• Server uses Public Key to verify

Server Setup to Use SSH Keys

• Generate Keys
• Specify allowed Key Exchange, and Encryption methods
• Specify a bunch of other stuff while you’re at it
• Test the connection

---

On Server, Backup SSH Settings/Keys

This assumes default locations and/or files!

On Client, Backup SSH Settings/Keys

You will have to perform these actions as root.

Verify SSH Keys Exist on Client and Server

If they exist, they will be in the ~/.ssh/ folder most likely. It is possible for a key to exist in a different directory too. The client config for ssh would probably list their alternate location if that was the case (but it’s probably not).

Client Example of Cygwin SSH Key Files and Permissions

You will have similar files on whatever your client is, but this is what Cygwin on Windows looks like:

On Client, Generate ed25519 SSH Keys

If the keys do not exist, you’ll need to generate them. This will create a private key file (which should be guarded). You’ll need to generate the keys for your client to offer key exchange to the server. The command on the client is:

-f

Specifies filename of the keyfile, used for specifying other than default name

-a

number of primality test while screening DH-GEX candidates

-t

type of key (RSA, ED25519, DSA, etc)

-C

Comment (not used in algorithm, only used in public key)

-o

openSSH key format instead of older PEM (needs OpenSSH 6.5+)

On Server, Make Directory and Set Permissions

On Client, Copy Public SSH Key to Server

ssh-copy-id is the preferred way. If you cannot ssh into the machine, you probably also cannot ssh-copy-id into it.

If for some reason you cannot ssh-copy-id, you can also pipe it through ssh, or simply paste the id_xxxx.pub file contents at the bottom of the ~/.ssh/authorized_keys file. Here is how to do it via ssh pipe:

Here is an example .pub file:

You just need to update the authorized_keys file on the server with the client .pub contents at the end of it and save it. You will need

Generate Keys on Server if They Don’t Exist

These are actual hostkey fingerprint files. We are going to remove the old ones, generate new ones, and then eventually restart sshd (not yet) to activate them.

Known Host Error

Regenerating ssh keys will cause the client to have an error message about known hosts. You simply remove the old fingerprint on your client and try again. This changes the fingerprint of the server, so the error is valid.

We are going to generate both RSA and ed25519 so we can choose great security, or fall back to lesser security for compatibility.

Remove Small Diffie-Hellman Moduli

If you use the RSA method, we want to make sure it doesn’t do a DH handshake with a weak key, so remove any weak keys:

On Server, Disable DSA and ECDSA HostKeys

We are going to comment out dsa and ecdsa as both are not good for security.

On Server, Enable ed25519 HostKey

In the same sshd_config file we will enable rsa and ed25519 for hostkey

Example SSHD_CONFIG File

Here is our final config and the references we used to build it. Do not copy and paste this config, it will not work for you. Understand what each section does!

Restart the SSH Server

WARNING!! It is advisable to have two shells running. One one shell, ssh in and edit your files. On the other shell, test login after you have done edits. It’s possible one of your changes will lock you out of SSH. Make sure you have some type of out of band management!

Once you restart ssh, you have a chance of not getting back in until you copy the backups back and figure out what was wrong.

Test Key from Client to Server

After you’ve restarted the sshd server, go ahead and try to manually use the key. Later, if it’s the only key found in ~/.ssh/ it will choose it by default and the -i flag is not required.

---

Troubleshooting SSHD Key Problems

Your /etc/ssh stuff will be owned by root and readable something like what is below:

Verify Server Key Permissions

Verify SSH Key File Permissions on Cygwin Client

Your client files will be owned by the user, and owned something like what follows (Cygwin Example):

Verify SSH Key File Permissions on Server

This server example has an rsa and ed25519 key as it accesses several other servers.

Troubleshoot SSH Service

Debug Your SSH Connection

This is a snippet of code with the important parts shown from a client connecting to the server. The logs are showing on the client screen.

• ssh protocol
• key exchange and encryption info: algorithm, cipher, MACs, etc
• server, port

-vvv gives even more info and might be worth looking at if you cannot login.

Further Secure Your SSH Connection

You will want to follow standard OS hardening guides and use a Firewall to Protect SSH. This article focused on using ed25519 and stronger types of RSA encryption than what we are seeing most people use.