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

Using amazon's EC2 Service, which is awesome in every regard.

Only problem is, I have problems logging in with the SSH keys they automatically genarate. I have no idea what the problem is, but have no desire to look any further, as I need to get back to working on my application. ...

tl;dr; So, what are the security implications that make SSH keys so much stronger than 20+char long passwords? From my understanding SSH keys primarily protect against brute force attacks - but if I created a username and password with 20 or 64+ charectors...how much more secure would using keys be?

share|improve this question
add comment

3 Answers

up vote 8 down vote accepted

Well, a typical SSH key is somewhere around 1024 or 2048 bytes. That's a chunk longer than any password you're going to type in a reasonable amount of time. The whole advantage to ssh keys is that your key password (you do set passwords on your ssh keys, right?) is effectively a proxy to the higher security of the key.

The big advantage to keys is that your password never traverses the network. A relatively common attack is to install a trojaned version of the ssh server; when people type in passwords, the modified server records them and sends them elsewhere. This is a particular problem because these same passwords often are used for access to a number of systems/services.

ssh keys largely eliminate this problem.

Ssh keys are usually simple to set up. You stick the public key on the remote system in the appropriate authorized_keys file, and configure your local ssh to present the appropriate private key when you connect. If you're having some specific problems we can probably help you work things out.

share|improve this answer
Just to clarify your answer, SSH public/private keys completely eliminate the "hacked SSH server recording your password" problem. A public/private key pair can be used for one side to authenticate the other, without ever getting the credentials. So recording one authentication will not allow you to falsify another authentication. The one potential security problem would be if using ssh-agent someone can steal the agent connection. Using "ssh-add -c" prevents this by requiring that you confirm every authentication attempt. –  Sean Reifschneider Nov 23 '10 at 2:43
ubderstood, that makes cents. Thank you for answering the question logically, and answering it on the basis of overal security, and what it actually prevents/protects. –  triple Nov 23 '10 at 2:50
add comment

A 20 character password is at most 640 bits of entropy (4 byte characters, 20 characters), and that's assuming a completely random unicode password involving 4-byte characters is used. For Ye Olde 8-bit ascii that's closer to 140 bits. And most passwords are not completely random.

A generated SSH keypair is a lot longer then that, generally between 1024 and 2048 bits but not limited to that, and can be password protected for extra protectional credit.

share|improve this answer
add comment

Realistically if the system has reasonable rate limiting a 20+ character password that uses Upper & Lowercase, Numbers, and Symbols is practically unbreakable. SSH keys are significantly harder to break, there's no question they are more secure. If the system does not have rate limiting your taking a serious risk (one I wouldn't take, even for my home computer). Sometimes good enough is all you need though. There are other factors to consider, be sure to use a unique password, and other normal password precautions apply

share|improve this answer
add comment

Your Answer


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

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