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.
Q-9: What does the User (client) Key-pair allow to happen? Does it allow the Client to speak with the Server? Or does it allow the Server to speak with the Client?
Basically, it allows the client to login to the server without having to type in a username/password. If password authentication is disabled you now have a system that can not be accessed by "brute force" attacks.
Q-8: It appears that this new Public-Key on the Server is located here: ~/.ssh/id_rsa.pub Correct?
Yes.
Q-7: This new Public-Key on my Server would still be called the User (client) Public-Key, right? (After all, all I did was "share" it with the Server.)
Yes, it is not the same thing as the server public key.
Q-9: What does the User (client) Key-pair allow to happen? Does it allow the Client to speak with the Server? Or does it allow the Server to speak with the Client?
Basically, it allows the client to login to the server without having to type in a username/password. If password authentication is disabled you now have a system that can not be accessed by "brute force" attacks.
So from my local machine I can log in to my server, and once the connection is established, communications can flow from CLIENT to SERVER back to CLIENT back to SERVER and so on, right?
Q-10: If the Server ever wanted to connect to my local machine (client), then would I need a Public/Private Key-pair set up the opposite way?
That is, there would be a Host (server) Private-Key on the Server and would have to be a Host (server) Public-Key installed on my local machine?
Q-10: If the Server ever wanted to connect to my local machine (client), then would I need a Public/Private Key-pair set up the opposite way?
Not necessarily, A key pair is just one type of ssh authentication. You could write a script with a valid username/password to execute commands on your local machine.
Q-11? So from my local machine I can log in to my server, and once the connection is established, communications can flow from CLIENT to SERVER back to CLIENT back to SERVER and so on, right?
Yes, basic ssh is a remote login terminal. It would be just like typing commands in a terminal window on your local machine. It can do secure file transfers i.e. scp, sftp and much more.
So from my local machine I can log in to my server, and once the connection is established, communications can flow from CLIENT to SERVER back to CLIENT back to SERVER and so on, right?
Q-10: If the Server ever wanted to connect to my local machine (client), then would I need a Public/Private Key-pair set up the opposite way?
That is, there would be a Host (server) Private-Key on the Server and would have to be a Host (server) Public-Key installed on my local machine?
From what I read on another website, Public-key Authentication involves TWO key-pairs, and it implies that you need one pair called the User (client) Key-pair to connect from the local machine to the server, and then you need a second key-pair called a Host (server) Key-pair to connect/talk the other way...
Nothing online or in forums seems to cover or explain this so that it is clear how things work. (Thus my comment that I question how many people really understand this!)
Public-Key pair is one method used to authenticate the client to the server which is on a per user basis. Yes, once authenticated communication is bidirectional.
The private key is on the client and the public key on the server. If your remote computer needed to connect to your local machine in the same manner your local computer is now the server and the remote computer the client. The local computer would have the public key and your remote the private key. They can be the same key pair saved in the same manner.
- The Public-Private key-pair is created using ssh-keygen
- The Private-Key is located here: ~/.ssh/id_rsa
- The Public-Key is located here: ~/.ssh/id_rsa.pub
- Using cPanel, the Public-Key is copied over to the server
- Now the Public-Key is located here on the server: /home/rob/.ssh/id_rsa.pub
- Now the Public-Key is located here on the client: ~/.ssh/id_rsa.pub
- The Public-Key on the server is copied to these files: /home/rob/.ssh/authorized_keys AND /home/rob/.ssh/authorized_keys2
Yes, The authorized_keys2 could be a backup if you imported more then once. The private key is only used by the client and the public only used by the host even though they were created and exist in ~/.ssh/
What might be interesting for you is enable the ssh server on your Mac and then you can play with keys and logging to yourself which makes you the server and client at the same time.
Problem is that the 2nd link is an example of all the CRAP on the Internet.
The article says:
Quote:
The mathematical relationship between the public key and the private key allows the public key to encrypt messages that can only be decrypted by the private key. This is a one-way ability, meaning that the public key has no ability to decrypt the messages it writes, nor can it decrypt anything the private key may send it.
Am I to assume that when I SSH in to my server, that the "handshake" between my local machine and the server follows a similar process to how you would send a "digital signature"?
Isn't there a *reliable* source out there (i.e. NOT Digital Ocean) that explicitly talks about each step that happens when you SSH in to a server from a local machine where asymmetric crytography has already been established?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.