docgyver

New update fixes some issues bugs introduced with 2019-11-10 causing changes made in the UI to be ignored. In addition, The part of the script which updates /etc/ssh/sshd_config (and then copies to /boot...) was updating block comment lines which happened to have Keywords in them which are maintained by the plugin. In particular are the keywords "PermitRootLogin"and "PasswordAuthentication". It is very likely you will now have 2 lines with PRL and 3 lines with the PA setting. The plugin will update all of them to the value set in the UI and sshd_config will function correctly but you should consider fixing the sshd_config. To do so you will need to manually edit the /etc/ssh/sshd_config file and then copy it to /boot/config/ssh/sshd_config. I know the whole point of the plugin is to avoid such steps and I apologize for the problem. [ lame excuses for why this happened removed by author ] Again, you don't have to do the cleanup but if you are inclined the steps are as follows: ssh/telnet to unraid server as root edit /etc/ssh/sshd_config with your favorite editor (e.g. vi /etc/ssh/sshd_config look for a block of text which looks like: # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and PasswordAuthentication XXX # PAM authentication via ChallengeResponseAuthentication may bypass PermitRootLogin XXX # If you just want the PAM account and session checks to run without PasswordAuthentication XXX Replace it with # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication 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 save the file Copy to USB flash drive: cp /etc/ssh/sshd_config /boot/config/ssh/sshd_config That's it. Going forward those lines will be appropriately ignored as will all block comment lines which contain impacted keywords. doc..

Looks like I was overzealous in my "fix" to protect folks from turning off password authentication by accident. I am no longer able to turn it off either. I also noticed I have 3 entries for PasswordAuthentication in sshd_config. I'm not sure if that is also a bug or a left over from something earlier, or, I suppose, both. I'll work on a fix today. Thanks for letting me know.

No I have not tested with the latest RC yet. I need to double check that the plugin script does a full restart of SSH after the settings are changed. If not then it could explain what you are seeing. I'll check in a bit.

Finished updating the rc.ssh:write_config() function to read the live copy of sshd_config before updating the plugin config in /boot/config/plugins/ssh.cfg. I was hoping I could leverage the values in unRaid's persisted (/boot/config/ssh/sshd_config) configuration but it would make the UI code more convoluted than necessary. With two copies of the settings the only "failure mode" I can think of is someone updating the ssh.cfg manually then rebooting with the intent those settings would be used. I think in that case the reboot will tell the plugin to exit which will then read from live and persist to ssh.cfg overwriting those changes. The benefit of the change is that now the plugin installation will respect previously tweaked settings in the /boot/config/ssh/sshd_config (unRaid's) config file. Those of you who change Port", "PermitRootLogin", "GatewayPorts", etc. will not have to manually fix those if you change them before installing the plugin.

Deleting the /boot/config/ssh folder is an extreme but easy to accomplish fix. I get that you fixed your issue already so this followup is for the next guy and includes a request: I would be surprised if you have copies of /boot/config/ssh/sshd_config both before and after plugin install state but if you do I could use those to figure out how things were messed up and fix/improve the plugin. As a guess I expect it is related to the PermitRootLogin setting located in /boot/config/ssh/sshd_config. The plugin defaults to setting this option to "no". Merely installing the plugin makes that change and afterwards you have to login as another user. That file "belongs" to unRaid not the plugin so removing the plugin does not reverse that change. Removing the whole /boot/config/ssh folder deletes that config file along with server certs and such. unRaid automatically creates it again if it is missing at boot time. As I write this, I am leaning toward changing this behavior which would avoid this particular risk. Unfortunately the "easy" thing is to change the default to "yes" with the risk that I'm reversing the setting for someone. The "proper" (and more time consuming) thing would be to check the current setting and retain that while highlighting in the interface that the "no" setting is recommended. I'm not sure if a plugin uninstall can be interactive or not. If it can then I will look into making the "delete /boot/config/ssh" an interactive choice. Let's assume that I am right about how ssh broke. If so then a couple of approaches to a fix which avoid the need for a physical console. Abandon the Plugin Options Telnet: PermitRootLogin is an ssh setting thus telnet will not be affected. Enable Telnet: Settings -> System Settings -> Management Access -> Use Telnet: Yes This assumes you turned it off. You _did_ turn it off right? Telnet to the server logging in as root Edit /boot/config/ssh/sshd_config and change PRL setting to "yes" Remember this assume PRL is the issue. (Alt) Remove the /boot/config/ssh folder Use Web UI to reboot A reboot forces the new setting to be picked up or (Alt) the ssh folder to be recreated. Recommended: after reboot disable telnet Create User: only root is blocked, not other users so this allows you to ssh in as a different user Settings -> User Preferences -> Users -> Add User Ssh in as the new user Use sudo or "su -" to fix the config file or remove the ssh folder as described above Use Web UI to reboot Cleanup: remove the created user if it is no longer desired Keep the plugin Options [re]Install the plugin Change the PermitRootLogin setting to yes Click Done I can't emphasize enough that the edit sshd_config option only fixes the problem if indeed the PermitRootLogin setting is the issue. If this doesn't fix your issue then please get me a copy of your broken sshd_config or, even better, both that and the before I will look into what the plugin is doing.

