SSH and Denyhosts updated for v6.1


Recommended Posts

Hi there,

 

I stumbled upon your plugin by doing a web search for non-root login via ssh on Unraid and wanted to give it a try. Unfortunately, it's either not working properly on 6.10 or I'm doing something wrong.

 

I created a user called "unraidssh" for testing purposes and disabled the root login (even though I'm not sure whether that's true, I'm assuming you can't have root login enabled and still use non-root users to login...):

 

grafik.thumb.png.cfb91818ee80969ccc0f49baf85e37f0.png

 

Yet when I try to log in via kitty, this is wha happens, even though I enter the correct password:

 

login as: unraidssh
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
Access denied
Keyboard-interactive authentication prompts from server:
| Password:

 

 

And the Unraid log shows this:

 

Jan  9 12:04:47 Tower sshd[28960]: Connection from 192.168.180.30 port 12218 on 192.168.188.24 port 22 rdomain ""
Jan  9 12:04:49 Tower sshd[28960]: Postponed keyboard-interactive for unraidssh from 192.168.180.30 port 12218 ssh2 [preauth]
Jan  9 12:04:51 Tower sshd[29012]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.180.30  user=unraidssh
Jan  9 12:04:53 Tower sshd[28960]: error: PAM: Authentication failure for unraidssh from 192.168.180.30
Jan  9 12:04:53 Tower sshd[28960]: Failed keyboard-interactive/pam for unraidssh from 192.168.180.30 port 12218 ssh2
Jan  9 12:04:53 Tower sshd[28960]: Postponed keyboard-interactive for unraidssh from 192.168.180.30 port 12218 ssh2 [preauth]

 

I even tried Windows 10's OpenSSH client just to make sure that this wasn't some Kitty issue, but the problem persisted.

 

Could you help me out here?

Link to comment
2 hours ago, Pillendreher said:

Hi there,

 

I stumbled upon your plugin by doing a web search for non-root login via ssh on Unraid and wanted to give it a try. Unfortunately, it's either not working properly on 6.10 or I'm doing something wrong.

 

I created a user called "unraidssh" for testing purposes and disabled the root login (even though I'm not sure whether that's true, I'm assuming you can't have root login enabled and still use non-root users to login...):

 

Yet when I try to log in via kitty, this is wha happens, even though I enter the correct password:

 

login as: unraidssh
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
Access denied
Keyboard-interactive authentication prompts from server:
| Password:

 

 

And the Unraid log shows this:

 

Jan  9 12:04:47 Tower sshd[28960]: Connection from 192.168.180.30 port 12218 on 192.168.188.24 port 22 rdomain ""
Jan  9 12:04:49 Tower sshd[28960]: Postponed keyboard-interactive for unraidssh from 192.168.180.30 port 12218 ssh2 [preauth]
Jan  9 12:04:51 Tower sshd[29012]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.180.30  user=unraidssh
Jan  9 12:04:53 Tower sshd[28960]: error: PAM: Authentication failure for unraidssh from 192.168.180.30
Jan  9 12:04:53 Tower sshd[28960]: Failed keyboard-interactive/pam for unraidssh from 192.168.180.30 port 12218 ssh2
Jan  9 12:04:53 Tower sshd[28960]: Postponed keyboard-interactive for unraidssh from 192.168.180.30 port 12218 ssh2 [preauth]

 

I even tried Windows 10's OpenSSH client just to make sure that this wasn't some Kitty issue, but the problem persisted.

 

Could you help me out here?

Thanks for your thorough information. Most of the questions that immediately came to mind were answered from the logs and picture. Biggest concern was you might have an old copy of the plugin but that isn't the case. I haven't upgraded to 6.10 yet but have been working on a testbed so that I can start getting ahead of the testing without having to update my primary system. Having Plex down is not "wife friendly" :)

That said I may take the risk and update to see what happens.

In the mean time please look at /etc/ssh/sshd_config for a line "AllowUsers..." and see if it has anything besides root in it. Given your example I would expect it to look like:
Allowusers root unraidssh

It should also be persisted in /boot/config/ssh/sshd_config. If you see the either line missing or the unraidssh user missing from either please try to "refresh" the plugin. I think just using the restart ssh button in the plugin should work but to be sure, unselect and reselect the user you want to enable then click apply.

I'll follow up  shortly.

 

To the point made by @bonienl, based on your post you know that normally only root can login. This plugin is, as you infer, meant to allow you to enable additional users. I'll get it working with 6.10 and/or help you work out why it isn't working for you.

Link to comment

@Pillendreher,

