3

A coworker recently said, "you can log in to the server using the -A flag if you want to load your private key." I nodded like I knew what they were saying and then snuck away to Google it.

It seems almost like using -A will magically allow you to log in without credentials. The man page:

Enables forwarding of the authentication agent connection. This can also be specified on a per-host basis in a configuration file.

Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

There's 6 words of description, then a paragraph of esoteric warning.

What does the -A flag do, how does it work, and how can I use it?

  • 1
    It tries to use the credentials you logged into your system. Its a bit similarly on how Windows will try to do this in a domain. If you login to a pc with your username and password, then try to access a network share, Windows will first try your username and password to see if that works. If so, you won't get a login prompt. Otherwise, you will get a login prompt. – LPChip Nov 16 '18 at 21:47
  • That's interesting. So my username and password literally on my laptop, would have to match the string for my username and password on the remote server? Seems easy. Why doesn't everyone do this instead of public / private keys, etc? – Monica Heddneck Nov 16 '18 at 22:17
  • @MonicaHeddneck Firstly, the analogy is not that close: the agent forwarding in SSH is not actually to do with usernames and passwords. Secondly, consider that in order to do that you would have to use the same password for every server. If you read any tips on good password practices, not reusing passwords will probably be in the top three. – IMSoP Nov 16 '18 at 23:05
2

ssh -A will cause deamon on server side to create authentication socket (which will be pointed by SSH_AUTH_SOCK environment variable) and which will allow you to forward authentication requests to your client machine (the one which initiated connection).

This means your private key from the original client can be used to authenticate further ssh connections initiated from the server to which you connected.

The warning basically means that users which can access your files bypassing normal filesystem checks (usually root in plain English) can manipulate your keys and can obtain access to systems which YOU can access.

2

Enables forwarding of the authentication agent connection.

As you say, this is a rather short description, because it assumes a lot of prior knowledge, so let's break it down.

... authentication ...

SSH connections can be authenticated in a number of ways - sometimes when your login is rejected, you'll see a list of failed methods. The two most common are using a password - which can be sent by the client, or asked for interactively - and using a public-private key pair.

Keys are what we're talking about here: the server knows a set of public keys it trusts, and you have to prove that you have the corresponding private key, by doing some funky maths with it.

... agent ...

Your SSH client needs to know how to find the private key, and use it to authenticate to the server. The simplest way is to store the key in a known file location, but if it has a passphrase, you're going to have to type that in every time you use the key.

An "authentication agent" is a piece of software that runs on your computer, and loads all your private keys once. When you want to connect to a server, your SSH client can ask the agent what keys it has, and use them to authenticate.

... forwarding of the ... connection

Finally, we get to agent forwarding. If you run an authentication agent on your PC, you can use it to log into server A. But what if you then need to connect from server A to server B (for instance, because server B isn't publicly accessible)? You would need to type a password, or store a key on server A, or even run an authentication agent on server A.

Agent forwarding simplifies this scenario by letting processes on the remote server talk to the authentication agent on your PC. It does this by creating a socket on the remote server which processes with the right permissions can connect to and send messages over your SSH connection, which are then forwarded to the original agent.

So with agent forwarding, your authentication looks like this:

  • Run an authentication agent on your PC
  • Load some private keys into the agent
  • Connect to server A, using the agent to authenticate, and enabling agent forwarding
  • Connect to server B, using the forwarded connection to authenticate, using the same agent
  • This can continue indefinitely, forwarding the connection over more and more hops until you lose track of where you are

Agent forwarding should be enabled with caution. ... An attacker ... can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

The caution in the manual is pointing out something which is technically true of all agent-based authentication: any process that can talk to the agent can use it to connect to anything you load the keys for. On a single-user workstation, that would generally require rogue software performing some automated attack. Agent forwarding will generally happen on a multi-user server, however, bringing the extra risk of rogue users: if they can get access to the agent forwarding socket (which in Unix tradition is represented as a special file on the filesystem) they can use it to impersonate you on other servers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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