ssh key-exchange - how can the server verify the client?
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?
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?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Dave Howe
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.
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. :(
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.