for ssh without password, are both ways correct

Now I need to ssh to a Linux Machine B from another Linux or Mac or Windows with Putty (Machine A). I've seen two ways to do that.
1. Generate public and private key on Machine A. Send the public key to Machine B and add it to authorized keys file. And now Machine A can ssh to Machine B without any password.
2. Generate public and private key on Machine B. Send the private key to Machine A. And now Machine A can ssh to Machine B with B's private key.

So are both ways correct? What are the differences? Thanks.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Kent WSr. Network / Systems AdminCommented:
That's how you do it. It's not two different ways, you just shared each machines public keys with each other. Instead of one way, you setup bi-directional.
Scott SilvaNetwork AdministratorCommented:
technically the private keys should stay on the system that generates them... Hence the term "private keys"
condor888Author Commented:
Hi mugojava, first of all, I only need one-way, that is, from machine A to machine B. Also, please pay attention to that for way 1, it is sending the public key while for way 2, it is sending the private key. Would you please give me your thought? Thanks!
Your Guide to Achieving IT Business Success

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

condor888Author Commented:
@scott_silva, so are you saying only the first way is the right way? I only need one direction, that is from Machine A to Machine B.
There are two ways to facilitate access from server a to server B' services One option is tge direct path connecting from server a to server b including requisite local tunnels to the services on b that need to accessed from A. The other option is the connection is initiated from server b to server A with remote tunnels which provide user/s on server A access to services on server b.

The ssh connection itself is a one way connection meaning the user initiating the connection can do things within that session it can not be overtaken/used........ By others.
condor888Author Commented:
Then why for AWS, it gives you a key (private key?) in order to connect to their server? @scott_silva
Kent WSr. Network / Systems AdminCommented:
I misread your #2.  I would use method one. I have not tried method 2. Generally in rsa based access you generate and share the public key with machines you want to access. Not the other way around. I'm not even sure that works. I'll have to try it.
Phil PhillipsDevOps ArchitectCommented:
Both of those ways will work. It doesn't matter where you generate the private/public key pair. As long as a machine is set up with the public key, you can use the private key to gain access to it. The main thing to remember is after generating the pair, and distributing the public key, you will want to limit access to your private key.
Scott SilvaNetwork AdministratorCommented:
"Then why for AWS, it gives you a key (private key?) in order to connect to their server? @scott_silva "

Just because someone does it doesn't make it right... The original premise of public/private key encryption was that you never shared the private key because then someone can pretend to be you...

Why it is called "public/private"

In the case of AWS, you get the private key because you are the controlling entity... The key is generated for you, but technically you would be generating the keys from your access system to administer your server... Therefore you get the private key.
Jason CarsonComputer TechnicianCommented:
The private key belongs on the client side(Machine A)

The public key belongs on the server(Machine B)

As to where you generate your public/private keys it can be done with either Machine. If  you generate the public/private keys on Machine A then copy the public key to Machine B. If you generate your private/public keys on Machine B then copy the private key to Machine A. You don't need to generate pairs on both machines.

If you have several client machines it's advisable that each have its own private/public pair for security reasons. For example, if one of your client devices was stolen you can pull the corresponding public key from the server without affecting other client machines. In the end this would mean each client machine has a unique private key and the corresponding public keys would be added to the server.
AWS likely provides you the private key to the public key they setup on the VM server's ssh authorized_keys. Not sure they do not have password authentication.
condor888Author Commented:
Here is a paragraph that I got from Amazon: "A key pair consists of a public key that AWS stores, and a private key file that you store. Together, they allow you to connect to your instance securely. For Windows AMIs, the private key file is required to obtain the password used to log into your instance. For Linux AMIs, the private key file allows you to securely SSH into your instance." So it looks like we are using the private key to SSH into the AWS instance. So it is method 2. Am I right?
Yes and no, it is more, third party generates a key pair provides the private key to you and adds the public key to the server/s to which you are granted access.
The mechanism is likely automated such that only the recipient/user has access to the private key with the option of regenerating/recreating.... minimizing exposure of possible rogue employee accessing/disseminating private keys. .... while the public key is added to the server/servers/application to which it is destined...
Did you get the private key during account setup????? i.e you signed up, selected your server/services, generated the key pair, you had the private key displayed/offered for download ........
Kent WSr. Network / Systems AdminCommented:
Arnold is spot on there, - put another way,
Method 2 is technically correct, but how AWS is implementing is looking at YOU as a "jump box" of sorts. If you were to ssh from a location with putty or another linux box TO AWS (assuming you were setting them up with keys yourself), you would generate the private key locally, upload the public key to AWS servers, and connect with something containing the private key to the publicly keyed AWS servers.
Basically, AWS does this for you, places the public key on your boxes, and give you the private key to store / implement as you choose. You are still connecting form the private key file to the public keys.  It's just the way they make this available seems backwards, at first.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
condor888Author Commented:
Arnold, when you setup the server, it will let you download the private key. So does it mean that instead of using your own private key generated on your own machine, AWS generated the key pair for you, put the public key on the server and let you use the private key to login?
I think it is a measure of security; with this setup they do not allow password based authentication. Without the key, no access, you can not guess the key. you can not brute force the key. etc.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SSH / Telnet Software

From novice to tech pro — start learning today.