Hey there. I've noted the two errors, with the following setup: Locally, I have: OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k 25 Mar 2021 from which I connect to some internal node at CERN (hammercloud-ai-11.cern.ch) via some publicly available node (lxplus.cern.ch) which all have: OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 The lxplus.cern.ch is actually a round robin DNS name, but all nodes behind have the same ssh server key. Since CERN uses AFS, I have to do GSSAPI auth. Locally I have a keytab file created with ktuil, which even works out of the box with SSH - that is, if I don't have a krb ticket yet, it automatically creates one. My SSH config looks like the following: Host hammercloud-ai-11.cern.ch GSSAPIAuthentication yes GSSAPIDelegateCredentials yes GSSAPIRenewalForcesRekey yes GSSAPITrustDns yes ProxyJump lxplus.cern.ch Host lxplus.cern.ch GSSAPIAuthentication yes GSSAPIDelegateCredentials yes GSSAPIRenewalForcesRekey yes GSSAPITrustDns yes # ControlMaster auto # ControlPersist 10s # ControlPath ~/.ssh/channel-mux/%r@%h:%p Host *.cern.ch User someUser IdentityFile ~/.ssh/id_ed25519 SetEnv "LANG=en_US.UTF-8" Further, I do have a custom locale which is basically en_US.UTF-8, but with some international stuff like "," as decimal separator. Now that works to login to lxplus, and from there (within an interactive session) to hammercloud-ai-11. When I use the ProxyJump however and directly go to hammercloud-ai-11, I start to see errors. 1) with LANG=en_DE.UTF-8 it segfaults: $ ssh hammercloud-ai-11.cern.ch -v ... Authenticated to hammercloud-ai-11.cern.ch (via proxy). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: proc debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: Sending environment. debug1: Sending env LANG = en_DE.UTF-8 Segmentation fault $ debug1: stdio forwarding: done Interestingly it seems to still try to send "my" locale instead what I've configured above with: SetEnv "LANG=en_US.UTF-8" 2) the same with LANG=C $ export LANG=C $ ssh hammercloud-ai-11.cern.ch -v ... Authenticated to hammercloud-ai-11.cern.ch (via proxy). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: proc debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: Sending environment. debug1: Sending env LANG = C malloc_consolidate(): invalid chunk size Aborted $ debug1: stdio forwarding: done Whether or not using a Control Channel doesn't seem to matter. When I comment the Host hammercloud-ai-11.cern.ch ... # GSSAPITrustDns yes It works in both cases. Commeting the same for lxplus (the proxy node), doesn't solve the issue. Any ideas? Cheers, Chris.
forgot: May 01 16:38:39 heisenberg kernel: ssh[16368]: segfault at 7e00000008 ip 00007f646525a86c sp 00007ffd72b5fb30 error 4 in libc-2.31.so[7f64651f9000+14b000] May 01 16:38:39 heisenberg kernel: Code: 43 28 00 00 00 00 48 8b 54 24 08 48 89 ef 48 89 43 10 48 83 cf 01 48 89 7b 08 48 89 53 18 48 89 2c 2b 48 85 c9 74 87 48 89 cb <48> 8b 43 08 89 c1 c1 e9 04 83 e9 02 49 8d 4c cc 10 49 39 cd 0f 85 May 01 16:38:50 heisenberg kernel: ssh[16375]: segfault at 7e00000008 ip 00007fe602caa86c sp 00007fff2ac78150 error 4 in libc-2.31.so[7fe602c49000+14b000] May 01 16:38:50 heisenberg kernel: Code: 43 28 00 00 00 00 48 8b 54 24 08 48 89 ef 48 89 43 10 48 83 cf 01 48 89 7b 08 48 89 53 18 48 89 2c 2b 48 85 c9 74 87 48 89 cb <48> 8b 43 08 89 c1 c1 e9 04 83 e9 02 49 8d 4c cc 10 49 39 cd 0f 85
(In reply to Christoph Anton Mitterer from comment #0) [...] > OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k 25 Mar 2021 [...] > When I comment the > Host hammercloud-ai-11.cern.ch > ... > # GSSAPITrustDns yes > > It works in both cases. GSSAPITrustDns is not part of the code provided by the OpenSSH team. Can you reproduce the problem with the stock code? If not then you probably need to report this to Debian instead.
Ah I seem, well then I guess it's best to close it here and I'll re-report @Debian. Thanks :-)
In that case, closing bug. Please reopen if you can reproduce the problem with the stock OpenSSH.
closing bugs resolved before openssh-8.9