SSH and Denyhosts updated for v6.1


Recommended Posts

So i have been using this plugin for over a year now. using the /boot/config/plugins/ssh/<user>/.ssh/authorized_keys file to copy in my key for remote login.

 

It was working just fine. Until recently it now tells me that my pubkey is denied. i haven;t changed it so i don;t know what is different. from the host i checked the user .ssh folder inside unraid and i see it is not there. so has the plugin stopped copying the authorized keys over?

Link to comment
  • 1 month later...
On 7/29/2020 at 9:23 PM, DeathStrike87 said:

So i have been using this plugin for over a year now. using the /boot/config/plugins/ssh/<user>/.ssh/authorized_keys file to copy in my key for remote login.

 

It was working just fine. Until recently it now tells me that my pubkey is denied. i haven;t changed it so i don;t know what is different. from the host i checked the user .ssh folder inside unraid and i see it is not there. so has the plugin stopped copying the authorized keys over?

Are you saying it's on the USB, but not copied to RAM at boot?

Link to comment
  • 1 month later...

My SSH has some issues after installing this plugin. Before this I would manually enable/disable SSH as I needed it through the Unraid GUI. I wanted to leave SSH on and figured I could do it with this plugin but now I can't connect. I get the following error when using a SFTP client to connect

[email protected]: Permission denied (publickey,password,keyboard-interactive).

SSH seems to work fine through a command line, but I didn't change anything with the client. Does anyone know what the issue here can be? I'm a noob so please dumb it down for me

 

Edit - nevermind, fixed itself somehow...

Edited by cromwell
Link to comment
  • 5 months later...
  • 4 months later...
On 4/29/2021 at 2:13 PM, ljm42 said:

hey @docgyver Unraid 6.9 is able to handle ssh config files without moving them around:
  https://wiki.unraid.net/Manual/Release_Notes/Unraid_OS_6.9.0#SSH_Improvements 

I don't think this plugin is compatible with how 6.9 does that. Is that something you plan to fix or should we ask @Squidto have CA restrict this plugin to 6.8.x and lower?

 

For now let's restrict it to 6.8.x. I need to dig into how to make them compatible and I'm not sure when I can do that. I still think there could be value for it for those who want to allow non-root to use ssh.

I have been in a private conversation with another unraid user who found a couple of input sanitization issues in Beets (unlikely to fix as it is still v5 code I inherited/took over) and DenyHosts.

The issue can only be exploited by someone who is already in the management interface and thus has "root" but it is worthy of a fix.

I'll look at both of these as soon as I can. So many hobbies...

  • Like 1
Link to comment
  • 1 month later...

I just updated the plugin to check for ver6.9 or greater and skip the copy of root's authorized keys for those versions.

 

For now I am going to leave the /boot/config/plugins/ssh/root/.ssh folder in place in case someone needs to copy something out of it.

 

I'm working on some other updates and will likely include a rename of the above folder in an upcoming update.

Link to comment

The plugin was working for me, but for some reason stopped allowing me to log in from user accounts. It's started but when I ssh over, it accepts my user password (I know because I've tried incorrect passwords to check) and then immediately get "Connection to 10.0.0.10 closed."

 

What would this be caused by?

 

Can I totally reset things so I'm back to square one and start over, perhaps? (I don't know where configuration is saved or if unistalling/reinstalling is completely fresh.)

 

Thanks.

 

(Note: root@ works just fine.)

Edited by ksignorini
Root comment.
Link to comment
18 hours ago, ksignorini said:

The plugin was working for me, but for some reason stopped allowing me to log in from user accounts. It's started but when I ssh over, it accepts my user password (I know because I've tried incorrect passwords to check) and then immediately get "Connection to 10.0.0.10 closed."

 

What would this be caused by?

 

Can I totally reset things so I'm back to square one and start over, perhaps? (I don't know where configuration is saved or if unistalling/reinstalling is completely fresh.)

 

Thanks.

 

(Note: root@ works just fine.)

 

tl;dr;

Things that might help. Please read below for a better understanding of how each thing might help

  1. Check sshd_config for AllowUser, DenyUser, AllowGroup, DenyGroup config entries and adjust as necessary
  2. reset ssh plugin
    1. backup /boot/config/plugins/ssh/<user folders>
    2. go to plugins tab and remove ssh plugin
    3. Add plugin back
    4. Restore user folders

 

I'll take a shot at the first question but need to know more about your setup.

First, as a complete guess it sounds like some 6.9.x behavior might have kicked in for you. Starting from 6.9.0 (from the release notes) "only root user is permitted to login via ssh". I'm not sure how that is being done but guess it is either with AllowUser, AllowGroup, DenyUser, and/or DenyGroup configuration items in sshd_config.

