Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
share|improve this question
    
please give us the output of ls -la /root/.ssh/ – mreithub May 25 '14 at 10:16
    
@mreithub Thanks for the quick reply - added above. – Danny May 25 '14 at 10:18
    
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 '14 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 '14 at 10:26
up vote 8 down vote accepted

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.

share|improve this answer
    
Thanks @michas - very helpful indeed, much appreciated. – Danny May 25 '14 at 13:28

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.

share|improve this answer
    
Thanks @mreithub - very helpful indeed. – Danny May 25 '14 at 13:27

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).
share|improve this answer

Try

/sbin/restorecon -r /root/.ssh

A possible problem with selling context

share|improve this answer

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.

share|improve this answer
2  
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 '15 at 9:50

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.