ssh key to acces without password error

businesscat · 06-21-2017, 04:17 AM

Hello everyone,

I´m need connect without password to other host. I´m using the following commands:

Code:

[root@pluton3 .ssh]# ssh-copy-id -i /home/nagios/.ssh/id_dsa.pub nagios@10.58.79.121 
28 
nagios@10.58.79.121's password:  
Now try logging into the machine, with "ssh 'nagios@10.58.79.121'", and check in: 
 
  .ssh/authorized_keys 
 
to make sure we haven't added extra keys that you weren't expecting.

in the other host (10.58.79.121) show the following files on /var/spool/nagios/.ssh :

-rw------- 1 nagios nagios 1.2K Jun 21 10:25 authorized_keys
-rw-r--r-- 1 nagios nagios 394 Jun 20 11:56 id_rsa.pub

When I try to connect via ssh with the user the host requires the password.

OS: RHEL 6.9

Thank you in advance

I hope not forget any relevant data.

cbing · 06-21-2017, 04:50 AM

Hi,

The issue is maybe related to the parent directories permissions.
Check them and try again.
Check also that the id_rsa.pub of the origin server match with the content of the authorized_keys of the destiny server.

BR.

Habitual · 06-21-2017, 05:46 AM

Code:

600 ~/.ssh/id_rsa 
700 ~/.ssh/

wpeckham · 06-21-2017, 05:48 AM

You did check the directory ~/.ssh but not the permissions on ~/ itself. Check that please.

businesscat · 06-21-2017, 07:59 AM

Thanks for the replies.

origin host:

drwxrwx--- 2 nagios nagios 4,0K jun 21 13:13 .ssh

destiny host:

drwxr-xr-x 2 nagios nagios 4.0K Jun 21 14:39 .ssh

If I use -vvv show the following traces:

Quote:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to IP [IP] port 22.
debug1: Connection established.
debug1: identity file /home/nagios/.ssh/identity type -1
debug3: Not a RSA1 key file /home/nagios/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/nagios/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /home/nagios/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/nagios/.ssh/id_dsa type 2
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,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-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@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: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,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-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@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_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 115/256
debug2: bits set: 515/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/nagios/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 73
debug1: Host '10.58.79.121' is known and matches the RSA host key.
debug1: Found key in /home/nagios/.ssh/known_hosts:73
debug2: bits set: 501/1024
debug1: ssh_rsa_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/nagios/.ssh/identity ((nil))
debug2: key: /home/nagios/.ssh/id_rsa (0x2b8910f23440)
debug2: key: /home/nagios/.ssh/id_dsa (0x2b8910f24c00)
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-with-mic,publickey,keyboard-interactive,password
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
debug3: Trying to reverse map address 10.58.79.121.
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

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: Trying private key: /home/nagios/.ssh/identity
debug3: no such identity: /home/nagios/.ssh/identity
debug1: Offering public key: /home/nagios/.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: Offering public key: /home/nagios/.ssh/id_dsa
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
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

In other host (clon of this) works perfectly and comunicate with the origin without password.

Thank you again

I continue try things

wpeckham · 06-21-2017, 12:23 PM

Try removing group write permission on the home folders. You list ONE instance above where group writes are allowed.

IF that does not suffice, check the sshd log entries for clues.

Habitual · 06-21-2017, 12:51 PM

Client:

Code:

stat --printf "%a %n \n" ~/.ssh/ ~/.ssh/known_hosts ~/.ssh/id_rsa

spews

Code:

755 /home/jj/.ssh/ 
600 /home/jj/.ssh/known_hosts 
600 /home/jj/.ssh/id_rsa

Server:

Code:

stat --printf "%a %n \n" ~/.ssh/ ~/.ssh/authorized_keys

spews

Code:

700 /root/.ssh/ 
600 /root/.ssh/authorized_keys

NOTE: I don't have a nagios user, so You will have to "adjust" as needed.
either one or more of those files:perms:ownership are incorrect, or
contents of ~/.ssh/id_rsa are "off" or it was genned with a key, and there's the xFactor, stuff I forgot.

I'd try something with a new key, eg: on your client host. Like:

Code:

ssh-keygen -f ~/.ssh/nagios -t rsa -N '' -b 4096 -q -C "Nagios key made on $(date +"%F")

which is ssh.fu for strong key.
Comment for the file is and will be "Nagios key made on yyyy-mm-dd" (depending?)
then as root:

Code:

ssh-copy-id -i /home/businesscat/.ssh/nagios.pub nagios@10.58.79.121