I don't have any of those but my config would not have been changed by the upgrade. Only new systems would have it blocked.

If one of my plugins is causing the problem, then is it "ssh.plg" or "denyhosts.plg"?

Deny hosts is more apt to block connections entirely (dropped before password prompt). For this reason I doubt it is Denyhosts.

Problems with the ssh plugin tend to be either breaking the ability to login as root (not what you are seeing) or user keys not working. Your experiment with a correct vs. incorrect password implies you aren't using keys either.

 

As to the second question, deny hosts uses /boot/config/plugins/denyhosts/denyhosts.cfg for its basic config. The default "working" directory defined in that config file is /usr/local/denyhosts. That folder is volatile memory and will go away on it's own. If you changed your working directory to a persistent store (e.g. /mnt/cache/apps) then you will need to clean that out manually.

Similarly, ssh.plg uses /boot/config/plugins/ssh/ssh.cfg for its basic config. User keys are stored in /boot/config/plugins/ssh/<user folder>.

If you use the "remove" option for either plugin then you start completely fresh. The ssh remove will remove /boot/config/plugins/ssh which includes the user key folders. Back it up if you don't have those public keys somewhere else.

 

Though I say "completely fresh" there is one thing which will persist even after a remove. The ssh config plugin persists changes to sshd_config to the copy managed by unraid itself. If you made a change, say to the port, then that change will remain even after removing the plugin.

That is especially important if PERMIT ROOT is set to NO. Removing the plugin would then require you to edit the sshd_config file manually. Hint: you might need to enable telnet to login if /boot is not exported.

 

 

Link to comment
7 minutes ago, docgyver said:

 

tl;dr;

Things that might help. Please read below for a better understanding of how each thing might help

  1. Check sshd_config for AllowUser, DenyUser, AllowGroup, DenyGroup config entries and adjust as necessary
  2. reset ssh plugin
    1. backup /boot/config/plugins/ssh/<user folders>
    2. go to plugins tab and remove ssh plugin
    3. Add plugin back
    4. Restore user folders

 

I'll take a shot at the first question but need to know more about your setup.

First, as a complete guess it sounds like some 6.9.x behavior might have kicked in for you. Starting from 6.9.0 (from the release notes) "only root user is permitted to login via ssh". I'm not sure how that is being done but guess it is either with AllowUser, AllowGroup, DenyUser, and/or DenyGroup configuration items in sshd_config.

I don't have any of those but my config would not have been changed by the upgrade. Only new systems would have it blocked.

If one of my plugins is causing the problem, then is it "ssh.plg" or "denyhosts.plg"?

Deny hosts is more apt to block connections entirely (dropped before password prompt). For this reason I doubt it is Denyhosts.

Problems with the ssh plugin tend to be either breaking the ability to login as root (not what you are seeing) or user keys not working. Your experiment with a correct vs. incorrect password implies you aren't using keys either.

 

As to the second question, deny hosts uses /boot/config/plugins/denyhosts/denyhosts.cfg for its basic config. The default "working" directory defined in that config file is /usr/local/denyhosts. That folder is volatile memory and will go away on it's own. If you changed your working directory to a persistent store (e.g. /mnt/cache/apps) then you will need to clean that out manually.

Similarly, ssh.plg uses /boot/config/plugins/ssh/ssh.cfg for its basic config. User keys are stored in /boot/config/plugins/ssh/<user folder>.

If you use the "remove" option for either plugin then you start completely fresh. The ssh remove will remove /boot/config/plugins/ssh which includes the user key folders. Back it up if you don't have those public keys somewhere else.

 

Though I say "completely fresh" there is one thing which will persist even after a remove. The ssh config plugin persists changes to sshd_config to the copy managed by unraid itself. If you made a change, say to the port, then that change will remain even after removing the plugin.

That is especially important if PERMIT ROOT is set to NO. Removing the plugin would then require you to edit the sshd_config file manually. Hint: you might need to enable telnet to login if /boot is not exported.

 

 

 

I did many of these steps yesterday and it appears to be working again. I had to completely remove the SSH plugin, rename/remove unRAID's SSH config folder, and reboot. Then I reinstalled SSH plugin and I can now give users permission to SSH or not. That works.

 

