SSH会在正确的密码字符串后忽略字符吗？

远程计算机10.10.10.1的用户名为“ user”的密码为“ asdFGH12”。即使输入密码“ asdFGH12dasdkjlkjasdus”或“ asdFGH12”字符串后的任何其他字符，我也可以登录。

$ ssh -v 10.10.10.1
OpenSSH_5.2p1 FreeBSD-20090522, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 10.10.10.1 [10.10.10.1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type 0
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1
debug1: match: OpenSSH_4.1 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2p1 FreeBSD-20090522
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.10.10.1' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:58
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
Last login: Tue Apr 23 14:30:59 2013 from 10.10.10.2
Have a lot of fun...
user@server:~> 

这是（某些）SSH服务器版本的已知行为吗？

这不是SSH服务器的限制，这是服务器的密码哈希算法的限制。

在Unix上对密码进行哈希处理时，将crypt()调用该函数。这可能使用许多后端之一，可能使用的是DES，或另一种限制算法（对于这种特定情况，我将假定您的服务器使用的是DES）。在现代操作系统中，默认情况下通常不使用DES，因为它会导致特别严重的限制：密码强度和验证限制为8个字节。

这意味着，如果您的密码设置为“ foobarbaz”，则通常变成“ foobarba”，而不会发出警告或通知。验证具有相同的限制，这意味着“ foobarbaz”，“ foobarba”和“ foobarbazqux”均针对此特定情况进行验证。

我怀疑您的操作系统使用的是DES密码加密，最多只能支持8个字符。

/server/361591/ssh-accepts-only-the-half-password

从 man crypt(3)

GNU扩展

此函数的glibc2版本具有以下附加功能。如果salt是一个以三个字符“ $ 1 $”开头，然后最多八个字符，并可选地以“ $”结尾的字符串，那么glibc crypt函数将使用基于MD5的算法，而不是使用DES机器，并且输出最多34个字节，即“ $ 1 $ <string> $”，其中“ <string>”代表盐中“ $ 1 $”之后的最多8个字符，后跟从集合[a–zA中选择的22个字节–Z0–9./]。
整个密钥在这里很重要（而不是仅前8个字节）。

您可以检查您的pam设置以查看您使用的是MD5还是DES：

% egrep "password.*pam_unix.so" /etc/pam.d/system-auth
password    sufficient    pam_unix.so md5 shadow nis nullok try_first_pass use_authtok

您还可以通过以下命令确认系统正在使用哪种哈希函数：

% authconfig --test | grep hashing
 password hashing algorithm is md5

您可以在此系统/etc/shadow文件中看到它也在使用MD5：

root:$1$<DELETED PASSWORD HASH>:14245:0:99999:7:::

您会在中看到的/etc/shadow每种哈希类型的代码：

• $ 1 – MD5
• $ 2 –河豚
• $ 2a – eksblowfish
• $ 5 – SHA-256
• $ 6 – SHA-512

您可以使用以下命令重新配置系统：

% authconfig --passalgo=sha512 --update

任何现有的密码都需要重新生成，您可以使用此命令强制用户在下次登录时重设密码：

% chage -d 0 userName

参考文献

• /server/361591/ssh-accepts-only-the-half-password
• /server/129137/what-is-the-longest-password-for-ssh
• https://scottlinux.com/2011/06/25/upgrade-red-hat-c​​entos-password-hashing/
• http://www.cyberciti.biz/faq/rhel-centos-fedora-linux-upgrading-password-hashing/