OpenSSH_6.2p2 on HP-UX B.11.31 ia64, sftp and ssh keys

1

We are running OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12 on a Unix server (HP-UX, B.11.31, ia64 architecture).

A client fails that tries to log on to our server using sftp and ssh keys (trying to log in as username2).

Our setup in home directory of username2:

drwx------   2 username2     groupname2        8192 Jan 22 15:24 .ssh
.ssh:
-rw-r--r--   1 username2     groupname2         512 Jan 22 12:58 authorized_keys
-rw-r--r--   1 username2     groupname2         442 Dec 10 19:29 known_hosts
-rw-r--r--   1 username2     groupname2         739 Dec 10 19:21 id_rsa.pub
-rw-------   1 username2     groupname2        3243 Dec 10 18:59 id_rsa

Our sshd_config looks like this ( here comments are stripped for the clarity of my question ):

Protocol 2,1
AddressFamily inet
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
KerberosAuthentication no
UsePAM no
X11Forwarding yes
Subsystem       sftp    /opt/ssh/libexec/sftp-server
Match Group groupname1
  # Force the connection to use SFTP and chroot to the required directory.
  ForceCommand internal-sftp
  ChrootDirectory directorypath # Home of username1
  # Disable tunneling, authentication agent, TCP and X11 forwarding.
  PermitTunnel no
  AllowAgentForwarding no
  AllowTcpForwarding no
  X11Forwarding no
Match Group groupname2
  # Force the connection to use SFTP and chroot to the required directory.
  ForceCommand internal-sftp
  ChrootDirectory directorypath # Home of username2
  # Disable tunneling, authentication agent, TCP and X11 forwarding.
  PermitTunnel no
  AllowAgentForwarding no
  AllowTcpForwarding no
  X11Forwarding no

This is what we got in our ( server side ) /var/adm/syslog/syslog.log:

Jan 21 15:18:41 host sshd[14582]: Connection from ip-address port portnumber
Jan 21 15:18:41 host sshd[14582]: SSH: Server;Ltype: Version;Remote: ip-address-portnumber;Protocol: 2.0;Client: J2SSH_Maverick_1.4.44__SEEBURGER_AG
Jan 21 15:18:41 host sshd[14582]: SSH: Server;Ltype: Kex;Remote: ip-address-portnumber;Enc: aes128-cbc;MAC: hmac-sha1;Comp: none [preauth]
Jan 21 15:18:44 host sshd[14582]: SSH: Server;Ltype: Authname;Remote: ip-address-portnumber;Name: username2 [preauth]
Jan 21 15:18:44 host sshd[14582]: Failed publickey for username2 from ip-address port portnumber ssh2
Jan 21 15:18:44 host sshd[14582]: Received disconnect from ip-address: 11: The user disconnected the application [preauth]

We can observe that the authorized_keys file is being accessed or read, but the client still cannot log in.

The message "Failed publickey" is a little confusing because we have tried with a couple of the clients public keys ( in the authorized_keys file ).

We then changed/chmod:ed authorized_keys to:

-rw-------   1 username2     groupname2         512 Jan 22 12:58 authorized_keys

And added this to sshd_config:

RSAAuthentication yes

But the client still cannot log in. The client is external and connects to us through proxy/dmz.

Output from "sftp -vvv host" ( on our local network ):

OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12, OpenSSL 1.0.1j 15 Oct 2014
HP-UX Secure Shell-A.06.20.030, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: RNG is ready, skipping seeding
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [ip-address] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "home_directory/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home_directory/.ssh/id_rsa type 1
debug1: identity file /home_directory/.ssh/id_rsa-cert type -1
debug1: identity file /home_directory/.ssh/id_dsa type -1
debug1: identity file /home_directory/.ssh/id_dsa-cert type -1
debug1: identity file /home_directory/.ssh/id_ecdsa type -1
debug1: identity file /home_directory/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12
debug1: Remote protocol version 1.99, remote software version OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12
debug1: match: OpenSSH_6.2p2+sftpfilecontrol-v1.3-hpn13v12 pat OpenSSH*
debug2: fd 4 setting O_NONBLOCK
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,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-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@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-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@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-gcm@openssh.com,aes256-gcm@openssh.com,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-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@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-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@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
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-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA d9:55:55:e7:58:da:aa:1f:c8:71:51:c2:c3:b4:08:3d
The authenticity of host 'host (ip-address)' can't be established.
ECDSA key fingerprint is d9:55:55:e7:58:da:aa:1f:c8:71:51:c2:c3:b4:08:3d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'host,ip-address' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: home_directory/.ssh/id_rsa (60000000000644b0),
debug2: key: home_directory/.ssh/id_dsa (0),
debug2: key: home_directory/.ssh/id_ecdsa (0),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: home_directory/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug2: input_userauth_pk_ok: fp 44:9a:6b:22:3e:7f:92:5b:fd:66:0a:5b:fe:61:55:dd
debug3: sign_and_send_pubkey: RSA 44:9a:6b:22:3e:7f:92:5b:fd:66:0a:5b:fe:61:55:dd
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to host ([ip-address]:22).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 1, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t3 r-1 i0/0 o0/0 fd 5/6 cc -1)

debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Connection to host closed by remote host.
Transferred: sent 3908, received 2544 bytes, in 0.0 seconds
Bytes per second: sent 2126260.2, received 1384136.6
debug1: Exit status -1
Connection closed

Anders

Posted 2016-01-27T17:55:39.730

Reputation: 11

post the verbose log from client (sftp -vvv host). Do you have correct permissions for chroot directory according to manual pages? – Jakuje – 2016-01-27T18:23:32.277

The chroot directory ( and home directory ) is drwxr-xr-x username2 groupname2 which should be OK I think. About the verbose log I have to redirect that question to the client which may take a while before I have the log. Anders – Anders – 2016-01-27T18:35:36.187

No, it is not. Check the manual page for sshd_config, option ChrootDirectory. This is what manual is for. You can create the log even from local machine if you have some private key (or obviously you can create one if you have access to that machine).

– Jakuje – 2016-01-27T18:37:38.563

Yes, I can create a log from local machine but that would not be the same route as our client takes. The manual says "For file transfer sessions using “sftp”, no additional configuration of the environment is necessary if the in-process sftp server is used, /..../". – Anders – 2016-01-27T19:02:43.480

It does not matter. Problem is not on the route, but with authentication, isn't it? – Jakuje – 2016-01-27T19:04:46.340

The manual says "For file transfer sessions using “sftp”, no additional configuration of the environment is necessary if the in-process sftp server is used, /..../". I can create a log tomorrow if the client hasn't sent one to me by then ( emailed him about it ). Its quite late here in Sweden and I have to leave work now. To be continued, I hope. – Anders – 2016-01-27T19:10:09.000

No, the important part was: At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group. – Jakuje – 2016-01-27T19:11:34.007

Output from "sftp -vvv host" ( on our local network ) added to my post. – Anders – 2016-01-28T11:49:41.933

In this log, I see Authenticated to host so it is different then the original report. Though it fails later, probably because of the wrong permissions on chroot directory. Did you check my previous comment? – Jakuje – 2016-01-28T12:58:26.373

The difference is that I ( not the external client and using another key ) ran "sftp -vvv host" on our local network. Yes, I checked it. The document that I initially read when I set up restricted sftp is not specific on that point. The manual that I read yesterday, however, is specific regarding permissions on chroot directory. Thanks. – Anders – 2016-01-28T13:59:25.540

No answers