LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Red Hat (https://www.linuxquestions.org/questions/red-hat-31/)
-   -   cannot connect w/o a password via ssh (https://www.linuxquestions.org/questions/red-hat-31/cannot-connect-w-o-a-password-via-ssh-4175633875/)

dan.mera 07-12-2018 12:16 PM

cannot connect w/o a password via ssh
 
Hello,
I hope that someone can suggest something to help me connect w/o a password to another server. Both source and destination are RedHat 7.4(Maipo) version).
I'm trying to setup ssh keys between a server to multiple other ones and i cannot get rid of password authentication and here is what is verified as prerequisites:
1. home directory is 755(source and destination )
2. .ssh directory is 700(source and destination )
3. all files are 600(authorized_keys,known_hosts,id_rsa and id_rsa.pub)(source and destination )
4. /etc/ssh/sshd_config has these set correctly:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

keys were copied with ssh-copy-id command to avoid mistakes.
I tried to create dsa keys but also same result, even tough i can see another server which is connecting via a dsa key.
From the same source i can connect to one destination successfully and comparing the /etc/ssh/sshd_config files are exactly the same.
to other destinations i'm getting these output using these commands:
ssh -vvv -i $HOME/.ssh/id-rsa xxx@hostname or
ssh -vvv xxx@hostname gives this:
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 (default cache: KEYRING:persistent:600)

debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:600)

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: /xxx/xxx/.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 DSA public key: /xxx/xxx/.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
debug1: Trying private key: /xxx/xxx/.ssh/id_ecdsa
debug3: no such identity: /xxx/xxx/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /xxx/xxx/.ssh/id_ed25519
debug3: no such identity: /xxx/xxx/.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
Any suggestions is appreciated as I ran out of google new ideas.
thank you

kilgoretrout 07-12-2018 12:43 PM

First, if you're running RHEL7.4, do you have a service contract with RedHat?

Second, exactly what command did you run to generate your key and what was the output.

I'm not an expert on RH systems, but judging from the output when you try to login, I'm guessing that for security reasons, RH has configured ssh to require both key and password. If you generated your key with a blank password, it may be refusing on that basis. Either that, or the key was generated with a password and you'll need to supply it when you login.

jsbjsb001 07-12-2018 12:54 PM

Quote:

Originally Posted by kilgoretrout (Post 5878536)
...I'm not an expert on RH systems, but judging from the output when you try to login, I'm guessing that for security reasons, RH has configured ssh to require both key and password. If you generated your key with a blank password, it may be refusing on that basis. Either that, or the key was generated with a password and you'll need to supply it when you login.

Not so sure about that. I used SSH from my smartphone to my desktop with CentOS 7.4 and it worked without any keys setup. They might need to enable certain options in their SSH config file.

dan.mera 07-12-2018 12:57 PM

I generated the key using ssh-keygen -t rsa -b 2048 and i didn't use a password for the key. the same key will connect to another destination w/o asking for any password. there is a service contract with redhat, but I'm not the linux admin even though the account used can su to root but the connection is attempted from the user and not from the root.
thanks

jsbjsb001 07-12-2018 01:01 PM

Quote:

Originally Posted by dan.mera (Post 5878541)
I generated the key using ssh-keygen -t rsa -b 2048 and i didn't use a password for the key. the same key will connect to another destination w/o asking for any password.
thanks

Did you notice any of the following messages ?

Code:

debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
...
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:600)
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /xxx/xxx/.ssh/id_ecdsa
debug3: no such identity: /xxx/xxx/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /xxx/xxx/.ssh/id_ed25519
debug3: no such identity: /xxx/xxx/.ssh/id_ed25519: No such file or directory

From you're error messages, it looks like it cannot find the key you created. And please use CODE tags when posting command output.

scasey 07-12-2018 01:15 PM

Look at (but probably shouldn't post) the contents of ~/.ssh/authorized_keys on the remote server to confirm that the key is there.

Also, note that man ssh-copy-id says:
Code:

The default_ID_file is the most recent file that matches: ~/.ssh/id*.pub...
so check that with
Code:

lr ~/.ssh/id*.pub
on the local server to be sure the correct key got copied.

Review man ssh-copy-id for details.

Oh! Is the account logging in as root? Or as the non-privileged user?

michaelk 07-12-2018 01:22 PM

Code:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /xxx/xxx/.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 DSA public key: /xxx/xxx/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply

The OP only stated that rsa and dsa keys were created. Both keys were were offered but neither was not accepted by the server. As stated the correct public key might not of be copied to the destination.

Is the other destination also running RHEL 7? I don't know if it is configured for 2fa. CentOS 7 is not.

dan.mera 07-12-2018 01:38 PM

now that you mentioned i noticed when comparing connecting to a destination sucessfull:
Quote:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
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: /data/britebil/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /data/britebil/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 435
and unsucessfull:
Quote:

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: /data/britebil/.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 DSA public key: /data/britebil/.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
debug1: Trying private key: /data/britebil/.ssh/id_ecdsa
debug3: no such identity: /data/britebil/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /data/britebil/.ssh/id_ed25519
debug3: no such identity: /data/britebil/.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
source and destination( 2 servers) are running the same version of RHEL 7.4. compared the destinations(success vs unsuccess) key and they are identical. running as a regular user the connection. thanks to all so far for questions and notes/suggestions

michaelk 07-12-2018 06:56 PM

Quote:

compared the destinations(success vs unsuccess) key and they are identical.
The authorized_keys file are identical on both destinations? Did you copy both public keys i.e. the id_dsa.pub and id_rsa.pub to each server? Could you of overwritten one of the keys so the public key on the unsuccessful destination does not match the private key?

How many keys are in the authorized_keys file on the unsuccessful server? Can you start over i.e delete the file and copy the correct public key?

dan.mera 07-13-2018 11:51 AM

one of my colleagues found the solution which I would like to share:
it seems that the security around the authentication had to do something with SE Linux.(not sure how that works)
but the home directory for this id changed from /home/user to /data/user.
ls -aZ whould show the security context like this:
drwx------. user user unconfined_u:object_r:default_t:s0 .ssh
and the solution found on this link https://www.sysarchitects.com/ssh_and_rhel6
changing the security context using this command
chcon -t ssh_home_t .ssh/
chcon -t ssh_home_t .ssh/authorized_keys
will make the security context like this:
drwx------. user user system_u:object_r:ssh_home_t:s0 .ssh

and the connection is successful.
Thank you to everyone who looked at it and tried to help me and hopefully it will help someone.

kilgoretrout 07-14-2018 01:30 PM

Quote:

it seems that the security around the authentication had to do something with SE Linux.(not sure how that works)
Should have known. I'm not sure anyone knows how selinux works. The first thing I've always done when running fedora is disable it and I'm not alone. That's obviously not appropriate in a production environment, however.


All times are GMT -5. The time now is 05:38 PM.