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?
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.
My TDL is quite large, I'll try to look at this in the next few weeks.
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.
We have version 7.9p1. Is this still relevant?
(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.
A commit references this bug: Author: bdrewery Date: Tue Nov 24 20:46:21 UTC 2020 New revision: 556185 URL: https://svnweb.freebsd.org/changeset/ports/556185 Log: - Fix KERB_GSSAPI build; missing prototypes for DH openssl-compat. PR: 212151 (maybe) Changes: head/security/openssh-portable/Makefile head/security/openssh-portable/files/extra-patch-gssapi-kexgssc.c head/security/openssh-portable/files/extra-patch-gssapi-kexgsss.c
kexgssc.c:392:2: error: implicit declaration of function 'DH_get0_key' is invalid in C99 [-Werror,-Wimplicit-function-declaration] DH_get0_key(kex->dh, &pub_key, NULL); ^ kexgssc.c:550:2: error: implicit declaration of function 'DH_get0_pqg' is invalid in C99 [-Werror,-Wimplicit-function-declaration] DH_get0_pqg(kex->dh, &dh_p, NULL, &dh_g); ^ kexgssc.c:550:2: note: did you mean 'DH_get0_key'? There's a prototype missing here in kexgssgex_client which may explain it. Sounds like the key exchange client code. So it will never get the key right. Please try r556185? openssh-portable-gssapi-8.4.p1_3,1
Spotted this as I recently enabled -Werror in the port.
Closing per lack of feedback and no other reports since last fix.