I have had several droplets in the past and not had this problem before.
I have copied an existing ssh key to a new droplet (Fedora 31) and am able to login via ssh key without issue with root.
When I copy another key over for a non root user I am always prompted for the password, this however does work on an older droplet I have.
This is all through the sshd service:
If I start another instance of sshd in debug mode with …
/usr/sbin/sshd -d -p 2222
… and then connect with …
ssh -p 2222 <username>@<ip_addr>
… it works fine and I am not prompted for a password.
I have not altered /etc/ssh/sshd_config at all and cannot see any significant difference between the one on a FC27 droplet to the one on this new FC31 droplet.
I have checked the ~/.ssh permissions for the user and all is as it should be.
Has something change between FC27 and FC31? Am I missing a configuration directive?
Any suggestions would be greatly appreciated.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Click below to sign up and get $200 of credit to try our products over 60 days!
Enter your email to get $200 in credit for your first 60 days with DigitalOcean.
Let’s first being with the usual stuff, I know you mentioned you’ve actually checked the permissions and other stuff like that but let me post how they should be just in case:
rwxr-xr-xare fine, but
rwxrwx---is no good, even if you are the only user in your group (if you prefer numeric modes: 700 or 755, not 775).
~/.ssh or authorized_keysis a symbolic link, the canonical path (with symbolic links expanded) is checked.
/.ssh/authorized_keysfile (on the remote machine) must be readable (at least 400), but you’ll need it to be also writable (600) if you will add any more keys to it.
Now that we’ve passed the standard stuff, let’s get going on the more interesting stuff.
You mentioned that when you actually run
On your droplet, you can then connect without a password, what does the debug information says on your droplet, It should state something like
In this case, what you can do is temporarily stop the SSH daemon and replace it with one in debug mode. Don’t worry, stopping the SSH daemon won’t kill any existing connections. This means it’s possible to run this without being connected to the droplet’s Console but it’s somewhat risky. If the connection does get broken for any kind of reason, you’ll need to connect using your droplet’s console. Anyway, you can run the following
If it again runs with the debug mode being on, then for sure it’s the SELinux causing the issues, it’s most probably set to Enforcing. The .ssh dir will probably be mislabeled. Look at
/var/log/audit/audit.log. Check with ls -laZ and then Run
restorecon -r -v /path/to/users/.ssh.