Bug 2621

Summary:	ControlMaster started by scp (non-ssh?) doesn't forward agent
Product:	Portable OpenSSH	Reporter:	Steffen (Daode) Nurpmeso <steffen>
Component:	Miscellaneous	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	normal	CC:	djm, hamish-openssh, matthijs
Priority:	P5
Version:	7.3p1
Hardware:	All
OS:	All

Description Steffen (Daode) Nurpmeso 2016-10-05 06:32:12 AEDT

?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

Comment 1 Matthijs Kooijman 2017-09-16 00:03:49 AEST

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).

Comment 2 Matthijs Kooijman 2017-09-16 00:36:25 AEST

I originally tested on 7.4p1 from Debian Stretch, and I just tested 7.5p1 from Debian Sid, which shows the same behaviour.

Comment 3 Damien Miller 2017-09-17 10:42:55 AEST

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.

Comment 4 Matthijs Kooijman 2017-09-17 18:27:55 AEST

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

Comment 5 Hamish Moffatt 2021-09-08 12:37:24 AEST

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.