0

I have a strange issue on a CentOS 7 machine.

If I login from the console, as two different usernames, I'm able to log in.

However, when I try that same username/password combinations, I get Permission denied.

Here're the relevant items from /etc/ssh/sshd_config:

$ sudo grep -E 'PasswordAuthentication|ChallengeResponseAuthentication|GSSAPIAuthentication|GSSAPICleanupCredentials|UsePAM' /etc/ssh/sshd_config | grep -v '^#'
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes

$ ls -ld ~
drwx------. 17 qa qa 4096 Apr 12 09:37 /home/qa

$ ls -ld ~/.ssh/
drwx------ 2 qa qa 4096 Apr 12 09:37 /home/qa/.ssh/

This is a full ssh login try:

$ ssh -v [email protected] 
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to install-tests.local [192.168.1.55] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/qa/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version dropbear_2013.58
debug1: no match: dropbear_2013.58
debug1: Authenticating to install-tests.local:22 as 'qa'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none
debug1: kex: diffie-hellman-group14-sha1 need=20 dh_need=20
debug1: kex: diffie-hellman-group14-sha1 need=20 dh_need=20
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: ssh-rsa SHA256:UkWhDf0R5TVg7Ud3HRmp+azue0T0jc5GzTQwLoCTQQQ
debug1: Host 'install-tests.local' is known and matches the RSA host key.
debug1: Found key in /home/qa/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/qa/.ssh/id_rsa
debug1: Trying private key: /home/qa/.ssh/id_dsa
debug1: Trying private key: /home/qa/.ssh/id_ecdsa
debug1: Trying private key: /home/qa/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password: 
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Any ideas?

2
  • How about an ls -l ~/.ssh to see the permissions on the files inside the .ssh directory? That would be helpful. Nice job on posting the info you did, though.
    – superboot
    Commented Apr 12, 2021 at 21:03
  • Since the problem isn't related to ssh keys, I'm not sure the files inside ~/.ssh are of interest. In any case, there is only the known_host file with 644 permission. @superboot
    – boardrider
    Commented Apr 12, 2021 at 21:21

1 Answer 1

0

Turns out the problem was not related to ssh, but to a mixup in DNS, which pointed the FQDN of the machine to the wrong IP address.
Obviously, once that was fixed, there're no more issues with ssh.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .