• SSH/access changes are disruptive for user and docker service


    Draic
    • Minor

    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 now when using a command that runs inside 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? I noticed access to /root is messed up now. Even non root users are redirected to create configs inside /root instead of own /home directories? How can I revert this? There is NO benefit for security. Forcing everything to run as root is the opposite of security. Why force that? Inside passwd the home directory is set up correctly, but logging in as that user, all configs are pulled from /root instead which results in permission error...

     

    Some examples:

    logging in as non-root user

    -bash: cd: /root: Permission denied
    -bash: /root/.bash_profile: Permission denied

     

    trying to run mc as non-root:

    draic@Prospero:/home/draic$ mc
    Failed to run:
    Cannot create /root/.config/mc directory

     

    Rant:

    Personally this feels like a shoehorned attempt at security improvements for an outdated way to handle users. Instead of furthing sticking with using a root user (and root user only), there should be a rework of user management on unraid. I do not use ssh to run stuff on unraid, but to run stuff in docker containers that are hosted on unraid. This always felt way to hacky to achieve on unraid, but now I feel like being forced to switch OS because I can't utilize docker the way I want and need to. 

    • Upvote 1



    User Feedback

    Recommended Comments

    As far as I'm aware, you can't log in as a non-root user, by design. I just tried ssh-ing in as one of the users I have configured for private shares on a server running -rc1 and it didn't accept the password, as I expected. That's how it has always been. Only the root user can log in.

     

    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.

    Link to comment

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

    Link to comment

     

    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

    Edited by Draic
    Link to comment

    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

    Edited by weirdcrap
    Link to comment
    12 minutes ago, weirdcrap said:

    The changes are detailed in beta 25 release notes, when those changes were made: 

     

    thanks but it just states what they achieved, not how it was done. I am asking for the actual commit to check the actual changes to the configs 

    Link to comment
    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

    Link to comment
    3 minutes ago, Draic said:

    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

    Yeah I noticed that when I upgraded my test server to beta 31 (the first beta I tried this round). My non-root users were still able to login but I was getting random permission errors when trying to do things like launch MC.

     

    Unfortunately rather than mess with troubleshooting it I decided to just scrub it and wait until the new stable comes out to see what DocGyver and the community would come up with for non-root access again.

     

    I'll be following your thread though to see what you find out so do keep us posted.

    • Like 1
    Link to comment

    +1  /bump

     

    New to Unraid and had to install the 6.9 rc due to having 10th gen intel and needing to take advantage of quick sync.  After upgrading I can no longer ssh in with root (no password).  I figured I would just set a password for the root user, but not only did that not allow me to ssh in, I can no longer terminal in from the webUI.   The terminal pops up and then immediately disappears.  Awesome.

     

     

    Link to comment
    5 hours ago, shadowlyze said:

    can no longer ssh in with root

    Your problem seems unrelated to this thread, which is about attempting to login with users other than root. 

     

    You should start your own thread in General Support. 

    Link to comment
    3 hours ago, trurl said:

    Your problem seems unrelated to this thread, which is about attempting to login with users other than root. 

     

    You should start your own thread in General Support. 

    Thanks for the insight.  I just created another user to see if I could ssh in, and no luck there either. 

    Link to comment
    7 minutes ago, shadowlyze said:

    Thanks for the insight.  I just created another user to see if I could ssh in, and no luck there either. 

     

    On 12/13/2020 at 7:21 PM, trurl said:

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

    And I see you already "liked" this one:

    On 12/14/2020 at 4:57 PM, trurl said:

    If you want a general purpose, multi-user linux create a VM.

     

    Link to comment
    33 minutes ago, trurl said:

     

    If you want a general purpose, multi-user linux create a VM.

     

     

    That's not at all what I want.  What I want is SSH to work the way it worked in the previous STABLE release. 

     

    As I'm just learning how Unraid works, it makes it that much harder when I find something that works for me, only for it to be removed with an "update".

    Link to comment
    6 hours ago, shadowlyze said:

     

    That's not at all what I want.  What I want is SSH to work the way it worked in the previous STABLE release. 

     

    As I'm just learning how Unraid works, it makes it that much harder when I find something that works for me, only for it to be removed with an "update".

     

    However the main thing is that SSH users other than root for unraid currently isn't supported. As such adding non-root users that can SSH goes outside the standard convention of unraid. In turn meaning that they likely don't test SSH access and usage with users other than root.

     

    I do agree however that allowing other ssh users would be good and to add to that proper user management with maybe even RBAC?

    • Like 1
    Link to comment

    On reddit someone posted editing /etc/profile


    it seems to be the following 2 lines:

     

    export HOME=/root
    cd $HOME
    


    for our server i had to copy the ssh keys again for all non root users and disable the export HOME for users allowed to login via ssh:

     

    [[ $UID == 1000 || $UID == 1001 || $UID == 1002 ]] || \
    export HOME=/root
    
    cd $HOME
    
    

     

    Edited by ap-wtioit
    Link to comment

    I guess I've been asleep at the helm and missed the issues that arose with the v6.9 changes. My own use case doesn't involve logging in as non-root. Instead I have non-root users setup with authorized_keys files with a command="some command" stanza and was not aware of the change to /etc/profile until today (2021/11/01). Likewise I wasn't aware of how sshd_config was changed to disallow non-root from logging in. In truth I still don't know since I am waiting for a parity check to finish so I can check what the bzimage has for sshd_config.

    Once I have that, I will modify the AllowUsers/DenyUsers (or Group variants) used by the default config to allow the users selected in the interface.

     

    I'm torn between a couple of thoughts regarding how to address the issue caused by the "HOME=/root" clause in /etc/profile.

    1. I've already experimented with adding a script to /etc/profile.d which resets the HOME variable. This gets HOME correct but still results in the permission error due to the cd $HOME line.
    2. Using a sed edit in place to modify /etc/profile to skip setting HOME for users selected in the ssh plugin.

     

    I'm loath to change /etc/profile for some reason even though I'm already changing /etc/ssh/sshd_config. The /etc/profile.d/ssh_config.sh script approach has a great appeal but leaves us with the error from the change directory command.

     

    I'm at best days (vs. hours or weeks) away from making a change so will monitor this thread for any feedback.

     

    I haven't found any plugins which make changes to /etc/profile.d no any guidance either. I want to avoid collisions with unRaid scripts in the future so if anyone knows a "standard" let me know. If I don't hear anything AND go with the /etc/profile.d approach I'll likely call the script plg_ssh-config.sh.

    Note I am likely going to change the name of the plugin from the simple "ssh" to "ssh_config" to improve clarity on what it does.

     

    doc..

    • Thanks 1
    Link to comment

    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

    Edited by Alex R. Berg
    Link to comment
    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'

    Link to comment


    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.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.