grantbey Posted October 14, 2020 Share Posted October 14, 2020 I'd like to add that for anyone having problems, check out the the syslog immediately after trying a log in: tail /var/log/syslog Mine had this line: Authentication refused: bad ownership or modes for directory / Which was easily fixed by doing this: cd / chown root:root . Quote Link to comment
phil1c Posted October 25, 2020 Share Posted October 25, 2020 I'm having that exact issue all of a sudden (the one described by grantbey above) and already tried: cd / chown root:root . and chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys and I've verified that my public key (that I've used for over a year) is in the authorized_keys file. When the key log in fails, I can log in with password. I'm also using the "built-in" functionality of unRAID (I forget what version it was introduced) where, placing a folder in /boot/config/ssh/ titled "root" automatically get's symlinked from ~/.ssh/ so I don't use a script to copy an updated sshd_config. I'm on the nvidia-plugin version of 6.9.0beta30. Any other ideas what I could try? Quote Link to comment
Can0n Posted October 29, 2020 Share Posted October 29, 2020 On 10/25/2020 at 5:37 PM, phil1c said: I'm having that exact issue all of a sudden (the one described by grantbey above) and already tried: cd / chown root:root . and chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys and I've verified that my public key (that I've used for over a year) is in the authorized_keys file. When the key log in fails, I can log in with password. I'm also using the "built-in" functionality of unRAID (I forget what version it was introduced) where, placing a folder in /boot/config/ssh/ titled "root" automatically get's symlinked from ~/.ssh/ so I don't use a script to copy an updated sshd_config. I'm on the nvidia-plugin version of 6.9.0beta30. Any other ideas what I could try? Try this as I had to do it too chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys Quote Link to comment
phil1c Posted October 29, 2020 Share Posted October 29, 2020 7 hours ago, Can0nfan said: Try this as I had to do it too chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys Thanks, but I already tried that. No help. Quote Link to comment
Can0n Posted October 29, 2020 Share Posted October 29, 2020 4 hours ago, phil1c said: Thanks, but I already tried that. No help. I got one of my two servers working other one on same 6.9 beta 29 is not working I even copied the authorized_keys file over and re-did perms just in case ultimately for the first one I used WinSCP to delete the .ssh folder in /root/ then made a new one in command line and applied the chmod's and got it working on first server have not tried the delete and make new directory on secondary yet will try now Quote Link to comment
Can0n Posted October 29, 2020 Share Posted October 29, 2020 4 hours ago, phil1c said: Thanks, but I already tried that. No help. this is what i did on the first server and it worked, second is still refusing the key in putty for some reason there is a sym link i had in /boot/config/ssh/ called root I deleted that and it left a dead symlink in /root/ called .ssh so if you do an ls -l /root/ if you have a file called .ssh you need to delete it then i did mkdir /root/.ssh/ cd / chown root:root . chmod 700 /root/.ssh chmod 600 /root/.ssh/authorized_keys this allows me to use the 4096 bit ppk file in putty for one server but other explictly rejects it not sure why Quote Link to comment
Starli0n Posted October 30, 2020 Share Posted October 30, 2020 (edited) On 10/19/2016 at 5:12 AM, ken-ji said: A slightly better way to maintain the keys across reboots is to * copy the authorized_keys file to /boot/config/ssh/root.pubkeys * copy /etc/ssh/sshd_config to /boot/config/ssh * modify /boot/config/sshd_config to set the following line AuthorizedKeysFile /etc/ssh/%u.pubkeys This will allow you to keep the keys on the flash always and let the ssh startup scripts do all the copying. Thanks @ken-ji your method works like a charm 👌 After I understood that /boot/config/ssh/root.pubkeys was a file and not a directory 🙄 That being said, I am using Unraid Version: 6.9.0-beta30 and as far there is this symlink: (I do not know if the symlink is present in the stable version) /root/.ssh/ -> /boot/config/ssh/root/ You can keep the /root/.ssh/authorized_keys as the default configuration for /etc/ssh/sshd_config file You have to put your public key files here: /boot/config/ssh/root/authorized_keys So you will have it there as a usual configuration: /root/.ssh/authorized_keys Therefore no need to copy the file from /etc/ssh/sshd_config to /boot/config/ssh/sshd_config for the modification Then restart ssh: /etc/rc.d/rc.sshd restart By the way, restarting is copying the files from /boot/config/ssh/ to /etc/ssh/ BUT not the directories inside the folder. Plus, it keeps the files that were already present in /etc/ssh/ even though there were deleted from /boot/config/ssh/. For that a reboot is required as the RAM is flushed. Edited October 30, 2020 by Starli0n Quote Link to comment
Starli0n Posted October 30, 2020 Share Posted October 30, 2020 On 10/20/2019 at 8:06 AM, ICDeadPpl said: Does anyone have a 'clean' unedited sshd_config file to share? Mine got messed up (by the ssh plugin). I uninstalled it and am going to go with the tips provided in this thread. So to have a clean sshd_config file, simply make a backup of the file: mv /boot/config/ssh/sshd_config /boot/config/ssh/sshd_config.bak Actually, /boot/config/ssh/sshd_config should no longer exist Then restart sshd: /etc/rc.d/rc.sshd restart Finally you should have the following files: /etc/ssh/sshd_config /etc/ssh/sshd_config.bak with /etc/ssh/sshd_config set to his default configuration Provided that it works the same way in the normal version as I am using the Beta 1 Quote Link to comment
Can0n Posted November 5, 2020 Share Posted November 5, 2020 On 10/29/2020 at 8:33 AM, phil1c said: Thanks, but I already tried that. No help. did you check that the files are owned by root? chown -R /etc/ssh/.ssh ultimately once I rebooted the server that wasn’t working it is now Quote Link to comment
Can0n Posted November 16, 2020 Share Posted November 16, 2020 I have noticed since installing 6.9 Beta 35 I am getting server refused our key on both of my servers it was working on Beta 29 I compared the authorized_keys file on both machines they match the keys file i have on my linux, Mac's and Putty setups i have in my home and no changes to the go file with the chmods were done anyone have an idea what might be causing this? Quote Link to comment
phil1c Posted December 4, 2020 Share Posted December 4, 2020 On 11/16/2020 at 1:07 AM, Can0nfan said: I have noticed since installing 6.9 Beta 35 I am getting server refused our key on both of my servers it was working on Beta 29 I compared the authorized_keys file on both machines they match the keys file i have on my linux, Mac's and Putty setups i have in my home and no changes to the go file with the chmods were done anyone have an idea what might be causing this? Yeah, this is where I was/am at. Works no issue from my Macbook but Putty on my Win10 desktop refuses to work. Quote Link to comment
phil1c Posted December 4, 2020 Share Posted December 4, 2020 Ok. I didn't change anything else except I updated from PuTTY 0.73 to 0.74 and now it works no issue from my Win10 machine. I'm on Unraid 6.9.0 beta35. Quote Link to comment
Can0n Posted December 10, 2020 Share Posted December 10, 2020 On 12/3/2020 at 9:03 PM, phil1c said: Ok. I didn't change anything else except I updated from PuTTY 0.73 to 0.74 and now it works no issue from my Win10 machine. I'm on Unraid 6.9.0 beta35. mine is too now as well since updating putty Quote Link to comment
spyd4r Posted February 10, 2021 Share Posted February 10, 2021 I'm seeing the same issue as well, this really feels like something that should just be baked into Unraid itself and configurable via the web GUI. Quote Link to comment
weirdcrap Posted February 12, 2021 Share Posted February 12, 2021 (edited) On 10/14/2020 at 11:11 AM, grantbey said: I'd like to add that for anyone having problems, check out the the syslog immediately after trying a log in: tail /var/log/syslog Mine had this line: Authentication refused: bad ownership or modes for directory / Which was easily fixed by doing this: cd / chown root:root . I also just got hit with my first case of "Authentication refused: bad ownership or modes for directory /" I have SSH'd into this server every day this week and used my public key. Now, with zero changes on my end, UnRAID says my permissions are wrong. I have a second server with the same exact setup and the public key works fine.... I'm mid appdata backup, I'm going to restart after and see if this persists. I use Termius, but also have putty installed. Updating putty from 0.7.3 to 0.7.4 did nothing to fix the issue. EDIT: While I'm waiting for the appdata backup to finish I've been poking around and I can't find anything wrong with the ownership of any of the files or folders according to output of ls -al. I've even tried re-owning and chmodding the relevant folders as suggested above and on other sites, it makes no difference. Public key auth is just flat out broken for no discernable reason. EDIT: Yeah a reboot fixes it with no changes to my config. Hopefully whatever causes this gets fixed before stable, its alarming to suddenly not be able to connect to your server. Luckily I don't disallow password auth right now, though I would like to turn it off at some point for heightened security. Edited February 12, 2021 by weirdcrap Quote Link to comment
ken-ji Posted February 12, 2021 Share Posted February 12, 2021 You are going to have to check each and every single plugin you have installed. Some of the plugins have incorrectly packaged files that muckup the ownership of the / directory. A quickfix if it hits you is to use the Web-based Shell tool to login as root, then poke around with the permissions of the / directory Quote Link to comment
weirdcrap Posted February 12, 2021 Share Posted February 12, 2021 41 minutes ago, ken-ji said: You are going to have to check each and every single plugin you have installed. Some of the plugins have incorrectly packaged files that muckup the ownership of the / directory. A quickfix if it hits you is to use the Web-based Shell tool to login as root, then poke around with the permissions of the / directory Yeah I was able to get in with my password still but I could not find anything wrong with my / directory. Next time it happens ill be sure to get a screenshot and share it so I can get some more eyes on it. If it was a plugin though wouldn't it affect me from the moment I booted the system? This occurred after 6 days of uptime and multiple uses of the key up to that point. I haven't added or removed any plugins, I think I may have updated one, the parity check tuning plugin. Quote Link to comment
ken-ji Posted February 12, 2021 Share Posted February 12, 2021 (edited) I took a lot at the Parity Check Tuning Plugin and it was packaged with the nobody:users for all the files including / Slackware packages are simple tar files applied to root and the ownership and permissions of the folders will override the system one. I think If you rebooted now, you'd find yourself unable to ssh in @itimpi You should fix this by packaging as root with the correct permissions Edited February 12, 2021 by ken-ji 1 Quote Link to comment
weirdcrap Posted February 12, 2021 Share Posted February 12, 2021 (edited) 9 minutes ago, ken-ji said: I took a lot at the Parity Check Tuning Plugin and it was packaged with the nobody:users for all the files including / Slackware packages are simple tar files applied to root and the ownership and permissions of the folders will override the system one. I think If you rebooted now, you'd find yourself unable to ssh in @itimpi You should fix this by packaging as root with the correct permissions Interesting. The reboot actually fixed it for me so UnRAID must be correctly applying the default permissions and overriding anything the plugins may be messing with at boot. I don't have any more plugin updates currently but I will keep my eye out for an update and see if my ssh breaks after applying it. EDIT: Yeah it was almost certainly the "usr" folder that caused this as I recall seeing that it was the only folder in / that wasn't owned by root. I ignored it as I didn't think that folder would have anything to do with my issue since my key and ssh files weren't stored there. Edited February 12, 2021 by weirdcrap Quote Link to comment
ken-ji Posted February 12, 2021 Share Posted February 12, 2021 or you have a properly defined plugin being installed after this one. Quote Link to comment
weirdcrap Posted February 12, 2021 Share Posted February 12, 2021 (edited) You were right @ken-ji My other server hadn't had the parity check tuning plugin updated yet so I installed. Sure enough I lost pub key access and my usr folder is owned by nobody:users now EDIT: So I went digging into the folders it seems to have touched and I ended up in the plugins folder and it looks like some of the other plugins ive installed over the years aren't owned by root either. Is it a rule of thumb that all of these files should be owned by root? Or is it different from plugin to plugin? Edited February 12, 2021 by weirdcrap Quote Link to comment
itimpi Posted February 12, 2021 Share Posted February 12, 2021 46 minutes ago, ken-ji said: You should fix this by packaging as root with the correct permissions The mkpkg command is being user with the option to force 'root' user so they should install fine and have the correct permissions, but I will check this out anyway. Quote Link to comment
Alexstrasza Posted February 12, 2021 Share Posted February 12, 2021 I've just come across this thread too. I think quite a few people will have their plugins on auto-update and suddenly find themselves unable to SSH in as a result of this - That's what happened to me. Quote Link to comment
XanALaOM00 Posted March 8, 2021 Share Posted March 8, 2021 after reading everything here, I am coming to the conclusion that Unraid simply needs to support this as a feature and not a hack. this is not something that is worth implementing if patching or updating plugins is just going to break it again. This is a very basic feature... SSH Pub/Priv keys have been around forever.. why no official support? Quote Link to comment
ljm42 Posted March 8, 2021 Share Posted March 8, 2021 15 hours ago, XanALaOM00 said: after reading everything here, I am coming to the conclusion that Unraid simply needs to support this as a feature and not a hack. Have you had a chance to check out the 6.9.0 release notes? https://wiki.unraid.net/Unraid_OS_6.9.0#SSH_Improvements It can't (yet?) be configured via the webgui, but you can simply drop your authorized_keys files into config/ssh/root on the flash drive and it will be activated the next time you reboot. There is no longer any need to tweak your go script to copy files to /root/.ssh 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.