Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have accounts on several third party sites - Bitbucket, Bluehost, etc.

From what I've gathered, it is common practice to use one key pair for all [id_rsa, id_rsa.pub], but only to give out the public key

Is that the correct usage, or is it better to generate a new pair for each site?

It would seem to me that this is insecure - any site I trust with nefarious intention [or that is hacked] could take my private key when I connect the first time, and use it to go into the other sites.

Can someone who understands SSH verify that its safe to use one key pair everywhere, and if so, perhaps explain why?

Also, if I have two home computers, is there any reason to use different key pairs from each?

Thanks all.

share|improve this question

migrated from stackoverflow.com Dec 29 '11 at 13:32

This question came from our site for professional and enthusiast programmers.

4 Answers 4

up vote 16 down vote accepted

Your private key is never sent to the other site so it's perfectly safe to reuse the public key. It's also OK to reuse the same key your local computers. However, bear in mind that if someone steals the key, they then have access to all of them. This may or may not be a concern.

share|improve this answer
1  
Of course, if you protect your SSH key with a passphrase, they can even steal it and still wont be able to use it. :) –  StrangeWill Dec 29 '11 at 17:02
2  
Unless the passphrase is easy to brute-force. –  Vincent Dec 29 '11 at 17:03
6  
So what you're saying is I should change my passphrase on my SSH keys from "hunter2" to something else? –  StrangeWill Dec 29 '11 at 17:16
5  
Like "correct horse battery staple"? –  Jay Bazuzi Jan 2 '12 at 18:43

There are several pairs of key in SSH. The one your are talking about is the client key pair. The client (i.e. the machine which is on your desk, under your physical control) stores the private key -- and the private key is never sent to the server. The public key is stored on the server (typically in the $HOME/.ssh/authorized_keys file).

When the client connects to the server, the client uses the private key to demonstrate to the server that he controls the private key, and can do computations with it (namely a digital signature). The server verifies the signature thanks to the public key. Knowledge of the public key does not give the power to generate new signatures, which is why it is called a "public" key: it can be made public, with no ill effect. In particular, copying your public key on any number of servers does not give power to any of these servers over the other servers, be they honest or completely controlled by an attacker.

As @artbristol points out, that's the private key which is important. If you copy your public key to ten servers, and someone steals the private key (possibly by hacking into your desktop system, or physically purloining it), then that someone gains immediate access to the ten servers in one go. Private keys are valuable.

share|improve this answer

It would seem to me that this is insecure - any site I trust with nefarious intention [or that is hacked] could take my private key when I connect the first time, and use it to go into the other sites.

Can someone who understands SSH verify that its safe to use one key pair everywhere, and if so, perhaps explain why?

Public keys work based on challenge authentication. Basically, you give several sites your public key, so each site can issue a challenge to you. This challenge is unique every time and can only be answered by a person with a private key.

A simplified example would be if the server takes your public key and encrypts a message like "The session key for user X at Dec 19th 16:30:03.351213 UTC is XPa7sK35WjMgAezrPmG1Sq4CV7nsFN1Uc3TRW6P8Evc". Your client computer receives the encrypted message, decrypts it with your private key, and then sends back the decrypted session key to the server, validating that you have the private key in your possession upon which the server authenticates you. (In practice its often more complicated with the server typically has public/private host keys, so you can encrypt your messages to the server and authenticate that the server is who it says it is).

Having your public key doesn't give a malicious server extra methods of attack with the exception of trying to factor the modulus from your public key to recreate your private key. This is only possible if your key is too small, that is 512-bit keys were cracked a decade ago, 768-bit RSA keys were reported cracked last year (with about 10^20 operations; or 2000 years on a single core of a modern processor); 1024-bit keys are still safe, and the ssh default is 2048-bit keys.

share|improve this answer

This document has all the details about how public key authentication works in SSH. I've summarized it below.

The client sends the following packet:

data type   description/value

byte      SSH_MSG_USERAUTH_REQUEST
string    user name
string    service
string    "publickey"
boolean   TRUE
string    public key algorithm name
string    public key to be used for authentication
string    signature

where signature is a signature using the private key over the following data:

string    session identifier
byte      SSH_MSG_USERAUTH_REQUEST
string    user name
string    service
string    "publickey"
boolean   TRUE
string    public key algorithm name
string    public key to be used for authentication

The server then looks to see if the specified public key is authorized for the given public key (@ThomasPornin discusses how this is done in his answer). The server then checks to make sure the signature is correct (this is done using the public key). If that succeeds, then authentication is successful.

As you can see (and as pointed out in @artbristol's answer), the private key is never transmitted to the server. You only have to prove that you know the private key by sending the digital signature.

share|improve this answer

Your Answer

 
discard

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.