Let's try it differently:

You have 4 different things:
1) A shared secret-key or shared season key that you have no control of and is the heart of the SSH communication. This will be the first thing a SSH connection will generate (each time a new connection is made, or even several times per connection)..
2) Server fingerprint .. This is important because it's used by the client to make sure he's talking with the server he wants (this only works when the clients already knows the servers fingerprint) .. Under the hood these are basically public/private key-pair (just created with some mandatory algorithms depending on the strenght and security desired) ... These are way more important then people belive they are. Also, these key-pairs are usually created in the installation process.. That doesn't mean they can't be changed and/or backed up... Actually, it would make sense to do so, thus ensuring the same fingerprint will be available to your clients)..
3) (Client) Public key ... This only works in pair with the private key and is used by the server as part of an algoritm to encrypt data that can only be decrypted by the private key... this si an assymetrical encryption
4) (Client) Private key ... This is the important part... Only the private key can decrypt what a paired public-key encripted... This is why when the server creates a challenge for you, the client, only holding this file can you decrypt that challenge and give back the correct response (confirming, thus, that you are who you say you are)...

Out of this, numbers 1 and 2 will exists no matter what you do when you use SSH...

So... How this works (assuming use of the public/private keys):

Any connection begin with creating a shared secret key that encrypts the communication (symmetric encryption). The way this is done is out of our scope and has nothing to do with public/private key-ring, but it's one of SSHs strenghts... Everything will be encrypted with this shared key from now on.. It is important to note that an algoritm is used from which both parties can get the same shared secret, yet it will never be transmitted over the network. By this time, also, the server fingerprint would have been checked (also, by making use of some asymmetrical encryption).
Now that the connection is encrypted and you trust the server, you log in (either the old fashion way) or in our case logging in using the key-ring:
1) The client states he wants to login in using a specific ID for the public/private pair (this is why you're asked for a name -- you're not asked for a file name, but for a name given to both your public and your private keys)
2) Assuming the server finds the public key (usually in the authorized_keys file) he will generate a random challenge (think of a random number) and use that public key to asymmetrical encrypt that challenge (so there wouldn't be any possible way to decrypt it without the private key)... It then sends the resulting encrypted string to the client.
3) The client decrypts the challenge (if it has that private key), it encrypts that challange with the shared secret key and then creates an MD5-hash of that encrypted value.. It sends back that MD5 hash
4) The server does the same with the unencrypted challenge he generated and compares the two MD5-hases.. If they fit, you're authentificated.

And that's basically it..

Let me say this: A lot of people confuse the clients public/private key-ring with the shared-secret key or the servers private/public key-ring (fingerprint) and think they are used when creating that shared-secret that allows the symmetrical encryption to occur... That is false.. The user's public/private key-ring is simply used on authentification, the connection is already secured by that time.

It's not.. That's the best link of all of the links found in this thread.. That's exactly how SSH2 works..

Um, I pointed out in post #29 where that link is flat-out wrong.

Once I find blatant errors like that I just tune out...

The description above is pretty rough, and the steps seems to be out of place, but it sounds like you are describing a Digital Signature.

I suspected that using the traditional Digital Signature approach was how things worked, yet it seems odd that I haven't been ale to find any detailed (and correct) descriptions of this?!

This
is in fact CORRECT.

Symmetric encryption means the one/same key to ENcrypt AND DEcrypt.

Asymmetric encryption means ONE-WAY ie use PUB key to ENcrypt, PRIV key to DEcrypt. You can also run that backwards for Digital Signature http://www.cgi.com/files/white-paper...r_35_pki_e.pdf

Also note that this exchange (a "Diffie-Hellman Key Exchange") is only used to communicate the initial shared-secret that is then used, with fast symmetric cryptography, to subsequently encipher the actual conversation. This secret, symmetric key is replaced from time to time so that large blocks of data are not sent using the same key and thus become susceptible to a "known plaintext attack."

