Autopkgtests are looking good for openssh 1:9.6p1-3ubuntu13.9 from noble-proposed. The intermittent failures from comment #19 have all been resolved, with openssh/s390x and crmsh/any regressed in jammy-updates (unrelated to this update).
Together with the previous comment (#20), this finalizes SRU verification for this bug report. PASS https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/o/openssh/20250307_164612_f5f9a@/log.gz PASS https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/o/openssh/20250307_185308_196f2@/log.gz PASS https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/armhf/o/openssh/20250307_182855_7ac4e@/log.gz PASS https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/ppc64el/o/openssh/20250310_143140_2979a@/log.gz FAIL https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/s390x/o/openssh/20250310_143626_6d8a7@/log.gz => For the final openssh/s390x failure: This is regressed in jammy-updates, unrelated to this upload. The summary shows that the new "ssh-gssapi" test still passes on s390x, which is relevant for SRU verification of this bug: """ 1735s autopkgtest [14:36:19]: @@@@@@@@@@@@@@@@@@@@ summary 1735s regress FAIL non-zero exit status 2 1735s systemd-socket-activation PASS 1735s sshd-socket-generator PASS 1735s ssh-gssapi PASS """ All of them show 3 login attempts with the final one using privatekey authentication: """ 1733s ## Checking ssh logs to confirm gssapi-with-mic auth was used 1733s Mar 10 14:36:17 sshd-gssapi.example.fake sshd[1678]: Accepted gssapi-with-mic for testuser1562 from 127.0.0.1 port 34648 ssh2: testuser1...@example.fake 1733s ## PASS test_gssapi_login [...] 1733s ## Checking ssh logs to confirm gssapi-keyex auth was used 1733s Mar 10 14:36:17 sshd-gssapi.example.fake sshd[1730]: Accepted gssapi-keyex for testuser1562 from 127.0.0.1 port 34654 ssh2: testuser1...@example.fake 1733s ## PASS test_gssapi_keyex_login [...] 1734s ## Checking ssh logs to confirm publickey auth was used 1734s Mar 10 14:36:18 sshd-gssapi.example.fake sshd[1768]: Accepted publickey for testuser1562-2 from 127.0.0.1 port 34658 ssh2: ED25519 SHA256:Y41A5NlL26LzekRtf+/QXlr/SJEnydvTS9aw9yEVT8c 1734s ## PASS test_gssapi_keyex_pubkey_fallback """ ** Tags removed: verification-needed-noble ** Tags added: verification-done-noble -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2028282 Title: [SRU] SSH pubkey authetication fails when GSSAPI enabled Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Jammy: Triaged Status in openssh source package in Noble: Fix Committed Status in openssh source package in Oracular: Fix Released Status in openssh source package in Plucky: Fix Released Status in openssh package in Debian: Fix Released Bug description: [ Impact ] * Login with publickey fails when openssh server is configured to use GSSAPI authentication, too. Error: "sign_and_send_pubkey: internal error: initial hostkey not recorded" * To trigger it, one needs to (a) perform a successful GSSAPI key exchange, (b) attempt public key authentication. * In addition, the client and the server must both have the hostbound authentication protocol extension enabled for the problem to manifest itself (On by default). * This is not a very common combination, but it can happen if one has Kerberos credentials for the correct realm but the wrong user, and a private key for the right user. * This SRU fixes this by adding an additional "ssh->kex->initial_hostkey != NULL" check in sshconnect2.c:sign_and_send_pubkey(), as suggested by upstream in https://bugzilla.mindrot.org/show_bug.cgi?id=3406 (comment 2). [ Test Plan ] The reproducer was codified in autopkgtests, thanks to Colin Watson! * Make sure to have the latest debian/tests/ssh-gssapi test case (included as of 1:9.9p1-2, and shipped as part of this SRU), especially the delta described in https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2028282/+attachment/5845545/+files/dep8-verifier.diff * Execute the "ssh-gssapi" dep8 test: $ autopkgtest -U openssh --apt-pocket=proposed=src:openssh --test-name=ssh-gssapi -- lxd autopkgtest/ubuntu/oracular/amd64 * Confirm the log contains 3 login attempts, with the final one using the "publickey" authentication method ("Accepted publickey for testuser..."): """ ## Checking ssh logs to confirm publickey auth was used Dec 14 22:44:16 sshd-gssapi.example.fake sshd-session[2213]: Accepted publickey for testuser2020-2 from 127.0.0.1 port 43364 ssh2: ED25519 SHA256:7vF3468XCZOawompwDThLsGsnPoUaP5Ki/3KaQLq/2M ## PASS test_gssapi_keyex_pubkey_fallback """ [ Test Plan 2 ] * In addition to the codified test for this specific issue, we want to confirm normal password and publickey login are still working as expected. * Enable "PasswordAuthentication yes" in /etc/ssh/sshd_config & restart ssh.service * Login using password, confirm success * Copy public key over to system-under-test * Enable "PubkeyAuthentication yes" in /etc/ssh/sshd_config & restart * Login using private key, confirm success [ Where problems could occur ] * This SRU tweaks the authentication logic of OpenSSH, therefore it's a high-impact change. If something goes wrong, it could lock people out of their remote machines. * The change has been deployed to Debian testing and Ubuntu Plucky since October 2024, without major issues raised. * I've added "[ Test Plan 2 ]" to confirm normal publickey & password login is still working as expected [ Other Info ] * Fixed as of 1:9.9p1-2 (e.g. in Plucky) * Rejected upstream, due to being a bug in the Debian delta: https://bugzilla.mindrot.org/show_bug.cgi?id=3406 * Fixed in Debian by Colin Watson: https://salsa.debian.org/ssh-team/openssh/-/commit/7d291bb === original bug report === Since the upgrade from Ubuntu 20.04 to 22.04 the SSH login via a SSH pubkey to our servers fails, while password and kerberos are still working. $ssh user@server sign_and_send_pubkey: internal error: initial hostkey not recorded This seem related to the bugreport at openssh: https://bugzilla.mindrot.org/show_bug.cgi?id=3406 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: openssh-server 1:8.9p1-3ubuntu0.1 ProcVersionSignature: Ubuntu 5.15.0-76.83-generic 5.15.99 Uname: Linux 5.15.0-76-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Thu Jul 20 17:25:01 2023 InstallationDate: Installed on 2020-08-24 (1060 days ago) InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: openssh UpgradeStatus: Upgraded to jammy on 2023-07-20 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2028282/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
