Jump to content

docgyver

Community Developer
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

5 Neutral

1 Follower

About docgyver

  • Rank
    Advanced Member

Converted

  • Gender
    Male
  • Location
    Atlanta, GA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You can copy the same public key under multiple users on the unraid side. If you have already added the 2nd (non-root) user to the list in the ssh plugin then there should be a path /boot/config/plugins/ssh/<user>/.ssh with a readme.txt file in it. If not then add the user in the plugin UI and hit apply. Once you have the path created you can copy the authorized_keys file from the /boot/.../root/.ssh folder to the parallel folder of the new user. That gets it "persisted" on the USB drive. Now to get it into /home/<user> with the right owner and permissions you just need to force the plugin to refresh things. Least impactful way is to go into the plugin UI and toggle a user and hit apply. A stop+start cycle or a reboot would also do the trick.
  2. Woot! Thanks for the feedback. Always nice to hear when it works.
  3. There was a bug introduced with the prior version. (2019-11-10). It should be fine now with 2019-11-26 or later
  4. 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..
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Thanks for the quick response @strike. I've added a Main and FAQ page at the nudging. :)
  13. NO worries. I should have looked closer when I did the commit. Thanks for your effort as well. Helps to work together.
  14. 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.
  15. 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.