SFTP certificates not being recognised

0

We currently access a third party's axway sftp server manually via a web ui and would like to set up a passwordless login to allow automatic downloads.

I have made sure the authorized_keys file is located in the correct path, that it has the correct permissions and in the right format. There is now three keys in the file; one for rsa, dsa and ecdsa. None seem to work.

We only have sftp access; no ssh.

As the third party is a multinational bluechip company with slow turn around time for technical queries I would like to be able to make an accurate request in the first instance.

Here is the output of -vvv:

kevin@ubuntu:~/.ssh$ sftp -vvv <SERVER NAME CHANGED TO PROTECT THE INNOCENT>
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: /etc/ssh/ssh_config line 55: Applying options for <SERVER NAME CHANGED TO PROTECT THE INNOCENT>
debug2: ssh_connect: needpriv 0
debug1: Connecting to <SERVER NAME CHANGED TO PROTECT THE INNOCENT> [nnn.nnn.nnn.nnn] port 2222.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/kevin/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/kevin/.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/kevin/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/kevin/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /home/kevin/.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/kevin/.ssh/id_dsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/kevin/.ssh/id_ecdsa" as a RSA1 public key
debug1: identity file /home/kevin/.ssh/id_ecdsa type 3
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256
debug1: identity file /home/kevin/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version SSHD
debug1: no match: SSHD
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [<SERVER NAME CHANGED TO PROTECT THE INNOCENT>]:2222
debug3: load_hostkeys: loading entries for host "[<SERVER NAME CHANGED TO PROTECT THE INNOCENT>]:2222" from file "/home/kevin/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/kevin/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
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-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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-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,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: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,blowfish-cbc,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc,blowfish-cbc,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96,hmac-sha256,hmac-sha256@ssh.com
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-sha1-96,hmac-md5-96,hmac-sha256,hmac-sha256@ssh.com
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
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: 129/256
debug2: bits set: 513/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn
debug3: put_host_port: [nnn.nnn.nnn.nnn]:2222
debug3: put_host_port: [<SERVER NAME CHANGED TO PROTECT THE INNOCENT>]:2222
debug3: load_hostkeys: loading entries for host "[<SERVER NAME CHANGED TO PROTECT THE INNOCENT>]:2222" from file "/home/kevin/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/kevin/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "[nnn.nnn.nnn.nnn]:2222" from file "/home/kevin/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/kevin/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host '[<SERVER NAME CHANGED TO PROTECT THE INNOCENT>]:2222' is known and matches the RSA host key.
debug1: Found key in /home/kevin/.ssh/known_hosts:1
debug2: bits set: 524/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: 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/kevin/.ssh/id_dsa (0x7f221aa9f240)
debug2: key: /home/kevin/.ssh/id_rsa (0x7f221aa9f200)
debug2: key: /home/kevin/.ssh/id_ecdsa (0x7f221aaa09d0)
debug1: Authentications that can continue: password,publickey,keyboard-interactive
debug3: start over, passed a different list password,publickey,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,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 DSA public key: /home/kevin/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: password,publickey,keyboard-interactive
debug1: Offering RSA public key: /home/kevin/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: password,publickey,keyboard-interactive
debug1: Offering ECDSA public key: /home/kevin/.ssh/id_ecdsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: password,publickey,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
Password Authentication
debug2: input_userauth_info_req: num_prompts 1
Password: 

The authorized_key file contains:

ssh-dss AAAAB3NzaC1kc3MAAACBA ... SQx9wCtDG8R3== kevin@ubuntu
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN ... pbrwdxE= kevin@ubuntu
ssh-rsa AAAAB3NzaC1 ... E5siYjCX3/b8qNjuGzPQoBRX kevin@ubuntu

(I ended up with three keys as the debug output showed that sftp was attempting all three types)

This shows the access rights of the files on the remote server:

sftp> ls -la
drwxr-x---   1 1000025  1000025      4096 Dec 08 21:50 .
drwxr-x---   1 1000025  1000025      4096 Dec 08 21:50 ..
drw-------   1 1000025  1000025      4096 Dec 08 02:03 .ssh
[snip]
sftp> cd .ssh
sftp> ls -la
drw-------   1 1000025  1000025      4096 Dec 08 02:03 .
drw-------   1 1000025  1000025      4096 Dec 08 02:03 ..
-r--------   1 1000025  1000025      1170 Dec 08 02:03 authorized_keys

My suspicions are that:

  • they have disabled passwordless access in which case is the above the expected output?
  • I'm not using the right username in the authorized_keys file
  • Some thing else altogether

Really appreciate some help in this matter as it has already chewed up an annoying amount of time.

Kevin Pluck

Posted 2013-12-08T22:16:46.100

Reputation: 101

Gone with using an Expect script, seems the third party have disabled all things useful and forced us to hack this script with plain-text password. – Kevin Pluck – 2013-12-09T11:56:44.260

Answers

0

The authorized_key file is not relevant, because it contains the public keys that allow logging onto your pc. You should instead offer the remote system the private key of the public/private pair that was generates to allow you to connect to the remote system.

In other words, you should issue the command:

   ssh me@remote_server -p 2222 -i .ssh/private_key_for_the_remote_server

MariusMatutiae

Posted 2013-12-08T22:16:46.100

Reputation: 41 321

Sorry, no cigar:

kevin@ubuntu:~/.ssh$ sftp -i id_dsa  foo.bar.com  
Password Authentication  
Password:   
kevin@ubuntu:~/.ssh$ sftp -i id_rsa  foo.bar.com  
Password Authentication  
Password:  
kevin@ubuntu:~/.ssh$ sftp -i id_ecdsa  foo.bar.com  
Password Authentication  
Password:  
kevin@ubuntu:~/.ssh$
 – Kevin Pluck  – 2013-12-08T23:05:38.113

Erm, formatting fail... – Kevin Pluck – 2013-12-08T23:06:26.787

@KevinPluck Those do not appear to be valid private keys. Does the file that contain them begin with -----BEGIN DSA PRIVATE KEY----- or some such thing? If not, they are not private keys. – MariusMatutiae – 2013-12-08T23:17:14.797

They look good to me:

kevin@ubuntu:~/.ssh$ cat id_rsa id_dsa id_ecdsa
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA6V0ZMu630vapgEpMLOziHB79X6mJwXcHthMr6E8B61BRkq+x
[snip]
-----END RSA PRIVATE KEY-----
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQCJ6H75joDH31bPKdAT+KlCQl8YGD+0+jY8I97JzwLeHl/pXuq/
[snip]
WsGb/DeIcOGw1B2eq00=
-----END DSA PRIVATE KEY-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIGxbtwj1JAQ0c6dqKidWI3TjAP37gqRDU9AUn7T8kmZDoAoGCCqGSM49
[snip]
-----END EC PRIVATE KEY-----
 – Kevin Pluck  – 2013-12-09T08:54:00.690