if you are prompted for a password, head on over to 10.58.79.121 using another identity, or method. and check /home/nagios/.ssh and under for owner:group:permissions
using

Code:

stat --printf "%a %n \n" /home/nagios/.ssh/ /home/nagios/.ssh/authorized_keys

NOTE: IDK if/where the nagios user $HOME "is", so that's homework? :)

Familiar with chmod?

Hope that helps!
And check /var/log/auth.log or /var/log/secure...? on 10.58.79.121 for signs.

Have Fun!

wpeckham · 06-21-2017, 08:03 PM

OK, I am seeing multiple checks of .ssh folders, but the PARENT folder is also critical.
IE: for root check the /root folder. for jj check the /home/jj folder.
for checking the remote nagios user folder you can

Code:

ssh nagios@<nagios server name or address> 'ls -ld .'

You will have to enter the nagios password, but then it should output the nagios home folder stats with permissions.

NOTE: whoever set up the nagios server MAY have disabled key authentication for security. I might.

Turbocapitalist · 06-22-2017, 12:51 AM

As others have asked, verify the permissions of the directories involved. On the destination host:

Code:

ls -lhd /home/
ls -lhd /home/nagios/
ls -lhd /home/nagios/.ssh/
ls -lh /home/nagios/.ssh/authorized_keys

Then on the source host do similar except for the last line.

Quote:

Originally Posted by businesscat

If I use -vvv show the following traces:

Code:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
. . .
debug1: identity file /home/nagios/.ssh/identity type -1
debug3: Not a RSA1 key file /home/nagios/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
. . . 

debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/nagios/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /home/nagios/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
. . .
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/nagios/.ssh/id_dsa type 2
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
. . .

In other host (clon of this) works perfectly and comunicate with the origin without password.

Thanks. That output helps.

However, there are several comments to make:

It looks like there may be a problem with the keys themselves. Please show the steps you used to generate them. If you 'borrowed' existing keys from another host, then stop and generate unique keys for this one. e.g.

Code:

 
ssh-keygen -t rsa -b 2048 -f dhost.rsa -C shost

Also, RSA1 and DSA keys have long since been deprecated. They are unsafe against modern computing power. There should not be any of either type anywhere on either your source or destination hosts. Newer versions of OpenSSH actively ignore such key types.

But you are using ancient versions of OpenSSH on both the client and the server. What assurances do you have that they are properly patched? Or what is the most recent version you can get in your backport repository?

Lastly, please don't run this all as root. At best, it complicates dealing with the file placement and file permissions.

businesscat · 06-22-2017, 02:34 AM

Quote:

Originally Posted by Turbocapitalist

As others have asked, verify the permissions of the directories involved. On the destination host:

Code:

ls -lhd /home/
ls -lhd /home/nagios/
ls -lhd /home/nagios/.ssh/
ls -lh /home/nagios/.ssh/authorized_keys

Then on the source host do similar except for the last line.

DESTINATION HOST:

user (on etc/passwd) nagios:x:498:499::/var/spool/nagios:/bin/bash

Code:

[root@DESTINATION HOST ~]# ls -lhd /var/
drwxr-xr-x. 20 root root 4.0K Jun  2 13:52 /var/
[root@DESTINATION HOST ~]# ls -lhd /var/spool/
drwxrwxr-x. 11 root root 4.0K Jun  6 09:42 /var/spool/
[root@DESTINATION HOST ~]# ls -lhd /var/spool/nagios/
drwxrwx--- 3 nagios nagios 4.0K Jun 21 14:39 /var/spool/nagios/
[root@DESTINATION HOST ~]# ls -lhd /var/spool/nagios/.ssh/
drwxr-xr-x 2 nagios nagios 4.0K Jun 21 14:39 /var/spool/nagios/.ssh/
[root@DESTINATION HOST ~]# ls -lhd /var/spool/nagios/.ssh/authorized_keys 
-rwxr--r-- 1 nagios nagios 1.6K Jun 21 14:39 /var/spool/nagios/.ssh/authorized_keys

/home/nagios/ doesn´t exists

SOURCE HOST:

nagios:x:503:503:Nagios:/home/nagios:/bin/bash

Code:

[root@SOURCEHOST ~]# ls -lhd /home/
drwxr-xr-x 13 root root 4,0K jun 21 14:00 /home/
[root@SOURCEHOST ~]# ls -lhd /home/nagios/
drwx------ 4 nagios nagios 4,0K jun 21 13:13 /home/nagios/
[root@SOURCEHOST ~]# ls -lhd /home/nagios/.ssh/
drwxrwx--- 2 nagios nagios 4,0K jun 21 13:13 /home/nagios/.ssh/
[root@SOURCEHOST ~]# ls -lhd /home/nagios/.ssh/authorized_keys 
-rwxrw-r-- 1 nagios nagios 394 jun  3  2013 /home/nagios/.ssh/authorized_keys

