windows - ssh can't use key, but password works

06
2013-08
  • user49884

    I have an Ubuntu server running for my SCM, and am doing my development on a windows computer. This setup has worked for a long time with out any problems. But now I get a strange problem.

    The problem started when I needed to change the access rights on a git repository on the server (don't tell me it was stupid to chmod the entire home directory... I already know). After that, every time I try to access the server via ssh (git inclusive) using my public key. I get the following error:

    $ ssh [email protected]
open log failed: Permission denied
Connection to 192.168.0.240 closed.

    However, when I try to connect to the server, using only password, everything works as expected:

    I have tried running the sshcommand with -vvv. It does not give me any idea where to look for the problem. Maybe you can see something from it.

    ...
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel 0: rcvd ext data 35
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: obuf_empty delayed efd 6/(35)
open log failed: Permission denied
debug2: channel 0: written 35 to efd 6
debug3: channel 0: will not send data after close
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

    Any ideas?

    • Answers
  • terdon

    Your problem is probably that the permissions of your user key are wrong. Try this on the Ubuntu server:

    chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa ~/.ssh/authorized_keys
chmod 644 ~/.ssh/id_rsa.pub
  • mpy

    In addition to terdons's answer, some weired behavior with ssh keys also occurs, if ~ is writeable by others.

    Assume, you have successfully set up ssh to use key login:

    user@local:~> ssh remote
Last login: Thu Mar  7 17:39:18 2013 from local
user@remote:~>

    Now make your home writable by some other user on the remote machine:

    user@remote:~> getfacl .
# file: .
# owner: user
# group: users
user::rwx
group::r-x
other::r-x
user@remote:~> setfacl -m u:coauthor:rwx .
user@remote:~> exit
user@local:~>

    Ok, now try again to log into remote:

    user@local:~> ssh remote
user@remote's password:

    ssh prompts for password now! Remove the ACL, and voilà ssh key is working again.

    [ My workaround was then to use a subdirectory for collaboration.]

    Craig Sanders knows the reason, this behavior depends on StrictModes yes in sshd_config. Quoting man 5 sshd_config:

    StrictModes Specifies whether sshd(8) should check file modes and ownership of the user's files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is “yes”.


    • Related Question

    SSH onto Ubuntu box using RSA keys
  • jex

    I recently installed OpenSSH on one of my Ubuntu machines and I've been running into problems getting it to use RSA keys.

    I've generated the RSA key on the client (ssh-keygen), and appended the public key generated to both the /home/jex/.ssh/authorized_keys and /etc/ssh/authorized_keys files on the server.

    However, when I try to login (ssh -o PreferredAuthorizations=publickey jex@host -v [which forces the use of public key for login]) I get the following output:

    jex@Po:~$ sshpc -vvv -o PreferredAuthentications=publickey
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.102 [192.168.0.102] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /home/jex/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/jex/.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: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-6ubuntu2
debug1: match: OpenSSH_5.1p1 Debian-6ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 525/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/jex/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '192.168.0.102' is known and matches the RSA host key.
debug1: Found key in /home/jex/.ssh/known_hosts:1
debug2: bits set: 490/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/jex/.ssh/id_rsa (0x20942c30)
debug3: input_userauth_banner
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred: 
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/jex/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).
jex@Po:~$

    I'm not entirely sure where I've gone wrong. I am willing to post my /etc/ssh/sshd_config if needed.


    • Related Answers
  • sybreon

    Try doing both of these:

    1. Only put the public key in /home/jex/.ssh/authorized_keys file. This is to help isolate the problem and make sure that it is not confused about multiple keys.
    2. Make sure that both the file and /home/jex/.ssh directories are readable by the user. I sometimes make errors on #2 because I was running as root when I created the .ssh/authorized_keys file.
  • Grumbel

    Are you sure the content of authorized_keys is correct? Maybe something went wrong when creating the file. To fix that try removing the file and then use:

    ssh-copy-id jex@host

    That will create the authorized_keys file automatically for you.

  • RainDoctor

    Check the permissions of authorized_keys file on the target.

    $chmod 700 ~/.ssh;chmod 700 ~/.ssh/authorized_keys