Draic

Members
  • Posts

    24
  • Joined

  • Last visited

Report Comments posted by Draic

  1. 7 minutes ago, Alex R. Berg said:

    TLDR: see below for my solution to revert the so called 'SSH Improvements', without reverting the security improvements. It is simply to 1) revert the /etc/profile HOME=/root change, and 2) fix users by usermod, and 3) possibly change sshd_config.

    Man that was one seriously annoying and very bad documented change. It effectively and purposefully disabled all non-root accounts for login on the linux system that unRaid was. At least they could have made bloody clear in the documentation of the change set for 6.9 what they changed, what the consequences would be for users who previously have used login using non-root account, and how those changes were impremented (like change in etc/profile) so we could undo it if in need. Its not like rocket-science on linux to use an admin account instead of root.

    Thank you to the people of this thread to present the issue and the changes, that was much appreciated. And thank you to @Mihai who found the security issue. I do appreciate fixing the security, but there's zero security risk of having extra non-root users available in linux for login via ssh-key, as apposed to just root (or please enlighten me).

    I have found a solution for me, though in time I suppose its wise to take the hint that Lime-Tech will happily in the future destroy our multi-user system, so I guess docker or vm. But for now for me that too big a hassle to migrate all my stuff there.


    My solution involves reverting the annoying "export HOME=/root' change in /etc/profile. Reverting to basic linux standard can hardly be a issue, security wise.

    My Solution
    At boot in the go-script I copy all files at /boot/custom/* to / (root), so /boot/custom/etc/profile goes to /etc/profile, and the original /etc/profile goes to /boot/custom_original/etc/profile, so on unRaid upgrades I can detect changes (if I so desire).

    1) Revert /ett/profile change: "export HOME=/root'

    2) Fix user home-dir and shell (/etc/passwd): For each non-root user that need login-shell, I run usermod to set home-dir and shell, for instance
     

    	usermod -d /mnt/user/home/alex -s /bin/bash alex
    	usermod -d /home/admin -s /bin/bash admin 


    3) sshd_config: Password-security in SSH is not good enough for me, and shouldn't be good enough for you if you attach your server so it can be reached from the internet via ssh. For that I use these sshd_config changes. I accepted LimeTechs change of specifiyng which users have `AllowTcpForwarding`, I just allow more users
     

    # To disable tunneled clear text passwords, change to no here!
    PasswordAuthentication no
    PermitEmptyPasswords no
    ChallengeResponseAuthentication no
    
    #Limit access to the following users
    AllowUsers root admin alex
    
    # limetech - permit only root SSH tunneling
    AllowTcpForwarding no
    Match Group root
    	AllowTcpForwarding yes 
    
    Match User alex
    	AllowTcpForwarding yes
    Match User admin
    	AllowTcpForwarding yes


    3a) I place sshd_config in `/boot/custom/etc/ssh` instead of /boot/config/ssh, just for that simple reason that my go-script backup unRaid original sshd_config via the custom folder. If you don't use my custom-script, just go with /boot/config/ssh. The keys I leave in /boot/config/ssh, but also copy to /home/admin/.ssh so I have my admin user for when array isn't mounted.



     

    unraid-custom-fix-ssh-improvements.zip

    is all of this needed to just get back to the old way it was handled by unraid? I wish they'd revert the 'improvements'

  2. 18 hours ago, SimonF said:

    Not sure if this will affect your spin downs, but your have the timer set to 1 hour, but the poll is set to 1800 secs.

     

    The poll could read the disk, try reducing spin down timer or increase poll timer.

    so I had it running with increased poll timer for 24h and nothing changed. There is still no spin down happening :/

  3. 1 minute ago, SimonF said:

    Not sure if this will affect your spin downs, but your have the timer set to 1 hour, but the poll is set to 1800 secs.

     

    The poll could read the disk, try reducing spin down timer or increase poll timer.

    I have increased the poll timer and will report back, but these settings weren't an issue on stable release

    • Like 1
  4. 44 minutes ago, weirdcrap said:

    The changes are detailed in beta 25 release notes:

     

    So they changed about 3 lines in the config which if I had to take a stab are:

     

    only root user is permitted to login via ssh (remember: no traditional users in Unraid OS - just 'root'): 

    AllowUsers root

     

    non-root tunneling is disabled: 

    Match Group root

    AllowTcpForwarding yes

     

    non-null password is now required: 

    Not sure about this one, I think by default SSH already didn't allow blank passwords. PermitEmptyPasswords is set to No but commented out in a freshly generated UnRAID sshd_config file (at least for me).

     

     

    Are you using DocGyver's SSH plugin to allow non-root users access?

     

    I decided before trying out the betas to scrub his plugin and its changes from my system on the off chance I was going to have conflicts since he doesnt appear to have updated it for the betas. 

     

    I have attached my sshd_config for you to compare with if you want as it should be entirely UnRAID defaults besides my changing of where to look for the authorizedkeysfile (line 44).

    sshd_config 3.23 kB · 1 download

    ah you expanded your answers. Thanks for the help.

     

    I do not think it is something inside the sshd_config that is causing the screw up. For all users their home directories are ignored and instead are redirected to /root/ which results in permission errors. THIS is what I want to disable again and I really wonder the reason why someone thought it good to implement that way

  5.  

    Quote

    That is the way it has always worked. Only root user has access to the command line and webUI. The Users created in the Unraid webUI are only for access to shares over the network (and root user is just an anonymous user for network shares).

     

    This is not a webUI user and I never claimed it to be. I have created non-root ssh users and I know this isn't intended by unraid (which is stupid imo). Before it wasn't supported but it still worked just fine. Now there are these errors and user home folders do not work, redirects and permission errors are happening. I just want to know where/how this was configured so I can disable the "security improvements". 

     

    I do not indent to follow unraids root-only paradigm. Before the 6.9 beta that wasn't a problem, but the new ssh changes are annoying. I just need to be pointed to a commit or something about what was changed/added to the config files, so I can rip it out again. Thanks

     

    Quote

    I don't recall reading about any changes in this area. Can you provide a link? If you've made some custom modifications then it's very difficult to guess what they might be.

    the blog mentions it as "ssh improvements"

    https://unraid.net/blog/unraid-6-9-rc1

  6. I want to revert the SSH "Improvements".

     

    If you change something like this, atleast document what exactly has changed. I have modified my ssh configurations in the past and now everything is broken from the update. How can I revert ssh back to the way it was before?

     

     

    I also now have a problem with docker:

    WARNING: Error loading config file: /root/.docker/config.json: stat /root/.docker/config.json: permission denied
     

    no idea how to fix this. there is no such config file but I guess there should be, but it wasn't created before because of all the permission changes

  7. Can't say that I see less writes on my Samsung SSDs recreated with 1MiB-aligned... 

     

    But one question:

    How can I check if my docker.img still has the no-cow attribute? chattr does not seem to work ("Inappropriate ioctl for device While reading flags on docker.img"). And is there a way to correct this without recreating the docker.img?