We implemented ssh-key based authentication. But what happens now is that when we add a new user, we need to edit the sshd_confif file, set PasswordAuthentication=yes which allows the new user to upload the new user's public keys to /home/userX/.ssh. Then I restart the ssh service. In our case, the users are in different locations, and we don't know when they will upload their keys. That means, we make our servers "vulnerable" during that time, with only the password to rely on.

After the new user uploads his/her keys, we then set PasswordAuthentication=no and restart ssh service.

Some existing users who did not upload their keys before the transition (from password based to key based authentication) also now want to upload their keys, which again means we need to "open" the server for them so that they too can upload their keys.

I am sure sysads have managed hundreds and hundreds of users, if not thousands, smoothly, but how do they do it without this kind of interruption? Is there anyway to automate this process? For example, could I do something like:
(1) use key based authentication for users who have already uploaded their keys
(2) If new users are added, or for the existing users who have accounts, but who have not uploaded keys, let them copy their keys with regular password (for example, using ssh-copy-id), so that we do not make our system vulnerable by "opening" it.

(3) No need to edit sshd_config file and restart the ssh service each time.

Or... is it unavoidable?

Hi

have the new user email the admin their public key and then the admin puts the public key in the users ~/.ssh/authorized_keys file.

Evo2.

P.S. Need to be careful to set the correct ownership and permissions of ~/.ssh/authorized_keys. A simple shell script makes it easy.

P.P.S. A weakness of this method is that if the users email is hijacked an attacker will be able to get control of their account on your system.

Getting the public key from the user and adding it via a script, like mentioned above, is one option.

Another option with more steps but more flexibility would be to use SSH certificates. Those are basically signed keys. They are apparently widely used in large scale deployments but rather little is written about them so far, at least it's not easy to find, but there is still something:

• If you’re not using SSH certificates you’re doing SSH wrong
  
• OpenSSH certificates
• Using SSH certificates
• 8.3.5.2. Creating SSH Certificates for Authenticating Users

One advantage is that you can put expiration dates on the keys.

1 members found this post helpful.

evo2, Turbocapitalist

Ok. So some manual intervention can't be helped then...

T., I will read and see if we can use the ssh-certificates.

Thanks you two!