Going to give that (wipe clean and start from scratch) a go now as well, after a backup of course. I haven't done an install in quite some time. Had a friend suggest I should update the version more regularly too so it doesn't look abandoned. Follow up shortly.

Sorry you are having issues with the DenyHosts plugin. It is true that a failed login to root can cause even a local ban. I've thought about adding a "whitelist" for all private IP addresses to the default config but "the tyranny of the default" would put this in place for folks who might not want it. I will look at the Readme.md and see if I can make potential impacts more clear and maybe as an option have an optional whitelist file that people can put in place. Thanks for the feedback.

Did you install both SSH and Denyhosts plugins? Denyhosts default behavior is to block logins to root with only a single failure. You may need to whitelist your source IP. I will wait to speculate further on the problem until after you confirm Denyhosts install or lack.

Thanks for the quick response @strike. I've added a Main and FAQ page at the nudging. :)

NO worries. I should have looked closer when I did the commit. Thanks for your effort as well. Helps to work together.

Quite correct Shaun. I didn't check the location of the "Post Install" script in the plg file in relation when I accepted the patch. I moved it to the bottom right above the script which does the "bottonstart" execution kicking off the plugin and things are fine now. If anyone has issues applying the update it may be caused by a rogue /var/log/plugins/ssh.plg file remaining after the failure of 2018.01.18 to load. "Easiest" (i.e. Web UI) fix is a reboot but is not not required if you are comfortable on the command line. Manual fix can be accomplished by running the command "rm /var/log/plugins/ssh.plg" by your preferred method (e.g. ssh and command line, User Scripts plugin...) Follow that in the UI with a check for updates on the plugins page and then update.

Yeah me too. Been working on a broken Nextcloud docker from 443 being part of the management interface. Let me see what is wrong with the new code.

Thanks so much. I opened up the file to change on Monday and hadn't even looked at the browser tab since. I also update the version so that someone checking for update will have a new version number. Maybe someday I'll get some icons in there too. I did find a couple that made sense and were CC license.

No significant implications. Group has no need for write access. Giving "other" read and execute is a bit more pemissive but it isn't like what that folder holds can't be known. It's on github I'll see what I need to change to get the permissions right on create. IIRC there was a mask involved. Been too lazy to pick an Icon. Wish there was a standard one. I'll take a look to see if there is one now.

Depends on on which plugin you are asking about. The DenyHosts plugin is intended to detect unwanted connections and block the source IP. The SSH plugin is intended to enable persisting various settings. Which of the two are you running?

Odd. I don't normally use another user but do have a couple defined. I will try to reproduce what you are seeing and fix it.

I am still running 6.2.4 because my last jump broke my Owncloud (now NextCloud) docker image. I haven't read the readme on what changes from 6.2 to 6.3 but I'd be surprised if it breaks the plugin. Do you have the files in the right folder on /boot? SSH files on my machine are like the following (with noise files removed). Note the dot (.) in .../user/.ssh/... $find /boot/config/plugins/ssh ! -type d /boot/config/plugins/ssh/ssh.cfg /boot/config/plugins/ssh/root/.ssh/authorized_keys /boot/config/plugins/ssh/otheruser/.ssh/authorized_keys

