Secure SSH

[Dr_Cox1911]

Hi guys,

 

I'm currently planning my switch from Debian to unRaid and thus gathering some info on how to securely set things up.

With Debian I used a rather safe mechanism consisting of key-based login with a user that has only rights to switch to other users and ssh. So I logged into this user with my key-file and then su'ed to the other user I needed.

 

Is something similiar possible with unRaid? Is it as simple as doing the exact same steps as with Debian? Anything special regarding future updates of unRaid?

[itimpi]

With unRAID you always log in as the 'root' user when using SSH.    There is no other users in the Linux sense.

[Dr_Cox1911]

So even if I create a user with the terminal?

[itimpi]

8 minutes ago, Dr_Cox1911 said:

So even if I create a user with the terminal?

It will appear to work, but then that user will be lost on a reboot as unRAID runs from RAM.

 

unRAID is set up so that all normal admin operations can be done from the GUI without the need for SSH sessions.

 

 

[Dr_Cox1911]

Thanks for the info, kinda bummer, because unRaid seems really rather unsecure then.

 

What would happen if I alter my openssh-config to forbid root login? No access would be possible then I suppose?

[trurl]

What exactly are you trying to accomplish?

 

unRAID is not debian. It isn't really even a full-blown implementation of slackware.

 

unRAID is a NAS, a host for VMs, and a host for dockers. All of that can usually be managed from the webUI. Some people do a little bash scripting, usually for additional file management, etc. But working at the command line isn't the usual way of using unRAID.

[Dr_Cox1911]

8 minutes ago, trurl said:

What exactly are you trying to accomplish?

 

Make ssh access on unRaid way more secure. As a fallback method I don't want to deactivate it but if it's a running server it should be more secured.

[itimpi]

You can make it require a key file for SSH access.   Why do you want it to be more secure than that, and why do you think that is insecure?  

 

Bear in mind that the only system level user in unRAID is 'root' which is used for admin purposes, and is not normally required for standard operation.

[Dr_Cox1911]

1 hour ago, itimpi said:

You can make it require a key file for SSH access.

How would I achieve this?

[bamhm182]

I personally added SSH keys to my root account by creating the keys normally (I had to create the ed25519 keys off-system. I forget exactly why creating them on-system wasn't working...) and putting them in /boot/config/ssh/ then I modified my /boot/config/go file (which is run during every boot) to copy the files over and set the permissions by adding the following:

 

mkdir /root/.ssh
cp /boot/config/ssh/authorized_keys /root/.ssh/authorized_keys
cp /boot/config/ssh/id_ed25519 /root/.ssh/id_ed25519
cp /boot/config/ssh/id_ed25519.pub /root/.ssh/id_ed25519.pub
cp /boot/config/ssh/id_ed25519 /root/.ssh/id_rsa
cp /boot/config/ssh/id_ed25519.pub /root/.ssh/id_rsa.pub
chown root:root /root/.ssh -R
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chmod 600 /root/.ssh/id_ed25519
chmod 644 /root/.ssh/id_ed25519.pub
chmod 600 /root/.ssh/id_rsa
chmod 644 /root/.ssh/id_rsa.pub

 

You'll also want to make sure /boot/config/ssh/sshd_config has passwords disabled and your keys set up. Actually, come to think of it, that go bit probably isn't even necessary if you just set up sshd_config to use the files in /boot/config/ssh/

[ken-ji]

4 hours ago, bamhm182 said:

I personally added SSH keys to my root account by creating the keys normally (I had to create the ed25519 keys off-system. I forget exactly why creating them on-system wasn't working...) and putting them in /boot/config/ssh/ then I modified my /boot/config/go file (which is run during every boot) to copy the files over and set the permissions by adding the following:

 

mkdir /root/.ssh
cp /boot/config/ssh/authorized_keys /root/.ssh/authorized_keys
cp /boot/config/ssh/id_ed25519 /root/.ssh/id_ed25519
cp /boot/config/ssh/id_ed25519.pub /root/.ssh/id_ed25519.pub
cp /boot/config/ssh/id_ed25519 /root/.ssh/id_rsa
cp /boot/config/ssh/id_ed25519.pub /root/.ssh/id_rsa.pub
chown root:root /root/.ssh -R
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chmod 600 /root/.ssh/id_ed25519
chmod 644 /root/.ssh/id_ed25519.pub
chmod 600 /root/.ssh/id_rsa
chmod 644 /root/.ssh/id_rsa.pub

 

You'll also want to make sure /boot/config/ssh/sshd_config has passwords disabled and your keys set up. Actually, come to think of it, that go bit probably isn't even necessary if you just set up sshd_config to use the files in /boot/config/ssh/

Yeah all you really needed to do is modify /boot/config/ssh/sshd_config to:

• read authorized keys from /etc/ssh or /boot/config/ssh (as /boot/config/ssh/* gets copied to /etc/ssh upon startup of the ssh server

And for bonus points, you probably want to modify ssh_config to read the default private keys from /etc/ssh as well.

[Brydezen]

Is there some kind of implementation for limiting the numbers of failed ssh password attempts and maybe ban an IP from trying anymore?

I fall over this little article/guide on using a tool called fail2ban, this is listing for failed ssh attempts and permanently ban them from trying any more :-D

 

This seems like a feature that we really need, as he states in the post; 

Quote

And you should be good to go! Just this morning I’ve brought the banhammer down on IPs from the Russian Federation, The Netherlands, Islamic Republic of Iran, and China.

 

 

I just mean, why would anyone from China need to ssh into my server for other things than to do something evil?

[pwm]

Turning off password login means there will not be any repeated login attempts - the attacking bots moves to another target the same moment the SSH server wants to negotiate SSH key instead of asking for a password.

[Brydezen]

but the process of setting up the key seems a bit much for some people. And then U have to backup the key somewhere, and if U are on the road, and forgot or dropped the usb stick then U are in very bad luck. And that fail2ban method seems so easy to implement if u don't want the long process of setting up an ssh key and storing it somewhere safe.

 

Best regards,

Brydezen 

[pwm]

It isn't unlikely that the people who finds it challenging to set up a key etc are the ones who suffer an extended danger of trigging fail2ban on themselves too.

[strike]

fail2ban is included in the let's encrypt docker.  So I guess you could use that and just create a jail for unraid log, create a voulme mapping to the unraid syslog and put the logpath in the jail config. Should work. There's probably several fail2ban dockers on dockerhub too. But I agree key based login is still the way to go IMO. If you want to use fail2ban you still have to configure it, set up jails etc, which means editing config files. And people who can figure out how to do that can probably set up key based login too if they put their mind to it.

Edited February 5, 2018 by strike