Is it platform specific
generic
Importance or Severity
Medium
Description of the bug
With client_auth user, the sonic-mgmt-framework REST server validates HTTP Basic
credentials by opening an SSH connection to the local sshd (127.0.0.1:22) using the
embedded Go SSH client (golang.org/x/crypto, pinned at v0.0.0-20200622 in go.mod),
and treats a successful SSH login as a successful authentication (see
rest/server/pamAuth.go).
On images whose base distro ships OpenSSH >= 8.8 (Bookworm and all later releases),
sshd disables the legacy ssh-rsa (RSA/SHA-1) host-key signature algorithm by
default. With an RSA-only host key, sshd advertises only rsa-sha2-512 /
rsa-sha2-256. The pinned 2020 x/crypto does not list rsa-sha2-256/512 in its
host-key algorithms (supportedHostKeyAlgos in ssh/common.go) — it only offers
ssh-rsa (SHA-1), ecdsa, ed25519, dss.
The result is an empty intersection on host-key algorithms, so the SSH handshake
fails during algorithm negotiation, before user authentication is ever attempted —
the password is never checked. This is not specific to Bookworm; it applies to any
base distro with OpenSSH >= 8.8. It was latent on Buster/Bullseye (older sshd still
offered ssh-rsa) and first surfaced at the Bookworm migration.
Steps to Reproduce
- Build/run an image whose base distro ships OpenSSH >= 8.8 (Bookworm or later).
- Enable REST user auth
- Send a request with valid credentials:
Actual Behavior and Expected Behavior
Actual behavior:
The request is rejected even though the credentials are correct.
Expected behavior:
With client_auth user and valid credentials, the REST server should authenticate
the request successfully (HTTP 200 with the requested data) on Bookworm and later,
regardless of the host having an RSA-only host key. The embedded SSH client should
be able to negotiate a host-key algorithm with a modern sshd (e.g. by supporting
rsa-sha2-256/512, and/or by the image providing an ed25519 host key as a common
algorithm).
Relevant log output
Output of show version, show techsupport
Attach files (if any)
No response
Is it platform specific
generic
Importance or Severity
Medium
Description of the bug
With
client_auth user, the sonic-mgmt-framework REST server validates HTTP Basiccredentials by opening an SSH connection to the local sshd (127.0.0.1:22) using the
embedded Go SSH client (
golang.org/x/crypto, pinned at v0.0.0-20200622 in go.mod),and treats a successful SSH login as a successful authentication (see
rest/server/pamAuth.go).On images whose base distro ships OpenSSH >= 8.8 (Bookworm and all later releases),
sshd disables the legacy
ssh-rsa(RSA/SHA-1) host-key signature algorithm bydefault. With an RSA-only host key, sshd advertises only
rsa-sha2-512/rsa-sha2-256. The pinned 2020 x/crypto does not listrsa-sha2-256/512in itshost-key algorithms (
supportedHostKeyAlgosinssh/common.go) — it only offersssh-rsa(SHA-1), ecdsa, ed25519, dss.The result is an empty intersection on host-key algorithms, so the SSH handshake
fails during algorithm negotiation, before user authentication is ever attempted —
the password is never checked. This is not specific to Bookworm; it applies to any
base distro with OpenSSH >= 8.8. It was latent on Buster/Bullseye (older sshd still
offered ssh-rsa) and first surfaced at the Bookworm migration.
Steps to Reproduce
Actual Behavior and Expected Behavior
Actual behavior:
The request is rejected even though the credentials are correct.
Expected behavior:
With client_auth user and valid credentials, the REST server should authenticate
the request successfully (HTTP 200 with the requested data) on Bookworm and later,
regardless of the host having an RSA-only host key. The embedded SSH client should
be able to negotiate a host-key algorithm with a modern sshd (e.g. by supporting
rsa-sha2-256/512, and/or by the image providing an ed25519 host key as a common
algorithm).
Relevant log output
Output of
show version,show techsupportAttach files (if any)
No response