Bug 212151 - [security/openssh-portable] GSSAPI kex strange new behavior
Summary: [security/openssh-portable] GSSAPI kex strange new behavior
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Bryan Drewery
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-25 15:53 UTC by Garrett Wollman
Modified: 2019-07-01 03:32 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (bdrewery)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Garrett Wollman freebsd_committer 2016-08-25 15:53:49 UTC
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@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@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.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@openssh.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@openssh.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: 
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@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@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.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: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
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)? 

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?
Comment 1 Garrett Wollman freebsd_committer 2016-08-25 15:58:41 UTC
Actually seems to be a more general problem with rekeying and GSSAPI kex -- I get the same failure mode if I manually rekey using the ~R escape.
Comment 2 Bryan Drewery freebsd_committer 2016-08-25 16:31:27 UTC
My TDL is quite large, I'll try to look at this in the next few weeks.
Comment 3 Garrett Wollman freebsd_committer 2016-08-30 15:26:39 UTC
It seems that GSSAPI kex is just completely broken for rekeying.  Even on a fresh connection, ~R to rekey goes straight to public-key rather than doing GSSAPI.
Comment 4 Walter Schwarzenfeld freebsd_triage 2019-07-01 01:15:14 UTC
We have version 7.9p1. Is this still relevant?
Comment 5 Garrett Wollman freebsd_committer 2019-07-01 03:32:55 UTC
(In reply to w.schwarzenfeld from comment #4)
I don't know, I had to disable the feature in order to be able to get my work done.