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'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?

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

 

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.

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

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

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, 20205 yr by Starli0n

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

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

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?

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.

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.

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

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.

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, 20215 yr by weirdcrap

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

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.

 

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, 20215 yr by ken-ji

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, 20215 yr by weirdcrap

or you have a properly defined plugin being installed after this one.

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, 20215 yr by weirdcrap

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.

 

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.

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?

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