Dr_Cox1911 Posted October 23, 2017 Share Posted October 23, 2017 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? Quote Link to comment
itimpi Posted October 23, 2017 Share Posted October 23, 2017 With unRAID you always log in as the 'root' user when using SSH. There is no other users in the Linux sense. Quote Link to comment
Dr_Cox1911 Posted October 23, 2017 Author Share Posted October 23, 2017 So even if I create a user with the terminal? Quote Link to comment
itimpi Posted October 23, 2017 Share Posted October 23, 2017 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. Quote Link to comment
Dr_Cox1911 Posted October 23, 2017 Author Share Posted October 23, 2017 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? Quote Link to comment
trurl Posted October 23, 2017 Share Posted October 23, 2017 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. Quote Link to comment
Dr_Cox1911 Posted October 23, 2017 Author Share Posted October 23, 2017 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. Quote Link to comment
itimpi Posted October 23, 2017 Share Posted October 23, 2017 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. Quote Link to comment
Dr_Cox1911 Posted October 23, 2017 Author Share Posted October 23, 2017 1 hour ago, itimpi said: You can make it require a key file for SSH access. How would I achieve this? Quote Link to comment
bamhm182 Posted December 22, 2017 Share Posted December 22, 2017 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/ Quote Link to comment
ken-ji Posted December 22, 2017 Share Posted December 22, 2017 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. Quote Link to comment
Brydezen Posted February 5, 2018 Share Posted February 5, 2018 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? Quote Link to comment
pwm Posted February 5, 2018 Share Posted February 5, 2018 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. Quote Link to comment
Brydezen Posted February 5, 2018 Share Posted February 5, 2018 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 Quote Link to comment
pwm Posted February 5, 2018 Share Posted February 5, 2018 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. Quote Link to comment
strike Posted February 5, 2018 Share Posted February 5, 2018 (edited) 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.