Setting Up Keys between Linux Servers

scottalanmiller

@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.

scottalanmiller

@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.

thanksajdotcom

@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?

thanksajdotcom

@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?

scottalanmiller

@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.

scottalanmiller

@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

thanksajdotcom

@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...

scottalanmiller

@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.

thanksajdotcom

@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.

scottalanmiller

@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.

thanksajdotcom

@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.

jasonh

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.)