I installed 6.10.0-RC2 and have had no issues logging in as either root or my test user. Both public key (root and testuser) and password (testuser) authentication works. I saw in the release thread that some older ssh clients may have issues connecting using ssh-rsa key types. I didn't drill down on the comment so I may not have that 100% correct so please do your own due diligence if it looks like you have pub key issues.

I also read that new systems have SSH disabled by default. Your system logs suggest you have enabled it or that this isn't a new install. I mention it only in case ssh somehow got disabled in the Settings:Management-Access tab.

 

I hope to have a test bed in place some time today so I can try a fresh install of 6.10 and see if that behaves differently than an upgraded system.

In addition to checking for an AllowUsers config entry please let me know if you installed 6.10.0-RC2 on a fresh system or was it an upgrade? Upgrades can be a little problematic since things like the AllowUsers line might not exist in an sshd_config which has been persisted from an older version of unRaid.

Thanks in advance for your reply and also for your patience and help as I work through how to robustly handle sshd_configs coming from older initial builds.

 

P.S.

I just re-read your OP and saw your speculation you can't have both root and non-root. That is not the case. The plugin supports root plus any number of (selected/enabled) non-root users.

Link to comment
On 1/9/2022 at 2:33 PM, docgyver said:

In the mean time please look at /etc/ssh/sshd_config for a line "AllowUsers..." and see if it has anything besides root in it. Given your example I would expect it to look like:

 

Allowusers root unraidssh

 

It should also be persisted in /boot/config/ssh/sshd_config. If you see the either line missing or the unraidssh user missing from either please try to "refresh" the plugin. I think just using the restart ssh button in the plugin should work but to be sure, unselect and reselect the user you want to enable then click apply.

I'll follow up  shortly.

 

Hey - thanks for replying :)

 

I just reinstalled the plugin, stopped SSH, selected unraidssh and pressed apply - unfortunately I still can't login via unraidssh.

 

This is what my sshd_config looks like:

 

#       $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO
# limetech - lets be verbose
LogLevel VERBOSE

# Authentication:
# limetech - we need to allow root
AllowUsers root unraidssh
PermitRootLogin yes

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#KbdInteractiveAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
# limeteh - disallow forwarding but see below
AllowTcpForwarding no
GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

# limetech - permit only root SSH tunneling
Match Group root
AllowTcpForwarding yes

 

Match Group root

 

is probably the culprit, huh? "unraidssh" is not part of the group "root":

 

root@Tower:~# id unraidssh
uid=1003(unraidssh) gid=100(users) groups=100(users)

 

Edited by Pillendreher
Link to comment
  • 1 month later...
1 minute ago, dtempleton said:

Sorry for what seems like a lame question:  Does the ssh plugin have an interface?  Nothing happens when I click on the green icon on the plugins page.  Does the plugin do all of its work 'behind the scenes' and we set selections by editing the sshd_config file in /etc/ssh ?

 

thanks

Not lame at all... Look under the settings tab. You will find an ssh item in the Network settings.

Link to comment
On 1/12/2022 at 4:39 PM, Pillendreher said:

 

Hey - thanks for replying :)

 

I just reinstalled the plugin, stopped SSH, selected unraidssh and pressed apply - unfortunately I still can't login via unraidssh.

 

This is what my sshd_config looks like:

 

#       $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO
# limetech - lets be verbose
LogLevel VERBOSE

# Authentication:
# limetech - we need to allow root
AllowUsers root unraidssh
PermitRootLogin yes

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no

# Change to no to disable s/key passwords
#KbdInteractiveAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
# limeteh - disallow forwarding but see below
AllowTcpForwarding no
GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

# limetech - permit only root SSH tunneling
Match Group root
AllowTcpForwarding yes

 

Match Group root

 

is probably the culprit, huh? "unraidssh" is not part of the group "root":

 

root@Tower:~# id unraidssh
uid=1003(unraidssh) gid=100(users) groups=100(users)

 

Group section(s) allow you to override settings based on various criteria. The out-of-box unRaid settings disable TCP Forwarding for "all" then [re]enable it for root membership. That does not impact ability to ssh into the box. Critical value there is the AllowUsers line near the top. I see that it includes an "unraidssh" user in addition to root. That should enable that user to connect via ssh.

Link to comment

I'm having problems getting SSH setup under 6.9.2  It was working until I upgraded to 6.9.2  from 6.3.5 when I lost the ability to log in automagically with authorized keys.  I  figured that I would sort that out later and logged in successfully with the root password.

 

I tried several things to get the authorized keys to work, and eventually renamed the /boot/config/ssh/ directory so that a new one would be created and I could set that one up from scratch.  More on that later.

 

