2

I'm connecting from machine M1 to machine M2 using ssh (to the same user on the other machine). I should also mention the user shares the same key on both machines. With password authentication, everything works fine; not so with public-key authentication; I've ensured ~/.ssh/authorized_keys on M2 has the RSA key as authorized, but still - ssh falls back to password authentication. I get the following with ssh -vvv:

debug2: key: /home/joeuser/.ssh/id_rsa (0x7f42679e8200),
debug2: key: /home/joeuser/.ssh/id_dsa ((nil)),
debug2: key: /home/joeuser/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred 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: /home/joeuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/joeuser/.ssh/id_dsa
debug3: no such identity: /home/joeuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/joeuser/.ssh/id_ecdsa
debug3: no such identity: /home/joeuser/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method

I should mention that I am able to connect using public-key authentication from other machines (not with the same key).

What are the potential reasons for key-based authentication failing in this case?

Note: The machines are both SLES (SuSE Linux Enterprise Server) 11.

einpoklum
  • 1,652
  • 3
  • 21
  • 31
  • 2
    Read the log file of the sshd. It should contain a clear reason why it rejects your ssh key. – Gerald Schneider Aug 30 '20 at 15:32
  • 1
    You need to check the logs on the server to find out why this failed. – Michael Hampton Aug 30 '20 at 16:27
  • also double check the authorized_keys file content vis-a-vis the key your client is offering. Run `ssh-keygen -l -f FILE` against each file, replacing FILE. Output should be the same. (If the authorized_keys file contains other keys it will have more lines but one of them should match the output of running this on your id_rsa. –  Sep 03 '20 at 07:18
  • @sitaram: Of course the key is there, otherwise this question wouldn't make sense... – einpoklum Sep 03 '20 at 22:25

3 Answers3

2

You were doing the right thing using ssh -vvv from the client, pair it with a sshd in debug mode, like this:

a second server instance: # /usr/sbin/sshd -p 1234 -dddd

a dedicated client to connect: $ ssh -i .ssh/id_rsa-admuser admuser@server -p 1234 -vvvv

In my case it turned out that the crucial info was printed on the client only. The server went through

debug2: user_key_allowed: check options...
debug2: user_key_allowed: advance ...
debug2: key not found

while the client came up with this:

debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa-admuser RSA SHA256:<censored> explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

So what was going on here?

The server was so old they could not negotiate a helper algorithm; the key was also dated, but generally fine.

What would be the basic approach now?

  1. start dedicated server on a different port
  2. connect from client in new session
  3. compare the key exchange on both sides, step by step
  4. validate findings using a newly generated second key pair

In this specific example there was a clear explanation that it was an insecure old method that had been deprecated, i.e. described here. https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

To be able to update that old box I could connect by adding -o PubkeyAcceptedKeyTypes=+ssh-rsa to the ssh command line on the client.

Florian Heigl
  • 1,479
  • 12
  • 20
1

Check the basics:

  1. id_rsa and id_rsa.pub exist on both M1 and M2
  2. id_rsa has permission 600 (i.e only the owner can read-write) on both M1 and M2
  3. authorized_keys file has key pasted as a single line (no line break)
  4. Permission of authorized_keys is 600
  5. Typically, permission on my .ssh folder is 600 (default)
  6. Check the permission of each folder /home all way up to .ssh
  7. I know you want to use RSA, but try DSA key and see if it works. If it does, then we'll have zeroed in SSH and RSA config.
tinkertwain
  • 305
  • 1
  • 8
-1

The error you get is

/home/joeuser/.ssh/id_dsa: No such file or directory

Make sure this file exists, contains the private key that corresponds to the public key that you've added, belongs to joeuser and has 600 user permissions:

sudo chown joeuser /home/joeuser/.ssh/id_dsa
sudo chmod 600 /home/joeuser/.ssh/id_dsa

You should also try to explicitly define the private key like this:

ssh -i ~/.ssh/id_rsa user@remote.example.com

If you are not sure if this is the right key then I'd recommend to create a new RSA key pair

ssh-keygen -b 4096

and add the content of the public key ~/.ssh/id_rsa.pub to the authorized_keys file of the remote server. Make sure that you don't overwrite an existing private key that you still need to login to other servers!

digijay
  • 1,155
  • 3
  • 11
  • 22