在我每天使用的 Oracle/RedHat VM 上(可能是在每晚升级之后),我遇到了此身份验证错误:
$ ssh machine
Bad packet length NNNNNNN. ssh_dispatch_run_fatal: Connection to A.B.C.D port NN: Connection corrupted
更加调试的视图:
$ ssh -vvvv machine
...
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
...
debug1: Local version string SSH-2.0-OpenSSH_9.3p1 Ubuntu-1ubuntu3.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
...
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
...
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128-cbc
debug2: ciphers stoc: [email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha1,[email protected],hmac-sha2-512
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_ECDH_REPLY received
...
debug3: send packet: type 21
debug2: ssh_set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: ssh_set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
...
debug2: pubkey_prepare: done
debug3: send packet: type 5
Bad packet length VERY_LONG_NUMBER.
debug2: sshpkt_disconnect: sending SSH2_MSG_DISCONNECT: Packet corrupt
debug3: send packet: type 1
ssh_dispatch_run_fatal: Connection to a.b.c.d port xyz: Connection corrupted
添加 我的客户端机器是 Ubuntu
$ ssh -V
OpenSSH_9.3p1 Ubuntu-1ubuntu3.2, OpenSSL 3.0.10 1 Aug 2023
答案1
我也遇到过这个问题。
我可以解决这个问题ssh -c [email protected]
答案2
这回答的麦克·奎因完全拯救了我。我想补充一点背景信息来澄清一下。
更明确的答案示例可能是:
ssh -c [email protected] [email protected]
其中-c
是cipher_spec
来自 SSH 手册 ( man ssh
):
-c cipher_spec
Selects the cipher specification for encrypting the
session. cipher_spec is a comma‐separated list of
ciphers listed in order of preference. See the Ciphers
key‐word in ssh_config(5) for more information.
man 5 ssh_config
并按照 SSH_config 手册( )中的建议进行操作:
Ciphers
Specifies the ciphers allowed and their order of
preference. Multiple ciphers must be comma‐separated.
If the specified list begins with a ‘+’
character, then the specified ciphers will be
appended to the default set instead of replacing
them. If the specified list begins with a ‘‐’
character, then the specified ciphers (including
wildcards) will be removed from the default set
instead of replacing them. If the specified list
begins with a ‘^’ character, then the specified
ciphers will be placed at the head of the default
set.
The supported ciphers are:
3des‐cbc
aes128‐cbc
aes192‐cbc
aes256‐cbc
aes128‐ctr
aes192‐ctr
aes256‐ctr
aes128‐[email protected]
aes256‐[email protected]
chacha20‐[email protected]
The default is:
chacha20‐[email protected],
aes128‐ctr,aes192‐ctr,aes256‐ctr,
aes128‐[email protected],aes256‐[email protected]
The list of available ciphers may also be obtained
using "ssh ‐Q cipher".
在配置中使用可以是:
Host host.example.com
Port 22
User user
Ciphers [email protected]
答案3
对于那些寻求实际解释和服务器端修复的人来说:
看起来像Oracle 发布修复了水龟攻击于 2024 年 2 月 1 日在他们的 openssh-server 软件包中。更新后的软件包版本是openssh-server-8.0p1-19.el8_9.2.x86_64
。
将 openssh-server 降级到版本8.0p1-19.el8_8
将恢复更新并且 SSH 将再次工作,尽管这可能不明智。
我认为最明智的解决方案是禁用CHACHA20-POLY1305
密码,如这邮政。
由于以下(其他)错误,我仍然无法通过 SSH 进入我们的 OL 服务器:
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to A.B.C.D port 22: message authentication code incorrect
我还禁用了AES-*-CTR
密码,例如
# cat /etc/crypto-policies/policies/modules/TERRAPIN.pmod
cipher@ssh = -CHACHA20* -AES-*-CTR
ssh_etm = 0
# update-crypto-policies --set DEFAULT:TERRAPIN
# systemctl restart sshd
这将导致自动密码检测,aes128-gcm
应该足够安全
$ ssh -v <client>
...
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
2024 年 2 月 16 日更新:Oracle 发布了针对此问题的修复程序, 包裹openssh-server-8.0p1-19.0.1.el8_9.2.x86_64
可以通过如下方式恢复此解决方法:
# rm /etc/crypto-policies/policies/modules/TERRAPIN.pmod
# update-crypto-policies --set DEFAULT
# systemctl restart sshd