Comments on: SSH Key Best Practices for 2025 – Using ed25519, key rotation, and other best practices

By: Vilius Šumskas

Vilius Šumskas — Fri, 06 Mar 2026 12:53:42 +0000

Great article! I think you could expand it a little bit in regards to key creation strategy, e.g. should individuals create only one key or should they be created per one individual per their device.

Regarding cloud providers, I don’t know AWS that much, but at least on Google Cloud there is what they call “OS Login”. It basically manages SSH keys for you, rotates them, etc., and then automatically provides the keys to VMs during login. Special lean binary (which acts as an SSH plugin) lets you in. Of course, this assumes that you trust Google with your private keys. On other hand, they probably could log in into VMs running on _their_ infra without you anyway 🙂

By: Andy Barr

Andy Barr — Fri, 05 Dec 2025 12:53:48 +0000

What a brilliant article, really enjoyed reading this and the part about the comments and dates is a great idea!! Two years are just coming up for my keys, so will be rotating them very soon in the new year. Now I have to remember where I have pushed out the public key to!!

Just going to do a quick search to see if you have an article on securing the SSH Server setup as this would make my life complete!!

By: Brandon

Brandon — Thu, 23 Oct 2025 01:53:55 +0000

In reply to James French. Thanks for your explanation James. What you mentioned about signing host keys might make this worth me figuring it out

By: Brandon

Brandon — Thu, 23 Oct 2025 01:50:15 +0000

In reply to Richard. Thanks Richard, I've made this more clear

By: Stuart Whitmore

Stuart Whitmore — Sat, 19 Jul 2025 22:36:43 +0000

Very helpful. I’m not tech-clueless and have decades of development experience, but for me SSH key management has always been… poorly managed, to put it nicely. Basically following beginner instructions hastily whenever needed without ever really taking the time to think through what I was doing, etc. I understood the public/private key part but didn’t make the effort to optimize my key handling. Sloppy, I know. Anyway, this article brings me to a higher level where I can make more reasoned choices and actually manage what I’m doing. Much appreciated.

By: Richard

Richard — Tue, 15 Jul 2025 16:43:35 +0000

Thank you Brandon – excellent article.
A minor typo perhaps? I understood it, but this may be clearer.

“rename it from newkey and to newkey.pub a more meaningful name”

Could read:
rename the keypair: newkey and newkey.pub to a more meaningful name. eg to app_xsftp2_cust1 and app_xsftp2_cust1.pub

or similar.

regards, Richard

By: James French

James French — Mon, 14 Jul 2025 03:38:12 +0000

SSH Certificates are very much worth the afternoon it takes to learn how to use them, even for a single user or small team. For user keys you deploy the CA public key to your servers (either globally or per-user).

Sign your public keys with an expiry, and then they’re trusted until they expire. No managing authorized_keys files any more. Key rotation is even easier, as you just generate a new key, sign it and discard the old one. Eliminates the risk of an old key being left behind somewhere.

I also sign my host keys (with a different cert) and my clients trust that cert. That solves two problems – it eliminates the ‘trust on first use’ issue and secondly it allows you to rotate your host keys regularly as well. Since the clients are checking for a valid signature, not the exactly public key so it stops the host-key changed issue.

I’ve just got an Ansible play that replaces and signs host keys which I run periodically. Has basically become a zero effort task.

By: Brandon

Brandon — Thu, 06 Mar 2025 15:32:41 +0000

In reply to Philip Ingram. Philip, I haven't been converted to the ways of SSH Certificates yet. Keys have served me well thus far. Perhaps in a larger organization they would make sense, but I work mainly on my own and small technical teams

By: Brandon

Brandon — Thu, 06 Mar 2025 15:29:12 +0000

In reply to Charles Hedlin. Thanks for the clarification Charles. I'm not sure of the exact mechanics how that works, but knew something bad was possible

By: Charles Hedlin

Charles Hedlin — Wed, 05 Mar 2025 16:26:58 +0000

Thank you for the helpful article. Your statement on SSH Agent forwarding allowing an attacker to intercept the private key is incorrect. It will only provide temporal access to the USE of the private key. The request is forwarded to the agent to be signed with the private key, the agent never exposes it.

So there is definitely a risk. An attacker could use your private key to access another host as you, and install whatever backdoors they want on that host. But they won’t have your private key.