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-00@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-req@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-00@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-req@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 adduser 3.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-err2 1.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 libselinux1 2.8-1+b1
ii libssl1.0.2 1.0.2o-1
ii libsystemd0 239-7
ii libwrap0 7.6.q-27
ii lsb-base 9.20170808
ii openssh-client 1:7.8p1-1
ii openssh-sftp-server 1:7.8p1-1
ii procps 2:3.3.15-2
ii ucf 3.0038
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages openssh-server recommends:
ii libpam-systemd 239-7
ii ncurses-term 6.1+20180714-1
ii xauth 1:1.0.10-1
Versions of packages openssh-server suggests:
ii ksshaskpass [ssh-askpass] 4:5.13.4-1
pn molly-guard <none>
ii monkeysphere 0.41-1
ii rssh 2.3.4-8
ii ssh-askpass 1:1.2.4.1-10
ii ssh-askpass-fullscreen [ssh-askpass] 0.3-3.1+b2
ii ssh-askpass-gnome [ssh-askpass] 1:7.8p1-1
pn ufw <none>
-- debconf information:
openssh-server/password-authentication: true
* openssh-server/permit-root-login: false
* ssh/use_old_init_script: true
ssh/vulnerable_host_keys:
ssh/disable_cr_auth: false
ssh/encrypted_host_key_but_no_keygen:
Reply to: