49

I've been struggling with this for a couple hours so any help is greatly appreciated...

I have 2x servers both of which I can ssh to with public keys from OSX, no issues at all there so I'm certain everything is good with sshd_config.

I'm trying to configure a cron job for rsync to sync the two servers and need server B (backup) to ssh into server A using a public key.

I cannot for the life of me work out why it doesn't find my public keys - they are in ~/.ssh/ (ie. /root/.ssh) and all file permissions are correct on A & B.

This is the output:

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: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
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

Also note it is looking for private keys which don't exist... 

drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root  403 May 25 01:37 authorized_keys
-rw-------. 1 root root    0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root  405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root  395 May 25 02:36 known_hosts
Improve this question
5
  • 2
    please give us the output of ls -la /root/.ssh/
    – mreithub
    May 25, 2014 at 10:16
  • @mreithub Thanks for the quick reply - added above.
    – Danny
    May 25, 2014 at 10:18
  • 3
    try removing the _tm1 from your key file names (i.e. mv id_rsa_tm1 id_rsa and mv id_rsa_tm1.pub id_rsa.pub)
    – mreithub
    May 25, 2014 at 10:20
  • @mreithub That worked! Thanks you very much, however i don't understand why i cannot append other strings to the file name. I do so on my iMac to connect to the servers without any issues... ie I can use id_rsa.tm1.imac.pub without any issues. What if i wanted multiple keys?
    – Danny
    May 25, 2014 at 10:26
  • On a Mac, SSH can also use keys stored in a MacOS user's keychain. If you have ever used ssh-add /root/.ssh/id_rsa_tm1, then the key is stored in the keychain persistently and SSH can find it from there. This is a Mac-specific extension: a generic OpenSSH client won't have such functionality, and to use non-default keys you would either have to use an option like ssh -i ~/.ssh/id_rsa_tm1 ..., or use the ~/.ssh/config file to specify which non-default key to use with a specific server.
    – telcoM
    Nov 22, 2021 at 22:10

15 Answers 15

Reset to default
38

A malformed authorized_keys file on the destination host is another reason ssh outputs the "we did not send a packet" message and asks for a password instead of using pubkey auth:-

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method

The problem in this particular case was that the public key data, which had been pasted into .ssh/authorized_keys at the destination host, was missing its first character:-

sh-rsa AAAA...

The solution was simply to add the missing "s".

ssh-rsa AAAA...

And so:-

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).
Improve this answer
4
  • 3
    thank you, every time I get this error it's because my authorized_keys file on the remote host (server) is malformed. I wish the error didn't make it sound like there was a problem with the client.
    – tamale
    Sep 18, 2017 at 14:53
  • 7
    Pasting into vim without pressing 'i' first!
    – Jordan Davidson
    Feb 28, 2018 at 4:36
  • For me it didn't seem malformed but I deleted the file and from the source machine I did the ssh-copy-id again to recreate it. Problem solved.
    – alvarez
    Jul 27, 2018 at 7:34
  • I've tried every solution found, nothing worked until this post. thank you.
    – user6308
    Aug 31 at 11:21
27

Have a look at your ssh man page:

   -i identity_file
          Selects a file from which the identity (private key) for public
          key authentication is read.  The default is ~/.ssh/identity for
          protocol   version   1,   and  ~/.ssh/id_dsa,  ~/.ssh/id_ecdsa,
          ~/.ssh/id_ed25519 and ~/.ssh/id_rsa  for  protocol  version  2.
          Identity files may also be specified on a per-host basis in the
          configuration file.  It is possible to have multiple -i options
          (and  multiple  identities  specified  in configuration files).

or the ssh_config man page:

   IdentityFile
          Specifies a file from which the user's DSA, ECDSA,  ED25519  or
          RSA   authentication   identity   is   read.   The  default  is
          ~/.ssh/identity for  protocol  version  1,  and  ~/.ssh/id_dsa,
          ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
          col version 2.  Additionally, any identities represented by the
          authentication  agent  will  be  used for authentication unless
          IdentitiesOnly is set.

You see, there are a few special file names which are tried if you do not specify a key. Those are also the files you see in your log output.

To use a key in a file with different name you have three options:

  • specify the file explicitly using the above -i option.
  • configure the file in your client config using the above IdentityFile option.
  • add the key to your agent using ssh-add.

For interactive sessions the agent is the most flexible one. For your cron job the -i option is probably the easiest one.

Improve this answer
1
  • 1
    Upvoting not because this answered my issue directly, but realised that in Ubuntu, doing ssh-copy-id as root doesn't mean it will transfer root's key, but instead the parent user that was logged and is sudo'ing as root...
    – KolonUK
    Dec 18, 2019 at 0:30
22

This exact string of error messages in the question can also occur in the case of a miss-matched private/public key pair on the local side. No that doesn't make any sense but I just tore my hair out for a long time trying to figure out what was going on.

  • Remote system A has .ssh/mykey.pub copied into .ssh/authorized_keys.
  • Local system B has .ssh/mykey that is the correct private key to match system A's public key, but also has a .ssh/mykey.pub file that is a miss-match, possibly the previous version of a replaced key.

SSH from B to A (ssh -i mykey A)will fail with the messages in the question, most notably if you turn on -vv from the ssh client you'll see:

Trying private key: .ssh/mykey
we did not send a packet, disable method

This is a lie because the actual key wasn't tried, it apparently used the local public key file with the matching name to figure out if it was likely to work and then didn't actually do anything when they were a mismatch. No amount of debug information on either side really hints at the problem.

Improve this answer
5
  • Wow! This one killed quite a bit of time for me too! Lost some hair! So in my case it was this too, only my pub key was indeed in the client side authorized_keys file, except it included a name@host entry at the very end, where my sshd host did not. I did not realize you need to match the authorized_keys on each end, in fact, I don't think I've ever matched them before. This was a problem only when my client was CentOS 7, connecting to Ubuntu 12.04. Going from MacOS, or other Ubuntu systems worked just fine.
    – gregthegeek
    Mar 7, 2017 at 0:15
  • So how do you fix this problem? You've described my problem to a T. My problem is further exacerbated because I'm leap frogging between a number of systems. Actually specifying the file isn't working for me
    – Madivad
    Apr 17, 2017 at 16:55
  • @Madivad You fix the problem by having matched public/private keys locally (or no public keys at all).
    – Caleb
    Apr 17, 2017 at 18:33
  • @Caleb That sounds more simple than it is unless (and I think the penny has dropped) this means I should be copying both public and private keys to each system that I want to use as an SSH client? I've tried creating an IdentityFile, but I'm obviously using it wrong
    – Madivad
    Apr 17, 2017 at 22:52
  • Removing the orphaned id_rsa.pub file on client solved this for me. I just ran into this problem yet again on a new Centos 7 client connecting to Ubuntu 12.04 server. authorized_keys name@host issue wasn't fixing it. I matched up directories, perms, exact same id_rsa key file, but there was an extra id_rsa.pub (on client side). Removed, now it works. I had ran ssh-keygen to create directories quick, then rsync from known good system. But that left an extra pub file not matching any private key (it was not on source rsync). I re-added unmatched pub file to verify. Make sure matched or remove.
    – gregthegeek
    May 12, 2017 at 18:35
7

I had the same issue on RedHat; checked logs and found that home directory had incorrect user rights.

sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user

Fixing home dir rights solved this.

Improve this answer
2
  • 5
    Welcome to U+L Stack Exchange site. You could make your answer more helpful to others by providing an example of what correct permissions should look like.
    – Erathiel
    May 20, 2015 at 9:50
  • I had a very similar issue except with ~/.ssh dir. At least on Fedora 28 when ~/.ssh permissions were 0775, I could not connect with public/private keys. So I changed permissions to 0755 and worked like a charm :)
    – PovilasB
    Jun 30, 2018 at 18:11
6

The default file names ssh is looking for are id_rsa and id_rsa.pub.

If you want to use other file names, you either have to specify them in ssh_config (using the IdentityFile setting) or via the ssh command line parameter -i.

Improve this answer
0
6

A simple way to debug in Debian/Ubuntu is: Connect with password and tail the log

tail -f /var/log/auth.log

