[SOLVED] Concern with ssh public keys

MaverickApollo · 04-24-2018, 03:56 PM

I've recently moved a server away from ssh passwords via PAM to certificate based authentication.

Uploading the id_rsa.pub files using ssh-copy-id, I thought what would stop anyone else knowing the username, create another certificate using ssh-key gen, uploading it to the server and gaining access?

Can anyone help me understand this potential risk?

MaverickApollo · 04-24-2018, 04:38 PM

I guess I just wasnt seeing it correctly, as you have to actually get the key on the actual server, without Passwords enabled, there is no way to log in, until you actually install the certificate by manual process on the target.

sundialsvcs · 04-24-2018, 09:44 PM

The SSH folks specifically talk about that concern here – https://www.ssh.com/ssh/keygen/#sec-...ires-Attention

Quote:

It is easy to create and configure new SSH keys. In the default configuration, OpenSSH allows any user to configure new keys. The keys are permanent access credentials that remain valid even after the user's account has been deleted.

In organizations with more than a few dozen users, SSH keys easily accumulate on servers and service accounts over the years. We have seen enterprises with several million keys granting access to their production servers. It only takes one leaked, stolen, or misconfigured key to gain access.

In any larger organization, use of SSH key management solutions is almost necessary. SSH keys should also be moved to root-owned locations with proper provisioning and termination processes. For more information, see how to manage SSH keys. A widely used SSH key management tool for OpenSSH is Universal SSH Key Manager.

Practically all cybersecurity regulatory frameworks require managing who can access what. SSH keys grant access, and fall under this requirement. This, organizations under compliance mandates are required to implement proper management processes for the keys. NIST IR 7966 is a good starting point.

Incidentally, this is one of the reasons why I use OpenVPN (with tls-auth) as the outermost bastion of my servers – restricting ssh and everything-else to users who have successfully passed that (cryptographically secured ...) gantlet. Unlike SSH, users can't manage their own certificates, and, also unlike SSH, credentials can be selectively revoked. If you can make it past the VPN, then you can see and use SSH, direct MySQL clients, and so-forth. Otherwise, you see absolutely nothing – no open ports, nothing that replies to you, nothing to attack or even try to attack. I discuss these ideas on my blog here.

Turbocapitalist · 04-25-2018, 03:36 AM

The key can be placed by another account using a properly configured sudo or even root.

If you're worried about people changing their keys you can relocate them the AuthorizedKeysFile directive in sshd_config on the server. The default is ~/.ssh/authorized_keys. You can make another directory for the keys which all accounts can read and place each account's authorized_keys file there, readable by the account but not writable.

Code:

sudo mkdir -m 755 /etc/ssh/authorized_keys/

sudo touch /etc/ssh/authorized_keys/apollo
sudo chgrp apollo /etc/ssh/authorized_keys/apollo
sudo chmod 640 /etc/ssh/authorized_keys/apollo

sudo touch /etc/ssh/authorized_keys/maverick
sudo chgrp apollo /etc/ssh/authorized_keys/maverick
sudo chmod 640 /etc/ssh/authorized_keys/maverick

# etc

Then load the files with the apropriate keys.

In the SSH daemon's configuration:

Code:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

SSH Certificates might be similar but are signed and so resistent to modification.