I am setting up a series of our servers to accept no-password logins from one server running Nagios, so that Nagios can run remote service checks on those servers automatically. I am using SSH public key authentication to do this.

How secure is this method? Sure you need the key to be able to authenticate, but in theory if someone got a hold of this key they could just log straight in to any one of my servers right? Am I right that this key must initially be transmitted in plain text - if so, wouldn't it be fairly simple to intercept?

Cheers

naturally you do have the concern of being able to bounce recklessly between a group of systems, but that's the point. the system is underpinned by managing the point of entry into that key authenticated environment, so you should have the confidence that no one can get access to one account to then go onto the others. in your case no one should be able to get onto a given account on your nagios box. you should also compare this to the chance of someone knowing the same password that you always use on dozens of boxes.

additional the key is manually placed on the peer, not automatically in ssh terms. most common way to transfer the key would be be via an ssh connection itself, i.e. you've already logged in and then paste the text into an ssh session on another box, or copy it over scp / sftp. so it's most likely to be totally secure to implement, but you *could* do it in a "dumb" way if you wanted to. but it costs a lot of money to hire someone to sky write an entire DSA key, and then arranging all your sysadmins to look up at the sky at the same time is a logistical nightmare!

Also, you can create a passphrase for the key when creating it so that if someone did get your key, they would still need to know your passphrase to use it.

Thanks guys. Not quite what I meant about the key being transferred in plaintext though, or maybe I am misunderstanding something? Hypothetical scenario:

- Hacker realises I have a Nagios box monitoring a number of servers via SSH authentication.

- Hacker uses man-in-the-middle attack or packet sniffing to monitor traffic going to/from Nagios server.

- Eventually one of those packets is going to contain my key, presumably in plaintext?

- Game over.

Also, slightly off topic but sometimes when I set up a user account on a server using 'adduser', set a password and then try to log in via SSH, I just keep getting asked for a password even though I enter the correct one time after time. Anyone run into this before?

no, the key isn't about encryption, it's about authentication. a secure ssh connection is established in a first phase before the key parts are compared. maybe what you should be asking is why can't you do a MITM attack on the cryptography side of things?

In an RSA/DSA auth setup, you initially create your public/private key pair on the local system. Then you copy your public key to the remote system(s).

At connection time, the remote system says to yours "hey, can you encrypt this random message with your private key, and I'll see if I can decrypt it with your public key". Your client encrypts the message with your private key, sends it over the connection, and the remote host tries to decrypt it. If it can decrypt it against your public key and get the same thing back that it sent out, then it knows that you are who you say you are, and authenticates you. If it fails, then you drop down to some other method (eg: keyboard-interactive).

At no point, after the initial setup, is either key transmitted over that connection. At no point, ever, is the private key transmitted (and the public key is non-sensitive information).

Also of interest is Diffie-Hellman key exchange. Basically, it's an algorithm where you go from shared-nothing to shared-secret without ever transmitting the secret.

SSH doesn't protect you from the remote host being completely compromised, and someone brute-forcing your password out of /etc/shadow. But it does protect you against someone eavesdropping.

Complich8 - brilliant explanation. However I thought it would have worked the other way around, i.e. the remote host would encrypt a message with the public key and ask the server to decrypt it with it's private key. If anyone could decrypt a private-key message with a public key, wouldn't that defeat the purpose?

You can go either way: messages encrypted with the public key can only be decrypted with the private, and messages encrypted with the private key can only be decrypted with the public.

If I encrypt something against my private key, anyone with my public key can decrypt it, and thus prove to themselves that I have the paired private key and am who I claim to be (ie: it's a signature). Similarly, anyone can encrypt against my public key and be confident that only I (or someone with my private key) can read it.

Slightly more formally, e(k2,e(k1,m)) = e(k1,e(k2,m)) = m (where k1,k2 are the key pair, m=message, e(k,m) = encrypting the message m with the key k)

In the context of SSH, I'm pretty sure the way I specified is the way that makes sense to do. Consider: either way you go (I encrypt you decrypt, or you encrypt I decrypt), there's an encryption, a decryption, a transmission of the message, and the transmission of the ciphertext that all have to happen.

However, asking the client to sign rather than to decrypt is clearly a little bit better, because sshd can have an arbitrary number of allowed keys on a given account.

If the server is going to ask the client "decrypt this string", then the server's going to have to send the client the ciphertext for every authorized_key entry that it has, and wait to see whether one of them is the right one. What's worse is that the client can't even tell (since it doesn't know the randomly-chosen plaintext), so it's just gotta compute that decryption on every message that gets sent, and send the result back. On the other hand, if the server's asking the client for the ciphertext of this string, then it doesn't have to transmit the information that it has N keys and the ciphertext for all of them. Rather, it transmits "here's a message, gimme the ciphertext" and then does it's own decryption against the keys in authorized_keys until it finds a match or runs out of them.

So rather than having both sides to N encryption/decryption operations, only the server has to to that many. Further, the server doesn't leak that information about how many keys it's got lying around. Moreover, the "you decrypt these things" protocol necessarily means more data transferred to accomplish the same thing. So "here, encrypt this to tell me who you are" is pretty much the clear winner.