SSH as root using public key still prompts for password on RHEL 6.1

Question

I have the following in model.py:

from django.db import models
from django.contrib.auth.models import User
from django.db.models.signals import post_save
from django.dispatch import receiver

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    university = models.CharField(max_length=30, blank=True)
    birth_date = models.DateField(null=True, blank=True)

    ROLE = (
        ('CUSTOMER', 'User'),  # (value to be set on model, human readable value)
        ('WORKER', 'Worker'),
    )

    role = models.CharField(max_length = 20, choices = ROLE, default = 'USER')


    def __str__(self):
        return self.user.username

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

@receiver(post_save, sender=User)
def save_user_profile(sender, instance, **kwargs):
    instance.profile.save()

I also have a corresponding form that, when filled out and sumbitted, saves to the database as a Profile properly.

What I do not understand is instance.profile.save() how does this work? To me it appears it should be instance.Profile.save() since, Profileexists. I am not sure where this lowercase profileis coming from?

Solution 1

I solved this by adding another user and then changing the Tomcat webapp/ directory to be owned by that regular user. That regular user has no problem authenticating with keys and that user can execute commands via ssh and scp (remote re-deploy to Tomcat).

Another security precaution that RHEL takes is to disable the Tomcat manager application so I can't remote deploy through the Tomcat manager either. (I tried adding the manager application back in and setting up admin and manager users but the manager application wont' run).

Solution 2

I had the same issue after installing Gitlab 6.4 on RHEL 6.5. No matter what i did i could not SSH using public keys for the main system user (git). Again the SSH keys were fine, as were the permissions on ~/.ssh (700) an ~/.ssh/authorized_keys (600). The issue was that seliunx was "enforcing" and the contexts in the .ssh directory were wrong, probably because the user was created as a system user. You could fix as @Dean-Schulze did by changing the user to normal user, but i managed to fix the contexts for the affected user using the restorecon command which may solve the issue you are having.

Check if selinux is enforcing

sestatus

Examine the contexts using

ls -laZ ~/.ssh

I found that the "type" context needed to be "ssh_home_t"

To fix the ssh directory login/su as the affected user and then run

restorecon -R -v ~/.ssh

If that does not work you may need to fix the context on the users home directory

restorecon -R -v ~/

More info I found useful http://themattreid.com/wordpress/2012/11/02/selinux-solutions-fixing-a-newly-provisioned-server-that-refuses-ssh-key-based-login/

Solution 3

A denial for ~./ssh looks like this in the /var/log/audit/audit.log:

type=AVC msg=audit(1355348670.326:87): avc:  denied  { read } for  pid=1490 comm="sshd"    name="authorized_keys" dev=dm-1 ino=277466 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

Is SELinux enabled?

getenforce

What's the context on ~/.ssh? It may be incorrect on a manually created directory.

# ls -alZd .ssh/
drwxr-xr-x. root root unconfined_u:object_r:admin_home_t:s0 .ssh/

But there should be after you do a relabel or set appropriate context.

# ls -alZd .ssh/
drwx------. root root system_u:object_r:ssh_home_t:s0  .ssh/

Or disable SELinux / set permissive :)

Solution 4

Malfunctioning public keys are usually caused by bad file permissions on the authorized_keys file. Make sure it is chmodded to 644.

I have had this "problem" many times. Problem is not just with permission of file authorized_keys, also permissions of directories ".ssh" and ".." (home directory of user) should be properly set. Problems would have been solved by setting permission like this: 700 to .ssh, at least 754 to ".." and 600 to file authorized_keys:

# ls -lah .ssh
drwx------. 2 root root 4.0K Dec 11 14:09 .
drwxr-xr--. 3 root root 4.0K Dec 11 14:08 ..
-rw-------. 1 root root  399 Dec 11 14:09 authorized_keys

Solution 5

Malfunctioning public keys are usually caused by bad file permissions on the authorized_keys file. Make sure it is chmodded to 644:

chmod 644 /root/.ssh/authorized_keys

If that doesn't resolve it, try checking for error messages in the /var/log/secure file on the server side.

And finally there is also a clue in your output that indicates SELinux might be blocking stuff:

ssh_selinux_setup_pty: security_compute_relabel: Invalid argument

There might be an explanation for that message in the SELinux log: /var/log/audit/audit.log.

View more solutions

Comments

[Michael Hampton]

Post the contents of /etc/pam.d/sshd.

[Dean Schulze]

[root@ga2-lab ~]# ls -lah .ssh total 12K drwxr-xr-x. 2 root root 4.0K Dec 11 14:09 . drwxr-xr-x. 3 root root 4.0K Dec 11 14:08 .. -rw-------. 1 root root 399 Dec 11 14:09 authorized_keys

[Andrey Voitenkov]

Is there anything like pam_selinux(sshd:session): Unable to get valid context for root in the logs?

[gertvdijk]

@DeanSchulze Tom meant the one on the client side containing the private keys. You seem to have more than 3 private keys and after 3 attempts it will not be able to continue with more. Specify the one matching with the private one put in authorized_keys file on the remote machine. What happens if you do ssh user@host -o IdentityFile=/home/user/myprivatekey?

[ewwhite]

I would start over. Generate new keys. Put a fresh sshd configuration on both sides... Oh, and upgrade to RHEL 6.3. No reason to be on the older version.

[Dean Schulze]

My authorized_keys file is 600. I added a new user and used the same ssh-copy-id on the same public key file and ssh works for that user. This looks like a restriction on the root user.

[Dean Schulze]

SELinux is enabled.

[gertvdijk]

It's always a good practice to not use the root user for things like this. Two important notes though. 1) this story about Tomcat should be in the question, 2) it's not an answer to your question, but rather a workaround for your specific needs you didn't mention in the question

[Ryan Foley]

@DeanSchulze I agree with gertvdijk, this is simply a workaround, it doesn't address the core issue: ssh access to root on your server through pki is denying access with no real indication why.

[Kieveli]

Nice!!! Worked for me! My '..' permissions were drwxr-xr--'. Changed that to 'drwxr-xr-x' and it worked perfectly.

[Arian Faurtosh]

How do I fix that without disabling SELinux.

[vfbsilva]

I have the same issue here, does it has something to do with SELinux? My log reports: type=USER_LOGIN msg=audit(1462396643.960:46925): user pid=23768 uid=0 auid=0 ses=7186 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=? addr=10.139.2.84 terminal=ssh res=failed'