SSH/access changes are disruptive for user and docker service

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.

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

 

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 December 14, 2020 by Draic

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 December 14, 2020 by weirdcrap

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 

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

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.

11 hours ago, Draic said:

isn't intended by unraid

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

atleast I now know that I am not the only person that takes issue with this change

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

 

 

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. 

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. 

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.

 

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

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?

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 March 8, 2021 by ap-wtioit

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

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 December 21, 2021 by Alex R. Berg

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'