Quote:

Originally Posted by Turbocapitalist

Thanks. That output helps.

However, there are several comments to make:

It looks like there may be a problem with the keys themselves. Please show the steps you used to generate them. If you 'borrowed' existing keys from another host, then stop and generate unique keys for this one. e.g.

Code:

 
ssh-keygen -t rsa -b 2048 -f dhost.rsa -C shost

Also, RSA1 and DSA keys have long since been deprecated. They are unsafe against modern computing power. There should not be any of either type anywhere on either your source or destination hosts. Newer versions of OpenSSH actively ignore such key types.

But you are using ancient versions of OpenSSH on both the client and the server. What assurances do you have that they are properly patched? Or what is the most recent version you can get in your backport repository?

Lastly, please don't run this all as root. At best, it complicates dealing with the file placement and file permissions.

In this moment:

Code:

[root@SOURCEHOST ~]# rpm -qa | grep ssh
openssh-4.3p2-82.el5
openssh-askpass-4.3p2-82.el5
rssh-2.3.4-1.el5
openssh-server-4.3p2-82.el5
openssh-clients-4.3p2-82.el5


[root@DESTINATION HOST ~]# rpm -qa | grep ssh
openssh-clients-5.3p1-122.el6.x86_64
openssh-5.3p1-122.el6.x86_64
openssh-server-5.3p1-122.el6.x86_64
libssh2-1.4.2-2.el6_7.1.x86_64

In another host (with the same template of DESTINATION HOST) works fine

This is the prompt of the generation of the sshkeys :

Code:

[root@SOURCEHOST .ssh]# ssh-copy-id -i /home/nagios/.ssh/id_dsa.pub nagios@DESTINATION HOST 
28 
nagios@DESTINATION HOST's password:  
Now try logging into the machine, with "ssh 'nagios@DESTINATION HOST'", and check in: 
 
  .ssh/authorized_keys 
 
to make sure we haven't added extra keys that you weren't expecting.

businesscat · 06-22-2017, 05:35 AM

Quote:

Originally Posted by Habitual

Hope that helps!
And check /var/log/auth.log or /var/log/secure...? on 10.58.79.121 for signs.

Have Fun!

Thanks Habitual!

I see the followings lines when I try to connect via ssh with the user:

Code:

Jun 22 12:33:01 DESTINY HOST sshd[16873]: Authentication refused: bad ownership or modes for directory /var/spool/nagios
Jun 22 12:33:01 DESTINY HOST sshd[16873]: Authentication refused: bad ownership or modes for directory /var/spool/nagios

I´m checking it now

wpeckham · 06-22-2017, 05:48 AM

The key format issue should be investigated, but you have good advice on that already and I will not address it.

The file and folder permissions:
SOURCE: /home/nagios/.ssh has 770 permissions, and it should have 700 permissions. (750 may also work, but 770 will disallow key authentication unless an over-ride of the default settings has been installed) No files under .ssh should have write permissions for anyone other than the user.

DESTINATION: /var/spool/nagios should have something like 755 (or 750) permissions not 770.
Why are the versions here so far backlevel? Is this a very old server? Is it maintained? When were updates last applied?
There have been a TON of improvements and security patches since that version. Running a version that old would worry me.

businesscat · 06-22-2017, 06:31 AM

Quote:

Originally Posted by wpeckham

The key format issue should be investigated, but you have good advice on that already and I will not address it.

The file and folder permissions:
SOURCE: /home/nagios/.ssh has 770 permissions, and it should have 700 permissions. (750 may also work, but 770 will disallow key authentication unless an over-ride of the default settings has been installed) No files under .ssh should have write permissions for anyone other than the user.

DESTINATION: /var/spool/nagios should have something like 755 (or 750) permissions not 770.
Why are the versions here so far backlevel? Is this a very old server? Is it maintained? When were updates last applied?
There have been a TON of improvements and security patches since that version. Running a version that old would worry me.

and this is it!!!

it works!

Code:

[nagios@SOURCE .ssh]$ ssh nagios@DESTINATION
Last login: Wed Jun 21 14:32:50 2017 
-bash-4.1$ hostname
DESTINATION

I hope, in the future, we can delete this host (SOURCE) and create again other host updated and clean.

Thank all so much!

and sorry for the stupid issue.