In the meantime I lost the ability to log into the server as root, even though the root password allowed login to the webGUI.

 

in the /boot/config/sshd_config file I see the following lines (about 27)

 

AllowUsers root
#LoginGraceTime 2m
PermitRootLogin prohibit-password
PermitRootLogin prohibit-password
#StrictModes yes
MaxAuthTries 6
#MaxSessions 10

 

I didn't know what 'prohibit-password' meant but from https://ubuntuforums.org/showthread.php?t=2359172  I learned that this is the new default for ssh_config to force automatic login, i.e. prohibiting the use of root passwords.  OK, but for now I need the password option, so I changed the lines using nano to:

 

AllowUsers root
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
PermitRootLogin yes              
#StrictModes yes

 

then stopped and restarted SSH with the plugin.   I still can't use a root password, and find that the sshd_config has been changed back to what it was before:

 

# Authentication:

AllowUsers root
#LoginGraceTime 2m
PermitRootLogin prohibit-password
PermitRootLogin prohibit-password
#StrictModes yes
MaxAuthTries 6
#MaxSessions 10

 

What is happening?  Is something writing a default sshd_config file here on every SSH restart, perhaps the SSH plugin?

 

(Edit: sure enough deleting the plugin allows 'PermitRootLogin yes' to persist and login works)

 

If so this is an important enough setting that it might should be accessible by the plugin GUI as an option

 

Secondly,

 

I note that in UnRAID

/root/.ssh  redirects to /boot/config/ssh/root

but, the ssh keys that are generated are placed in /boot/config/ssh not in the root subdirectory,

Is that as planned?

I did try copying the keys to .../root and then to my client authorized keys but no joy so far.  I'm more flummoxed by not being able to use a root password.

 

Thanks for all you do!

Dennis

 

 

 

Edited by dtempleton
internal comment
Link to comment
  • 4 weeks later...

Doesn't appear to work on Unraid 6.9.2, as I can't get the WebGUI to load the 'SSH authorized keys' box on the 'Edit User' page. Both of my other 6.10.0-rc2 boxes however loads this fine. Logs are empty and so is the console, there doesn't appear to be any errors, it just doesn't load the WebGUI on 6.9.2. See attached both screenshots. Should also mention I've done multiple re-installs, which has no effect.

 

6.10.0-rc2:

6.10.0-rc2__working.png

 

6.9.2:

6.9.2__not_working.png

Edited by unraidyn
clarifications
Link to comment
On 3/15/2022 at 6:22 PM, unraidyn said:

Doesn't appear to work on Unraid 6.9.2, as I can't get the WebGUI to load the 'SSH authorized keys' box on the 'Edit User' page. Both of my other 6.10.0-rc2 boxes however loads this fine. Logs are empty and so is the console, there doesn't appear to be any errors, it just doesn't load the WebGUI on 6.9.2. See attached both screenshots. Should also mention I've done multiple re-installs, which has no effect.

 

6.10.0-rc2:

6.10.0-rc2__working.png

 

6.9.2:

6.9.2__not_working.png

I was not aware that 6.10 was introducing the ability to edit the authorized keys for individual users. That appears to be native unraid functionality which may obviate the need for my plugin beyond 6.10.

I did a little testing with 6.10 a month or so back when someone reported an issue with the plugin. I have since rolled back since I was doing the testing on my live system. While testing I didn't use or even look at the edit user screen(s).

I'll fire up another test to confirm that 6.10 allows both root and other users' authorized_keys to be edited.

The "official" word about end users vis-a-vis logging in is that unraid isn't meant for that. Users are only for share security. It is possible and I would say LIKELY that the edit users screen will ultimately only allow editing authorized_keys for root.

Link to comment

Important notice

On 3/13/2022 at 12:34 PM, wgstarks said:

Console errors after updating to 6.10 RC-3.

 

1560253194_ScreenShot2022-03-13at10_56_02AM.thumb.png.4ad04ebeb2bdb31d7f5e8b2c9e7cec55.png

Thanks for the report.

I'll be doing some additional testing on 6.10 this week. I will make sure to check what is happening there. I added code to extract the native sshd_config from the bzroot with the intent of eventually comparing that to the copy my plugin edits and reporting any "drift". Right now there is no other functionality depending on that extraction so short term I will likely just disable it.

My instinct tells me that the kludge I have to use to get the / (root) volume out of bzroot stopped working.

Link to comment
On 2/17/2022 at 8:12 PM, dtempleton said:

I'm having problems getting SSH setup under 6.9.2  It was working until I upgraded to 6.9.2  from 6.3.5 when I lost the ability to log in automagically with authorized keys.  I  figured that I would sort that out later and logged in successfully with the root password.

 

