Bug#819361: openssh-client: ssh/scp rekey fails when using GSSAPI KEX

[Harald Barth]

The reason for this bug is how the list of key exchange methods is
created and then modified later.

1. The original KEX list is taken from options.

2. The extension negotiation "options" which are not real kex enc
   types are added to the list.

3. The GSSAPI enc types are prepended (code from the gssapi patch)

Then later after the initial KEX handshake, the comment says

   /* remove ext-info from the KEX proposals for rekeying */

but in effect the code does not remove only the ext-info stuff but
resets the list to the original option list. So what needs to be done
is that the GSSAPI enc types have to be prepended _again_ at this
point to restore the list to contain for GSSAPI useful content.

In the attachment is a patch against debians openssh_7.4p1-5 which
fixes the bug. Probably this patch should be merged with the
gssapipatch instead, but that I leave to the maintainer.

As this is a regression which makes it very difficult to transfer files
bigger than the rekey limit, please fix ASAP.

Harald.


--- sshconnect2.c.orig  2017-01-04 19:47:10.0 +0100
+++ sshconnect2.c   2017-01-05 04:13:08.977425272 +0100
@@ -222,7 +222,6 @@
orig = myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS];
xasprintf([PROPOSAL_SERVER_HOST_KEY_ALGS],
"%s,null", orig);
-   free(gss);
}
}
 #endif
@@ -273,6 +272,16 @@
/* remove ext-info from the KEX proposals for rekeying */
myproposal[PROPOSAL_KEX_ALGS] =
compat_kex_proposal(options.kex_algorithms);
+#ifdef GSSAPI
+   /* repair myproposal after it was crumpled by the */
+   /* ext-info removal above */
+   if (gss) {
+   orig = myproposal[PROPOSAL_KEX_ALGS];
+   xasprintf([PROPOSAL_KEX_ALGS],
+ "%s,%s", gss, orig);
+   free(gss);
+   }
+#endif
if ((r = kex_prop2buf(kex->my, myproposal)) != 0)
fatal("kex_prop2buf: %s", ssh_err(r));

Bug#819361: openssh-client: ssh/scp rekey fails when using GSSAPI KEX

[rave dog]

Even if there is no immediate fix between 2-2 and 2-4 perhaps, this bug is
still relevant in version 7.2p2-4. Interestingly enough it does not seem to
honor the "ReKeyLimit 0G" either to bypass it completely.

br,

R

Bug#819361: openssh-client: ssh/scp rekey fails when using GSSAPI KEX

[Peter Gille]

On 2016-03-28 00:15:12 CEST, Colin Watson  wrote: 

> On Sun, Mar 27, 2016 at 05:11:43PM +0200, Peter Gille wrote:
>> I get failures during rekey when using ssh with kerberos authentication
>> and GSSAPI key-exchange.
>
> Could you please try 1:7.2p2-2 and see if it fixes this?  It certainly
> has a fix specific to GSSAPI key exchange.

Yes, I still get the same behaviour with version 7.2p2-2.

> Thanks,

Cheers,
Peter

Bug#819361: openssh-client: ssh/scp rekey fails when using GSSAPI KEX

[Colin Watson]

On Sun, Mar 27, 2016 at 05:11:43PM +0200, Peter Gille wrote:
> I get failures during rekey when using ssh with kerberos authentication
> and GSSAPI key-exchange.

Could you please try 1:7.2p2-2 and see if it fixes this?  It certainly
has a fix specific to GSSAPI key exchange.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#819361: openssh-client: ssh/scp rekey fails when using GSSAPI KEX

[Peter Gille]

Package: openssh-client
Version: 1:7.2p2-1
Severity: normal

Dear Maintainer,

I get failures during rekey when using ssh with kerberos authentication
and GSSAPI key-exchange. This can be noticed in long-running ssh
sessions or when doing large scp transfers (or triggered manually in the
ssh client, using the ~R escape sequence).

As far as I can make out the ssh client offers a different set of
key-exchange algorithms on initial connection and when doing the
rekeying. Here is an example output:

---
$ ssh -vvv foo.example.com
[...]
debug1: Authenticating to foo.example.com:22 as 'user'
[...]
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group1-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
[...]
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
[...]
Last login: Fri Mar 25 09:56:20 2016 from foo
foo% echo "now sending rekey request with ~R"
now sending rekey request with ~R
foo% debug1: need rekeying
debug1: SSH2_MSG_KEXINIT sent
debug1: rekeying in progress
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: host key algorithms: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,null
[...]
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
[...]
debug1: kex: algorithm: curve25519-sha...@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: rekeying in progress
debug1: rekeying in progress
debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:w7yxbCZNBwQ0S0AgmCrFYa3XUpDjvWiDOw4/YOY9q8E
The authenticity of host 'foo.example.com (10.0.1.2)' can't be established.

ECDSA key fingerprint is SHA256:w7yxbCZNBwQ0S0AgmCrFYa3XUpDjvWiDOw4/YOY9q8E.
   Are you sure you want to continue connecting (yes/no)? 
  Host key 
verification failed.
---

So it appears that the client does not see the gss-* methods but the
server still does.

/ Peter


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssh-client depends on:
ii  adduser   3.114
ii  dpkg  1.18.4
ii  libc6 2.22-3
ii  libedit2  3.1-20150325-1+b1
ii  libgssapi-krb5-2  1.13.2+dfsg-5
ii  libselinux1   2.4-3+b1
ii  libssl1.0.2   1.0.2g-1
ii  passwd1:4.2-3.1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.9-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- debconf information: