the theory of SSH public and Private key and its application in realworld machines

Question

there.

In this question, I have a very specific one about public and private keys. So Public keys should be put on the opposite side. For example, if we have a server, the public key of the server should be put in the user's machine And the user's machine public key should be put into the server machine this is the theory that is telling the example with the example of Alice and Bob. they want to transfer a file within each other But my question starts here I saw many, many websites for setting up SSH via a public key and private keys (including ssh.com, windows website, raspberry pi documentation(as my server)). But I didn't see any Source that says, put the ssh public key of the server to the user's machine.

So we know the server has the user's public key so that when the server wants to send data over the SSH tunnel, it will encrypt it using the public key and the user will decrypt it using the private key. But how a user can encrypt this data to send it to the server without having the server's public key ?? I didn't see anywhere to set up this one I did the steps of mentioned trustable sites to set up SSH key authentication and it worked for me, but I cannot understand how this two-way connection is established without having the server public key. Is that true that it will transfer in the background with the first connection initially or without having the server's public key the users can receive and encrypt data from the server?

I know that was a little long question, but the idea behind this is simple, and I think something is not true here or something is misunderstood by me. So I will appreciate if you help me to solve this.

Answer 1

my question starts here I saw many, many websites for setting up SSH via a public key and private keys (including ssh.com, windows website, raspberry pi documentation(as my server)). But I didn't see any Source that says, put the ssh public key of the server to the user's machine.

RFC 4251

"4. Architecture

4.1 Host Keys

Each server host SHOULD have a host key. Hosts MAY have multiple host keys using multiple different algorithms. Multiple hosts MAY share the same host key.
[...] The server host key is used during key exchange to verify that the client is really talking to the correct server. For this to be possible, the client must have a priori knowledge of the server's public host key.

Two different trust models can be used:

o The client has a local database that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure, and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain.

o The host name-to-key association is certified by a trusted certification authority (CA). The client only knows the CA root key, and can verify the validity of all host keys certified by accepted CAs.

The second alternative eases the maintenance problem, since ideally only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible. Also, a lot of trust is placed on the central infrastructure."

https://www.rfc-editor.org/rfc/rfc4251#page-4

Answer 2

In public/private key cryptography, there has to be a means to exchange each other's public key. If you transmit it just before using it, over the same channel, a MITM attacker could exchange the key with their own and listen in on and modify the whole encrypted communication.

So, the best practice is to transmit the public key using another channel. The second best approach is to transmit the public key just once and store it permanently. Since an SSH client requires the server's public key and vice versa, that just the thing to do.

how a user can encrypt this data to send it to the server without having the server's public key ?

It can't, see above. If your SSH client simply accepts the server's transmitted public key while connecting that'll work, but in an insecure way.