Solved

ssh key-exchange - how can the server verify the client?

Posted on 2015-02-23
7
234 Views
Last Modified: 2015-03-04
I thought I understood how ssh key exchange works; Once a connection is established, the server encrypts messages with the clients public key so only the client can decrypt it.

But what if more that one client has a copy of that private key? Either by design, or if a client system is cloned (or even just renamed), the copy of the key works - so a client cloned for a test  environment still has a key to the production server. The "tag" in id_rsa.pub, e.g. "root@myPC" doesn't necessarily relate to "myPC"

A client system checks the fingerprint of the server and will complain if it changes (ssh_config - StrictHostKeyChecking - unless that has been disabled); But can it be set up the other way around, so a key is only usable by a fingerprinted client?
0
Comment
Question by:tfewster
7 Comments
 
LVL 6

Assisted Solution

by:Oleksiy Gayda
Oleksiy Gayda earned 100 total points
Comment Utility
The short answer is - there should never exist more than one copy of your private key. The whole point of the public key cryptography is to assure authenticity and non-repudiability of communications, based on the fact that a specific private key is unique to a specific client. Easiest way (and, arguably, the only correct way) to fix the predicament you're describing (multiple copies of the private key existing) is to revoke and replace the compromised key. Other than that, your only chance at differentiating systems would be by a public IP address (which wouldn't help if both systems are connecting from the same NAT-ed/public IP address).
0
 
LVL 33

Expert Comment

by:Dave Howe
Comment Utility
not quite how it works.  the public key of the server is used to authenticate to the client & also protect the setup of a symmetric key used to encrypt the rest of the conversation.  over that encrypted channel,  the client authenticates using a supported method - password,  pki, kerberos token,  whatever; if that is compromised,  then the server won't know different than from the genuine user, but that is true of all systems.
0
 
LVL 33

Expert Comment

by:Dave Howe
Comment Utility
in the case where multiple users log into the system as the same account (but with different keys),  often it won't even log which key was used. :(
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 21

Assisted Solution

by:Mazdajai
Mazdajai earned 50 total points
Comment Utility
Be design. Any client with private key can have access to any servers with the correct pair of public key with no passphrase.

You can setup passphrase in the event that private key is lost and only access to the client with the correct passphrase.
0
 
LVL 20

Accepted Solution

by:
tfewster earned 0 total points
Comment Utility
Thanks to all for your comments and insights. To be fair, I didn't set up this environment so the copies of keys lying around aren't my  doing, but I need to clean it up and only allow key-pair "trust" relationships where they are truly appropriate.

I think my answer lies in `man sshd`: The section on the authorized_keys file describes the "from" option that can be put in that file on the server, e.g
             
from="tfewsters_PC.example.net" ssh-rsa  AAAAB2...19Q== just_a_tag@example.net

Open in new window

would only allow that key to be used from client "tfewsters_PC.example.net".  Wildcards and IP addresses could be used, so I could specify 'from="192.168.1.*"'  to say 'If that have the key AND they're on the (e.g. production) subnet, they're trustworthy'.

I did think about iptables, or internal firewalls, but this seems quite simple to administer and I can manage the distribution of the authorized_keys file to a group of servers
0
 
LVL 33

Assisted Solution

by:Dave Howe
Dave Howe earned 50 total points
Comment Utility
Yes. that can help a lot - if a given key is associated with a given source ip range, then limiting logins to that range can help prevent abuse. Of course, if you don't need ssh from outside your own IP range, you can lock that down completely using iptables then you won't get half of chinanet knocking on the door.... :)
0
 
LVL 20

Author Closing Comment

by:tfewster
Comment Utility
Found the solution myself. None of the Expert comments helped toward that, though they confirmed my views so partial points have been awarded.

To clarify my example scenario, I'm not really talking about PCs and end-user clients: If you have a client-server application environment or a server cluster, you may want trust relationships between the servers so e.g. a Cluster master can distribute config files to its peers/subordinates.  If the Production systems are cloned to set up a Test environment, the keys _should_ be revoked - but that step may be missed.
0

Featured Post

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (https://kb.isc.org/article/AA-01272), affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
Recently, I read that Microsoft has analysed statistics for their security intelligence report. It revealed: still, the clear majority of windows users do their daily work as administrator. An administrative account is a burden, security-wise. My ar…
Viewers will learn how to properly install and use Secure Shell (SSH) to work on projects or homework remotely. Download Secure Shell: Follow basic installation instructions: Open Secure Shell and use "Quick Connect" to enter credentials includi…
This video discusses moving either the default database or any database to a new volume.

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now