Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections
On Sun, 9 Sep 2018, Timo Weingärtner wrote: Hallo Giacomo Mulas, For me the problem can be reproduced by installing libpam-ssh. openssh 7.8 + libpam-ssh: broken openssh 7.4 + libpam-ssh: works any openssh + no libpam-ssh: works I conferm, same here. So the question now is: what changed between openssh 7.4 and 7.8 that caused the interaction with libpam-ssh to break ssh-agent forwarding? Did some change in openssh expose a bug in libpam-ssh or is the bug in openssh? Can I help to solve this? Any diagnostics I can run? In the meanwhile, please could this be documented in both openssh and libpam-ssh, so that a user is made aware of this and can decide whether (s)he wants to install/enable libpam-ssh anyway or not? Thanks for the help Giacomo Mulas -- _ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections
Hallo Giacomo Mulas, 08.09.18 10:16 Giacomo Mulas: > On Fri, 7 Sep 2018, Timo Weingärtner wrote: > > So the connection to some ssh-agent is working. Please check which process > > owns the socket pointed to by $SSH_AUTH_SOCK. If it is not sshd you have > > another problem; perhaps something like libpam-ssh is starting a new > > ssh-agent for your ssh session? > > ls -l $SSH_AUTH_SOCK yields > > srw--- 1 gmulas ssh 0 set 8 10:05 /tmp/ssh-TteIoyXhPTF2/agent.14983= > > whereas lsof $SSH_AUTH_SOCK yields nothing run as regular user and > lsof /tmp/ssh-TteIoyXhPTF2/agent.14983= run as root yields > > COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME > ssh-agent 14984 gmulas3u unix 0x4846ae07 0t0 6314996 > /tmp/ssh-TteIoyXhPTF2/agent.14983 type=STREAM > > the parent ID of this ssh-agent is 1 (?) That's normal when it was started without a command to run. > I hope this can help. Please let me know if there is something else I can do > to track the problem. For me the problem can be reproduced by installing libpam-ssh. openssh 7.8 + libpam-ssh: broken openssh 7.4 + libpam-ssh: works any openssh + no libpam-ssh: works The problem might be that libpam-ssh starts an ssh-agent and sets SSH_AUTH_SOCK regardless of whether an agent is forwarded and newer openssh- server doesn't change SSH_AUTH_SOCK pointing to its own socket? Grüße Timo signature.asc Description: This is a digitally signed message part.
Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections
On Fri, 7 Sep 2018, Timo Weingärtner wrote: So the connection to some ssh-agent is working. Please check which process owns the socket pointed to by $SSH_AUTH_SOCK. If it is not sshd you have another problem; perhaps something like libpam-ssh is starting a new ssh-agent for your ssh session? ls -l $SSH_AUTH_SOCK yields srw--- 1 gmulas ssh 0 set 8 10:05 /tmp/ssh-TteIoyXhPTF2/agent.14983= whereas lsof $SSH_AUTH_SOCK yields nothing run as regular user and lsof /tmp/ssh-TteIoyXhPTF2/agent.14983= run as root yields COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME ssh-agent 14984 gmulas3u unix 0x4846ae07 0t0 6314996 /tmp/ssh-TteIoyXhPTF2/agent.14983 type=STREAM the parent ID of this ssh-agent is 1 (?) I hope this can help. Please let me know if there is something else I can do to track the problem. Bye Giacomo -- _ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections
Hallo Giacomo Mulas, 07.09.18 11:09 Giacomo Mulas: > Package: openssh-server > Version: 1:7.8p1-1 > Severity: normal > > Dear Maintainer, > > with the recent updates of openssh, agent forwarding is broken in incoming > connections. It still works properly in outgoing connections, which I > tested by logging in on several computers running e.g. debian stable or > other distros or even another os altogether. However, when I try to connect > from other machines to my computer, or even upon using locah ssh to > localhost, no credentials are forwarded. > E.g., on the session from which I use ssh: > > gmulas@spitzer:~$ ssh-add -l > 2048 SHA256:1EiqSAb6gUEpa27SrPhpx2lbj0I2yjz6TWO6HgUuFO4 > /homes/spitzer/gmulas/.ssh/id_rsa (RSA) 1024 > SHA256:bcMLBbvPfsCMMYUkXJYLljsNsBhpkC3N//38mnObjIw > /homes/spitzer/gmulas/.ssh/id_dsa (DSA) 256 > SHA256:GdCSZj0SYfo3XgnGAEfaFVJSjqzGuHAq01oYpG5HNEA > /homes/spitzer/gmulas/.ssh/id_ecdsa (ECDSA) > > then I successfully login to my laptop using one of those keys, with > > ssh -A capitanata > > but if I then ask which credentials are available I get: > > gmulas@capitanata:~$ ssh-add -l > The agent has no identities. So the connection to some ssh-agent is working. Please check which process owns the socket pointed to by $SSH_AUTH_SOCK. If it is not sshd you have another problem; perhaps something like libpam-ssh is starting a new ssh-agent for your ssh session? Grüße Timo signature.asc Description: This is a digitally signed message part.
Bug#908195: openssh-server: agent forwarding broken in incoming ssh connections
Package: openssh-server Version: 1:7.8p1-1 Severity: normal Dear Maintainer, with the recent updates of openssh, agent forwarding is broken in incoming connections. It still works properly in outgoing connections, which I tested by logging in on several computers running e.g. debian stable or other distros or even another os altogether. However, when I try to connect from other machines to my computer, or even upon using locah ssh to localhost, no credentials are forwarded. E.g., on the session from which I use ssh: gmulas@spitzer:~$ ssh-add -l 2048 SHA256:1EiqSAb6gUEpa27SrPhpx2lbj0I2yjz6TWO6HgUuFO4 /homes/spitzer/gmulas/.ssh/id_rsa (RSA) 1024 SHA256:bcMLBbvPfsCMMYUkXJYLljsNsBhpkC3N//38mnObjIw /homes/spitzer/gmulas/.ssh/id_dsa (DSA) 256 SHA256:GdCSZj0SYfo3XgnGAEfaFVJSjqzGuHAq01oYpG5HNEA /homes/spitzer/gmulas/.ssh/id_ecdsa (ECDSA) then I successfully login to my laptop using one of those keys, with ssh -A capitanata but if I then ask which credentials are available I get: gmulas@capitanata:~$ ssh-add -l The agent has no identities. The same happens if I do "ssh -A localhost" on my computer. Nothing changes if I add "-4" or "-6" options (i.e. it does not depend on using IPv4 vs IPv6). Nothing changes if I use gnome's keyring daemon vs openssh's agent. If I turn up debugging level, e.g. "ssh -Avv", I get (among other unrelated stuff) on a _broken_ agent connection: debug1: Entering interactive session. debug1: pledge: exec debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0 debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug2: callback start debug1: X11 forwarding requested but DISPLAY not set debug1: Requesting authentication agent forwarding. debug2: channel 0: request auth-agent-...@openssh.com confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 while on a _working_ connection I get: debug1: Entering interactive session. debug1: pledge: exec debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0 debug2: channel_input_open_confirmation: channel 0: callback start debug2: x11_get_proto: /usr/bin/xauth list :0 2>/dev/null Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 1 debug1: Requesting authentication agent forwarding. debug2: channel 0: request auth-agent-...@openssh.com confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 Aside from X-related stuff, which should be irrelevant, the only difference I see is debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /home/gmulas/.ssh/authorized_keys:3: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding I did not change anything in the ssh configuration upon the latest package. upgrades. While I did not tag this as an "important" or "grave" bug, the broken functionality is a fairly important one for the sshd server, its origin should definitely be tracked down and either fixed or at least documented. Please let me know if I can run any useful tests to help. Thanks in advance, bye Giacomo Mulas -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.17-jak (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.117 ii debconf [debconf-2.0] 1.5.69 ii dpkg 1.19.0.5+b1 ii libaudit1 1:2.8.4-2 ii libc6 2.27-6 ii libcom-err21.44.4-2 ii libgssapi-krb5-2 1.16-2 ii libkrb5-3 1.16-2 ii libpam-modules 1.1.8-3.8 ii libpam-runtime 1.1.8-3.8 ii libpam0g 1.1.8-3.8 ii libselinux12.8-1+b1 ii libssl1.0.21.0.2o-1 ii libsystemd0239-7 ii libwrap0 7.6.q-27 ii lsb-base 9.20170808 ii openssh-client 1:7.8p1-1 ii openssh-sftp-server1:7.8p1-1 ii procps 2:3.3.15-2 ii ucf3.0038 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd 239-7 ii ncurses-term6.1+20180714-1 ii xauth
