Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Error "vcmi_device_t is not defined" in SELinux when Adding a New Port for SSH Question Question
How did my database got hacked ? Question Question

Question

Non root user unable to login with ssh key

Posted February 12, 2020 2.5k views
SecurityFedora

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.

Add a comment
pashioz
By:
pashioz

Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Error "vcmi_device_t is not defined" in SELinux when Adding a New Port for SSH Question Question
How did my database got hacked ? Question Question

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.

×
Submit an Answer
1 answer
KFSys February 12, 2020

Hi @pashioz,

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:

  • Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ andrwxr-xr-x are 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).
  • If~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.
  • Your ~/.ssh/authorized_keys file (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.
  • Your private key file (on the local machine) must be readable and writable only by you: rw——-, i.e. 600.

Now that we’ve passed the standard stuff, let’s get going on the more interesting stuff.

You mentioned that when you actually run

/usr/sbin/sshd -d -p 2222

On your droplet, you can then connect without a password, what does the debug information says on your droplet, It should state something like 

Authentication allowed

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 

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

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.

Regards,
KDSys

Reply Report
  • pashioz February 13, 2020

    Hi @KDSys ,

    Thanks for your prompt response.

    I can confirm the following:

    • All local and remote .ssh directories have permissions 700
    • All local and remote .ssh files have permissions 600
    • All local and remote .ssh files and directories are owned by the correct user.

    I then did the following:

    1. ssh <user>@<ip_addr> // (locally) got prompted for a password
    2. systemctl stop sshd.service // (on remote server)
    3. /usr/sbin/sshd -d // (on remote server)
    4. ssh <user>@<ip_addr> // (locally) logged in OK with no password prompt

    Then logged out of the session and restarted the sshd.service.

    Checked SELinux and it is indeed set to SELINUX=enforcing which is not the case on my old server.

    Then the command you suggested:

    1. estorecon -r -v /path/to/users/.ssh // (on remote server)
    2. ssh <user>@<ip_addr> // (locally) got prompted for a password

    So I changed SELINUX to SELINUX=permissive and rebooted the machine and retried the login.

    1. ssh <user>@<ip_addr> // (locally) logged in OK with no password prompt

    Thank you @KDSys for answering my question, I had disabled SELinux on previous droplets as it simply caused issues like this and others, when setting up the new servers I deliberately left it set enforcing hoping for increased security, I have to wonder how one can leave on enforcing without encountering these kinds of issues, but that is maybe a topic for another question at another time :)

    Reply Report
    • KFSys February 13, 2020

      Hi @pashioz,

      I’m glad I was able to help out in this case. I’ve been thinking recently why can’t we actually disable SELinux altogether however after going more in depths and reading about it, I understand why we can’t.

      A quick google search actually does help a lot in explaining it as well

      SELinux provides some safeguards that can protect users' files even when your users are careless. Traditional Unix security uses discretionary access control. ... One reason is because a rogue process on your system could find itself very limited with respect to the files that it can access.
      Reply Report
  • pashioz February 13, 2020

    Hi @KDSys , my more detailed reply got flagged as spam, I don’t know why, I have emailed the moderators about it, until then, you were correct SELinux was causing the issue.

    Regards
    Pashioz

    Reply Report

Related

Looking for something else?

Ask a new question Search for more help