"Password-free" logins are actually more secure, at least from a theoretic point of view, because you must possess an authorized key. It can be problematic in practice, however, because if you can ever get your hands on the account, you can either steal an authorized key or plant one of your own. On a great many systems that I have worked with over these years, I usually found at least one authorized key that no one recognized. I basically have never found auditing of those keys.

Alternatives to this strategy do exist. There are other ways to establish what is an "authorized key," and to dictate where that key is allowed to log-in, based on the use of secure central authority such as Kerberos or LDAP (MS OpenDirectory).

I never use ssh as the first line of defense if I have any say in the matter: I always use OpenVPN with the "Dwarvish Door" strategy that I have previously described in this forum. I never directly expose anything that will allow a login: prompt to be offered to the outside world, nor one that so-easily allows a cryptographic key to be inserted by a successful intruder.

It is not correct.

You can encrypt something with the public key and decrypt it with the private key.

You can also encrypt something with the private key and decrypt it with the public key.

To say, "the public key (cannot) decrypt anything the private key may send it" is WRONG!

This could well be a case that the person who wrote this has piss-poor writing skills and didn't mean what he said, but taken literally, it is wrong. (Geek often struggle with writing things clearly...)

And since DigitalOcean got that wrong, I closed the page and move onward.

I see it's hard to stay on topic in threads...

While I appreciate the effort, I am skeptical that the steps described in 1-4 in post #31 are accurate.

Anyone else care to explain how my server authenticates me when I try to connect to it using public-key authentication?

My best guess is that the server issues a "challenge" that works like how is described in the following link under the section "Digital Signatures"...

http://www.pgpi.org/doc/pgpintro/

Does this sound correct?

Of course, PGP admittedly adds in their own twist to asymmetric cryptography, so maybe the way the server challenges me is slightly different?

I'm not sure why I can't find dozen of links that explain all of this step-by-step. Am I the only one who wants to know precisely how all of this works?

This is completely wrong... The public key can't decrypt anything the private key encrypts... Actually the private key is not meant to encrypt anything.. I don't know who told you this..

Your scenario wouldn't even make sense... Why would they be called private and public if they could be used at the same thing? And security wise that would be a total failure..

No.. It's like the "Public key cryptography" paragraph.. Digital Signatures are a different things...

I suspect that you might be mistaken on this point, Smokey . . .

"The public key can only decrypt something that the private key encrypts." Therefore, if decryption is successful, the recipient can be confident that the message must have originated from the sender. This is the basis of "message signing."

Likewise, "anything that the public key encrypts, can only be decrypted by the private key." Thus, anyone on Planet Earth can "send a private message," knowing that only the intended recipient of that message can decrypt it. This is the basis of "secure messaging."

Any operation (encryption or decryption ...) that is instigated by the holder of "one key of the pair," can only be reversed by a holder of "the other key of the pair." That is the essence of public-key encryption (PKI).

Again, see the PGP page....

http://www.pgpi.org/doc/pgpintro/

"The basic manner in which digital signatures are created is illustrated in Figure 1-6. Instead of encrypting information using someone else's public key, you encrypt it with your private key. If the information can be decrypted with your public key, then it must have originated with you."

Regardless of the different uses for Public-key Authentication versus a Digital Signature...

A Public-Key can be used to decrypt a message encrypted by a Private-Key of the same key pair.

That is a fact.

And what Digital Ocean had on their website was wrong.

Ok, have you tried replacing the public key and the private key and authenticate yourself?

Thank you!

To add to this, if the goal of Person-A was to send "launch codes" to Person-B, then it would make the most sense for Person-A to take Person-B's Public-Key, encrypt the "launch-codes", and then let Person-B use his Private-Key to decrypt things. That way only Person-B can get the "launch codes".


Using the scenario I described, Person-A could also encrypt the "launch codes" using his Private-Key, and then let Person-B use his Public-Key to decrypt the "launch codes", however, if Person-C, Person-D, and others had Person-A's Public-Key, then the "launch codes" would still be decryptable, but not very "private"!!

So using the second scenario wouldn't make sense in practical terms, yet it would still technically work.