I tried several things to get the authorized keys to work, and eventually renamed the /boot/config/ssh/ directory so that a new one would be created and I could set that one up from scratch.  More on that later.

 

In the meantime I lost the ability to log into the server as root, even though the root password allowed login to the webGUI.

 

in the /boot/config/sshd_config file I see the following lines (about 27)

 

AllowUsers root
#LoginGraceTime 2m
PermitRootLogin prohibit-password
PermitRootLogin prohibit-password
#StrictModes yes
MaxAuthTries 6
#MaxSessions 10

 

I didn't know what 'prohibit-password' meant but from https://ubuntuforums.org/showthread.php?t=2359172  I learned that this is the new default for ssh_config to force automatic login, i.e. prohibiting the use of root passwords.  OK, but for now I need the password option, so I changed the lines using nano to:

 

AllowUsers root
#LoginGraceTime 2m
#PermitRootLogin prohibit-password
PermitRootLogin yes              
#StrictModes yes

 

then stopped and restarted SSH with the plugin.   I still can't use a root password, and find that the sshd_config has been changed back to what it was before:

 

# Authentication:

AllowUsers root
#LoginGraceTime 2m
PermitRootLogin prohibit-password
PermitRootLogin prohibit-password
#StrictModes yes
MaxAuthTries 6
#MaxSessions 10

 

What is happening?  Is something writing a default sshd_config file here on every SSH restart, perhaps the SSH plugin?

 

(Edit: sure enough deleting the plugin allows 'PermitRootLogin yes' to persist and login works)

 

If so this is an important enough setting that it might should be accessible by the plugin GUI as an option

 

Secondly,

 

I note that in UnRAID

/root/.ssh  redirects to /boot/config/ssh/root

but, the ssh keys that are generated are placed in /boot/config/ssh not in the root subdirectory,

Is that as planned?

I did try copying the keys to .../root and then to my client authorized keys but no joy so far.  I'm more flummoxed by not being able to use a root password.

 

Thanks for all you do!

Dennis

 

 

 

Apologies for such a delayed response. Been a crazy few weeks.

Thanks for calling out the location that the ram copy of /root/.ssh points to. As you may know, Limetech now persists root's ssh files at /boot/config/ssh/root. The files stored in /boot/config/ssh "top level" are the server level files. Those "persisted" copies get copied to /etc/ssh (again this is a ram disk location) for actually running the system. Any edits made to /etc/ssh/* files will be lost unless they are subsequently copied back to /boot/config/ssh. I will need to check to see if that happens natively.

Limetech has started adding various ssh support natively which obviates some aspects of this/my plugin. As much as possible I'm trying to work with native code so that these sort of "conflicts" are avoided.

Later this week I should have a better update on how the plugin works with  6.9.2 vs 6.10.rc1 functionality.

Hopefully that will also include an update address your and a few other reported issues.

Thanks for letting me know and for your appreciation.

Link to comment
On 3/25/2022 at 5:32 AM, ThatDude said:

Sorry is this is a silly questions, can I use this plugin to jail a SSH user to a specific directory?

 

I wan't to use Borg on a separate machine to backup to my unraid but I don't want that user to have access to the root file system.

Not silly at all. Short answer is no this plugin isn't setup to do that exact (chroot) thing.

That said, your high-level use case is exactly why/how I started using (and later maintaining) this plugin. Instead of chroot I use "command limited" authorized_keys entries. In my case I'm using an rsync like tool and the authorized keys entry for the user is set to run that command. You can do that with an entry like this:

command="/usr/bin/rsync" ssh-rsa AAAAB....userPubKey...

When the user with the matching private key connects, sshd will automatically (and only) run the specified command. By "only" I mean that if one were to try something like

Quote

ssh remotehost /bin/bash

sshd will ignore the passed command.

What you will need to do is create an entry that runs the borg "server side" command. You will also have to install borg in a way that the command is accessible. As far as I know, you will have to install borg in unraid directly vs. in a docker container. I'm not sure if it is possible or how to run a command in a docker container from an authorized_keys command limited entry.

  • Like 1
Link to comment
  • 2 weeks later...
On 3/28/2022 at 6:09 PM, docgyver said:

Not silly at all. Short answer is no this plugin isn't setup to do that exact (chroot) thing.

That said, your high-level use case is exactly why/how I started using (and later maintaining) this plugin. Instead of chroot I use "command limited" authorized_keys entries. In my case I'm using an rsync like tool and the authorized keys entry for the user is set to run that command. You can do that with an entry like this:

command="/usr/bin/rsync" ssh-rsa AAAAB....userPubKey...

