Why am I still getting a password prompt with ssh with key authentication?

Question

I have two Oracle Linux 7.1 servers setup (devapp and subversion are the hostnames). What I want to do is ssh into subversion from devapp without having to enter a password. I followed this guide: http://linux.byexamples.com/archives/297/how-to-ssh-without-password

Everything worked successfully in the guide yet when I do "ssh @subversion", it still prompts for a password. What am I missing?

 [bzerbe@devapp ~]$ ssh -vvv bzerbe@subversion
 OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
 debug1: Reading configuration data /home/bzerbe/.ssh/config
 debug1: Reading configuration data /etc/ssh/ssh_config
 debug1: /etc/ssh/ssh_config line 56: Applying options for *
 debug2: ssh_connect: needpriv 0
 debug1: Connecting to subversion [172.20.50.214] port 22.
 debug1: Connection established.
 debug3: Incorrect RSA1 identifier
 debug3: Could not load "/home/bzerbe/.ssh/id_rsa" as a RSA1 public key
 debug1: identity file /home/bzerbe/.ssh/id_rsa type 1
 debug1: identity file /home/bzerbe/.ssh/id_rsa-cert type -1
 debug1: identity file /home/bzerbe/.ssh/id_dsa type -1
 debug1: identity file /home/bzerbe/.ssh/id_dsa-cert type -1
 debug1: identity file /home/bzerbe/.ssh/id_ecdsa type -1
 debug1: identity file /home/bzerbe/.ssh/id_ecdsa-cert type -1
 debug1: identity file /home/bzerbe/.ssh/id_ed25519 type -1
 debug1: identity file /home/bzerbe/.ssh/id_ed25519-cert type -1
 debug1: Enabling compatibility mode for protocol 2.0
 debug1: Local version string SSH-2.0-OpenSSH_6.6.1
 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
 debug2: fd 3 setting O_NONBLOCK
 debug3: load_hostkeys: loading entries for host "subversion" from file "/home/bzerbe/.ssh/known_hosts"
 debug3: load_hostkeys: found key type ECDSA in file /home/bzerbe/.ssh/known_hosts:1
 debug3: load_hostkeys: loaded 1 keys
 debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh...01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh...00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
 debug2: kex_parse_kexinit:
 debug2: kex_parse_kexinit:
 debug2: kex_parse_kexinit: first_kex_follows 0
 debug2: kex_parse_kexinit: reserved 0
 debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
 debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256
 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
 debug2: kex_parse_kexinit: none,zlib@openssh.com
 debug2: kex_parse_kexinit: none,zlib@openssh.com
 debug2: kex_parse_kexinit:
 debug2: kex_parse_kexinit:
 debug2: kex_parse_kexinit: first_kex_follows 0
 debug2: kex_parse_kexinit: reserved 0
 debug2: mac_setup: setup hmac-md5-etm@openssh.com
 debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
 debug2: mac_setup: setup hmac-md5-etm@openssh.com
 debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
 debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
 debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
 debug1: sending SSH2_MSG_KEX_ECDH_INIT
 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
 debug1: Server host key: ECDSA 6d:cd:e2:d2:3d:61:1c:9c:3e:7d:91:4b:36:65:4c:a8
 debug3: load_hostkeys: loading entries for host "subversion" from file "/home/bzerbe/.ssh/known_hosts"
 debug3: load_hostkeys: found key type ECDSA in file /home/bzerbe/.ssh/known_hosts:1
 debug3: load_hostkeys: loaded 1 keys
 debug3: load_hostkeys: loading entries for host "172.20.50.214" from file "/home/bzerbe/.ssh/known_hosts"
 debug3: load_hostkeys: found key type ECDSA in file /home/bzerbe/.ssh/known_hosts:1
 debug3: load_hostkeys: loaded 1 keys
 debug1: Host 'subversion' is known and matches the ECDSA host key.
 debug1: Found key in /home/bzerbe/.ssh/known_hosts:1
 debug1: ssh_ecdsa_verify: signature correct
 debug2: kex_derive_keys
 debug2: set_newkeys: mode 1
 debug1: SSH2_MSG_NEWKEYS sent
 debug1: expecting SSH2_MSG_NEWKEYS
 debug2: set_newkeys: mode 0
 debug1: SSH2_MSG_NEWKEYS received
 debug1: SSH2_MSG_SERVICE_REQUEST sent
 debug2: service_accept: ssh-userauth
 debug1: SSH2_MSG_SERVICE_ACCEPT received
 debug2: key: /home/bzerbe/.ssh/id_rsa (0x7fbd227eb4d0),
 debug2: key: /home/bzerbe/.ssh/id_dsa ((nil)),
 debug2: key: /home/bzerbe/.ssh/id_ecdsa ((nil)),
 debug2: key: /home/bzerbe/.ssh/id_ed25519 ((nil)),
 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
 debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
 debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
 debug3: authmethod_lookup gssapi-keyex
 debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
 debug3: authmethod_is_enabled gssapi-keyex
 debug1: Next authentication method: gssapi-keyex
 debug1: No valid Key exchange context
 debug2: we did not send a packet, disable method
 debug3: authmethod_lookup gssapi-with-mic
 debug3: remaining preferred: publickey,keyboard-interactive,password
 debug3: authmethod_is_enabled gssapi-with-mic
 debug1: Next authentication method: gssapi-with-mic
 debug1: Unspecified GSS failure. Minor code may provide more information
 No Kerberos credentials available

 debug1: Unspecified GSS failure. Minor code may provide more information
 No Kerberos credentials available

 debug1: Unspecified GSS failure. Minor code may provide more information


 debug1: Unspecified GSS failure. Minor code may provide more information
 No Kerberos credentials available

 debug2: we did not send a packet, disable method
 debug3: authmethod_lookup publickey
 debug3: remaining preferred: keyboard-interactive,password
 debug3: authmethod_is_enabled publickey
 debug1: Next authentication method: publickey
 debug1: Offering RSA public key: /home/bzerbe/.ssh/id_rsa
 debug3: send_pubkey_test
 debug2: we sent a publickey packet, wait for reply
 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
 debug1: Trying private key: /home/bzerbe/.ssh/id_dsa
 debug3: no such identity: /home/bzerbe/.ssh/id_dsa: No such file or directory
 debug1: Trying private key: /home/bzerbe/.ssh/id_ecdsa
 debug3: no such identity: /home/bzerbe/.ssh/id_ecdsa: No such file or directory
 debug1: Trying private key: /home/bzerbe/.ssh/id_ed25519
 debug3: no such identity: /home/bzerbe/.ssh/id_ed25519: No such file or directory
 debug2: we did not send a packet, disable method
 debug3: authmethod_lookup password
 debug3: remaining preferred: ,password
 debug3: authmethod_is_enabled password
 debug1: Next authentication method: password
 bzerbe@subversion's password:

