Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

What is the longest (how much characters) for SSH password?

I like strong and long password but dont know the character limit.


share|improve this question
Why not just use RSA instead of an incredibly long password that you will have to write down to remember? –  MDMarra Apr 4 '10 at 0:35
Use a key instead and disable logins without a key if you really want it to be secure. –  Dave Holland Apr 4 '10 at 0:37
It actually makes sense to have a long password if you use keys -- it makes the keys the easiest way in, not the hardest. Make a crazy-long password, write it down, lock it up, and only use it in emergencies. Writing down your passwords is a Good Thing if you keep it safe. People are better at safeguarding things as opposed to ideas. –  tylerl Apr 4 '10 at 1:35
tylerl, credits to Bruce Schneier for your last sentence :) –  Shadok Mar 1 '11 at 11:16

3 Answers 3

There is no fixed maximum length. Your password is not stored, a "salted hash" of your password is stored, usually in the /etc/shadow file, which is always of a particular length. Even if your password is 50+ characters, the hashed representation of the password will be much smaller.

By all means use strong passwords, but passwords are meant to be easy to use and memorable - if you make it too long, you might end up needing to write it down, which would probably be a bigger security concern than a shorter password.

share|improve this answer
There may be a limit in the SSH client or server, or in the protocol itself. (Goblin was asking specifically about a SSH password.) –  grawity Apr 4 '10 at 13:02
"SSH password" doesn't really mean much. If the question is about "passwords protecting ssh private keys", there's still no fixed maximum length on openssh... –  user39644 Apr 26 '10 at 5:17
"Even if your password is 50+ characters, the hashed representation of the password will be much smaller." I checked out my /etc/shadow file and the hashed password for my user is way more than 50 characters at 118. (Ubuntu 12.04 LTS). This suggests to me that an extremely long password would still be beneficial. –  Programster Aug 26 '13 at 22:33

If the password is stored as DES or MD5 then only the first 8 characters are significant. SHA passwords have no such limit. See the crypt(3) man page for details.

share|improve this answer
Not really. The password is hashed to a 8-byte string by MD5, as you say, but there are limit also for SHA. SHA1 is 20 bytes (160 bits), SHA 256 is... wanna guess? –  Dan Andreatta Apr 6 '10 at 15:02
@Dan: That's the size of the resulting hash, not which characters of the password are relevant. –  Ignacio Vazquez-Abrams Apr 6 '10 at 15:11
You are right. I stand corrected. –  Dan Andreatta Apr 6 '10 at 15:26

https://tools.ietf.org/html/rfc4253 -- SSH is a secure protocol for communicating with a remote terminal, and doesn't use a password (it uses a cryptographic key negotiation). That said once you are connected to the remote terminal, you will usually see an "message of the day"(MOTD) and be asked for login credentials, the rules of which are determined by the OS of the remote terminal. (Overflowing the character buffer of the name or password field is a recurring security flaw) popular limits are 8, 32, and 255 characters in length.

share|improve this answer
telnet just connects like plain old terminal, especially a switched one like a dialup modem (if you remember those), and relays the normal login prompt etc (canonically /etc/login on Unix). SSH however handles password or other authentication in the protocol, limited both by the standardized protocol and the options enabled by both server and client. Decrement your rfc to 4252 and see especially 5.4 and 8. Oh, and SSH can be used as a general secure transport for many things, not only a remote terminal/shell, although that's a very important use. –  dave_thompson_085 Jun 25 at 23:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.