LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This 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


Reply
  Search this Thread
Old 07-15-2016, 06:42 PM   #46
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled

Quote:
Originally Posted by Smokey_justme View Post
Ok, have you tried replacing the public key and the private key and authenticate yourself?
I have not, and I'm not entirely if it would work in the context of passwordless SSH authentication.

If I could get some help understanding how the server actually verifies the client is worthy of logging in, then I could better answer your question.

But as sundialsvcs mentioned, in pure public-key cryptography terms, either key (i.e. Public or Private) can be used to lock/unlock a message.

I'm still struggling to understand why the information I am looking for is not more readily available?! Am I Googling the wrong terms?

Can someone please help me figure this out?

Last edited by RobInRockCity; 07-15-2016 at 06:46 PM.
 
Old 07-15-2016, 08:37 PM   #47
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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.
 
Old 07-15-2016, 09:48 PM   #48
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

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

References: http://www.ietf.org/rfc/rfc4252.txt and http://man.openbsd.org/ssh

Since RSA supports both, the challange-response thing that I presented in on of my previous posts and which was used in ssh1 (I think, I didn't have the patience to look for an exact date of the change) has gone unnoticed in the collective mind (e.g.: http://security.stackexchange.com/qu...ing-a-password , http://unix.stackexchange.com/questi...ing-a-password )

Well, live and learn...

Last edited by Smokey_justme; 07-15-2016 at 09:49 PM.
 
Old 07-15-2016, 10:59 PM   #49
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Smokey_justme View Post
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 View Post
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 View Post
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 View Post
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 View Post
L.E.: Now you've made me doubd myself so I also started googling...
Ha ha... Glad it isn't just me.
 
Old 07-16-2016, 03:13 PM   #50
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Smokey_justme View Post
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)..

References: http://www.ietf.org/rfc/rfc4252.txt and http://man.openbsd.org/ssh
I read those links and didn't see anything about how the server authenticates the client.


Here is what I was able to find...

http://serverfault.com/questions/142...ey-negotiation

Quote:
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.

Also...

http://docstore.mik.ua/orelly/networ...sh/ch02_04.htm

Quote:
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.)


Quote:
Originally Posted by Smokey_justme View Post
Since RSA supports both, the challange-response thing that I presented in on of my previous posts and which was used in ssh1 (I think, I didn't have the patience to look for an exact date of the change) has gone unnoticed in the collective mind (e.g.: http://security.stackexchange.com/qu...ing-a-password , http://unix.stackexchange.com/questi...ing-a-password )

Well, live and learn...
Quote:
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.
 
Old 07-16-2016, 05:28 PM   #51
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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.
 
1 members found this post helpful.
Old 07-16-2016, 05:33 PM   #52
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Does anyone know of any "official" sources that described what Smokey_justme and I found online?

While I'm sure stackexchange is reliable source, it would be nice to get verification of how all of this works from a more formal source.

Thanks.
 
Old 07-16-2016, 05:38 PM   #53
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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.
 
1 members found this post helpful.
Old 07-16-2016, 05:54 PM   #54
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Smokey_justme View Post
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 View Post
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 View Post
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.

This sure is some deep stuff to follow...
 
Old 07-16-2016, 05:56 PM   #55
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Smokey_justme View Post
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!
 
Old 07-16-2016, 09:25 PM   #56
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
Quote:
Originally Posted by RobInRockCity View Post
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..
 
1 members found this post helpful.
Old 07-16-2016, 11:00 PM   #57
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Smokey_justme View Post
Quote:
Originally Posted by robinrockcity
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?
 
Old 07-16-2016, 11:02 PM   #58
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Smokey_justme View Post
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 View Post
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 View Post
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!!
 
Old 07-17-2016, 08:13 AM   #59
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
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.
 
Old 07-17-2016, 01:47 PM   #60
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
All very deep!!

Quote:
Originally Posted by Smokey_justme View Post
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 View Post
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 View Post
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 View Post
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.

The server authenticates the client.

How does that sound?
 
  


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
Can't login as root - Debian 8.5 - authentication failed. remaining authentication methods 'publickey password' LnxRider Debian 11 07-30-2016 11:06 PM
[SOLVED] Is ssh keys authentication more secure than password authentication? GrepAwkSed Linux - Security 6 03-17-2012 08:25 PM
configure ssh authentication using password file and sftp/scp authentication using ld cameliab Linux - Software 1 08-29-2011 03:28 AM
LDAP Authentication Understanding metallica1973 Linux - Networking 4 01-02-2007 09:13 PM
Password Authentication works for TELNET... but not FTP GEEXTER Linux - General 5 07-30-2003 04:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 04:19 PM.

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
Open Source Consulting | Domain Registration