I've followed all the recommendations of setting the directory permissions too. Example:

 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/authorized_keys

On the subversion server, my /etc/ssh/sshd_config looks like this:

 # $OpenBSD: sshd_config,v 1.90 2013/05/16 04:09:14 dtucker Exp $

 # This is the sshd server system-wide configuration file. See
 # sshd_config(5) for more information.

 # This sshd was compiled with PATH=/usr/local/bin:/usr/bin

 # The strategy used for options in the default sshd_config shipped with
 # OpenSSH is to specify options with their default value where
 # possible, but leave them commented. Uncommented options override the
 # default value.

 # If you want to change the port on a SELinux system, you have to tell
 # SELinux about this change.
 # semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
 #
 #Port 22
 #AddressFamily any
 #ListenAddress 0.0.0.0
 #ListenAddress ::

 # The default requires explicit activation of protocol 1
 Protocol 2

 # HostKey for protocol version 1
 #HostKey /etc/ssh/ssh_host_key
 # HostKeys for protocol version 2
 HostKey /etc/ssh/ssh_host_rsa_key
 #HostKey /etc/ssh/ssh_host_dsa_key
 HostKey /etc/ssh/ssh_host_ecdsa_key

 # Lifetime and size of ephemeral version 1 server key
 #KeyRegenerationInterval 1h
 #ServerKeyBits 1024

 # Ciphers and keying
 #RekeyLimit default none

 # Logging
 # obsoletes QuietMode and FascistLogging
 #SyslogFacility AUTH
 SyslogFacility AUTHPRIV
 #LogLevel INFO

 # Authentication:

 #LoginGraceTime 2m
 PermitRootLogin yes
 StrictModes no
 #MaxAuthTries 6
 #MaxSessions 10

 AllowGroups root sysadmins appl

 RSAAuthentication yes
 PubkeyAuthentication yes

 # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
 # but this is overridden so installations will only check .ssh/authorized_keys
 AuthorizedKeysFile .ssh/authorized_keys

 #AuthorizedPrincipalsFile none

 #AuthorizedKeysCommand none
 #AuthorizedKeysCommandUser nobody

 # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
 #RhostsRSAAuthentication no
 # similar for protocol version 2
 #HostbasedAuthentication no
 # Change to yes if you don't trust ~/.ssh/known_hosts for
 # RhostsRSAAuthentication and HostbasedAuthentication
 #IgnoreUserKnownHosts no
 # Don't read the user's ~/.rhosts and ~/.shosts files
 #IgnoreRhosts yes

 # To disable tunneled clear text passwords, change to no here!
 #PasswordAuthentication yes
 #PermitEmptyPasswords no
 PasswordAuthentication yes

 # Change to no to disable s/key passwords
 #ChallengeResponseAuthentication yes
 ChallengeResponseAuthentication no

 # Kerberos options
 #KerberosAuthentication no
 #KerberosOrLocalPasswd yes
 #KerberosTicketCleanup yes
 #KerberosGetAFSToken no
 #KerberosUseKuserok yes

 # GSSAPI options
 #GSSAPIAuthentication no
 GSSAPIAuthentication yes
 #GSSAPICleanupCredentials yes
 GSSAPICleanupCredentials yes
 #GSSAPIStrictAcceptorCheck yes
 #GSSAPIKeyExchange no

 # Set this to 'yes' to enable PAM authentication, account processing,
 # and session processing. If this is enabled, PAM authentication will
 # be allowed through the ChallengeResponseAuthentication and
 # PasswordAuthentication. Depending on your PAM configuration,
 # PAM authentication via ChallengeResponseAuthentication may bypass
 # the setting of "PermitRootLogin without-password".
 # If you just want the PAM account and session checks to run without
 # PAM authentication, then enable this but set PasswordAuthentication
 # and ChallengeResponseAuthentication to 'no'.
 # WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
 # problems.
 #UsePAM no
 UsePAM yes

 #AllowAgentForwarding yes
 #AllowTcpForwarding yes
 #GatewayPorts no
 #X11Forwarding no
 X11Forwarding yes
 #X11DisplayOffset 10
 #X11UseLocalhost yes
 #PrintMotd yes
 #PrintLastLog yes
 #TCPKeepAlive yes
 #UseLogin no
 UsePrivilegeSeparation sandbox # Default for new installations.
 #PermitUserEnvironment no
 #Compression delayed
 #ClientAliveInterval 0
 #ClientAliveCountMax 3
 #ShowPatchLevel no
 #UseDNS yes
 #PidFile /var/run/sshd.pid
 #MaxStartups 10:30:100
 #PermitTunnel no
 #ChrootDirectory none
 #VersionAddendum none

 # no default banner path
 #Banner none

 # Accept locale-related environment variables
 AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
 AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
 AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
 AcceptEnv XMODIFIERS

 # override default of no subsystems
 Subsystem sftp /usr/libexec/openssh/sftp-server

 # Uncomment this if you want to use .local domain
 #Host *.local
 # CheckHostIP no

 # Example of overriding settings on a per-user basis
 #Match User anoncvs
 # X11Forwarding no
 # AllowTcpForwarding no
 # ForceCommand cvs server

