In the past I've done the same things, as some have mentioned already, as a form of two-factor authentication. There were a few reasons for this that made a lo

In the past I've done the same things, as some have mentioned already, as a form of two-factor authentication. There were a few reasons for this that made a lot of sense: (1) Private keys were being stored haphazardly -- people were not protecting them with passwords and occasionally they ended up on network drives. It's possible to enforce password policies for the hosts in question, but not possible to enforce 'how you protect/handle your private key' centrally[0]. (2) The second only applied to an environment I managed in the past, but we had many Linux hosts that were AD domain joined and authentication occurred directly via AD credentials (no local account authentication). The servers were configured to allow password-only login when the user had never connected to the host before. Once the user had connected the first time, the host would receive the public key for that user and future logins would only require the key[0]. [0] ... that latter part they failed to ever get working properly. It always prompted for both. Based on my conversations with the team managing the servers, there was zero priority assigned to fixing that problem -- they were resentful of the fact that the Linux (Debian, incidentally) hosts were domain joined and allowed domain authentication and they had a poor opinion of the security of using AD user accounts for authentication (nobody would make an argument other than Micro == small, soft == not hard or some other snark like that -- we had some BOFH over there).