?0[steffen@wales ]$ scp ... ... ... ?0[steffen@wales ]$ ssh ... ... * [steffen@...]$ ssh-add -l Could not open a connection to your authentication agent. * [steffen@...]$ logout Shared connection to ... closed. ?0[steffen@wales ]$ ll /tmp/.ssh_...-steffen srw------- 1 steffen steffen 0 Sep 28 20:57 /tmp/.ssh_...-steffen= ?0[steffen@wales ]$ date Wed Sep 28 20:57:59 CEST 2016 This is OpenSSH_7.3p1 on client and OpenSSH_7.2p2-hpn14v4 on server, and the configuration includes "ControlMaster auto" and "ForwardAgent yes". This could be related to "Allow agent forwarding in sftp & scp"[1]. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=831
This seems a more general problem: Agent forwarding seems only to happen when starting a new ControlMaster. If ssh re-uses an existing ControlMaster, the -A option seems to be (silently!) ignored: Passing -A to the master works: matthijs@grubby:~$ ssh tika-login -o ControlMaster=yes -o ControlPath=/tmp/foo -A matthijs@login:~$ echo $SSH_AUTH_SOCK /tmp/ssh-Kmwf42CH18/agent.3830 matthijs@login:~$ logout Connection to tikatika.nl closed. But passing -A to a "slave" ssh does not: matthijs@grubby:~$ ssh tika-login -o ControlMaster=yes -o ControlPath=/tmp/foo And in another terminal: matthijs@grubby:~$ ssh -o ControlPath=/tmp/foo tika-login -A matthijs@login:~$ echo $SSH_AUTH_SOCK matthijs@login:~$ I can imagine there's a technical reason to not support this, but then at least it should be documented and passing -A should show an error or warning (possibly depending on ExitOnForwardFailure).
I originally tested on 7.4p1 from Debian Stretch, and I just tested 7.5p1 from Debian Sid, which shows the same behaviour.
Agent forwarding is always inherited from the multiplexing master process. This is documented in sshd_config: > X11 and ssh-agent(1) forwarding is supported over these multi‐ > plexed connections, however the display and agent forwarded will > be the one belonging to the master connection i.e. it is not pos‐ > sible to forward multiple displays or agents. Putting the original bug title back, because this bug is specific to scp/sftp's explicit deactivation-by-default of agent forwarding.
Ah, thanks for clarifying, I've must have missed that part in the manpage. I've created a new bug for showing a warning when this happens, which does still seem like a valid, but indeed separate issue to me: https://bugzilla.mindrot.org/show_bug.cgi?id=2780
I see in scp.c that -oForwardAgent=no is added to the command line arguments internally to disable forwarding, but can be overridden. Would it be helpful to also add -oControlMaster=no so that scp does not end up creating the control master with agent forwarding disabled? Alternatively it would be useful if the config file could match against scp/sftp so that ControlMaster=no could be set for that case.