Because there is no a security category is posted here.
About the ssh-keygen command to generate the pair of keys files is used the -t option. Now according with the man - noble (1) ssh-keygen.1.gz for the mentioned option it indicates:
-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
Specifies the type of key to create. The possible values are “dsa”, “ecdsa”,
“ecdsa-sk”, “ed25519”, “ed25519-sk”, or “rsa”.
I read a lot of tutorials using -t rsa but I found these posts too:
Both written at yr 2016 and because now we are in yr 2024 I am assuming that something could had been already changed. I mean a new type suggested and not mentioned at all in the 2 links shared above
Therefore having Ubuntu Server24.04 working with OpenSSH9.6p1 and assuming that Ubuntu Desktop 24.04 to be used as client uses the same version of OpenSSH to generate the keys files through the ssh-keygen command
Question
OpenSSH 9.6p1: What is the best key type for the ssh-keygen command through the -t option?
To be honest would be very nice add in the official OpenSSH page a table indicating for each release what key type should be used. Of course it as a suggestion. So far I only could find the following deprecation note at OpenSSH - Release 8.9 as follows:
ssh(1), ssh(8): since DSA keys are deprecated, move them to the
end of the default list of public keys so that they will be tried
last. PR#295
We just went through a bit of this at work when creating a new AMI for future instances on AWS. It seemed like the suggestion was to use ecdsa and not rsa. Something about rsa not being as hard to crack I think. Also, the key produced is a bit smaller. That really shouldn’t be a problem though.
Your question piqued my curiousity. I have been using key pair authentication for some years now. I used this command to generate the key pairs: ssh-keygen -t rsa -b 4096
When I would look at the /var/log/auth.log file I’d see messages about deprecated RSA keys. I didn’t know they were telling me about MY deprecated RSA keys, I thought it was related to unsuccessful login attempts by others.
SSH supports several public key algorithms for authentication keys. These include:
rsa - an old algorithm based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm may be advisable. It is quite possible the RSA algorithm will become practically breakable in the foreseeable future. All SSH clients support this algorithm.
dsa - an old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
ecdsa - a new Digital Signature Algorithm standarized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. We would recommend always using it with 521 bits, since the keys are still small and probably more secure than the smaller keys (even though they should be safe as well). Most SSH clients now support this algorithm.
ed25519 - this is a new algorithm added in OpenSSH. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable.
The algorithm is selected using the -t option and key size using the -b option. The following commands illustrate:
Just now I ran the command “ssh-keygen -t ed25519”, copied the public portion to the authorized_keys file on my server, disabled the prior RSA key, and was able to log in as before.
Although the article mentions that support for ed25519 is not yet universal I can say that it works with Ubuntu 24.04 LTS at both ends. The ed25519 public key is not very large. I guess the authentication is not based on factoring a large number but on some other mathematical property. More for me to read…
Some further reading revealed that ed25519 is considered equal in security to an RSA key of about 3000 bits. I had been using RSA keys of 4096 bits so they were, in theory, more secure. However, both ed25519 and RSA-4096 keys are currently unbreakable, requiring billions of years of crunching numbers to be solved.
ed25519 keys allow for faster authentication than RSA. I noticed that when I switched to ed25519, but it’s just a fraction of a second. Once authenticated, the connection is changed to a symmetric key cipher and the through-put is identical—it’s only the authentication step that is faster.
You need to generate a key pair on the host computer. The public key is the one you use to log in from the client computer. The private key should be used by the server to challenge the public key.
If memory serves me well, you could make it so that there’s public-key rotation after every n logins. I don’t know how this works, though.
@xahodo
Thanks, I was doing the ssh-keygen on the remote /client PC but putty would always show “permission denied”!! Is it easier to connect with another running Linux PC. Will this also work if I only have a root account on the LFS machine!!!
There is some option for ssh that allows you to turn off use of keys. If you set that it works like rsh used to… no keys or logins, it just drops you into a shell in the remote computer.
I will have to look up the option, hold on
I wanted to be able to connect to my home server from both within the home network as well as from the “outside world” via the internet.
I generated the key pair on the CLIENT computer and copied the public key portion into the file ~/.ssh/known_hosts on the SERVER. (I put the public key onto a USB stick and walked over to the server. If your server is not physically accessible you have to make the transfer before you turn off non-authenticated access.) The private key should be kept on the client machine only.
I don’t think this approach to authentication generates much overhead at all. There is almost no delay when I connect to my server while at home (much less than a second), a short delay when connecting from the other side of the US (two or three seconds), and a longer delay (five to ten seconds) when overseas. Once authenticated the connection is as fast as your internet access allows—the authentication process happens only once, at the initiation of the connection.
I have only ever had to setup keys in the client.
I have to confess that I dont understand keys with ssh, and for communication between local machines I dont see why they should be used,
Connecting over the internet is another matter… you definitely need secure connections there.
Any SSH connection would be encrypted. If on a local network, I don’t think it’s a security issue to just use a username and password. Over the internet, using keys would make it more secure than just a username and password. Mostly because people reuse passwords and there are always going to be hacks or leaks.
Even in the case of a local network, using a key would avoid typing in a username and password.
Not sure about LFS - but - I use keys all the time between all my Linux / NIX systems… I don’t use password authentication… I have some 12-15 Linux or UNIX machines - including MacOS and FreeBSD (TrueNAS)… My employer did something to my work MacBook (maybe via Falcon Crowdstrike?) and I can no longer SSH to it - but I can still SSH anywhere else, from it…
I really hate trying to use SSH keys with PuTTY - it’s awful… But I only need to do that sometimes to SSH from a Windows jumphost - I have a windows shortcut that loads pagaent.exe with my PPK SSH key… MobaXterm does most of that heavy lifting - but it’s very slow on one host, so if I need to quickly SSH somewhere without waiting for MobaXterm to load a new terminal tab - pagaent.exe and putty are quicker…