When the user with the matching private key connects, sshd will automatically (and only) run the specified command. By "only" I mean that if one were to try something like

sshd will ignore the passed command.

What you will need to do is create an entry that runs the borg "server side" command. You will also have to install borg in a way that the command is accessible. As far as I know, you will have to install borg in unraid directly vs. in a docker container. I'm not sure if it is possible or how to run a command in a docker container from an authorized_keys command limited entry.

 

Thank you for this, I already had Borg installed via nerd-tools and your solution partly solves the securtiy issue. The remaining problem is that the Borg util still has access the the entire root file system and could be used maliciously.

 

The solution I'm looking at is to run sshserver as a sandboxed docker:

 

https://github.com/linuxserver/docker-openssh-server

 

But also using the extra security you mentioned above (which is new to me - and great).

Link to comment
6 hours ago, ThatDude said:

 

Thank you for this, I already had Borg installed via nerd-tools and your solution partly solves the securtiy issue. The remaining problem is that the Borg util still has access the the entire root file system and could be used maliciously.

 

The solution I'm looking at is to run sshserver as a sandboxed docker:

 

https://github.com/linuxserver/docker-openssh-server

 

But also using the extra security you mentioned above (which is new to me - and great).

That sounds like it could be a good approach. One thing to keep in mind is that the ssh container will need to be able to access the Borg application. If Borg runs in a different container that could be tricky to work out.
Once you figure that part out, you can limit the container(s) access to the array via a folder mapping and essentially have a chroot.

Link to comment

Hello,

The plugin seems to work well in unRAID 6.9.2
Much like SMB settings in unRAID I would like to provide access to certain folders for a user. I tried to find information on the github repository and this forum but it seems not yet discussed as such. Would it be possible to organize (and deny) access to certain folders using the SSH protocol for a user? and if so how to do that?

Would this method be advisable?: https://fedingo.com/how-to-restrict-ssh-users-to-specific-folder/

Edited by LimeCenter
Link to comment
  • 3 months later...

Just installed https://raw.githubusercontent.com/docgyver/unraid-v6-plugins/master/ssh.plg on 6.10.3, chose the users, updated setings, restarted sshd, and it works. Thank you! I can understand from a security POV that this is off by default, however this is quite _useful_. Like, SFTPing from the build machine into unraid to transfer the built packages. You don't want to do this as root.

Edited by rookie701010
  • Like 1
Link to comment
  • 8 months later...
31 minutes ago, Speedy905 said:

Hello, is there a way for the SSH Daemon to auto start on boot, and to keep the port instead of reverting back to default? I've already enabled the SSH Service but every reboot it doesn't autostart and the port goes back to 22.

 

Thanks.

Nevermind.... I found it. 

 

Management Access -> Scroll down a bit until you see the SSH settings.

Link to comment
  • 3 months later...

There's a bug in the detection of whether WORK_DIR is on persistent storage, so it always says persistent, unless its on 'ramfs' (the first match in the array). 

This code fixes it: Adding 'tmpfs' to array, and don't break on first mismatch (in .plg file)
 

denyhosts_datacheck()
{
  array=( ramfs proc tempfs sysfs tmpfs )
  fs=$( stat -f -c '%T' $WORK_DIR )
  if [ "$fs" = "msdos" ]; then
    echo "<p style="color:red\;"><b>WARNING:</b> Your WORK_DIR is located on your flash drive. This can decrease the life span of your flash device!</p>"
  else
    found=0
    for i in "${array[@]}"
    do
      if [[ "'$i'" = "'$fs'" ]]; then
        echo "<p style="color:red\;"><b>WARNING:</b> Your WORK_DIR is not persistent and WILL NOT survive a reboot. The WORK_DIR maintains a running history of past DenyHosts entries and ideally should be maintained across reboots.  Please locate your WORK_DIR on persistent storage. eg. cache/array disk</p>"
        found=1
        break
      fi
    done
    if (( ! $found )) ;then
        echo "<p style="color:green\;">WORK_DIR located on persistent storage. Your data will persist after a reboot :-)</p>"      
    fi
  fi
}



I'm not really sure whether its a good idea to put it on /boot due to spamming writes on USB, and also I would prefer it to be not dependent on /mnt being available. So I suspect the best option would be copying to/from /boot on start/stop or mount or something like that. What do others do to persist the data, and what is the data? I would be fine with moving the deny-lists to /boot as I expect those are not written frequently, unless of cause I'm spammed from unlimited number of ipv6 addresses... (if that can happen...)

Edited by Alex R. Berg
Link to comment
  • 1 month later...

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.