Pillendreher Posted January 9, 2022 Share Posted January 9, 2022 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? Quote Link to comment
bonienl Posted January 9, 2022 Share Posted January 9, 2022 Only user 'root' can be used to access the server. All other users are for share access. Quote Link to comment
docgyver Posted January 9, 2022 Author Share Posted January 9, 2022 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. Quote Link to comment
docgyver Posted January 9, 2022 Author Share Posted January 9, 2022 @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. Quote Link to comment
Pillendreher Posted January 12, 2022 Share Posted January 12, 2022 (edited) 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 January 12, 2022 by Pillendreher Quote Link to comment
dtempleton Posted February 17, 2022 Share Posted February 17, 2022 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 Quote Link to comment
docgyver Posted February 17, 2022 Author Share Posted February 17, 2022 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. Quote Link to comment
docgyver Posted February 17, 2022 Author Share Posted February 17, 2022 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. Quote Link to comment
dtempleton Posted February 17, 2022 Share Posted February 17, 2022 23 minutes ago, docgyver said: Not lame at all... Look under the settings tab. You will find an ssh item in the Network settings. Thanks! Quote Link to comment
dtempleton Posted February 18, 2022 Share Posted February 18, 2022 (edited) 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 February 18, 2022 by dtempleton internal comment Quote Link to comment
wgstarks Posted March 13, 2022 Share Posted March 13, 2022 Console errors after updating to 6.10 RC-3. Quote Link to comment
unraidyn Posted March 15, 2022 Share Posted March 15, 2022 (edited) 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.9.2: Edited March 15, 2022 by unraidyn clarifications Quote Link to comment
docgyver Posted March 23, 2022 Author Share Posted March 23, 2022 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.9.2: 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. Quote Link to comment
docgyver Posted March 23, 2022 Author Share Posted March 23, 2022 Important notice On 3/13/2022 at 12:34 PM, wgstarks said: Console errors after updating to 6.10 RC-3. 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. Quote Link to comment
docgyver Posted March 23, 2022 Author Share Posted March 23, 2022 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. Quote Link to comment
ThatDude Posted March 25, 2022 Share Posted March 25, 2022 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. Quote Link to comment
docgyver Posted March 28, 2022 Author Share Posted March 28, 2022 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. 1 Quote Link to comment
ThatDude Posted April 12, 2022 Share Posted April 12, 2022 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). Quote Link to comment
docgyver Posted April 12, 2022 Author Share Posted April 12, 2022 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. Quote Link to comment
LimeCenter Posted April 15, 2022 Share Posted April 15, 2022 (edited) 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 April 15, 2022 by LimeCenter Quote Link to comment
rookie701010 Posted July 15, 2022 Share Posted July 15, 2022 (edited) 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 September 29, 2022 by rookie701010 1 Quote Link to comment
Speedy905 Posted March 17, 2023 Share Posted March 17, 2023 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. Quote Link to comment
Speedy905 Posted March 17, 2023 Share Posted March 17, 2023 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. Quote Link to comment
Alex R. Berg Posted June 18, 2023 Share Posted June 18, 2023 (edited) 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 June 18, 2023 by Alex R. Berg Quote Link to comment
addohm Posted August 4, 2023 Share Posted August 4, 2023 I've been unable to log in as a user on SSH with this plugin. Enabled, Users Selected, Permit Root Disabled, Password Authentication On, Permit Empty Off. I tried restarting sshd. Current unraid v6.12.3 Quote Link to comment
Recommended Posts
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.