[Bug 212151] [security/openssh-portable] GSSAPI kex strange new behavior

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212151

            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 at FreeBSD.org
          Reporter: wollman at FreeBSD.org
             Flags: maintainer-feedback?(bdrewery at FreeBSD.org)
          Assignee: bdrewery at 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 forwarded
to the server.  In 7.3, a rekey is still forced, but the ensuring key exchange
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 purpose
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 at 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-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms:
ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at 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 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc:
chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos:
umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib at openssh.com,zlib
debug2: compression stoc: none,zlib at openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms:
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve25519-sha256 at 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 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com
debug2: ciphers stoc:
chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com
debug2: MACs ctos:
umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib at openssh.com
debug2: compression stoc: none,zlib at openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256 at libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 at 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)? 

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?

-- 
You are receiving this mail because:
You are the assignee for the bug.