October 23, 20178 yr 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?
October 23, 20178 yr With unRAID you always log in as the 'root' user when using SSH. There is no other users in the Linux sense.
October 23, 20178 yr 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.
October 23, 20178 yr Author 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?
October 23, 20178 yr 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.
October 23, 20178 yr Author 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.
October 23, 20178 yr 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.
October 23, 20178 yr Author 1 hour ago, itimpi said: You can make it require a key file for SSH access. How would I achieve this?
December 22, 20178 yr 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/
December 22, 20178 yr 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.
February 5, 20188 yr 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?
February 5, 20188 yr 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.
February 5, 20188 yr 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
February 5, 20188 yr 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.
February 5, 20188 yr 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, 20188 yr by strike
Archived
This topic is now archived and is closed to further replies.