4

I just uploaded my public key to a server, ensured permissions are right, and when i try to log it simply refuses it.

after enabling loglevel DEBUG in sshd_config i get:

Nov 22 06:53:36 host-1 sshd[8612]: debug1: Forked child 8617.
Nov 22 06:53:36 host-1 sshd[8617]: Set /proc/self/oom_score_adj to 0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 22 06:53:36 host-1 sshd[8617]: debug1: inetd sockets after dupping: 3, 3
Nov 22 06:53:36 host-1 sshd[8617]: Connection from some_ip port 50466
Nov 22 06:53:36 host-1 sshd[8617]: debug1: HPN Disabled: 0, HPN Buffer Size: 87380
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Client protocol version 2.0; client software version OpenSSH_6.0p1 Debian-3
Nov 22 06:53:36 host-1 sshd[8617]: SSH: Server;Ltype: Version;Remote: some_ip-50466;Protocol: 2.0;Client: OpenSSH_6.0p1 Debian-3
Nov 22 06:53:36 host-1 sshd[8617]: debug1: match: OpenSSH_6.0p1 Debian-3 pat OpenSSH*
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Remote is NON-HPN aware
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Enabling compatibility mode for protocol 2.0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v10
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is loglevel
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is passwordauthentication
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is permitemptypasswords
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is usepam
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Config token is subsystem
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys
Nov 22 06:53:36 host-1 sshd[8617]: debug1: fd 4 clearing O_NONBLOCK
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Could not open authorized keys '/home/xxx/.ssh/authorized_keys2': No such file or directory
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: Failed publickey for xxx from some_ip port 50466 ssh2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys
Nov 22 06:53:36 host-1 sshd[8617]: debug1: fd 4 clearing O_NONBLOCK
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: debug1: temporarily_use_uid: 1000/1000 (e=0/0)
Nov 22 06:53:36 host-1 sshd[8617]: debug1: trying public key file /home/xxx/.ssh/authorized_keys2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: Could not open authorized keys '/home/xxx/.ssh/authorized_keys2': No such file or directory
Nov 22 06:53:36 host-1 sshd[8617]: debug1: restore_uid: 0/0
Nov 22 06:53:36 host-1 sshd[8617]: Failed publickey for xxx from some_ip port 50466 ssh2
Nov 22 06:53:36 host-1 sshd[8617]: debug1: do_cleanup

it keep trying authorized_keys2 (which i though were deprecated everywhere) but it does open authorized_keys at some time (the correct file with my keys) and then says absolutely nothing more about it and goes back to authorized_keys2

what's wrong here?

I do have in my sshd_config:

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

and there's no authorized_keys2 string in that file anywhere. And yes, sshd restarted before tests.

I guess i can just use authorized_keys2 but want to understand what's happening here. Any clues?


edit: ssh -v host

client$ ssh -v host
OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to host [someip] port 22.
debug1: Connection established.
debug1: identity file /home/xxx/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/xxx/.ssh/id_rsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/xxx/.ssh/id_dsa-cert type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa type -1
debug1: identity file /home/xxx/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v10
debug1: match: OpenSSH_5.8p1-hpn13v10 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA xx:xx...
debug1: Host 'host' is known and matches the ECDSA host key.
debug1: Found key in /home/xxx/.ssh/known_hosts:11
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/xxx/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: /home/xxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/xxx/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
xxx@host's password: 
gcb
  • 344
  • 1
  • 4
  • 18
  • 1
    Can you supply the output of `ssh -v xxx@host-1` too? authorized_keys2 is deprecated, but it's still checked in sshd (historical reasons), the checking will be removed sometime in the future. – ott-- Nov 22 '12 at 07:55
  • @ott-- added `ssh -v host` – gcb Nov 22 '12 at 08:24

3 Answers3

7

It looks like it's falling back to authorized_keys2 for compatibility reasons when it fails to find a valid authorized_keys file. Check that your authorized_keys file is correctly formed.

user9517
  • 115,471
  • 20
  • 215
  • 297
  • it has only one key. it's practically `cat id_rsa.pub > authorized_keys`... don't know what can go wrong. also, it checks for `authorized_keys2` twice, before caring about `authorized_keys` and then go right back to checking `authorized_keys2`. it's weird. – gcb Nov 22 '12 at 08:18
  • 1
    @gcb: Your log snippet only shows it checking authorised_keys the falling back to the deprecated versions. – user9517 Nov 22 '12 at 08:20
  • @lain you are correct... i will blame the lack of sleep. i read a 2 on the first log line that file was mentioned. Ok, so it's less weird now. Also, i recreate the keys and more carefully move pub to the server, nothing. any way i can parse that file? or make sshd log more verbose? – gcb Nov 22 '12 at 08:26
  • 1
    ok, i think it parses OK `ssh-keygen -l -f ~/.ssh/authorized_keys` does show the only key there as RSA – gcb Nov 22 '12 at 08:32
  • it was malformed. the above command was reporting a 5k instead a 2k RSA key size... somehow i managed to screw up a simple `cat >` *twice* – gcb Nov 22 '12 at 08:43
1

I had the exact same issue with the same message in the error log. However, it was due to a wrong username used when connecting to a server.

In other words, I was typing: ssh -i ~/.ssh/id_key myuser@IP_Address while the authorized_keys file was located in /root/.ssh folder. After changing the login command to ssh -i ~/.ssh/id_key root@IP_Address everything started working fine.

Kelvin
  • 173
  • 1
  • 1
  • 6
1

Can the user with uid=1000 access the .ssh/authorized_keys directory? What OS are you running? Some distributions with SELinux enabled can disallow sshd to read from .ssh/authorized_keys. You can restore that using: restorecon -R -V /home/xxx/.ssh/

Tim
  • 166
  • 2
  • standard gentoo from linode, no selinux as far as i can tell. permissions are ok. home dir, .ssh, and auth file are only readable by user xxx[uid=1000] – gcb Nov 22 '12 at 07:23