Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've generated rsa keys with cygwin ssh-keygen and copied them to the server with

ssh-copy-id -i id_rsa.pub root@my.ip.address

I've got the following settings in my /etc/ssh/sshd_config file

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
PermitRootLogin yes

When I ssh root@my.ip.address it still prompts for a password.

The output below from /usr/sbin/sshd -d says that a matching keys was found in the .ssh/authorized_keys file, but it still requires a password from the client.

I've read a bunch of web postings about permissions on files and directories, but nothing works. Is it possible to ssh with keys in RHEL 6.1 or is this forbidden?

The debug output from ssh and sshd is below.

$ ssh -v root@my.ip.address
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Connecting to my.ip.address [my.ip.address] port 22.
debug1: Connection established.
debug1: identity file /home/dschulze/.ssh/id_rsa type 1
debug1: identity file /home/dschulze/.ssh/id_rsa-cert type -1
debug1: identity file /home/dschulze/.ssh/id_dsa type 2
debug1: identity file /home/dschulze/.ssh/id_dsa-cert type -1
debug1: identity file /home/dschulze/.ssh/id_ecdsa type -1
debug1: identity file /home/dschulze/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 9f:00:e0:1e:a2:cd:05:53:c8:21:d5:69:25:80:39:92
debug1: Host 'my.ip.address' is known and matches the RSA host key.
debug1: Found key in /home/dschulze/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/dschulze/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering DSA public key: /home/dschulze/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/dschulze/.ssh/id_ecdsa
debug1: Next authentication method: password

Here is the server output from /usr/sbin/sshd -d

[root@ga2-lab .ssh]# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_5.3p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 172.60.254.24 port 53401
debug1: Client protocol version 2.0; client software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user root service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "root"
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 0
debug1: test whether pkalg/pkblob are acceptable
debug1: PAM: setting PAM_RHOST to "172.60.254.24"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: db:b3:b9:b1:c9:df:6d:e1:03:5b:57:d3:d9:c4:4e:5c
debug1: restore_uid: 0/0
Postponed publickey for root from 172.60.254.24 port 53401 ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: db:b3:b9:b1:c9:df:6d:e1:03:5b:57:d3:d9:c4:4e:5c
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
debug1: do_pam_account: called
Accepted publickey for root from 172.60.254.24 port 53401 ssh2
debug1: monitor_child_preauth: root has been authenticated by privileged process
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support enabled
debug1: PAM: establishing credentials
PAM: pam_open_session(): Authentication failure
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc /dev/pts/1
ssh_selinux_setup_pty: security_compute_relabel: Invalid argument
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 17323
debug1: session_exit_message: session 0 channel 0 pid 17323
debug1: session_exit_message: release channel 0
debug1: session_pty_cleanup: session 0 release /dev/pts/1
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close: session 0 pid 0
debug1: channel 0: free: server-session, nchannels 1
Received disconnect from 172.60.254.24: 11: disconnected by user
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: deleting credentials

Here are the contents of /etc/pam.d/sshd:

#%PAM-1.0
auth       required pam_sepermit.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth

Here is the output of ls -lah .ssh

[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
share|improve this question
1  
Can you show the output of ls -lah /home/user/.ssh ? –  Tom O'Connor Dec 11 '12 at 21:45
    
Post the contents of /etc/pam.d/sshd. –  Michael Hampton Dec 11 '12 at 21:56
    
[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 –  Dean Schulze Dec 11 '12 at 22:24
    
Is there anything like pam_selinux(sshd:session): Unable to get valid context for root in the logs? –  Andrey Voitenkov Dec 12 '12 at 9:50
    
@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? –  gertvdijk Dec 12 '12 at 13:56

6 Answers 6

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.

share|improve this answer
    
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 Dec 11 '12 at 23:07

What does your /etc/ssh/sshd_config look like? Specifically lines related to Root login and Passwd Auth.

You are not "supposed" to ssh as root - but am assuming yo know that anyway. THe reason I mention this is that some distributions try to dissuade you from sshing to root directly. I do no tthink that is the case with CentOS out of the box. I wonder if SeLinux tries to do so at times...

In any event look at the /etc/ssh/sshd_config and see if that has any reasons to cause the behavior you see. Paste it here i yo uwant.

share|improve this answer

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 :)

share|improve this answer
2  
+1 - When I first started using RHEL, I started to make it habit to check if it was an SELinux issue before anything else –  Safado Dec 12 '12 at 21:54
    
SELinux is enabled. –  Dean Schulze Dec 14 '12 at 21:31
    
@evilensky I have a similar issue, but it's search instead of read. type=AVC msg=audit(1416866758.228:130): avc: denied { search } for pid=2198 comm="sshd" name="/" dev=dm-2 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir –  Arian Nov 24 at 22:14
    
How do I fix that without disabling SELinux. –  Arian Nov 24 at 22:15
up vote -3 down vote accepted

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).

share|improve this answer
    
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 –  gertvdijk Dec 14 '12 at 21:42
    
RHEL installs Tomcat with the webapps/ directory with ownership and permissions set so you have to be root to deploy an application. RHEL also installs Tomcat without the manager app, but that is done for security. That's probably something that RedHat should change. –  Dean Schulze Dec 16 '12 at 19:46
    
@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. –  Ryan Foley Jan 3 at 11:55

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
share|improve this answer
    
Nice!!! Worked for me! My '..' permissions were drwxr-xr--'. Changed that to 'drwxr-xr-x' and it worked perfectly. –  Kieveli Jun 23 at 11:50

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/

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.