SOLVED: SSH and Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

OpenSSHI ran across the error “Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).” while ssh’ing to another server today:

$ ssh myhost
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Usually this means that the permissions of ~/.ssh, ~/.ssh/authorized_keys or your home directory on the other box isn’t setup right The permissions should look like so:

  1. -rwx——. /home/jason
  2. -rwx——. /home/jason/.ssh
  3. -rw——-. /home/jason/.authorized_keys

You would fix with:

$ chmod 0700 ~
$ chmod 0700 ~/.ssh
$ chmod 0600 ~/.ssh/authorized_keys

In my case, the permissions were correct. I ran the ssh command with extra verbose (-v -v)

$ ssh -v -v myhost
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/jason/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: /etc/ssh/ssh_config line 62: Deprecated option "RhostsAuthentication"
debug2: ssh_connect: needpriv 0
debug1: Connecting to myhost [192.168.12.6] port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/jason/.ssh/id_rsa type 1
debug1: identity file /home/jason/.ssh/id_rsa-cert type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/jason/.ssh/id_dsa type 2
debug1: identity file /home/jason/.ssh/id_dsa-cert type -1
debug1: identity file /home/jason/.ssh/id_ecdsa type -1
debug1: identity file /home/jason/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0
debug1: match: OpenSSH_6.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,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,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
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-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr 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: 154/256
debug2: bits set: 520/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Warning: Permanently added 'myhost,192.168.1.66' (RSA) to the list of known hosts.
debug2: bits set: 525/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/jason/.ssh/id_rsa (0x7ff594d8ecb0)
debug2: key: /home/jason/.ssh/id_dsa (0x7ff594d90550)
debug2: key: /home/jason/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).

I didn’t see a reason why I wasn’t getting a password prompt but I do see it reading my ssh_config file. A real quick override of the ssh_config showed me that my ssh_config was the culprit:

$ ssh -F /dev/null myhost
jason@myhost's password:

So what is in my ~/.ssh/config file?

ServerAliveInterval 240
BatchMode yes
TCPKeepAlive = yes

Neither ServerAliveInterval or TCPKeepAlive have anything to do with authentication but BatchMode does. From the ssh_config man page:

BatchMode

The argument must be yes or no. If set to yes, passphrase/password querying will be disabled. This option is useful in scripts and other batch jobs where you have no user to supply the password.

So, if my public ssh key is not in the ~/.ssh/authorized_keys, the connection will fail with a permission denied. Let’s verify but removing BatchMode from the ~/.ssh/config file:

ServerAliveInterval 240
TCPKeepAlive = yes
$ ssh -F /dev/null myhost
___$

Success 🙂

Share Button

Getting “Xlib: PuTTY X11 proxy: wrong authentication protocol attempted”? I have the answer :)

Here’s the scenario:

You ssh to a remote server with your login and either sudo or su to another user to run some application that uses a X Windows front end.  There is a firewall between your desktop and the remote server that allows only ssh connections (port 22).  When you run into the error “Xlib: PuTTY X11 proxy: wrong authentication protocol attempted”.  What to do?

ssh jason@remote-server -X
jason $ echo $DISPLAY
localhost:10.0
jason $ su - oracle
oracle's Password:
oracle $ xterm
Xlib: connection to "localhost:10.0" refused by server
Xlib: PuTTY X11 proxy: wrong authentication protocol attempted
xterm Xt error: Can't open display: localhost:10.0

On recent OpenSSH Server releases, you can simply enable “ForwardX11Trusted yes” in the /etc/ssh/sshd_config file and restart the OpenSSH server.  If you’re not using a recent OpenSSH Server release or if you can’t for security or political reasons, what could you do? Give up? It’s simpler than you think.

You need to temporarily transfer the authorization to the other account. First, get the key from your account:

jason $ xauth list
aspc2o1/unix:10 MIT-MAGIC-COOKIE-1 bc334c66cfec3c5c3d5b0efc4ee9d3ad

Next, sudo/su to the other account and add the authorization key.

jason $ su - oracle
oracle $ xauth add aspc2o1/unix:10 MIT-MAGIC-COOKIE-1 bc334c66cfec3c5c3d5b0efc4ee9d3ad

Now, you should be able to start any X Windows application, assuming that your DISPLAY variable is set to go through the ssh tunnel:

oracle $ xterm

UPDATE:

Kyle McBride provided an easy way to automate adding the key to xauth. Add the following to your .bashrc or .profile file.

xauth list | while read x ; do sudo -u oracle xauth add $x ; done

The -u oracle will run the xauth command as the user oracle otherwise the keys will be added to the root user.

Share Button