Key Invalidation When Connecting to Jumpserver
After upgrading to Sonoma last year, I found that when connecting to Jumpserver via iTerm2, I was prompted to enter a password, and the RSA key became invalid. However, it worked fine on Terminal and other devices. Connecting to other servers via iTerm2 also worked without requiring a password.
Today, I noticed that the software version on Terminal is OpenSSH_9.6p1, while on iTerm2 it is OpenSSH_9.4p1. After some troubleshooting with the environment variable PATH, I found that regardless of whether it was Terminal or iTerm2, I needed to enter a password when connecting to Jumpserver.
Later, I specified PubkeyAcceptedKeyTypes ssh-rsa for Jumpserver in the config file, and then I was able to connect normally.
OpenSSH_9.6p1, OpenSSL 3.2.1 30 Jan 2024
debug1: Reading configuration data /Users/leo/.ssh/config
debug1: Reading configuration data /Users/leo/.orbstack/ssh/config
debug1: /Users/leo/.ssh/config line 216: Applying options for moxijump
debug1: /Users/leo/.ssh/config line 257: Applying options for *
debug1: Reading configuration data /opt/homebrew/etc/ssh/ssh_config
debug1: auto-mux: Trying existing master at '/Users/leo/.ssh/master-leo@11.89.9.55:22023'
debug1: Control socket "/Users/leo/.ssh/master-leo@11.89.9.55:22023" does not exist
debug1: Connecting to 11.89.9.55 [11.89.9.55] port 22023.
debug1: Connection established.
debug1: identity file /Users/leo/.ssh/id_rsa type 0
debug1: identity file /Users/leo/.ssh/id_rsa-cert type -1
debug1: identity file /Users/leo/.ssh/id_ecdsa type -1
debug1: identity file /Users/leo/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/leo/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/leo/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/leo/.ssh/id_ed25519 type -1
debug1: identity file /Users/leo/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/leo/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/leo/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/leo/.ssh/id_xmss type -1
debug1: identity file /Users/leo/.ssh/id_xmss-cert type -1
debug1: identity file /Users/leo/.ssh/id_dsa type -1
debug1: identity file /Users/leo/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.6
debug1: Remote protocol version 2.0, remote software version Go
debug1: compat_banner: no match: Go
debug1: Authenticating to 11.89.9.55:22023 as 'leo'
debug1: load_hostkeys: fopen /Users/leo/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /opt/homebrew/etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /opt/homebrew/etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
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: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-rsa SHA256:d8kxnBwTQQp0O05+cGNPpAf494Rsdf+jdCEnYuo
debug1: load_hostkeys: fopen /Users/leo/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /opt/homebrew/etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /opt/homebrew/etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '[11.89.9.55]:22023' is known and matches the RSA host key.
debug1: Found key in /Users/leo/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /Users/leo/.ssh/id_rsa RSA SHA256:6ZfT0O8kiR6EdSRmC5IKMOuGG0pFBQxKpqsdColjYhE
debug1: Will attempt key: /Users/leo/.ssh/id_ecdsa
debug1: Will attempt key: /Users/leo/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/leo/.ssh/id_ed25519
debug1: Will attempt key: /Users/leo/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/leo/.ssh/id_xmss
debug1: Will attempt key: /Users/leo/.ssh/id_dsa
debug1: Offering public key: /Users/leo/.ssh/id_rsa RSA SHA256:6ZfT0O8kiR6EdSRmC5IKMOuGG0pFBQxKpqsdColjYhE
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /Users/leo/.ssh/id_ecdsa
debug1: Trying private key: /Users/leo/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/leo/.ssh/id_ed25519
debug1: Trying private key: /Users/leo/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/leo/.ssh/id_xmss
debug1: Trying private key: /Users/leo/.ssh/id_dsa
debug1: Next authentication method: password
Summary
SSH clients and servers should support SSH-RSA key types without the need for explicit specification. In most cases, such specification is unnecessary.
If your key can be used to connect to multiple servers without additional configuration, and only one server requires explicit specification of PubkeyAcceptedKeyTypes ssh-rsa, this may indicate that the server has configured a stricter security policy or that there may be server-specific configuration issues.
One possible reason is that the SSH configuration on the server has explicitly disabled certain key types or restricted the accepted key types. In this case, the client needs to ensure compatibility with the server by explicitly specifying PubkeyAcceptedKeyTypes ssh-rsa.
If this configuration is specific to a particular server and not a global configuration, you can specify this option for that server in the SSH configuration file (usually ~/.ssh/config) without affecting the configuration of other servers.
Although this situation is relatively rare and not the default configuration, in some specific environments, such additional configuration may be necessary to ensure the normal operation of SSH connections.
Rabbit Blog使用微信扫描二维码完成支付
