Date: Thu, 25 Aug 2016 15:53:49 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 212151] [security/openssh-portable] GSSAPI kex strange new behavior Message-ID: <bug-212151-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212151 Bug ID: 212151 Summary: [security/openssh-portable] GSSAPI kex strange new behavior Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: bdrewery@FreeBSD.org Reporter: wollman@FreeBSD.org Flags: maintainer-feedback?(bdrewery@FreeBSD.org) Assignee: bdrewery@FreeBSD.org With the update to 7.3, there is a strange new behavior for GSSAPI key exchange. Historically, if the client's Kerberos tickets were updated (e.g= ., as a result of running "kinit"), and the GssapiRenewalForcesRekey option is enabled, a rekey would be forced, allowing the updated tickets to be forwar= ded to the server. In 7.3, a rekey is still forced, but the ensuring key excha= nge fails: either ssh will try to switch to a different kex algorithm (which is= not desirable, since suddenly switching to public-key kex defeats the whole pur= pose of configuring GSSAPI kex), or if non-GSSAPI kex methods are explicitly disabled, it will simply drop the connection. Needless to say, this makes = it impossible to leave any ssh sessions up overnight (given the typical ticket lifetime of 8 hours). Here's some debug output: debug1: credentials updated - forcing rekey 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-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha= 2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha5= 12,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-= hellman-group14-sha256,diffie-hellman-group14-sha1 debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@opens= sh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openss= h.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,= ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,null debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@o= penssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@o= penssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.= com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh= .com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.= com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh= .com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com,zlib debug2: compression stoc: none,zlib@openssh.com,zlib debug2: languages ctos:=20 debug2: languages stoc:=20 debug2: first_kex_follows 0=20 debug2: reserved 0=20 debug2: peer server KEXINIT proposal debug2: KEX algorithms: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g=3D=3D,gss-group1-sha1-toWM5Slw5Ew8Mqkay= +al2g=3D=3D,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g=3D=3D,curve25519-sha256= @libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie= -hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman= -group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@o= penssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@o= penssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.= com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh= .com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.= com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh= .com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com debug2: compression stoc: none,zlib@openssh.com debug2: languages ctos:=20 debug2: languages stoc:=20 debug2: first_kex_follows 0=20 debug2: reserved 0=20 debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> 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:fatQqLLWiPUxicU4OFlxbVSn9dc5n6YvDr+SnyQ0fvk DNS lookup error: general failure The authenticity of host 'hergotha.csail.mit.edu (207.180.169.34)' can't be established. ECDSA key fingerprint is SHA256:fatQqLLWiPUxicU4OFlxbVSn9dc5n6YvDr+SnyQ0fvk. No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?=20 This clearly looks to be a bug in the patch, since the client is not even offering the GSSAPI kex algorithms when doing a rekey, but if GSSAPI is manually forced by setting the KexAlgorithms option, it just aborts the connection: debug1: credentials updated - forcing rekey debug1: need rekeying debug1: SSH2_MSG_KEXINIT sent debug1: rekeying in progress debug1: channel 0: free: client-session, nchannels 1 So I'm guessing something changed in 7.3 that broke GssapiRenewalForcesRekey processing. This presumably isn't our fault, so perhaps it can be reported= to the upstream maintainers, whoever they may be at this point? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212151-13>