I didn't try changing the icon when I took over the plugins and have no preference. If you can send me the icon or a link I will add it to the plugin directly.

I'm on a business trip which makes me cautious about changing the port that I use in case it would cause me to lose access but I will give it a try hopefully tonight. It sounds like the problem may have resolved itself but still it would be good for me to try changing the port just to make sure that all works. doc..

Somehow I've been missing notifications on the thread. I must have deleted one and never got back here. I just updated to 6.2.4 on Friday and blew up docker containers since I didn't RTFM before jumping from 6.1 to 6.2. I hope to have things cleared up sometime today (Monday) and will look at both ssh and Denyhosts. I can tell you that ssh plugin seems to be working for me without any further changes. At least my authorized keys file is making it into place. I'll kick the tires on other features late today or tomorrow. Sorry for my absence. doc..

If you don't open up SSH to the outside via a Port Forward, "DMZ Host Forward", or some other means then your risk is fairly low that you would have attackers. Denyhosts monitoring then becomes, as you imply, one more thing to clean up, monitor, ignore, ... This may come off a bit "tin-foil hat" but one thing to keep in mind is that our IOT (internet of things) devices are notoriously bad about security. At some point they will likely become beach-head or bot-net "infected" devices. If you want to control your light bulbs from your phone you should consider adding them and all other IOT devices to their own network. </tin-foil> Adding the SSH plugin may be something you want to consider if for no other reason it helps with setting up public-key style auth. It sucks to have to type a complicated password for my unraid when I'm on my tablet. :-) hth, doc..

I just noticed that myself yesterday. Been going on in my logs for quite some time too. Looks like it only happens on start but you will likely see a permissions issue on sync-hosts more regularly. It looks like I was getting it each time denyhosts detected a new suspicious event. I noticed that denyhosts was running as "sudo -h nobody" and nobody would not have access to /etc files. Yesterday I removed the sudo which broke things then changed it to just sudo without the "-h nobody" it has been running fine. As best I can tell the original author's intent behind using sudo is/was two-fold. I am almost certain he was trying to orphan the daemon. Without the sudo the web page never returns after you click "start". The second possible reason is to lower the privilege of the daemon. If that was the intent it must have been that /etc/hosts.deny (et. al.) had different permissions and/or ownership in the past. For my use I'm ok with the daemon running as root so I've updated the plg file. If you "check for updates" on your plugins you should see the new version now.

updated to use the 2.7.10 version of Python found in PhAzE repo

Hopefully this is the right place for posting new/updated plugins. For a long time I have been used the ssh plugin for installing (and now just persisting settings for) ssh. By shear luck (not sure good or bad) I jumped from v5 straight to v6.1. Due to the security improvements in v6.1 the current copy of the only ssh plugin I was aware of did not work. I saw both in the support thread and github repo that people were asking about updates and so I decided to fix the plugin for myself and post a patch. Since then I learned that the maintainer seems to have either taken a break or been otherwise busy. I'm studiously avoiding naming the person since I don't know if there are political mines that I'm stepping around but will say I am very grateful for his initial work on creating the plugin. Without that effort I am sure I would not have forked the copy and started maintaining it. You can find my version of both the SSH and DenyHosts plugins here. Note the other plugins by the previous author are also there but HAVE NOT BEEN UPDATED IN ANY WAY. Indeed the support files will still be pulled from the original fork's release/download folders even if you grab the .plg file from my repo. I'm not new to unRaid but I am new to developing for it so I welcome constructive feedback and will respond as quickly as my time will allow to any issues people have with the plugins I'm maintaining. Since I think these posts can be edited I will update this list here when and if I update the other items that I forked. Currently maintaining: ssh DenyHosts -edit: Plugins which can now be found as docker containers: Beets, Dropbox, LogitechMediaServer, NZBGet, Pyload DocGyver..