(I'm going to double-check everything against your steps now.)

 

However, and this was not the case before, when I log in with a user account I get:

 

mylogin@Mylogins-MacBook-Pro-16 ~ % ssh [email protected]
[email protected]'s password: 
Linux 5.10.28-Unraid.
-bash: cd: /root: Permission denied
-bash: /root/.bash_profile: Permission denied
mylogin@unRAIDBox:/home/mylogin$ 

 

(Names have been changed to protect the innocent.)

 

What script is causing it to try to log into root's folder when a user logs in? It's dumping the user into their /home/mylogin folder correctly a the end, but it appears to try to dump into root's first.

 

Thanks.

Edited by ksignorini
Link to comment

*short version* or <tl;dr;>

unraid explicitly sets HOME=/root in /etc/profile followed by "cd $HOME". If /root is mode 755 users wind up in /root when they login. If /root is mode 700 you get the behavior you report.

 

I need to create a fresh USB boot and see how v6.9 and v6.9.3 act out of the box.

 

I figured out a "fix" but need to find and read plugin best practices before I implement it.

 

*Long Version*

Oddly enough I rarely login interactively to a user account. Most of the users I create have authorized_keys files/entries which run a specific application. e.g. rsync server. This allows me to have workstation backups push backups to unraid without giving an interactive shell.

That said, I just did some poking around and found that /etc/profile explicitly sets "HOME=/root" then does a "cd $HOME". That in itself didn't initially generate the error you see but my /root folder was mod 755 and yours might be a more appropriate 700.Once When I set /root to 700 I get the same messages you do.

 

I need to try a fresh install to see if 700 is the new default and/or figure out why mine was 755. I thought it might have been a side effect of the plugin prior to my changing to handle ver6.9 but I only chmod the .ssh folder and files.

 

You will find that "echo $HOME" will return /root which will not end well for many things. Even a simple "cd ~" will try to go to /root and fail.

I've got an idea for a work around but need to find out plugin best practice for adding something to /etc/profile.d. My "fix" will still result in the "cd..permission denied" error when logging in but HOME will be set correctly.

In the mean time if you want to do the fix yourself then create a file called: /etc/profile.d/ssh_config.sh

The content should be

export HOME=/home/$USER

 

Then do "chmod +x /etc/profile.d/ssh_config.sh" to make it executable. The file will go away on reboot since the /etc folder is memory mapped (not persisted). Hopefully I can find out an/the acceptable naming scheme for profile.d scripts before your next boot. Main thing I want is to avoid future collisions with unraid scripts.

Link to comment
Fatal: Plugin URL on xml template does not match PluginURL in .plg (https://raw.githubusercontent.com/docgyver/unraid-v6-plugins/master/ssh.plg vs )

 

You problem is that on the .plg you've got an unescaped ampersand on line 74

dd if=/boot/bzroot bs=512 skip=$(cpio -ivt -H newc < /boot/bzroot 2>&1 > /dev/null | awk '{print $1}') | xzcat | (cd /boot/config/plugin/ssh/baseline ; cpio -i -d -H newc --no-absolute-filenames etc/ssh/sshd_config )

 

and unescaped ampersands aren't allowed in XML.  Either escape it (&amp;) or ideally put the entire FILE code within a CDATA tag  IE: the .plg file is invalid and will not load even if simply pasting it into Install Plugin

Link to comment
  • 4 weeks later...

@docgyver i think i found a bug in your newest version of the ssh config plugin 😞

 

I use unraid 6.9.2 and can't seem to finish the plugin setup process because of a wrong foldername (/boot/config/pluns/ssh/baseline instead of /boot/config/plugins/ssh/baseline) here https://github.com/docgyver/unraid-v6-plugins/blob/3b6714012073c901b5d1d2d300ef1615ccd74caf/ssh.plg#L75 

 

Since there is no error message i'm just guessing but the whole process gets stopped so the plugin never registers for unraid (no webpage, no rc file).

 

Can you help?

Link to comment
1 hour ago, docgyver said:

@xxlbug Sorry about that chief. bug in code which isn't even being used yet. Sorry about the trouble.

Please try an update or if it never installed to install from scratch with 2021.12.01

thank you for the ultra quick reaction and super quick fix!

 

Found the real culprit and created an PR for the fix. The plugin url goes to raw.github.com but this produces an "HTTP 404 Not found" which stops the plugin install. New adress is raw.githubusercontent.com, which worked for me 🙂

Link to comment
19 hours ago, xxlbug said:

thank you for the ultra quick reaction and super quick fix!

 

Found the real culprit and created an PR for the fix. The plugin url goes to raw.github.com but this produces an "HTTP 404 Not found" which stops the plugin install. New adress is raw.githubusercontent.com, which worked for me 🙂

In case github didn't tell you, I merged your change then also updated the version to  2021.12.01.1 since it was the same day. Fair chance no one pulled the 2021.12.01 version but better safe than sorry.

It is very strange that it needed the usercontent url since, I think, it has been the other way since I took over years ago. Regardless, thanks for the extra effort in triage and the fix.

  • Thanks 1
Link to comment
17 minutes ago, wgstarks said:

Im seeing this line on boot-

 

 

Im not sure if this is expected or if it represents some problem. Its possible that the line has been there for a long time and Ive just never noticed.

 

brunnhilde-diagnostics-20211208-1711.zip 175.62 kB · 0 downloads

That message is coming from some of the new code. I'll see if I can suppress it. I'm extracting sshd_config from unraid's initrd (root) volume so that I can (eventually) compare that baseline/default copy against what is persisted on the /boot usb drive. My high-level thinking is to produce INFO and possibly WARN level messages when there are differences which could produce unexpected behavior.

Link to comment
6 minutes ago, docgyver said:

That message is coming from some of the new code. I'll see if I can suppress it. I'm extracting sshd_config from unraid's initrd (root) volume so that I can (eventually) compare that baseline/default copy against what is persisted on the /boot usb drive. My high-level thinking is to produce INFO and possibly WARN level messages when there are differences which could produce unexpected behavior.

Thanks. Was wondering how it could already exist.

Link to comment
  • 4 weeks later...

I'm planning to sync my local backups via rsync over ssh between 2 servers (1 unraid, 1 synology) -  the UnRAID install is quite fresh, so it shouldnt be a plugin update issue.

 

If I got it correctly, this plugin should allow me to set up additional users (apart from root) with SSH access.
I can find the Settings - SSH subtab, but that doesnt seem to actually allow any user specific changes (even though I can select 1 or multiple users)
 

Quote

Creating & Selecting Users

The plug-in allows multiple users to have SSH access. Use the standard Users page in the UnRAID WebGUI to create and maintain your users. 

The standard Users page did not change at all though, and I cannot access the server via any other user than root. 
If the ssh options only apply to Users created AFTER the plugin is installed this should be mentioned.
But I also cannot login with a user created after the plugin installation, so what I see is, the UnRAID Users page does not do anything for the ssh access?

 

(btw) The manual mentions how to create a user via cmdline, and that is needs an appropriate UID, but it doesn't mention how to assign the UID upon creation or change it afterwards:

# usermod -u <UID> <username>

 

Further down (create key pair section) its described again:

Quote

1. In UnRAID **Users** page; create a new user (or do it from command line)
2. Go to OpenSSH settings page and select that user for SSH. Hit Apply and/or Start SSH

So I stopped the service on SSH page, and then selected 2 users and hit apply (the selected options should fit, allow root, password enabled, and so on)
But I still cannot use those users for ssh access....

What am I missing?

Edited by wambo
Link to comment
On 1/4/2022 at 9:28 AM, wambo said:

I'm planning to sync my local backups via rsync over ssh between 2 servers (1 unraid, 1 synology) -  the UnRAID install is quite fresh, so it shouldnt be a plugin update issue.

 

If I got it correctly, this plugin should allow me to set up additional users (apart from root) with SSH access.

This plug allows you to manage which users are allowed to use SSH. It will not create users. You should create users with the unRaid interface. Advanced users could also create users using the command line but I do not recommend doing that as a novice. The unRaid user creation works perfectly fine for most use cases.
I can find the Settings - SSH subtab, but that doesnt seem to actually allow any user specific changes (even though I can select 1 or multiple users)
Fixed with latest update

 

The standard Users page did not change at all though, and I cannot access the server via any other user than root. 

Standard  user page is not modified by this plugin.
If the ssh options only apply to Users created AFTER the plugin is installed this should be mentioned.
But I also cannot login with a user created after the plugin installation, so what I see is, the UnRAID Users page does not do anything for the ssh access?

The plugin will work with users created pre and post plugin installation. This behavior was a side-effect of the bug fixed in the latest update.

 

(btw) The manual mentions how to create a user via cmdline, and that is needs an appropriate UID, but it doesn't mention how to assign the UID upon creation or change it afterwards:

# usermod -u <UID> <username>

Your use case shouldn't need a manual/command-line created user.

On 1/4/2022 at 9:28 AM, wambo said:

Further down (create key pair section) its described again:

It sounds like you have some familiarity with creating ssh pub/priv key pairs. If that is the case all you need to do is drop the public part of the key into /boot/config/plugins/ssh/<user>/authorized_keys and then use the plugin to restart ssh. You have to use the plugin to restart not command line. Reboot would also suffice but isn't required.

So I stopped the service on SSH page, and then selected 2 users and hit apply (the selected options should fit, allow root, password enabled, and so on)
But I still cannot use those users for ssh access....

What am I missing?

What you are missing is the fix I just put in to a "regression error". :)

Version 6.9+ of unRaid does some additional work to secure SSH. Part of that includes restricting ssh to only root. I added some updates to work with that change but I was careless about how I put in a change after that fix and went back to the old behavior.

Please also see some of my in-line comments to your various questions

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
Reply to this topic...

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