Obviously I could scp the key to every host the user needs SSH access to. But if there are many hosts this could take a long time. Especially if public key authentication is not set up yet, every scp would require me to input a password. This could be very time consuming and annoying.

Would using auto mounted home directories solve this problem? Because then every host would use the same home directory for each user, public keys would only need to be copied once. This doesn't seem right however. Can someone give me advice?

  • Ansible might be a good way to go.
    – DopeGhoti
    Commented Oct 9, 2017 at 17:40
  • I think you're right Commented Oct 9, 2017 at 17:43

3 Answers 3


There are a bunch of ways to do this, especially if you're on recent versions of OpenSSH. Remember also that you need more than a way to add them, you need a way to remove them (and quickly—consider if the key is compromised, the person parts on bad terms, etc.). A key addition that takes a day to propagate is an annoyance; a key removal that takes a day to propagate is a serious security concern.

Keeping in mind the importance of removal being easy, that suggests a few approaches:

  1. It sounds like you already have some way of creating the users quickly. There is a good chance that's LDAP, for example. LDAP can store SSH public keys, and you can hook this in to sshd using the configuration option AuthorizedKeysCommand. For example, if you're running SSSD, sss_ssh_authorizedkeys is intended for that. (See, e.g., RedHat docs on SSSD authorized keys). Key addition and removal can be instant, worst case is typically a few seconds for LDAP propagation. You can very likely fully automate this (and if you have a bunch of users probably already have!), requiring no admin intervention.

  2. If your servers must handle authentication offline (and beyond what SSSD can do), another approach is to use the certificate authority (CA) support in OpenSSH. This is documented mostly in the ssh-keygen manpage’s “Certificates” section. Basically you set up your servers' sshd to trust your CA and to automatically fetch update revocation lists. Then you sign the client's public key with said CA and give the cert to the client. At that point, the client can log in to all the servers using said cert. To un-authorize the client, you add it to the revocation list (as explained in the immediately following section in the man page). Key addition is instant, removal depends on how often you update revocation lists. Unfortunately there isn't anything like OCSP for SSH CAs. Automation (without admin help) of adds is possible to do securely; of removes is easy.

  3. You could—as you suggest—use shared, auto-mounted (or permanently-mounted; auto-mount is not required) home directories so all servers see the same ~/.ssh/authorized_keys — but this is a lot of overhead if you otherwise don't need a shared $HOME. Key addition and removal are instant to fairly quick, depending on caching. Key management likely entirely done by the user, not an admin.

    3b. Ulrich Schwarz points out that you can change the location of the user's authorized keys file; it doesn't need to be ~/.ssh/authorized_keys. So you could share a directory containing all users' authorized keys files, and not have the overhead of fully shared home directories.

  4. You could use your configuration management tool like @DopeGhoti suggests. Be very careful not to forget about a host—especially one where the key was manually added. Probably means key addition and removal will require manual intervention by the admin.

  • There is, at least in principle, a variation on 3 where the users' authorized_keys are not under their own control (or at least not in their ~), so you'd only share a single directory containing all those files between the servers. Commented Oct 9, 2017 at 19:06
  • @UlrichSchwarz good point, edited in.
    – derobert
    Commented Oct 9, 2017 at 19:09

Ansible is a free ssh-based solution for remote system administration designed to run a given command (or playbook) on a configurable set or subset of hosts; for something as simple as distributing secure shell keys, this would probably be a low-lift option.


Create file with hosts:

$ vim server.list

Install sshpass:

# apt-get install sshpass

Create simple script for ssh copying:

$ vim script.sh
while read -r line
    echo "running $line"
    sshpass -p sshPassword ssh-copy-id userName@$line -o "StrictHostKeyChecking no"
done < "server.list"

Run script:

$ sh script.sh
running server1.ru
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1
running server2.ru
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .