Community Developer
  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

1 Follower

About docgyver

  • Rank


  • Gender
  • Location
    Atlanta, GA

Recent Profile Visitors

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

  1. Thanks so much for the effort. Heads down on some certification course right now but will add the >= putty version check soon and will look into what is needed for the cert stuff and maybe even switch to grabbing putty from the official site and not keep it as part of the plugin itself.
  2. Currently the plugin only copies the authorized_keys file from /boot/config/plugins/<user>/.ssh folders to ~<user>/.ssh folders. I have considered adding pub/priv key pairs which have been placed in the /boot folders but would want to give serious thought to any security implications. It is likely no more of an attack surface but still not something I want to do lightly. In the short term what I would do is store your private key file either on the flash drive or, since you want to do this on array start, a place you think safe on the array. For example's sake lets say /tmp/id
  3. 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 t
  4. Woot! Thanks for the feedback. Always nice to hear when it works.
  5. There was a bug introduced with the prior version. (2019-11-10). It should be fine now with 2019-11-26 or later
  6. 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 correct
  7. 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.
  8. 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.
  9. 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 liv
  10. 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 make
  11. 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.
  12. 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 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.
  13. 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.
  14. Thanks for the quick response @strike. I've added a Main and FAQ page at the nudging. :)
  15. NO worries. I should have looked closer when I did the commit. Thanks for your effort as well. Helps to work together.