Passwordless authentication is often desirable, for instance when setting up scheduled sftp jobs, or just making remote logins smoother. And in the SSH world, public key authentication is a simple and efficient way to do that. But is it really usable in an enterprise environment?
When running with the default configuration, most SSH servers look for authorized login keys under a user’s home directory. Provided that the users have a shell and write access to their own home directory, they will be able to set up public key authentication by themselves. It works immediately, and there’s no need to hassle the IT folks – it’s a time-saver for everybody, a win-win, right? In the academic world of universities and campus networks – the world where SSH was born – that tends to be right. In a large scale enterprise with strict compliance regulations and audit requirements, that may not be the case. The trend is to lock down the user keys and only allow administrators to add new keys and remove old ones. This means copying the keys from the home directories to a root-owned location, testing that the keys work, and changing the SSH server configuration to look for keys in the new location.
A couple things to keep in mind when locking down the keys:
1) The keys need to be tied to individual user accounts. In practice this means that the new location should have user specific subdirectories, for instance, /etc/ssh/userkeys/username where username is the actual username that is allowed to be accessed with this key. In the SSH server configuration, the location of the authorized keys needs to contain a variable token that is substituted during the login process with the actual username of the user that is being authenticated. In OpenSSH, for example, this would mean configuring the server with the following setting: AuthorizedKeysFile /etc/ssh/userkeys/%u/authorized_keys
2) Keep the user permissions to minimum. The point of the lockdown is that users will not be able to modify the keys. The files and directories need to be owned by root, and writable to root and nobody else. Because the authentication process is done with user privileges, the users do need read access to their public keys. To keep things simple, in a typical Unix environment this often means giving global read access to the authorized key files. As the premise of public key authentication is that public key data can be shared openly, this is usually considered an acceptable tradeoff for the control of the keys. If this is a concern, group permissions or ACLs can be used to narrow down the read permissions, but the added complexity may increase the maintenance effort too much to be worthwhile.
But let’s not get too carried away with the technical details; we need to keep in mind the old adage that security is a process. How much of the process is manual work and how much is automated, how the process interacts with other processes, and how the process keeps flowing years down the road – there are many things to think through when finding the right solution. Managing keys manually may be the most efficient way in small environments. In large environments with lots of legacy keys, a tool for automating the boring parts of the process may be what is needed to keep the key management process rolling.
Live SSH Key Remediation Webinar, Presented by SSH
On the 27th February 2013, SSH are running a live webinar discussing the topic of SSH Key Remdiation. This case study focused webinar will demonstrate how a major top 10 international bank engaged SSH Communications Security’s technical deployment team to remediate their secure shell environment after failing an audit. SSH helped this customer discover more than 1 million legacy keys across 10,000+ hosts and begin the process of bringing their environment into compliance while enhancing their security posture. If Legacy Keys are a concern in your organisation, then this unique, interesting and informative webinar is for you.
Guest Blog by Jan Hlinovsky, SSH Communication Security Corporation