Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi all, I'm a little bit confused about asymmetric key cryptography, particularly the use of RSA keys with SSH.
I have used ssh keys successfully in the past, but only after much headache and not much understanding. My comprehension is this: there is a public and private key, which when combined, allow a user to login.
My question is essentially which key goes where?
I have tried reading several posts and articles online, but they are mostly way above my head and the jargon does not make sense to me. I believe the private key is carried with the user, as in a "license" or fingerprint that is individually owned by a user. I think the public key stays on the remote server (the machine that is connected to during ssh 168.x.x.x ??), and the private key is on the local machine from which you are initiating the ssh session.
If that is true, then how does the private key stay private? Doesn't that schema mean the private key is transmitted over the network to the remote server, to be checked against the public key and accepted/rejected? or is the public key transmitted by the remote server to the local machine? In that case, how can the remote machine verify the local machine is authorized to connect?
The public key goes onto the remote server you are going to connect to.
The private key stays on the local client you are going to connect from.
During authentication, the actual private key never leaves the client. Instead, the client takes some identifying session data and signs it with the private key. The server then checks using the public key to see if the signature is valid.
The keys never need to be combined. The private key stays only readable and usable by you. The public key may be given to anyone to whom you need to prove your identity. The way it works is that nobody without the private key can sign a message that the public key will verify.
The public key goes onto the remote server you are going to connect to.
The private key stays on the local client you are going to connect from.
During authentication, the actual private key never leaves the client. Instead, the client takes some identifying session data and signs it with the private key. The server then checks using the public key to see if the signature is valid.
Thanks Turbocapitalist, that makes sense. One question regarding the signature- how does the server know what a valid signature looks like? The link you provided (great resource btw thank you for that) makes it sound like there must be some information that is shared plain text over the network in order to do the signature verification.
Thanks Turbocapitalist, that makes sense. One question regarding the signature- how does the server know what a valid signature looks like? The link you provided (great resource btw thank you for that) makes it sound like there must be some information that is shared plain text over the network in order to do the signature verification.
I think this has what you are looking for (under the section "Asymmetrical Encryption")
Just FYI, the asymmetric encryption and signing keys are two different keys, they have to be because using a key for both gives away info about it.
A signature scheme is basically a MAC with non-repudiation. It basically hashes the message using a hash function and then applies a keyed asymmetric signing transform (decryption). Whoever receives the message and the signature can check it by encrypting the signature and checking the hash.
As said above, think of the public key as a lock (only for encryption) and the private key as a key (only for decryption).
Thanks Turbocapitalist, that makes sense. One question regarding the signature- how does the server know what a valid signature looks like? The link you provided (great resource btw thank you for that) makes it sound like there must be some information that is shared plain text over the network in order to do the signature verification.
The signature verification comes after the encrypted connection between the machines is already established. So no clear text is transmitted. Here's a description of the SSH connection process (if the link works) http://www.linuxjournal.com/article/9566
For key-based authentication, the server has a priori the public part of the public/private key pair. In other words, that type of authentication cannot take place if the keys are not already in place first. Then if a private key was used to sign something then the matching public key, and only the matching public key, works to verify the signature (public key cryptography).
The signature verification comes after the encrypted connection between the machines is already established. So no clear text is transmitted. Here's a description of the SSH connection process (if the link works) http://www.linuxjournal.com/article/9566
This is incorrect according to the article: the signature verification is used to establish the encryption keys in the first place, so the signature itself can't be encrypted.
Quote:
We know how to compute the individual encryption and MAC keys provided that we derive the basic parameters using the simple equation above. But, how do we get the parameters to begin with, in a secure, authenticated manner?
...we use a known and trusted server public key to authenticate key exchanges. Authentication of key exchange data is nothing more than signing with a private key. And, OpenSSH typically uses ssh-dsa or ssh-rsa keys for this purpose.
However, reading a signature will not reveal the private key (provided the thing signed was correctly padded), so encryption is not needed.
We know how to compute the individual encryption and MAC keys provided that we derive the basic parameters using the simple equation above. But, how do we get the parameters to begin with, in a secure, authenticated manner?
...we use a known and trusted server public key to authenticate key exchanges. Authentication of key exchange data is nothing more than signing with a private key. And, OpenSSH typically uses ssh-dsa or ssh-rsa keys for this purpose.
My reading of that is rather than the user's key it would be the server's key, the one(s) in /etc/ssh/, where the initial connection is established before authentication. However, I've not studied the transport layer protocol at all.
The purpose of this protocol is to perform client user
authentication. It assumes that this runs over a secure transport
layer protocol, which has already authenticated the server machine,
established an encrypted communications channel, and computed a
unique session identifier for this session.
So user authentication is done AFTER the encrypted session is set up.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.