Are they both different methods to accomplish the same goal?
I assume "they both" means "adding the keys to an
authorized_keys" and "using ssh-agent"; and "the same goal" means "without having to input the git user's password every time".
No. They do not accomplish the same goal.
When a client connects to an SSH server, the client needs to authenticate. The server informs which authentication methods it allows, the client can be configured to decide in which order to try them. The client tries them (and possibly retries, like if you type the password wrong you will get another chance) until the authentication succeeds, there is nothing more to try or the server disconnects.
(A server may be configured to require more than one method to succeed; this is not the case here.)
A common setup is: a server allows
password methods (possibly among others); a client tries the former before the latter. If the client has no keys, it skips the
After you added a public key to the
authorized_keys file on the server in question and your SSH client started using the corresponding private key, you never get to the
password method because
publickey is tried first and it's enough to authenticate you.
The same authorized key can authenticate multiple SSH sessions. If there are more authorized keys in the file then any of them can be used any number of times, independently form one another.
(The number of connections or login sessions may be limited by other factors, resources being the ultimate factor; but not by the mechanism of public keys, it's just not its job.)
Adding a key to
authorized_keys is a method to log in "without having to input the git user's password every time". Now you know how it works for you. It's not obvious but it works for your boss as well.
Your boss's case
You said your boss had had to "put in the password for git every time". Well, an SSH server can be configured to require a key and a password from a specific user, but this is certainly not the default behavior; and the fact ssh-agent helped tells me this possibility is out of the question (the agent holds keys, not passwords). What really happened is your boss had created an encrypted private key which requires a passphrase to be decrypted and he had used the same string as the password; and when he tried to use the key to authenticate, it was not the server asking for a password, it was the client (local
ssh program) asking for the passphrase in order to decrypt the key locally and only then use it for authentication.
If your boss wants to use the key without typing anything then he should remove the passphrase. This answer of mine explains and solves exactly what I think happened to your boss. The right command is
ssh-keygen -p, check the linked answer for details, I won't repeat myself here.
Using ssh-agent is not a method to log in "without having to input the git user's password every time". Ssh-agent is for holding private keys and handling authentication request other programs (mainly
ssh) relay to it.
Adding an encrypted key to ssh-agent makes the agent ask for the passphrase. Then the agent can use the key without asking again, whenever
ssh relays to it an authentication request coming from an SSH server. SSH client does this by default whenever it can reach an agent.
(To be clear:
ssh can use default or specified key(s) by itself, regardless if there's an agent available or not.)
While ssh-agent is not a method to log in without having to input the password every time, is's a method to use an encrypted key without using its passphrase every time.
One agent can serve many clients:
sshs or other programs that know how to talk to the agent. Clients that want to use an agent check the
SSH_AUTH_SOCK environment variable to locate a Unix-domain socket provided by an agent. It's possible to run more than one agent, clients will find different agents if their
SSH_AUTH_SOCK variables differ.
Note one can use keys without any agent (it's highly possible you do this) or with an agent (your boss does this), but using an agent without specifying some key in some
authorized_keys file misses the point. If your boss removes his public key from the
authorized_keys file on the server then he won't be able to log in with the key, with or without an agent.
Using ssh-agent has advantages over a scenario where sole
ssh uses keys:
- An encrypted key can be used multiple times, on request from multiple processes, after providing the passphrase once (your boss's case).
- A specific set of keys can be loaded without changing the config of
ssh and without using
- The root user can made an agent available to other user(s)'s processes without making the key(s) available for them.
- One can request
ssh to forward the authentication agent connection. When you do this while ssh-ing to a server,
ssh processes you invoke on the server (to reach yet another server) will be able to access your local agent. This way you can authenticate with your locally available private keys (holding by the local agent) without copying them to the intermediate server.