Hi guys,
My question is about passwordless SSH.

is it possible that a system generates a key and whichever system has that key, should be able to SSH that system
But
this SSH should be passwordless.

Note: I think it is possible with Amazon servers where they give you a key (like .pem, .ppk or else) and whoever has that key, can access their server.

Have any idea ???

Thanks.

Yes, this is possible.

1 members found this post helpful.

I'm not seeing a special case here, is this not just default preshared keys?

1 members found this post helpful.

on a linux system (centos in my case) you would follow these steps:

that will give you access to that server using ssh keys, you can leave the key without a password if you wish.

also, one file it creates is something.pub which contains the plaintext key you would put on a server that you wish to access using your corresponding private-key file.

i like to think of the public key as the LOCK, and the private key as the KEY.

a quick google search of 'passwordless ssh' will give you examples for any OS you can think of.

1 members found this post helpful.

Hi,
Thanks for sharing for your thoughts.

TenTenths:
Could you please elaborate ? The process, how can I do that in my RHEL systems ?

acid_kewpie:
Please let me explain it to you that how it is not a normal case !!

Generally what we do for password-less SSH it that:
Suppose there are two systems. One is a physical system (server) and one is my laptop (both have linux OS).

Now, i want to SSH from my laptop to that server.

For that, I will create a key pair in my laptop (id_rsa, id_rsa.pub) without any passphrase (so that it could be password-less). I will copy my laptop's '.pub' key into server system as 'authorized_keys' file and I will be able to SSH that server system from my laptop without password.

So far so good.

But now consider the scenario that if there are multiple laptops who want to SSH that server (password-less), then I am supposed to create a keypair in each laptop and then copy each '.pub' key into that server. That way could be problematic because if a particular laptop is not required to SSH that server, then I will have to remove that laptop's public key from servers 'authorized_keys' file. Every time, doing the same is not good.

The solution could be that, a key should be provided by the server to any laptop owner.
If the owner has that key, he will be able to SSH that server otherwise not.

Thats what I asked in my question that "is it possible that a system (server) generates a key and whichever system has that key, should be able to SSH that system".

In this way, this is not a normal case which we do usually.


szboardstretcher:
Thanks for the solution but the solution you have provided is not fit for the situation.

According to your solution, I should create key pair in my laptop and copy the '.pub' key to the server which I don't want to do. (as mentioned in my earlier paragraph). (I want somewhat reverse process).


#############

I think I have found a possible solution.

Sharing it with you guys:

The only problem I am having in this solution is that, this solution fails if I reboot the system.
Every time i have to follow the whole procedure which is not good.

Any comment for this guys ?

Thanks.

As far as i can tell, you've done exactly what i explained, but in a less efficient manner.

Yes, this is called security. You DO NOT want to use ONE key for everyone. You want to use individual keys.

There is no one that is going to agree that using one ROOT SSH key for X people is a good idea. You are doing it wrong and you need to stop and think about the consequences.

Seriously.

1 members found this post helpful.

Let me get this straight...

The standard method is that each client has its own key, and the keys for all authorized clients are added to the authorized_keys file on the server. If you want to add a client, you add its key to the authorized_keys file. If you want to remove a client, you remove its key from the authorized_keys file.

You want to replace this system with one in which there is ONE key required to access the server, and that same key is distributed to every client that you want to grant access. Adding a client means sending this shared key to the client. Removing a client means generating a new key on the server, and sending it to every single client EXCEPT the one that you want to remove access.

How on earth is this better or more efficient than the standard way? It's akin to assigning every employee in an organization the same login and password, and having to change that shared login and password for everybody in the entire organization every time an employee quits or gets fired. The logistical and security nightmare this would introduce boggles the mind.

2 members found this post helpful.

you can have multiple 'lines' in the authorized_keys file

one for each key


instead of
>> is append to file,
> just the one will overwrite it

and you shouldn't need to use eval $(ssh-agent)

just a simple ssh-agent should suffice, but in all honesty, I don't see why it is needed at all



As already pointed out, no 'special case' here, you are doing very standard things in a complicated way.

https://access.redhat.com/site/docum...-keypairs.html
see it doesn’t explicitly tell you how, I think the writer(s) assume the ready reader has the 'basics'


EDIT:

Please Note the chmod commands in the link I gave, they are important for the security of your keys

1 members found this post helpful.

@rohitchauhan: Ok, you seem to be confused about what you're doing... What you want is not a 'reverse process' of key-authentication.. Rather, you simply want to:

1) As you said... create a key, give it access and provide it to everyone (it won't matter if multiple laptops connect with the same key)... But as you we're already told.. This will be less secure and even troubling when you want to restrict someone's access.

-- or --

2) Create one key per user... Actually, I don't understand why everyone doesn't have their own account? That's the proper way to do it (and trust me, it's nothing special about it).

Please keep in mind that (from the command you've shown us) you're giving root access... 'root' shouldn't even be allowed to connect remotely (not even through ssh)

P.S. The efficient way is that everyone creates a key on their laptop.. and install it to their user account on the server... See the first post from 'szboardstretcher' about the two needed commands to do this..

3 members found this post helpful.

YIKES! I didn't even notice that.

Granting ssh access to root is bad
Granting passwordless ssh access to root is even worse
Granting passwordless ssh access to root for anybody who holds the magic key is quite possibly the worst security setup I have seen mentioned on this or any other forum

1 members found this post helpful.

hell, I didn't see that either !

Due to some fancy editing, i can say that i noticed that before.

Thanks to everyone for their valuable replies.

szboardstretcher:
1. Yes, you are right.I know that there are serious security concerns. I understand sharing server's private key is not a good idea but i will have to go ahead with that. I understand that but unfortunately i can not do much about it other then telling my client about them.

2. Giving root access is required as there are few people who are in development team and they need root access (we can consider them as trustworthy). So giving password-less root access can be allowed at least until project finishes. I don't know why client is not using SUDO but thats their concern.

3. The working solution for me:
The same process can be done for multiple servers.

Very very thanks to every one again.

If managing the keys is a problem, remember also that you can configure SSH to use keys obtained from an LDAP server.

The bottom line here, though, is that you do want each authorized user to be uniquely identified, using a unique certificate that is issued only to him, is therefore identified as being "his," and can be individually revoked or replaced. That is what keys are for. It is of no advantage to you at all, merely that the exchange between the two systems is encrypted. You need to be able to open and to shut the door to recognizeable, and recognized, individuals."