Skip to content

Instantly share code, notes, and snippets.

@free-pmx
Last active November 8, 2024 21:27
Show Gist options
  • Save free-pmx/7d7ea755b3b2c02baacb963814e9c11a to your computer and use it in GitHub Desktop.
Save free-pmx/7d7ea755b3b2c02baacb963814e9c11a to your computer and use it in GitHub Desktop.

Passwordless SSH can lock you out of a node

If you follow standard security practices, you would not allow root logins, let alone connections over SSH (as with Debian standard install). But this would deem your PVE unable to function properly, so you can only resort to fix your /etc/ssh/sshd_config 1 with the option:

PermitRootLogin prohibit-password

That way, you only allow connections with valid keys (not password). Prior to this, you would have copied over your public keys with ssh-copy-id 2 or otherwise add them to /root/.ssh/authorized_keys.

But this has a huge caveat on any standard PVE install. When you examine the file, it is actually a symbolic link:

/root/.ssh/authorized_keys -> /etc/pve/priv/authorized_keys

This is because there's already other nodes' keys there to allow for cross-connecting - and the location is shared. This has several issues, most important of which is that the actual file lies in /etc/pve which is a virtual filesystem 3 mounted only when all goes well during boot-up.

What could go wrong

If your /etc/pve does not get mounted during bootup, your node will appear offline and will not be accessible over SSH, let alone GUI.

NOTE If accessing via other node's GUI, you will get confusing Permission denied (publickey,password) in the "Shell".

You are essentially locked-out, despite the system otherwise booted up except for PVE services. You cannot troubleshoot over SSH, you would need to resort to OOB management or physical access.

This is because during your SSH connection, there's no way to verify your key against the /etc/pve/priv/authorized_keys.

NOTE If you allow root to authenticate also by password, it will lock you out of "GUI only". Your SSH will not work - obviously - with key, but fallback to password prompt.

How to avoid this

You need to use your own authorized_keys, different from the default that has been hijacked by PVE. The proper way to do this is define its location in the config:

cat > /etc/ssh/sshd_config.d/LocalAuthorizedKeys.conf <<< "AuthorizedKeysFile .ssh/local_authorized_keys"

If you now copy your own keys to /root/.ssh/local_authorized_keys file (on every node), you are immune from this design flaw.

NOTE There are even better ways to approach this, e.g. SSH certificates, in which case you are not prone to encounter this bug for your own setup. This is out of scope for this post.


NOTE All respective bugs mentioned above filed with Proxmox.

Footnotes

  1. https://manpages.debian.org/bookworm/openssh-server/sshd_config.5.en.html

  2. https://manpages.debian.org/bookworm/openssh-client/ssh-copy-id.1.en.html

  3. https://pve.proxmox.com/wiki/Proxmox_Cluster_File_System_(pmxcfs)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment