Prompt for password just once when setting up sftp/ssh

[Paul Maglinger]

Running HP-UX 11.31 on our end connecting to unknown sftp server on the other. They want key authentication so passwords are not necessary. We generated a new key and sent the public key to them to install. The username on the remote server is different than any account on our local server. To facilitate the connection we use a command string similar to: sftp -o IdentityFile=vendor_rsa username@files.theirserver.com When we do this we get prompted for a password - but only one time. All subsequent connects are made without a password prompt. Can I get confirmation that this is expected behavior, or once the public key is in place there should never be a prompt for authentication - not even once? If it is expected, could someone point me to supporting documentation? I'm told it should never prompt, but this is the way that it has always behaved. If there is a step that I'm missing that would prevent the "first-time prompt", please point me in the right direction. Thanks!

[Bill Hassell]

Not the expected behavior. Key negotiation should succeed for each connection and be independent for each sftp command.  I suspect an unusual setup on the far end. To troubleshoot, run sftp -v for debug level 1 (and more v's for debug 2,3) and look at the credential negotiation for the first connection and then the subsequent connections.

[Dennis Handly]

>-o IdentityFile=vendor_rsa username@files.theirserver.com

If sftp is like scp and if there is only one vendor_rsa and username on files.theirserver.com, you can put this info in ~/.ssh/config so you only need to type:

sftp files

[Paul Maglinger]

Thank Bill and Dennis for the replies.  Good to see you guys still hanging around.

I ran the command line with -vvv and got:

(server1:jsmith)[/home/jsmith] ssh -vvv -o IdentityFile=vendor_rsa mycompany_scp@files.theirserver.com

OpenSSH_5.9p1+sftpfilecontrol-v1.3-hpn13v12, OpenSSL 0.9.8y 5 Feb 2013

HP-UX Secure Shell-A.05.90.007, 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 files.theirserver.com [12.130.140.38] port 22.

debug1: Connection established.

debug1: identity file vendor_rsa type 1

debug1: identity file vendor_rsa-cert type -1

debug1: Remote protocol version 2.0, remote software version SSH

debug1: no match: SSH

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.9p1+sftpfilecontrol-v1.3-hpn13v12

debug2: fd 4 setting O_NONBLOCK

debug3: load_hostkeys: loading entries for host "files.theirserver.com" from file "/home/jsmith/.ssh/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/jsmith/.ssh/known_hosts:85

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

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: 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-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-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-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,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: REQUESTED ENC.NAME is 'aes128-ctr'

debug1: kex: server->client aes128-ctr hmac-md5 none

debug2: mac_setup: found hmac-md5

debug1: REQUESTED ENC.NAME is 'aes128-ctr'

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: 126/256

debug2: bits set: 502/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key: RSA ce:6f:c2:0e:18:f3:95:1b:11:8d:a5:8e:cc:d0:f5:b6

debug3: load_hostkeys: loading entries for host "files.theirserver.com" from file "/home/jsmith/.ssh/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/jsmith/.ssh/known_hosts:85

debug3: load_hostkeys: loaded 1 keys

debug3: load_hostkeys: loading entries for host "12.130.140.38" from file "/home/jsmith/.ssh/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/jsmith/.ssh/known_hosts:86

debug3: load_hostkeys: loaded 1 keys

debug1: Host 'files.theirserver.com' is known and matches the RSA host key.

debug1: Found key in /home/jsmith/.ssh/known_hosts:85

debug2: bits set: 530/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: vendor_rsa (600000000001bbc0)

debug1: Authentications that can continue: publickey,password

debug3: start over, passed a different list publickey,password

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: vendor_rsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: pkalg ssh-rsa blen 279

debug2: input_userauth_pk_ok: fp a5:99:f1:5e:15:02:07:75:56:99:60:3f:11:3e:42:6a

debug3: sign_and_send_pubkey: RSA a5:99:f1:5e:15:02:07:75:56:99:60:3f:11:3e:42:6a

debug3: no such identity: vendor_rsa

debug2: we did not send a packet, disable method

debug3: authmethod_lookup password

debug3: remaining preferred: ,password

debug3: authmethod_is_enabled password

debug1: Next authentication method: password

mycompany_scp@files.theirserver.com's password:

debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)

debug2: we sent a password packet, wait for reply

debug1: Authentications that can continue: publickey,password

Permission denied, please try again.

mycompany_scp@files.theirserver.com's password:

debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)

debug2: we sent a password packet, wait for reply

debug1: Authentications that can continue: publickey,password

Permission denied, please try again.

mycompany_scp@files.theirserver.com's password:

debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64)

debug2: we sent a password packet, wait for reply

debug1: Authentications that can continue: publickey,password

debug2: we did not send a packet, disable method

debug1: No more authentication methods to try.

Permission denied (publickey,password).

(server1:jsmith)[/home/jsmith]

I sent the results to the owners of the remote server and was told they don't support OpenSSH.  Seems kind of odd to me that they wouldn't.   They are recommending I use something else besides the HPUX servers - possibly Windows with WinSCP or the like.

[Dennis Handly]

debug1: Offering RSA public key: vendor_rsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: pkalg ssh-rsa blen 279

debug2: input_userauth_pk_ok: fp a5:99:f1:5e:15:02:07:75:56:99:60:3f:11:3e:42:6a

debug3: sign_and_send_pubkey: RSA a5:99:f1:5e:15:02:07:75:56:99:60:3f:11:3e:42:6a

debug3: no such identity: vendor_rsa

debug2: we did not send a packet, disable method

It seems vendor_rsa doesn't exist on the other side?

[Paul Maglinger]

So they didn't install the public key I sent?

[Bill Hassell · Accepted solution]

>> they don't support OpenSSH.

Looks like an ssh daemon/server is running on their end. Maybe what they mean is that they know nothing but PC stuff. But the real question still remains: did they add the public key to their authorized_keys respository? If not, then it is irrelevant whether you use WinSCP or any other Windows program. The trace clearly shows that they don't have your public key yet.

[Dennis Handly]

>did they add the public key to their authorized_keys respository?

I suppose one quick check is to talk to HP-UX and leave the key out and see if you get similar messages?

> they don't support OpenSSH.

Did they mean they don't support that type of public key format and they need to convert it?

[Paul Maglinger]

When I tried using psftp from a Windows box using the same private key I generated on HPUX it actually returned a message saying that it would accept an OpenSSH key.  I didn't get that kind of feed back on the HPUX box.

[Bill Hassell]

Aren't standards wonderful?

There are so many to choose from...

However, ssh-keygen should resolve the issue.

From the man page, look at the -e option to read your local key and then -m to change the key to match the target:

      -m key_format
           Specify a key format for the -i (import) or -e (export)
           conversion options.  The supported key formats are: ``RFC4716''
           (RFC 4716/SSH2 public or private key), ``PKCS8'' (PEM PKCS8
           public key) or ``PEM'' (PEM public key).  The default conversion
           format is ``RFC4716''.

 Now if the destination folks can figure out what kind of key they understand...