Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've used this article: in order to help set up ssh certificates (I'm on mac os x).

I see that the keys are put in a file called authorized_keys2.

Does it matter what this file is called? Also, on non-personal servers (servers where others may have root access) is it safe to use the same authorized_keys2 file? Would they be able to use that to access my personal servers somehow? Or do I use separate authorization files for different servers/ groups of servers?

Are there any other good "general practices" as far as having several servers with key based auth that are not mentioned in this article?

share|improve this question
up vote 3 down vote accepted

authorized_keys2 or more commonly authorized_keys are the default filenames. At least with OpenSSH server you are able to rename the file as you like with the AuthorizedKeysFile directive:


Specifies the file that contains the public keys that can be used for user authentication.  AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup.  The following tokens are defined: %% is replaced by a literal ’%’, %h is replaced by the home directory of the user being authenticated, and %u is replaced by the username of that user.  After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user’s home directory.  The default is “.ssh/authorized_keys”.

The distinction from authorized_keys versus authorized_keys2 comes about during the transition from SSH v1 to SSH v2. Now SSH v2 is the "default standard" so the name has converged back to authorized_keys in most cases.

The "key" (pardon the pun) point to understand is the private key remains private and is stored on the client machine only. The public key may be published to one or many servers as access needs dictate. In that way, ability to see/view/copy the public key only grants additional access to the private key but importantly may not be used by itself to gain access.


My favorite series of articles regarding SSH key based authentication were published by IBM several years ago.

Keep in mind these articles are 10 years old now and some things have changed. Still, they remain the most comprehensive explanation for all the nuances involved I have found to date.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.