Setting Up Keys between Linux Servers
-
I found a great walkthough for how to setup keys between your Linux servers. This is really handy so you can authenticate via a username and password to one SSH server and then not have to keep typing passwords once your on a server.
The link is here: http://www.clearcenter.com/support/documentation/clearos_guides/setting_up_ssh_trust_between_two_servers
First, run...
ssh-keygen -t rsa
Just press enter to accept the defaults. Next, we get the server to trust itself.
cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
Now we need to copy the files for the trust to the other machine(s) on our network.
scp -r /root/.ssh* target_hostname:/root/
Repeat this for each machine you want to setup trust between. This will need to be done from each machine to every other machine. If you've SSH'ed from the original machine to other machines before, before you start testing the keys, I would clear out your known_hosts file and start fresh.
vi /root/.ssh/known_hosts
Once inside that file, just press dd until you've cleared out all the lines in the file. Then do Esc and :wq and hit Enter.
Now, if you type...
ssh target_hostname
....it should log you in without a password. I log in as root on all my machines, so if you need to use a different username, type...
ssh username@hostname
Anyways, this took only a few minutes to setup but it's been a huge time saver already! My only public facing SSH server is my jump server and it's password is quite secure. Hope this helps someone else!
Thanks,
A.J. -
@thanksaj said:
Next, we get the server to trust itself.cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
That's not normal. Most of the time you don't do that.
-
@thanksaj said:
vi /root/.ssh/known_hosts
Once inside that file, just press dd until you've cleared out all the lines in the file. Then do Esc and :wq and hit Enter.
This is not advised as it disables a security mechanism. There is no need for this. And if you did need to do it, this is not how to do it. Just do echo '' > /root/.ssh/known-hosts to clear it out. No need to edit it.
-
@scottalanmiller said:
@thanksaj said:
vi /root/.ssh/known_hosts
Once inside that file, just press dd until you've cleared out all the lines in the file. Then do Esc and :wq and hit Enter.
This is not advised as it disables a security mechanism. There is no need for this. And if you did need to do it, this is not how to do it. Just do echo '' > /root/.ssh/known-hosts to clear it out. No need to edit it.
That works too. Is that two single quotes or a single double quote?
-
@scottalanmiller said:
@thanksaj said:
Next, we get the server to trust itself.cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys
That's not normal. Most of the time you don't do that.
What would be the result if you didn't do this?
-
@thanksaj said:
@scottalanmiller said:
@thanksaj said:
vi /root/.ssh/known_hosts
Once inside that file, just press dd until you've cleared out all the lines in the file. Then do Esc and :wq and hit Enter.
This is not advised as it disables a security mechanism. There is no need for this. And if you did need to do it, this is not how to do it. Just do echo '' > /root/.ssh/known-hosts to clear it out. No need to edit it.
That works too. Is that two single quotes or a single double quote?
Either. You are just passing a null.
-
@thanksaj said:
What would be the result if you didn't do this?
You would not be able to SSH to the localhost (loopback). Sometimes you want that, but you want to know that it is there or else it can be a security hole. I've seen shops that disallow it. It's a fine thing to do and is often done on management machines, but you just want to know that you are doing it.
For example, this would work fine without a password....
ssh localhost
-
@scottalanmiller said:
@thanksaj said:
What would be the result if you didn't do this?
You would not be able to SSH to the localhost (loopback). Sometimes you want that, but you want to know that it is there or else it can be a security hole. I've seen shops that disallow it. It's a fine thing to do and is often done on management machines, but you just want to know that you are doing it.
For example, this would work fine without a password....
ssh localhost
Why would you ssh to the machine you're already on? That seems pointless...
-
@thanksaj said:
Why would you ssh to the machine you're already on? That seems pointless...
Makes adding the key to do so by default seem like an odd process then
There are reasons to do it like for uniform management scripts, triggering an external connection type, etc. But it is rare and should be thoughtful.
-
@scottalanmiller said:
@thanksaj said:
Why would you ssh to the machine you're already on? That seems pointless...
Makes adding the key to do so by default seem like an odd process then
There are reasons to do it like for uniform management scripts, triggering an external connection type, etc. But it is rare and should be thoughtful.
I suppose...I think they do it so that when you scp the files to the other machines, they are good to go.
-
@thanksaj said:
I suppose...I think they do it so that when you scp the files to the other machines, they are good to go.
You mean so that they automatically connect anywhere with a single key set in a matrix "any to any" configuration? That makes sense, although that setup is not advised. That makes every machine a root level jump box to every other machine. It's a security nightmare. If you are going to do that at the very least do it via Chef or Puppet. But better to just use Jump and storage boxes and not allow machines to just openly hack each other.
I prefer, normally, having a highly lean and secured and well monitored Jump box and having all key connections being one way and not at root level. The combination is very secure. Doing a root key mesh is highly insecure. Any breach is a total breach.
-
@scottalanmiller said:
@thanksaj said:
I suppose...I think they do it so that when you scp the files to the other machines, they are good to go.
You mean so that they automatically connect anywhere with a single key set in a matrix "any to any" configuration? That makes sense, although that setup is not advised. That makes every machine a root level jump box to every other machine. It's a security nightmare. If you are going to do that at the very least do it via Chef or Puppet. But better to just use Jump and storage boxes and not allow machines to just openly hack each other.
I prefer, normally, having a highly lean and secured and well monitored Jump box and having all key connections being one way and not at root level. The combination is very secure. Doing a root key mesh is highly insecure. Any breach is a total breach.
I'm not worried about it, tbh. The only public-facing server at the SSH level is my jump server, and the password is fully complex and 23 characters.
-
It's always best practice to disable root login over SSH, especially from the Internet; use su or sudo for root access. Another good practice is to disable password-based authentication; only use keys with a passphrase. The setup you're doing here is useful for allowing scripted/automated connections between machines (e.g. for backups, scheduled tasks, etc) but they should be accounts with limited access, not root. You should be creating layers that make it difficult for someone to gain access to your systems; root keys with no passphrase means you're solely relying on that one strong password (which is one keylogger away from being defeated.)