SSH ignora i caratteri dopo la stringa di password corretta?

La macchina remota 10.10.10.1 ha la password "asdFGH12" per l'utente denominato "utente". Sono in grado di accedere anche se digito la password "asdFGH12dasdkjlkjasdus" o qualsiasi altro carattere dopo la stringa "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:~> 

È un comportamento noto di (certe) versioni del server SSH?

Questa non è una limitazione da parte del tuo server SSH, questa è una limitazione da parte dell'algoritmo di hash della password del tuo server.

Quando si esegue l'hashing delle password su Unix, crypt()viene chiamata la funzione. Questo può usare uno dei tanti back-end, una possibilità sta usando DES o un altro algoritmo limitante (per questo caso particolare, suppongo che il tuo server stia usando DES). DES non viene generalmente utilizzato per impostazione predefinita nei moderni sistemi operativi perché comporta una limitazione particolarmente negativa: la validità e la convalida della password sono limitate a 8 byte.

Ciò significa che se la password è stata impostata come "foobarbaz", diventa "foobarba", di solito senza preavviso o avviso. La stessa limitazione si applica alla validazione, il che significa che "foobarbaz", "foobarba" e "foobarbazqux" convalidano tutti per questo caso particolare.

Sospetto che il tuo sistema operativo stia utilizzando la crittografia della password DES, che supporta solo un massimo di 8 caratteri.

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

A partire dal man crypt(3)

ESTENSIONE GNU

La versione glibc2 di questa funzione ha le seguenti funzionalità aggiuntive. Se salt è una stringa di caratteri che inizia con i tre caratteri "$ 1 $" seguiti da un massimo di otto caratteri e facoltativamente terminato da "$", quindi invece di utilizzare la macchina DES, la funzione glibc crypt utilizza un algoritmo basato su MD5 e genera fino a 34 byte, in particolare "$ 1 $ <stringa> $", dove "<stringa>" indica gli 8 caratteri che seguono "$ 1 $" nel sale, seguiti da 22 byte scelti dall'insieme [a – zA -Z0-9./].
L'intera chiave è significativa qui (anziché solo i primi 8 byte).

Puoi controllare la tua configurazione di pam per vedere se stai usando MD5 o 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

Puoi anche confermare quale funzione di hashing sta usando il tuo sistema con questo comando:

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

E puoi vedere in questo /etc/shadowfile di sistema che sta usando anche MD5:

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

I codici che vedrai nel /etc/shadowper ogni tipo di hashing:

• $ 1 - MD5
• $ 2 - pesce palla
• $ 2a - pesce eksblow
• $ 5 - SHA-256
• $ 6 - SHA-512

Puoi riconfigurare il tuo sistema con questo comando:

% authconfig --passalgo=sha512 --update

Eventuali password esistenti dovranno essere rigenerate, è possibile utilizzare questo comando per forzare gli utenti a reimpostarle al successivo accesso:

% chage -d 0 userName

Riferimenti

• /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-centos-password-hashing/
• http://www.cyberciti.biz/faq/rhel-centos-fedora-linux-upgrading-password-hashing/