ssh-agent and/or using authorised_keys for securing a remote connection for a git repository

Question

I'm trying to set up a suite of backup servers using git on some remote vm's. The remote vm's will be linked with some directories on my local machine, with various branches inside the local machine directories.

I have set up one of the git repositories using an rsa key generated on my local machine, which I have then pasted into the vm's git user .ssh/authorized_keys, which seems to work and I can push/pull to the repository from my machine without having to input the git users' password every time.

Then, my boss has put his rsa key into the authorized_keys file so he could also work on the repositories but he had to put in the password for git every time and he worked around it by using ssh-agent to cache his rsa credentials.

Are they both different methods to accomplish the same goal, or are they for different scenarios; i.e. is the the method of adding the keys to an authorized_keys file meant to work for multiple sessions or only one session, or is the ssh-agent meant to be for multiple sessions?

I'm just a bit confused as to the scenarios in which each would be used, so if someone could try explain them to me that would be very helpful, thanks.

Answer 1

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.

---

Adding to authorized_keys

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 publickey and password methods (possibly among others); a client tries the former before the latter. If the client has no keys, it skips the publickey method.

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.

---

ssh-agent

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 ssh -i.
• 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.