LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices



Reply
 
Search this Thread
Old 10-31-2007, 09:27 AM   #1
moistTowelette
Member
 
Registered: Sep 2003
Posts: 79

Rep: Reputation: 15
SSH Public Key Authentication - how secure is it?


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
 
Old 10-31-2007, 09:48 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,415

Rep: Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968
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!
 
Old 10-31-2007, 09:59 AM   #3
69_rs_ss
Member
 
Registered: Jan 2004
Location: NY, USA
Distribution: Arch, openSUSE 11.1
Posts: 170

Rep: Reputation: 31
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.
 
Old 10-31-2007, 10:15 AM   #4
moistTowelette
Member
 
Registered: Sep 2003
Posts: 79

Original Poster
Rep: Reputation: 15
Ssh

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?
 
Old 10-31-2007, 10:49 AM   #5
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,415

Rep: Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968Reputation: 1968
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?
 
Old 10-31-2007, 02:56 PM   #6
complich8
Member
 
Registered: Oct 2007
Distribution: rhel, fedora, gentoo, ubuntu, freebsd
Posts: 104

Rep: Reputation: 15
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.

Last edited by complich8; 10-31-2007 at 03:00 PM.
 
Old 10-31-2007, 05:12 PM   #7
moistTowelette
Member
 
Registered: Sep 2003
Posts: 79

Original Poster
Rep: Reputation: 15
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?

Last edited by moistTowelette; 10-31-2007 at 05:16 PM.
 
Old 10-31-2007, 06:47 PM   #8
complich8
Member
 
Registered: Oct 2007
Distribution: rhel, fedora, gentoo, ubuntu, freebsd
Posts: 104

Rep: Reputation: 15
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh public key authentication teacup Linux - Networking 4 11-28-2011 12:27 AM
Public Key Authentication with SSH edafe Ubuntu 1 08-26-2006 12:06 PM
ssh public key authentication setup mikewgilligan Linux - Security 7 07-12-2006 09:54 PM
Can't use public key authentication with SSH Noob69 Linux - General 5 01-06-2006 07:27 AM


All times are GMT -5. The time now is 04:35 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration