When trying to ssh -v 'somehost'

Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kaldown/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/kaldown/.ssh/id_dsa
debug1: Trying private key: /home/kaldown/.ssh/id_ecdsa
debug1: Trying private key: /home/kaldown/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

And why he telling that it's type 1 instead of type 2

debug1: identity file /home/kaldown/.ssh/id_rsa type 1
debug1: identity file /home/kaldown/.ssh/id_rsa-cert type -1
debug1: identity file /home/kaldown/.ssh/id_dsa type -1
debug1: identity file /home/kaldown/.ssh/id_dsa-cert type -1
debug1: identity file /home/kaldown/.ssh/id_ecdsa type -1
debug1: identity file /home/kaldown/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/kaldown/.ssh/id_ed25519 type -1
debug1: identity file /home/kaldown/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420

in sshd_config:

PermitRootLogin no
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication no
UsePAM yes
UsePrivilegeSeparation sandbox

P.S. I'm using FreeBSD 10.1 which have a problems with ssh-copy-id, telling strange

Unmatched '

So I just scp my public key in .ssh/authorized_keys of exact user

1) Why it uses .ssh/id_rsa instead of .ssh/id_rsa.pub as a public key?

2) Why it's telling me that type 1, when I created this with ssh -t rsa (rsa2) key

3) Why I can't connect with keys, but password only with that config.

Server-side: CentOS 7, 3.10

Thank you.


Your id_rsa file contains information about both your private and public key. It is only offering the public part of the key.

I believe that type 1 or type 2 designates whether it is an RSA or DSA key.


sshd_config is for the server so that's where you are saying look in this file for the public key to make sure it matches a private key your client is sending.

Public keys on server go in ~/.ssh/authorized_keys

Then the client sends its private key in ~/.ssh/id_rsa and the server matches them up and allows you in

The client side is setup here

[root@chef01-east.domain.com /etc/ssh]# grep IdentityFile /etc/ssh/ssh_config
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa

The comments also mean they are defaults for the client.

If you want to send a different key you can always do

ssh -i /path/to/key/file user@host.com
  • 1) ~/.ssh/authorized_keys on server => ~/.ssh/authorized_keys of account which I trying to authenticate? So I copied my id_rsa.pub to that direction. 2) I tried to send both: id_rsa and id_rsa.pub by specifying ssh -i option. Still can't login by keys, but after commenting '#PasswordAuthentication no' I can reach server with password-only. Sorry, may be I didn't understand what you trying to tell me either. – kAldown Dec 9 '14 at 14:31
  • But thank's for make it clear with understanding that client should sent exact private key to server for matching. – kAldown Dec 9 '14 at 14:35
  • if everything is setup right it's usually permissions on the server side ~/.ssh needs to be owned by the user and 700 and authorized_keys needs to be 600 – Mike Dec 9 '14 at 14:59
  • Yes it is: <code>ls -la .ssh/ total 4 drwx------. 2 forcookies wheel 28 Dec 9 18:03 . drwx------. 3 forcookies wheel 60 Dec 9 04:51 .. -rw-------. 1 forcookies wheel 381 Dec 9 18:03 authorized_keys </code> – kAldown Dec 9 '14 at 15:19
  • =| No, no, no. Its never ever okay for anything in a PKI system to send a private key unless both parties own it and are extremely confident in the privacy of the channel they use. Private means always private. What the SSH client would be sending is the public key related to the private key. The public key is then used by the server to encrypt things that can only be decrypted by the corresponding private key. The client would already have the server's public key so it could encrypt stuff to send to the server as well. – jeteon Feb 1 '16 at 12:02
restorecon -r -vv /home/user/.ssh

Will fix problem.

Found here

  • Ubuntu does not have restorecon installed – briankip Nov 24 '17 at 9:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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