I'm starting to administer a new Mac Mini as a server for my office. We would like to be able to SSH into the machine but do not want password authentication enabled long-term, favoring strong public key auth.

ssh-copy-id still requires a password to operate, at least the first time. Is it possible to disable password authentication on a per-account basis if a public key is associated with the account?

Alternatively, is there an automated (as in: I don't have to check my email) way to install those public keys that doesn't involve a user-set password, uses a one-time password, etc.?

  • 1
    It's not clear to me what your question is about. For a), you really can enable/disable password auth on a per-user basis in sshd_config. Is your Q about that? For b) you don't need the ssh-copy-id script; you can just append the public key to the user's ~/.ssh/authorized_keys by other means.
    – user313992
    Commented Aug 30, 2019 at 10:18
  • Also, sshd_config offers different ways to manage the authorized keys centrally instead of via ~/.ssh/authorized_keys files inside each users home dir.
    – user313992
    Commented Aug 30, 2019 at 10:33
  • Any automated method is going to open a huge can of security worms. You could do it from procmail, but you'd want to verify that the key was really sent by the user (e.g. require the user to have a known gpg key to send a signed email, for procmail rule to verify the signature - shifting the keys problem from ssh to gpg). Or you could set up a web app system for users to log in and upload a key. but then you'd have to hope that your web app didn't have any exploitable holes (and remember, some of it would have to run as root in order to install authorized_keys in the users' home dirs)
    – cas
    Commented Aug 30, 2019 at 11:02
  • in short, for a single server in a single office, the most viable/practical answer is make the users install their keys (and accept that you'll probably still have to do some manually. bosses in particular are resistant to doing stuff they don't see as being important). The time and effort required to build, test, secure (hah! :-), and maintain a custom automated system for this vastly exceeds the time and effort in making the users do it and doing some manually when you have to.
    – cas
    Commented Aug 30, 2019 at 11:06
  • @cas - well, sure. But if a ready-made solution were available and all I had to do was install it... Commented Aug 30, 2019 at 17:48

2 Answers 2


You could use a config-management-system such as Ansible or Puppet.

Having used both, I think Ansible is easier to learn for an Ops-Guy. The authorized_key module is straightforward to use.

  • 2
    You don't use either ansible or puppet to manage just one machine. It would be overkill for the task, and hours or more of work setting it up. and even if the OP doesn't care about that, this answer still doesn't provide any automated way for the OP to get the keys from the users. They'd still have to manually enter them into the ansible or puppet config, which is not much different than manually editing/creating ~/.ssh/authorized_keys for each user.
    – cas
    Commented Aug 30, 2019 at 10:51

You asked "Is it possible to disable password authentication on a per-account basis if a public key is associated with the account?"

Unfortunately, sshd_config doesn't have any option to do that. Maybe you could submit a wishlist bug report asking for the feature (but first check whether the "bug" has been submitted before). Don't expect a positive - or quick - response.

In the meantime, you could announce a cut-off date sometime in the future (at least a month) when password authentication will be disabled, and that users will need to install a public key before then.

Put the same message in /etc/motd too, so they get reminded every time they log in. Provide at least a link to a web page with instructions for a) generating a public/private key pair on various common platforms, and b) various methods of installing a public key into ~/.ssh/authorized_kets on your mac mini server.

If you wanted to do some really evil nagging about it, you could set up a cron job to expire the passwords of every non-system user who doesn't have a ~/.ssh/authorized_keys file, forcing them to change their password every time they log in. Not recommended in anything even resembling a professional environment, but possibly OK for a short time on a home server where the users are slack family/friends.

  • Re first sentence, it’s extremely unclear what is the “that” which sshd config doesn’t have an option to do. It doesn’t help that the question itself lumps several things together, but you exacerbate that by not stating which you are answering.
    – Wildcard
    Commented Sep 3, 2019 at 11:07
  • the "that" is the OP's question Is it possible to disable password authentication on a per-account basis if a public key is associated with the account?
    – cas
    Commented Sep 3, 2019 at 11:11
  • At least, that's the question I was answering. OTOH, "sshd doesn't have any option to do that" unintentionally applies equally well to all the questions the OP asked.
    – cas
    Commented Sep 3, 2019 at 11:19
  • I can think of a somewhat kludgey, hackish, method. Setup a match group, with a groupname designated only for this purpose, and put in the required AuthenticationMethods directive in it. Then run a cron job (say once every hour) that looks at all user's ~/.ssh and if an authorized_keys file is present, adds that user to the group using usermod or something. Reduce or increase that 1 hour time to suit your level of paranoia.
    – user339730
    Commented Sep 3, 2019 at 17:02
  • @sitaram, yep. that would make a good answer for you to write up, but reversed. the group should start with all users in it, and sshd configured to allow password auth for that group. sshd's default auth method should be pubkey only. The cron job removes users from the group if they have an authorized_keys file (and optionally after an announced cut-off date). Users would still have to install their own key.
    – cas
    Commented Sep 3, 2019 at 22:35

You must log in to answer this question.

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