Reynier Perez Mira
2015-Nov-03 03:56 UTC
[CentOS] SSH login between servers still asking for password, why?
I have two servers identified as `server-1 - 192.168.3.128` and `server-2 -
192.168.3.130`. I am setting up `capifony` for automatic deployment from
server-1 to server-2 and this is what I have done so far:
1. In both servers I have created a user `deploy` without password since
that's the user I will use for deployment.
2. In server-1 I setup a SSH keys by running the command: `ssh-keygen` and
I leave without pass-phrase and default directories.
3. I have copied the content of `/home/deploy/.ssh/id_rsa.pub` at server-1
into server-2 at `/home/deploy/.ssh/authorized_keys`.
4. From server-1 I try to reach server-2 by running `ssh
deploy at 192.168.3.130` and it's asking for a password (below is the
output)
$ ssh deploy at 192.168.3.130
The authenticity of host '192.168.3.130 (192.168.3.130)'
can't be
established.
RSA key fingerprint is
3c:81:da:7a:78:0f:b0:2f:44:3b:62:fb:c9:6f:33:86.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.3.130' (RSA) to the list of
known hosts.
deploy at 192.168.3.130's password:
This is the `-v` output of the command above:
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.3.130 [192.168.3.130] port 22.
debug1: Connection established.
debug1: identity file /home/deploy/.ssh/identity type -1
debug1: identity file /home/deploy/.ssh/identity-cert type -1
debug1: identity file /home/deploy/.ssh/id_rsa type 1
debug1: identity file /home/deploy/.ssh/id_rsa-cert type -1
debug1: identity file /home/deploy/.ssh/id_dsa type -1
debug1: identity file /home/deploy/.ssh/id_dsa-cert type -1
debug1: identity file /home/deploy/.ssh/id_ecdsa type -1
debug1: identity file /home/deploy/.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*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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: Host '192.168.3.130' is known and matches the RSA host key.
debug1: Found key in /home/deploy/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more
information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more
information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more
information
debug1: Unspecified GSS failure. Minor code may provide more
information
Cannot determine realm for numeric host address
debug1: Next authentication method: publickey
debug1: Trying private key: /home/deploy/.ssh/identity
debug1: Offering public key: /home/deploy/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/deploy/.ssh/id_dsa
debug1: Trying private key: /home/deploy/.ssh/id_ecdsa
debug1: Next authentication method: password
deploy at 192.168.3.130's password:
Why? What I am doing wrong?
Kahlil Hodgson
2015-Nov-03 04:07 UTC
[CentOS] SSH login between servers still asking for password, why?
First thought is that you may have a file permission issue on the target -- possibly selinux contexts. Have a look in /var/log/secure on the target server and it will tell you what the culprit is. I tend to use ssh-copy-id because this always ensures you've got your permissions right. Kal
Clint Dilks
2015-Nov-03 04:07 UTC
[CentOS] SSH login between servers still asking for password, why?
Hi On Tue, Nov 3, 2015 at 4:56 PM, Reynier Perez Mira <reynierpm at gmail.com> wrote:> I have two servers identified as `server-1 - 192.168.3.128` and `server-2 - > 192.168.3.130`. I am setting up `capifony` for automatic deployment from > server-1 to server-2 and this is what I have done so far: > > 1. In both servers I have created a user `deploy` without password since > that's the user I will use for deployment. > 2. In server-1 I setup a SSH keys by running the command: `ssh-keygen` and > I leave without pass-phrase and default directories. > 3. I have copied the content of `/home/deploy/.ssh/id_rsa.pub` at server-1 > into server-2 at `/home/deploy/.ssh/authorized_keys`. > 4. From server-1 I try to reach server-2 by running `ssh > deploy at 192.168.3.130` and it's asking for a password (below is the output) > >/var/log/secure should give you an indication of why the key is not being accepted. But you may have to turn the log level up. But initial thoughts are that it is likely to be a permissions problem the ~deploy/.ssh directory needs to be 700 If you are using SE Linux then you may want to try doing restorecon -Rv ~deploy/.ssh> $ ssh deploy at 192.168.3.130 > The authenticity of host '192.168.3.130 (192.168.3.130)' can't be > established. > RSA key fingerprint is > 3c:81:da:7a:78:0f:b0:2f:44:3b:62:fb:c9:6f:33:86. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added '192.168.3.130' (RSA) to the list of > known hosts. > deploy at 192.168.3.130's password: > > This is the `-v` output of the command above: > > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Connecting to 192.168.3.130 [192.168.3.130] port 22. > debug1: Connection established. > debug1: identity file /home/deploy/.ssh/identity type -1 > debug1: identity file /home/deploy/.ssh/identity-cert type -1 > debug1: identity file /home/deploy/.ssh/id_rsa type 1 > debug1: identity file /home/deploy/.ssh/id_rsa-cert type -1 > debug1: identity file /home/deploy/.ssh/id_dsa type -1 > debug1: identity file /home/deploy/.ssh/id_dsa-cert type -1 > debug1: identity file /home/deploy/.ssh/id_ecdsa type -1 > debug1: identity file /home/deploy/.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* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.3 > 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: Host '192.168.3.130' is known and matches the RSA host key. > debug1: Found key in /home/deploy/.ssh/known_hosts:1 > debug1: ssh_rsa_verify: signature correct > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > 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: gssapi-keyex > debug1: No valid Key exchange context > debug1: Next authentication method: gssapi-with-mic > debug1: Unspecified GSS failure. Minor code may provide more > information > Cannot determine realm for numeric host address > > debug1: Unspecified GSS failure. Minor code may provide more > information > Cannot determine realm for numeric host address > > debug1: Unspecified GSS failure. Minor code may provide more > information > > > debug1: Unspecified GSS failure. Minor code may provide more > information > Cannot determine realm for numeric host address > > debug1: Next authentication method: publickey > debug1: Trying private key: /home/deploy/.ssh/identity > debug1: Offering public key: /home/deploy/.ssh/id_rsa > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic,password > debug1: Trying private key: /home/deploy/.ssh/id_dsa > debug1: Trying private key: /home/deploy/.ssh/id_ecdsa > debug1: Next authentication method: password > deploy at 192.168.3.130's password: > > Why? What I am doing wrong? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
Reynier Perez Mira
2015-Nov-03 04:23 UTC
[CentOS] SSH login between servers still asking for password, why?
Thanks guys by checking permissions on /home/deploy/.ssh directory I can see that the owner was root and that was the cause of the issue, setting that to deploy allow me to connect from server-1 to server-2 successfully Kind regards,> -----Original Message----- > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On > Behalf Of Clint Dilks > Sent: Monday, November 2, 2015 11:08 PM > To: CentOS mailing list <centos at centos.org> > Subject: Re: [CentOS] SSH login between servers still asking for password, > why? > > Hi > > On Tue, Nov 3, 2015 at 4:56 PM, Reynier Perez Mira <reynierpm at gmail.com> > wrote: > > > I have two servers identified as `server-1 - 192.168.3.128` and > > `server-2 - 192.168.3.130`. I am setting up `capifony` for automatic > > deployment from > > server-1 to server-2 and this is what I have done so far: > > > > 1. In both servers I have created a user `deploy` without password > > since that's the user I will use for deployment. > > 2. In server-1 I setup a SSH keys by running the command: > > `ssh-keygen` and I leave without pass-phrase and default directories. > > 3. I have copied the content of `/home/deploy/.ssh/id_rsa.pub` at > > server-1 into server-2 at `/home/deploy/.ssh/authorized_keys`. > > 4. From server-1 I try to reach server-2 by running `ssh > > deploy at 192.168.3.130` and it's asking for a password (below is the > > output) > > > > > /var/log/secure should give you an indication of why the key is not being > accepted. But you may have to turn the log level up. > > But initial thoughts are that it is likely to be a permissions problem the > ~deploy/.ssh directory needs to be 700 If you are using SE Linux then you > may want to try doing restorecon -Rv ~deploy/.ssh > > > > > > > > $ ssh deploy at 192.168.3.130 > > The authenticity of host '192.168.3.130 (192.168.3.130)' can't > > be established. > > RSA key fingerprint is > > 3c:81:da:7a:78:0f:b0:2f:44:3b:62:fb:c9:6f:33:86. > > Are you sure you want to continue connecting (yes/no)? yes > > Warning: Permanently added '192.168.3.130' (RSA) to the list > > of known hosts. > > deploy at 192.168.3.130's password: > > > > This is the `-v` output of the command above: > > > > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: Applying options for * > > debug1: Connecting to 192.168.3.130 [192.168.3.130] port 22. > > debug1: Connection established. > > debug1: identity file /home/deploy/.ssh/identity type -1 > > debug1: identity file /home/deploy/.ssh/identity-cert type -1 > > debug1: identity file /home/deploy/.ssh/id_rsa type 1 > > debug1: identity file /home/deploy/.ssh/id_rsa-cert type -1 > > debug1: identity file /home/deploy/.ssh/id_dsa type -1 > > debug1: identity file /home/deploy/.ssh/id_dsa-cert type -1 > > debug1: identity file /home/deploy/.ssh/id_ecdsa type -1 > > debug1: identity file /home/deploy/.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* > > debug1: Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-2.0-OpenSSH_5.3 > > 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: Host '192.168.3.130' is known and matches the RSA host key. > > debug1: Found key in /home/deploy/.ssh/known_hosts:1 > > debug1: ssh_rsa_verify: signature correct > > debug1: SSH2_MSG_NEWKEYS sent > > debug1: expecting SSH2_MSG_NEWKEYS > > debug1: SSH2_MSG_NEWKEYS received > > 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: gssapi-keyex > > debug1: No valid Key exchange context > > debug1: Next authentication method: gssapi-with-mic > > debug1: Unspecified GSS failure. Minor code may provide more > > information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more > > information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more > > information > > > > > > debug1: Unspecified GSS failure. Minor code may provide more > > information > > Cannot determine realm for numeric host address > > > > debug1: Next authentication method: publickey > > debug1: Trying private key: /home/deploy/.ssh/identity > > debug1: Offering public key: /home/deploy/.ssh/id_rsa > > debug1: Authentications that can continue: > > publickey,gssapi-keyex,gssapi-with-mic,password > > debug1: Trying private key: /home/deploy/.ssh/id_dsa > > debug1: Trying private key: /home/deploy/.ssh/id_ecdsa > > debug1: Next authentication method: password > > deploy at 192.168.3.130's password: > > > > Why? What I am doing wrong? > > > > _______________________________________________ > > CentOS mailing list > > CentOS at centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos