Is RSA sunsetting already on the roadmap for PVE?
- Thread starter esi_y
- Start date
How does that work in general in production (outside of the cluster)? Do you distribute changed keys automatically to all clients and put them somewhere in /etc/ssh?
Generally (not taking into account PVE specifics at all here), I would suppose you want to use (from different account ideally)
ssh-copy-id of the new keys some time before the old ones "expire", then wipe the old ones when the time comes.I say generally, because I do not really do it. Not that it's undoable, but OpenSSH does not support what it should [1] to make this not a chore (having to run own scripts). What I use are SSH certificates, you can have them expire automatically. But I am almost worried to mention it here on the forum because I am currently trying to bring the understanding into pve-devel SSH discussion on this, when I do not have any horses in the race, i.e. I am happy if PVE goes juggling around individual keys and all that if that's considered less error-prone or more maintainable.
EDIT: I just find it crazy we all are used to e.g. browsers turning down old SSL certs like it was a serious business but people running 10 year old SSH keys on their servers on sudoers accounts with lame passwords.
[1] https://www.rfc-editor.org/rfc/rfc4819.txt
Last edited:
@LnxBil So that you do not say I am pitching SSH certs, I know of some people who use the comment at the end of the lines in 
authorized_keys to store an imaginary expiry piece of info, then cron/systemd.timer it to periodically weed out the old ones. Which is why I said, have more accounts there.