Try to connect from an other terminal and you will see the error...

In my case the /root directory was 770 and not 700 which is the default The error was "Authentication refused: bad ownership or modes for directory /root"

Fix this and you are done.

Improve this answer
2
  • thx you so much, man! you saved my day!
    – Anthony
    May 15, 2019 at 19:15
  • That helped clarify it. Mine was saying User suchandsuch from 123.123.123.123 not allowed because not listed in AllowUsers. Thank you so much!
    – ᴍᴇʜᴏᴠ
    Aug 22, 2019 at 17:41
2

Try

/sbin/restorecon -r /root/.ssh

A possible problem with selling context

Improve this answer
1
  • I'm on Ubuntu and there's no such binary.
    – Sridhar Sarnobat
    Apr 14, 2018 at 4:18
1

[ I was bitten by this vague error today, so I'm adding to the list of possible causes of the "we did not send a packet, disable method" debug2 message. ]

It may be the account you're logging in as (on the remote system) does not have read access to the public key file (on the remote system). For instance, in our environment we have a custom AuthorizedKeysFile location specified in /etc/ssh/sshd_config:

AuthorizedKeysFile /usr/local/etc/ssh_authorized_keys/%u_pub

And /usr/local/etc/ somehow had its permissions changed to:

drwx------. 3 root root 29 Feb 20  2018 /usr/local/etc/

Resolved by (re-) setting permissions to:

drwxr-xr-x. 3 root root 29 Feb 20  2018 /usr/local/etc/
Improve this answer
1

When I was struggling with this, my main problem was getting server-side logging/debugging to show. Of great help was the following (paraphrased) suggestion taken from Ciro Santilli 冠状病毒审查六四事件法轮功's answer to How to check sshd log? on ServerFault:

Start a new SSH Server instance on a new port in debug mode with:

/usr/sbin/sshd -d -p 2222

then connect to it from the client with:

ssh -p 2222 user@host

This gave all the information I needed to fix the problem (in my case, the ownership/permissions of the user's home directory).

Improve this answer
1

I've spent hours in this problem. At the end i went back to my / folder and i listed all of my server files ls -l and i realized that my root folder was assigned to another user and another group 1000:1000 so i just had to do chown -R root:root and right away it went back to work.

Improve this answer
1
  • This is very dangerous advice. This might be applicable to a chrooted system where each user has their own / folder (which is not the real / directory of the entire system, but actually something else). But if you successfully run chown -R root:root in the real root directory of a non-chrooted system, you would cause all the file ownership information in the server to be lost, which is likely to prevent the server from working. To recover, it might be easiest and fastest to restore the entire server from backups.
    – telcoM
    Nov 22, 2021 at 22:16
0

After running

ssh-copy-id user@remote-host

normally it should work. But if it fails, try this: login to the remote host as the user you want to login in future and run:

ssh-keygen

It helped me.

Improve this answer
0

So what happened for me is that I have 2 VMs to access from my local machine (2 keys id_rsa.pub and id_rsa2.pub). I realized that my ssh connection is using id_rsa.pub by default for any ssh [email protected] connection. I solved my issue by adding a config file and specify the identity to be used for every host like the following :

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2
Improve this answer
0

I had a really weird issue where I needed to specify the user with the option -l. Works:

ssh -i file.pem -l admin [email protected]

For what ever reason admin@ alone wasn't accepted.

Improve this answer
0

Found myself another typo

authorized_key

instead of

authorized_keys
Improve this answer
2
  • By default, ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2 are the only filenames that will work. You can set a different filename in opensshd with AuthorizedKeysFile. Instead of "I found another typo out" (out of the infinite possible number of typos) maybe something like: > Just a tip here... Make sure you have an S at the end of authorized_keyS... I just found myself struggling to get authentication to work and I found it's because I forgot the S at the end... Remember you can have many KEYS in the Authorized Keys file. > If it's still not working, you should double check t
    – erwin
    Nov 23, 2021 at 11:40
  • 1
    @erwin ok, thx for advice!
    – ndK
    Dec 3, 2021 at 14:36
-3

client:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart
Improve this answer

You must log in to answer this question.

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