Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
You're not googling the wrong terms. It's just a complicated thing around public-key-encryption (which uses public keys to encrypt and private keys to decrypt -- the goal being transmitting a message in a secure manner) and digital signatures (which uses private keys to encrypt a hash of the message and public to decrypt that hash).. It just so happens that the RSA algorithm which supports both is the most commonly used algorithm for this... That's why we can be both right depending on what we mean by encryption and signing (and specially because the ssh server provides, to my knowledge, an encrypted challenge rather than simply taking a signed message -- this might be counter-intuitive??)...
And btw, Ok, I agree that I shouldn't have used statements like "This is completely wrong" ..
L.E.: Now you've made me doubd myself so I also started googling...
Last edited by Smokey_justme; 07-15-2016 at 08:50 PM.
Ok, So I googled and I googled... And it seems that the challenge-response thing is not used any more for public/private keys (although this is the most found result on the internet)... In this aspect, now when authenticating against a SSH server, the signing (what you would call encrypting with a private key) and verifying (what you would call decrypting with a public key) is done on a message that can be known by both the client and the server (and because it includes the shared-key, it can't be repeated -- but at this point there's already a secure connection established and the server is already trusted)..
You're not googling the wrong terms. It's just a complicated thing
Finally something we can agree on!
Quote:
Originally Posted by Smokey_justme
around public-key-encryption (which uses public keys to encrypt and private keys to decrypt -- the goal being transmitting a message in a secure manner) and digital signatures (which uses private keys to encrypt a hash of the message and public to decrypt that hash)..
Agreed.
Quote:
Originally Posted by Smokey_justme
It just so happens that the RSA algorithm which supports both is the most commonly used algorithm for this... That's why we can be both right depending on what we mean by encryption and signing (and specially because the ssh server provides, to my knowledge, an encrypted challenge rather than simply taking a signed message -- this might be counter-intuitive??)...
Agreed.
Quote:
Originally Posted by Smokey_justme
And btw, Ok, I agree that I shouldn't have used statements like "This is completely wrong" ..
No problem.
Quote:
Originally Posted by Smokey_justme
L.E.: Now you've made me doubd myself so I also started googling...
Ok, So I googled and I googled... And it seems that the challenge-response thing is not used any more for public/private keys (although this is the most found result on the internet)... In this aspect, now when authenticating against a SSH server, the signing (what you would call encrypting with a private key) and verifying (what you would call decrypting with a public key) is done on a message that can be known by both the client and the server (and because it includes the shared-key, it can't be repeated -- but at this point there's already a secure connection established and the server is already trusted)..
when you connect, the server uses your public key to sign a challenge, and your client uses your private key id_rsa to decrypt the challenge, re-encrypt it with the server's public host key and send it back.
the host verifies that you decrypted the challenge properly, by decrypting your response with its private key, and the client/host establish an encrypted connection, based on the shared data, not on your public/private keys.
The following sequence demonstrates the conversation between client and server.
Your client says, "Hey server, I'd like to connect by SSH to an account on your system, specifically, the account owned by user smith."
The server says, "Well, maybe. First, I challenge you to prove your identity!" And the server sends some data, known as a challenge, to the client.
Your client says, "I accept your challenge. Here is proof of my identity. I made it myself by mathematically using your challenge and my private key." This response to the server is called an authenticator.
The server says, "Thanks for the authenticator. I will now examine the smith account to see if you may enter." Specifically, the server checks smith's public keys to see if the authenticator "matches" any of them. (The "match" is another cryptographic operation.) If so, the server says, "OK, come on in!" Otherwise, the authentication fails.
(*NOTE: I don't think this description is accurate - it describes using what I would consider the wrong keys.)
In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model.
---------
What is a nonce?
In security engineering, a nonce is an arbitrary number used only once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.
This sounds consistent with the first link I posted above.
Quote:
After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model. (In SSHv2 something a bit different but conceptually close is actually used)
This again sounds consistent with what I found and your link above.
And that's what I said it happens in post #31 .. Yet I was wrong and those links are wrong... That's what happened in the past in ssh1..
Now the process is described here: http://www.ietf.org/rfc/rfc4252.txt .. And this document is the official standard on authentication that every ssh client and server has to (or should) respect..
What basically happens is that at one point the client sends this message:
Code:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
where the signature is a signed (a.k.a encrypted with the private key) version of:
Code:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
The server just has to verify (a.k.a decrypt with the public key and compare to the original)... In the text, session identifier is the shared-season-key used for the actual symmetric encryption throu out the whole season (which at this point is already generated and known by both the client and server)..
P.S. Also search for the Authentication section in http://man.openbsd.org/ssh (what better than the manual to clear things up)
Last edited by Smokey_justme; 07-16-2016 at 05:35 PM.
IETF and man-pages are formal sources... You can even type "man ssh" in your CLI Doesn't get more official then documents written by people who write the actual code
P.S. My links to Stackexchange where to demonstrate that many people actual though and still think like I did when I wrote post #31... I was wrong and they are wrong.
Last edited by Smokey_justme; 07-16-2016 at 05:41 PM.
And that's what I said it happens in post #31 .. Yet I was wrong and those links are wrong... That's what happened in the past in ssh1..
So everything I typed in post #50 - which is a combination of what you found and what I found - is wrong??
Quote:
Originally Posted by Smokey_justme
Now the process is described here: http://www.ietf.org/rfc/rfc4252.txt .. And this document is the official standard on authentication that every ssh client and server has to (or should) respect..
What basically happens is that at one point the client sends this message:
Code:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
where the signature is a signed (a.k.a encrypted with the private key) version of:
Code:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
The server just has to verify (a.k.a decrypt with the public key and compare to the original)... In the text, session identifier is the shared-season-key used for the actual symmetric encryption throu out the whole season (which at this point is already generated and known by both the client and server)..
What you describe looks like it is described here...
Quote:
5. Authentication Requests
All authentication requests MUST use the following message format.
Only the first few fields are defined; the remaining fields depend on
the authentication method.
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string method name in US-ASCII
.... method specific fields
The 'user name' and 'service name' are repeated in every new
authentication attempt, and MAY change. The server implementation
MUST carefully check them in every message, and MUST flush any
accumulated authentication states if they change. If it is unable to
Quote:
7. Public Key Authentication Method: "publickey"
The only REQUIRED authentication 'method name' is "publickey"
authentication. All implementations MUST support this method;
however, not all users need to have public keys, and most local
policies are not likely to require public key authentication for all
users in the near future.
With this method, the possession of a private key serves as
authentication. This method works by sending a signature created
with a private key of the user. The server MUST check that the key
is a valid authenticator for the user, and MUST check that the
signature is valid. If both hold, the authentication request MUST be
accepted; otherwise, it MUST be rejected. Note that the server MAY
require additional authentications after successful authentication.
Quote:
To perform actual authentication, the client MAY then send a
signature generated using the private key. The client MAY send the
signature directly without first verifying whether the key is
acceptable. The signature is sent using the following packet:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
I don't really understand what is being said here, other than a "signature" is created using the client's Private-Key...
Quote:
Originally Posted by Smokey_justme
P.S. Also search for the Authentication section in http://man.openbsd.org/ssh (what better than the manual to clear things up)
Sadly, I don't see anything there that describes what you say above.
IETF and man-pages are formal sources... You can even type "man ssh" in your CLI Doesn't get more official then documents written by people who write the actual code
P.S. My links to Stackexchange where to demonstrate that many people actual though and still think like I did when I wrote post #31... I was wrong and they are wrong.
Well, as you can see in post #50, I got sucked into the wrongness as well!!
These groups should hire a couple of English teachers or competent tech writers, because all of this should not be as difficult as it is!!
I appreciate your willingness to work with me towards a more updated answer to how things actually work!
So everything I typed in post #50 - which is a combination of what you found and what I found - is wrong??
Pretty much. Sorry..
Quote:
What you describe looks like it is described here...
That's exactly what it is
Quote:
I don't really understand what is being said here, other than a "signature" is created using the client's Private-Key...
Well, that's exactly what happens... Wasn't that the question? If you have follow-ups, just name them...
Quote:
Sadly, I don't see anything there that describes what you say above.
Quote:
Originally Posted by man page
Public key authentication works as follows: The scheme is based on public-key cryptography, using cryptosystems where encryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. ssh implements public key authentication protocol automatically, using one of the DSA, ECDSA, Ed25519 or RSA algorithms. The HISTORY section of ssl(8) contains a brief discussion of the DSA and RSA algorithms.
The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account.
The key here (and I'm really disapointed in myself for not paying attention to this) is that some of those protocols are signing protocols (and only private-keys sign). While RSA can do both signing and public-key-encryption, DSA and Ed25519 (I'm not sure about ECDSA and not interested enough to google) are only signing-protocols (they do have derivates for public-key-encryption, yet with different names)
A special note is that while encryption can mean different things, the meaning of signing when we're talking about private/public keys is the same everywhere... The private key signs (so anyone holding a public key can be absolutely sure you're the one that send that message). The document does not describe more details about what get's signed, it's true, but the IETF is sufficiently explicit of that matter...
Quote:
This sure is some deep stuff to follow...
It's actually not.. The harder thing as you already saw is to fight the misconceptions..
I don't really understand what is being said here, other than a "signature" is created using the client's Private-Key...
Well, that's exactly what happens... Wasn't that the question? If you have follow-ups, just name them...
Okay, you asked for it!
Quote:
7. Public Key Authentication Method: "publickey"
This method works by sending a signature created
with a private key of the user. The server MUST check that the key
is a valid authenticator for the user, and MUST check that the
signature is valid. If both hold, the authentication request MUST be
accepted; otherwise, it MUST be rejected.
What does the bold part mean?
Quote:
To avoid unnecessary processing and user
interaction, the following message is provided for querying whether
authentication using the "publickey" method would be acceptable.
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string "publickey"
boolean FALSE
string public key algorithm name
string public key blob
Public key algorithms are defined in the transport layer
specification [SSH-TRANS]. The 'public key blob' may contain
certificates.
This is Greek to me?! What does this mean?
Quote:
To perform actual authentication, the client MAY then send a
signature generated using the private key. The client MAY send the
signature directly without first verifying whether the key is
acceptable. The signature is sent using the following packet:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
Again, what does this mean in simple English?
Quote:
The value of 'signature' is a signature by the corresponding private
key over the following data, in the following order:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
This sounds like circular logic when compared to the above paragraph.
Sorry, but I am not following what is being said...
Quote:
When the server receives this message, it MUST check whether the
supplied key is acceptable for authentication, and if so, it MUST
check whether the signature is correct.
How does it check whether the supplied key is acceptable?
How does it check whether the signature is correct?
A special note is that while encryption can mean different things, the meaning of signing when we're talking about private/public keys is the same everywhere... The private key signs (so anyone holding a public key can be absolutely sure you're the one that send that message).
Got it!
Quote:
Originally Posted by Smokey_justme
The document does not describe more details about what get's signed, it's true, but the IETF is sufficiently explicit of that matter...
Yeah.
Quote:
Originally Posted by Smokey_justme
It's actually not.. The harder thing as you already saw is to fight the misconceptions..
Well, there is certainly TONS of outdated or wrong information on this topic out there on the Internet!!
Ok.... So at this point it's really, really hard for me to understand what you don't understand ) .. But I'll try..
So, before getting into the questions let's make some things clear:
-- We make abstraction of the protocol used for this data to be transmited, we don't care how the ssh protocol works, we only care what original data that is sent by the client and the final data that is received by the server (and/or vice-versa).. The only piece of information we do care about from how ssh works is the shared-key (that is already known by both client and server without ever being transmited over the wire). It's also important to note that we do care that at this point the server is trusted and the connection encrypted (but again, how that happened is another subject, we should mix them).
-- We make abstraction of the algorithm used.. For us, signing should mean that a mathematical formula is applied on the specific data by making use of the private key and verifying should be that a mathematical formula is applied on a signed data using the public key to recover the original data.
The easiest to mimic here would be RSA algorithm code where RSA.decrypt would be used for signing, and RSA.encrypt whould be used for verifying (this is not a mistake). That simple line of code expressing a simple mathematical formula is actually enough to get us where we need to go.
-- We make abstraction of any extra verification steps.. In real-life, real problems are not resolved with just one line of code... But we don't care about sanity checks, length checks and all that..
-- We don't play with certificates, while it's pretty much the same thing it will only complicate our process... When you understand how a pair of keys work and what certificates are, you won't have any problems understanding how authentication with them works.
-- When we have structures we should think of them like writing information on a piece of paper, one item per line..:
Code:
byte SSH_MSG_USERAUTH_REQUEST //this is 1 byte, and can be any number between 0-255.. Here it will be the exact constant that is defined to be SSH_MSG_USERAUTH_REQUEST in the SSH protocol
string user name //This is defined as a UTF-8 string by the standards.
string service name //This is defined as an ASCII string by the standards.
string "publickey" // This is a string that should literally be "publickey".
boolean TRUE // A byte that should be 1
string public key algorithm name //Just a string
string public key to be used for authentication //Just a string.
string signature //string.
These are protocol fields and we shouldn't care how these are actually transmited.. Imagine writing them into a piece of paper and then giving them to a secretary to either fax them, mail them or e-mail them.. All you care is that in the end, exactly this information will get to the desired destination.. A note should be that strings are, if there is no other explicit requirement, null-terminated (that means the special character 'null' is appended to it... Google this if you don't understand what it is..).. Anyway, understanding types and all these requires understanding a bit of programming (preferably C)
Now:
Code:
7. Public Key Authentication Method: "publickey"
This method works by sending a signature created
with a private key of the user. The server MUST check that the key
is a valid authenticator for the user, and MUST check that the
signature is valid. If both hold, the authentication request MUST be
accepted; otherwise, it MUST be rejected.
The bold part here means exactly what is said... The server will receive the clients request, it will check if the key-ring is accepted on the server (e.g. by checking for the public key in ~/.ssh/authorized_keys) and if it is it will run the mathematical formula for verifying the signature (e.g. RSA.encrypt) and compare the outputed string with the original string... If all fits, you're authenticated.
Read more on the next questions..
Code:
To avoid unnecessary processing and user
interaction, the following message is provided for querying whether
authentication using the "publickey" method would be acceptable.
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string "publickey"
boolean FALSE
string public key algorithm name
string public key blob
Public key algorithms are defined in the transport layer
specification [SSH-TRANS]. The 'public key blob' may contain
certificates.
Well, this basically means that the client can start sending these type of data to the server without asking first if the publickey method is acceptable as an authentication protocol... The server will check it's setting if it accepts this authentication, will check the user name field if it's a valid user, the service name if it's a valid service for that user (e.g. maybe we want SFTP for file transfers, not a shell), it will check the public key algorith name (e.g. rsa) and will check if it supports that algorithm, and finally it will verify the public key blob field with the users accepted public-keys.
It will give back a response depending on what he finds..
Code:
To perform actual authentication, the client MAY then send a
signature generated using the private key. The client MAY send the
signature directly without first verifying whether the key is
acceptable. The signature is sent using the following packet:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
The client MAY send (usually if the previous request was successful). As you can see this is very similar to the package we saw above but the boolean field is now set to TRUE and has appended a signature field. Now imagine on the last line you would simply write one long string with all that information again, only this time in an ecrypted form (e.g. using the RSA.decrypt function).. That's your signature for the paper... That's how you tell everyone that you're the one who wrote this.. And that's what we call signing
Well, almost, because in our case the signature field that is defined as:
Code:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
This is not circular logic because the server only knows the session identifier field.. That doesn't need to be transmitted to him in the clear..
But anything else needs to be transmited both encrypted for the server and unencrypted so the server knows how the original fields looked like so he can successfully verify the signature. (special note: nothing is actually transmitted in the clear, the protocol is already encrypted, yet the signature field can't even be understood by the server without the correct public-key). Also, the server wouldn't even know what algorithm to apply if you wouldn't first tell him, in the clear...
So, in the end, the server will check if the user exists and can authenticate with that service, if he can authenticate using that public-key, and then take the signature and run the verify algorithm on it (e.g. RSA.encrypt).. Then compare the resulting fields:
--session identifier should match what he already knows is the session identifier
--user name should match with what he received as an unencrypted string
--service name should match whit what he received as an unencrypted string
--and this goes on...
If all this happens, you're who you say you are..
Last edited by Smokey_justme; 07-17-2016 at 08:20 AM.
Ok.... So at this point it's really, really hard for me to understand what you don't understand .. But I'll try..
So says the crypto-wizard!
Quote:
Originally Posted by Smokey_justme
So, before getting into the questions let's make some things clear:
-- We make abstraction of the protocol used for this data to be transmited, we don't care how the ssh protocol works, we only care what original data that is sent by the client and the final data that is received by the server (and/or vice-versa)..
-- We make abstraction of the algorithm used.. For us, signing should mean that a mathematical formula is applied on the specific data by making use of the private key and verifying should be that a mathematical formula is applied on a signed data using the public key to recover the original data.
-- We make abstraction of any extra verification steps.. In real-life, real problems are not resolved with just one line of code... But we don't care about sanity checks, length checks and all that..
-- When we have structures we should think of them like writing information on a piece of paper, one item per line..:
I was under the assumption that the client encrypted a simple code and sent it over to the server for verification. However, it appears instead that the client sends over a "data structure" - to use a programming term - to the server instead.
Quote:
Originally Posted by Smokey_justme
Now:
Code:
7. Public Key Authentication Method: "publickey"
This method works by sending a signature created
with a private key of the user. The server MUST check that the key
is a valid authenticator for the user, and MUST check that the
signature is valid. If both hold, the authentication request MUST be
accepted; otherwise, it MUST be rejected.
The bold part here means exactly what is said... The server will receive the clients request, it will check if the key-ring is accepted on the server (e.g. by checking for the public key in ~/.ssh/authorized_keys) and if it is it will run the mathematical formula for verifying the signature (e.g. RSA.encrypt) and compare the outputed string with the original string... If all fits, you're authenticated.
Okay.
Quote:
Originally Posted by Smokey_justme
Read more on the next questions..
Code:
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
This is not circular logic because the server only knows the session identifier field.. That doesn't need to be transmitted to him in the clear..
But anything else needs to be transmited both encrypted for the server and unencrypted so the server knows how the original fields looked like so he can successfully verify the signature. (special note: nothing is actually transmitted in the clear, the protocol is already encrypted, yet the signature field can't even be understood by the server without the correct public-key). Also, the server wouldn't even know what algorithm to apply if you wouldn't first tell him, in the clear...
So, in the end, the server will check if the user exists and can authenticate with that service, if he can authenticate using that public-key, and then take the signature and run the verify algorithm on it (e.g. RSA.encrypt).. Then compare the resulting fields:
--session identifier should match what he already knows is the session identifier
--user name should match with what he received as an unencrypted string
--service name should match whit what he received as an unencrypted string
--and this goes on...
If all this happens, you're who you say you are..
Let me put into my own words what I think you are saying...
The client wants to connect to the server. The client must send a message to the server requesting access.
The message includes the following information in plain-text...
Code:
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
The message also includes a signature which is encrypted. The signature has the above info plus a "session-identifier".
Everything looks like this...
Code:
****PLAIN-TEXT***********************************************************
SSH_MSG_USERAUTH_REQUEST 50
user name robserv5
service name ssh-userauth
publickey publickey
TRUE TRUE
public key algorithm name RSA
public key AB3MzaC2ycDMt6kSRyePUGI...
signature ===>
^^^^^ENCRYPTED^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
session identifier 12345
SSH_MSG_USERAUTH_REQUEST 50
user name robserv5
service name ssh-userauth
publickey publickey
TRUE TRUE
public key algorithm name RSA
public key AB3MzaC2yckSRyePUGI...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*************************************************************************
When the server receives this authentication request, it first compares the username and public-key against what it has in its authorized_keys file. If the username and public-key match, then the server knows the public-key being submitted is valid. The server continues checking the request.
Next the server decrypts the client signature (which was encrypted with the client's private-key) by using the copy of the client's public-key which it keeps on file in its authorized_keys file.
If the server is able to decrypt the signature, then the server knows the client is the owner of the public-key on file, and thus a valid user.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.