Devapp server files:

[bzerbe@devapp .ssh]$ ls -la
total 20
drwx------. 2 bzerbe appl     67 Oct  7 10:50 .
drwx------. 9 bzerbe bzerbe 4096 Oct  7 10:49 ..
-rw-r--r--. 1 bzerbe appl     89 Oct  6 10:48 config
-rw-------. 1 bzerbe appl   1675 Oct  7 10:50 id_rsa
-rw-r--r--. 1 bzerbe appl    408 Oct  7 10:50 id_rsa.pub
-rw-r--r--. 1 bzerbe appl    186 Oct  7 10:50 known_hosts

Subversion server files:

[bzerbe@subversion .ssh]$ ls -la
total 12
drwx------. 2 bzerbe appl     46 Oct  7 10:51 .
drwx------. 6 bzerbe bzerbe 4096 Oct  7 11:10 ..
-rw-------. 1 bzerbe appl    408 Oct  7 10:50 authorized_keys
-rw-r--r--. 1 bzerbe appl    182 Oct  7 10:51 known_hosts

[bzerbe@subversion .ssh]$ ls -lZ ~/.ssh/authorized_keys
-rw-------. bzerbe appl unconfined_u:object_r:home_root_t:s0 /home/bzerbe/.ssh/authorized_keys

