If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below. ** If you are logged in, most ads will not be displayed. **

Mahela007 got it right.
Asymmetric encryption is used:
- to exchange the generated session key (which is symmetric). The public/private pair of the server are used here.
- to authenticate the user. This is, where the userīs public/private key comes into the game.

Symmetric encryption is used:
- for the connection encryption.

So basically:
- asymmetric encryption for the initialization of the connection
- and symmetric encryption for the "heavy lifting", aka data transfer (shell, filetransfers, etc)

Mahela007 got it right.
Asymmetric encryption is used:
- to exchange the generated session key (which is symmetric). The public/private pair of the server are used here.
- to authenticate the user. This is, where the userīs public/private key comes into the game.

Symmetric encryption is used:
- for the connection encryption.

So basically:
- asymmetric encryption for the initialization of the connection
- and symmetric encryption for the "heavy lifting", aka data transfer (shell, filetransfers, etc)

haha,thank you. but, let's imagine you're right, please, explain me, how the symmetric encryption works here? I thought it should use one key for encryption and decryption. And I thought encryption here is needed for making secure connection only, right?

What is symmetric encryption?
- You need the same key to encrypt and decrypt

What are the advantages of symmetric encryption?
- relatively easy in design
- therefore the CPU usage is low (compared to asymmetric encryption)
So it is desireable to use that for ssh.

But you need to ensure:
- that the Session Key is good. That is: long and random enough
- that the Session Key is exchanged in a *secure* way.

You cannot send it plaintext.
Anyone with a networksniffer would be able to decrypt your connection -> The encryption effort is just a waste of time and effort.

This is there the asymmetric encryption helps.

What is asymmetric encryption?
- You have a key pair. Public and Private key
- What is encrypted with one, can be decrypted with the other
- This is why a public key can be transmitted plaintext.

So, the client gets the Public Host Key (White key with H in the picture).

Ah, I am sorry. Contrary to what I have written earlier, the Session Key is generated on the Client -not on the Server-, using random data.
This Session Key is encrypted, using the Public Host Key, that the client now has.
The encrypted Session Key is then sent to the server.
The server decrypts the Session Key, using its Private Host Key. (Black key with H)

Now both client and server have the same Session Key and thanks to asymmetrical encryption, it is ensured, that the transmission was safe.

The mentioned requirements for using symmetrical encryption have been met.
So a symmetrical connection can be established.

Ok, that chapter is over. We do have a secure connection
Now the authentication process can begin.

It uses another set of key pair: The Black&White with U
Letīs assume the Public User Key is already known to the server. ie: It is in the authorized_keys2 file
Then the server will use that Public User Key to encrypt some random data
and send it to the client.
The client is supposed to answer with the decrypted data.
It can only do that, if it has the right Private User Key.
BTW: Thatīs why it is so important to keep the private keys safe.
If the client answers correct, then the Userīs authentication has been proven.

The user finally gets a shell

Uff, lots of typing for a sunday morning.
But at least I have 250 posts now.
I am a linux user now
(What was I the last 13 years then? )

What is symmetric encryption?
- You need the same key to encrypt and decrypt

What are the advantages of symmetric encryption?
- relatively easy in design
- therefore the CPU usage is low (compared to asymmetric encryption)
So it is desireable to use that for ssh.

But you need to ensure:
- that the Session Key is good. That is: long and random enough
- that the Session Key is exchanged in a *secure* way.

You cannot send it plaintext.
Anyone with a networksniffer would be able to decrypt your connection -> The encryption effort is just a waste of time and effort.

This is there the asymmetric encryption helps.

What is asymmetric encryption?
- You have a key pair. Public and Private key
- What is encrypted with one, can be decrypted with the other
- This is why a public key can be transmitted plaintext.

So, the client gets the Public Host Key (White key with H in the picture).

Ah, I am sorry. Contrary to what I have written earlier, the Session Key is generated on the Client -not on the Server-, using random data.
This Session Key is encrypted, using the Public Host Key, that the client now has.
The encrypted Session Key is then sent to the server.
The server decrypts the Session Key, using its Private Host Key. (Black key with H)

Now both client and server have the same Session Key and thanks to asymmetrical encryption, it is ensured, that the transmission was safe.

The mentioned requirements for using symmetrical encryption have been met.
So a symmetrical connection can be established.

Ok, that chapter is over. We do have a secure connection
Now the authentication process can begin.

It uses another set of key pair: The Black&White with U
Letīs assume the Public User Key is already known to the server. ie: It is in the authorized_keys2 file
Then the server will use that Public User Key to encrypt some random data
and send it to the client.
The client is supposed to answer with the decrypted data.
It can only do that, if it has the right Private User Key.
BTW: Thatīs why it is so important to keep the private keys safe.
If the client answers correct, then the Userīs authentication has been proven.

The user finally gets a shell

Uff, lots of typing for a sunday morning.
But at least I have 250 posts now.
I am a linux user now
(What was I the last 13 years then? )

thank you for such a long respond, but I still didn't see where you use here the same code for encryption and decryption. OK then, I'll find out it myself.
And congratulations on becoming a linux user

Check this out mzv: Very usefull.Inside SSH-1 (SSH, The Secure Shell: The Definitive Guide)
Errmm.. I just have one more little question. Could you please check if the following is correct?
"When the client computer sends the session key for the first time over to the server, it [the session key] is encrypted with the public key of the host. Now, this transfer is secure because although the public key of the server is available to anyone, information encrypted using the public key is can only be decrypted with the private key of the server [which is secret]