docgyver

@Johann Do you need unraid to have a default SFTP path on an inbound connection or a particular unRaid user to have a default SFTP path when connecting from unraid out to another server? High level thinking here as I await your response... Changing unRaid's inbound default SFTP could have unintended consequences for other apps. More risk that someone will mess things up comes with the more dials and buttons we add to the plugin. If this is the direction you intend I'd be more inclined to figure out how to change the user's home directory. e.g. Have a manually created "passwd" file in the /boot/config/plugins/ssh/<user> folder and use that to change the home directory. Outbound is much easier though. I could add support for an ".ssh/config" file to be copied to the /home/<user>/.ssh folder from /boot. doc..

Thanks. I've updated for tmpfs and "any match". I put my WORK_DIR on the same cache array I use for the docker disk image and docker application "config". That is the "usual" place for this sort of persistent data. I forget what array triggers (stop/start/...) exist but there might be a practical way to use an in memory filesystem that persists the data to /boot "at the last moment".

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.

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.

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.

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

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.

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.

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

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

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.

Your use case shouldn't need a manual/command-line created user. 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

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.

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.

@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