Remote machine has password "asdFGH12" for user named "user". I'm able to log in even if I type in password "asdFGH12dasdkjlkjasdus" or any other characters after the "asdFGH12" string.

$ ssh -v
OpenSSH_5.2p1 FreeBSD-20090522, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to [] 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 '' 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_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
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
Have a lot of fun...

Is this a known behavior of (certain) SSH server versions?

  • What OS is this? – slm Apr 23 '13 at 11:59
  • 1
    My ssh daemon ( OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012 ) does not allow me to add extra characters after the password. – Anthon Apr 23 '13 at 12:01
  • 1
    Problem is definitely with the hashing scheme. DES/traditional crypt hashing truncates or pads all given passwords to eight characters so the hashing algorithm will work. I'd wager you're using a traditional unix variant, most BSD's and Linux distros have at least been at md5 by default for the last decade or so. – Bratchley Apr 23 '13 at 12:14

This is not a limitation on the part of your SSH server, this is a limitation on the part of your server's password hash algorithm.

When hashing passwords on Unix, the crypt() function is called. This may use one of many backends, a possibility is using DES, or another limiting algorithm (for this particular case, I will assume your server is using DES). DES is generally not used by default in modern operating systems because it results in a particularly bad limitation: password strength and validation is limited to 8 bytes.

This means that if your password was set as "foobarbaz", it becomes "foobarba", usually without a warning or notice. The same limitation applies to validation, which means that "foobarbaz", "foobarba", and "foobarbazqux" all validate for this particular case.


I suspect you're OS is using DES password encryption, which only supports a maximum of 8 characters.


From man crypt(3)


The glibc2 version of this function has the following additional features. If salt is a character string starting with the three characters "$1$" followed by at most eight characters, and optionally terminated by "$", then instead of using the DES machine, the glibc crypt function uses an MD5-based algorithm, and outputs up to 34 bytes, namely "$1$<string>$", where "<string>" stands for the up to 8 characters following "$1$" in the salt, followed by 22 bytes chosen from the set [a–zA–Z0–9./].
The entire key is significant here (instead of only the first 8 bytes).

You can check your pam setup to see whether you're using MD5 or 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

You can also confirm which hashing function your system is using with this command:

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

And you can see in this systems /etc/shadow file that it's using MD5 as well:

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

The codes you'll see in the /etc/shadow for each type of hashing:

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

You can reconfigure your system with this command:

% authconfig --passalgo=sha512 --update

Any existing passwords will need to be regenerated, you can use this command to force users to reset them the next time they login:

% chage -d 0 userName


  • 2
    Checking the PAM config will only tell you what the system is using right now, not what was used to encrypt the password that the user is using. It is possible for them to be different if it was ever changed. – Chris Down Apr 23 '13 at 12:20
  • Sorry this was as hot question, I couldn't type the answer as fast as everyone was thinking 8-). – slm Apr 23 '13 at 12:27
  • Note that authconfig is generally specific to RHEL (and derivatives). – Chris Down Apr 23 '13 at 12:28
  • 1
    if authconfig specific then alternate option is grep ENCRYPT_METHOD /etc/login.defs – Rahul Patil May 25 '13 at 20:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.