Any ideas?

Your ran ssh-copy-id, or manually put the contents of the local id_rsa.pub into the remote ~/.ssh/authorized_keys file? — Jeff Schaller, Oct 07 '16 at 17:43
ls -lZ ~/.ssh/authorized_keys on the server. Are the selinux labels correct? — Jakuje, Oct 07 '16 at 21:47

score 1 · Answer 1 · answered Oct 07 '16 at 18:44

Does the problem persist when you confirm the subversion server has the file /home/bzerbe/.ssh/authorized_keys containing the public key from devapp ? And that file has mode 0600 ?

Your ssh -vvv command states:

debug1: Offering RSA public key: /home/bzerbe/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

When I run a similar ssh -vvv command on a host that succeeds, I get a different log entry:

debug1: Offering DSA public key: /home/vagrant/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).

It looks like you are offering the key, and the subversion server is missing the public key in the correct file.

Your question states: "I've followed all the recommendations of setting the directory permissions too" but it's not clear that you've set those on on devapp or subversion.

On the server subversion, your sshd config is expecting that public key to be in /home/bzerbe/.ssh/authorized_keys

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

I hope that helps.

score 0 · Answer 2 · answered Oct 07 '16 at 18:09

0

You can change the configuration like this :

 # To disable tunneled clear text passwords, change to no here!
 #PasswordAuthentication yes
 PermitEmptyPasswords yes
 PasswordAuthentication no

answered Oct 07 '16 at 18:09

Rio Harapan Pangihutan

9

I don't think that will help with the key authentication not working. – ilkkachu Oct 07 '16 at 20:57

score 0 · Answer 3 · answered Oct 07 '16 at 18:36

It says it is offering the public key. So your setup on the client side is probably correct. The server side (subversion) is for some reason not accepting the key. To figure out why take a look att sshd's log on the server side. You will probably find it in /var/log/secure on your system.

score 0 · Answer 4 · answered Oct 11 '16 at 15:02

Figured it out... I followed this article and executed these lines:

restorecon -R -v /home/bzerbe
restorecon reset /home/bzerbe/.ssh context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/bzerbe/.ssh/authorized_keys context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0

Alexis Evelyn · Answer 5 · 2016-10-08T03:13:00.567

-1

It is because your /etc/ssh/sshd_config has PasswordAuthentication yes instead of PasswordAuthentication no.

edited Oct 08 '16 at 03:13

answered Oct 07 '16 at 17:24

Alexis Evelyn

586
1
4
19

1

PasswordAuthentication controls whether a password is allowed for authentication, not whether it is required. – chepner Oct 07 '16 at 17:28
Is the OP not asking for no password? "I see Everything worked successfully in the guide yet when I do "ssh @subversion", it still prompts for a password. What am I missing?" If the problem is in generating a key, then I can redirect to a different question. – Alexis Evelyn Oct 07 '16 at 17:34
He wants public-key auth to be sufficient; in this case, it's asking for a password because the key is being rejected. Disabling password authentication would prevent him from logging in altogether. – chepner Oct 07 '16 at 17:37
passwordauthentication here is just one method of providing a password via ssh; there is also keyboard-interactive; see https://tools.ietf.org/html/rfc4252#page-5 – Jeff Schaller Oct 07 '16 at 17:38
Okay, I see your point now @chepner. I had to take a fresh look at this as I saw, why am I being asked for the password (at all) and not why won't my key work (because of invalid configuration). Well, the AuthorizedKeys directory is most likely missing the key then, or it is set incorrectly. Well see what OP says. – Alexis Evelyn Oct 08 '16 at 03:16

Why am I still getting a password prompt with ssh with key authentication?

5 Answers5