HP public authentication -- sftp

[Lo Kam Chi]

I want to sftp by batch from HP-UX to a Window server. After generating the key pair---id_rsa and id_rsa.pub, they are placed in $HOME/.ssh2 folder. I have copy the content of id_rsa.pub into authorized_keys. But when I issue the command I get the following error:

$ sftp -vvvb /usr/BL/bin/testSFTP.script BLBL@10.100.31.14
OpenSSH_5.1p1+sftpfilecontrol-v1.2-hpn13v5, OpenSSL 0.9.7m 23 Feb 2007
HP-UX Secure Shell-A.05.10.008, HP-UX Secure Shell version
debug1: Reading configuration data /home/ibp/.ssh/config
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: RNG is ready, skipping seeding
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.100.31.14 [10.100.31.14] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /home/ibp/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
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/ibp/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /home/ibp/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
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
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/ibp/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version 3.2.3 F-Secure SSH Windows NT Server
debug1: no match: 3.2.3 F-Secure SSH Windows NT Server
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1+sftpfilecontrol-v1.2-hpn13v5
debug2: fd 4 setting O_NONBLOCK
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
debug3: Received SSH2_MSG_IGNORE
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 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,rijndael-cbc@lysator.liu.se,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,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
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,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-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,cast128-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,cast128-cbc,blowfish-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5
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: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 116/256
debug2: bits set: 529/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: Received SSH2_MSG_IGNORE
debug3: check_host_in_hostfile: filename /home/ibp/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '10.100.31.14' is known and matches the DSA host key.
debug1: Found key in /home/ibp/.ssh/known_hosts:1
debug2: bits set: 488/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Received SSH2_MSG_IGNORE
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Received SSH2_MSG_IGNORE
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/ibp/.ssh/id_rsa (40041c10)
debug2: key: /home/ibp/.ssh/id_dsa (40041b80)
debug3: Received SSH2_MSG_IGNORE
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
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/ibp/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Received SSH2_MSG_IGNORE
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/ibp/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Received SSH2_MSG_IGNORE
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).
Connection closed

What's wrong?? Please help.

[Matti_Kurkela · Accepted solution]

The Windows-based SSH server is rejecting your public keys. To find out why, you should check the logs of the Windows server.

NOTE: The version of the remote server is "3.2.3 F-Secure SSH Windows NT Server". F-Secure SSH is the product that later became "ssh.com SSH". It uses a different public key file format. Fortunately the conversion is rather simple.

You should convert your public key on the HP-UX with a command like this:

ssh-keygen -e -f $HOME/.ssh/id_rsa.pub > $HOME/.ssh/id_rsa.converted.pub

The list of authorized keys should be arranged differently in the Windows side too.

On the Windows host, you should copy your public key to e.g. $HOME/.ssh2/id_rsa.converted.pub, then write a file named "$HOME/.ssh2/authorization". It will be a list of authorized key file names. In your case the file should contain just one line like this:

Key id_rsa.converted.pub

MK

[Steven E. Protter]

Shalom,

Check out these two documents:
Set up ssh to only permit public key authentication.
http://www.hpux.ws/?p=19

Public key authentication
http://www.hpux.ws/?p=10

SEP

[Steven Schweda]

> The Windows-based SSH server is rejecting
> your public keys.

It looks to me as if the HP-UX-based SSH
client emits many complaints about the key
files it tries to use, long before any key
data get sent to the server.

> After generating the key pair [...]

Did you make the keys on the HP-UX system, or
on the Windows system?

> You should convert your public key [...]

Perhaps. It depends on how they were made.

[Tingli]

Make sure the ownership of file authorized_keys should be BLBL.

[Lo Kam Chi]

I don't know whether the ownership of the authorization is BLBL. Because I can only see 10 when typing ls -al in sftp. The window adminstrator say they can't show the ownership in window platform.

Acutually, I type 'ssh-keygen -t rsa' with no passphrase. then pass the file to window adm to place under $HOME/.ssh2/id_rsa.pub (server side). Is it need to change the name to authorization?
I already uncommend Pubkeyauthoriization yes. But I don't know why it don't works?

[Rita C Workman]

Hi Lo_Kam,

Just went through this and found a couple things that affected my HPUX-2-Windows SFT process.

1. To transfer the keys, didn't matter if Windows side made them or HPUX side made them, they were sent via email. Believe they corrupted due to fact that email defaults to ascii send.

To fix for my shop so we could automate future transfers:

1. Removed all existing keys - so did Windows side.
2. I (HPUX side) recreated keys:
ssh-keygen -t rsa (NO passphrase !)
You can use dsa, your choice.
3. Windows side set account to accept password only.
4. I sftp to their Windows server, with account password, dropped the id_rsa.pub file ONLY to the account.
Signed off....
5. Windows side then reset the account to be key-certificate authentication ONLY.
6. Reran sftp to Windows box, and connection worked fine. Dropped a couple testfiles.
Signed off....
7. Windows folks confirmed testfiles.

So we can now do a script (with no passwords included) to automate the process.

Hope this helps you, but it will depend largely on what their Windows box is running.

Regards,
Rita

[Tingli]

In Window, go to Command Prompt and type in:

dir /q

shows the owner of the file.

[Lo Kam Chi]

Rita C Workman ,

I want to know how to reset the window to key authentication only. I am not windown adm so I don't know. Thank you.

[Rita C Workman]

Lo Kam,

I am not the Windows Admin either - the Windows person there did that.

Please note I mentioned that results will depend on what is being run. In my case, the software Windows was using (GlobalScape) will read OpenSSH commands. Some vendors software does not, or it takes the open source code and re-wraps the commands to make them proprietary and won't run the OpenSSH commands. I was fortunate that was not the case here.

They had to clean up the keys on Windows. I had no access to their system for this, other than to ftp the file and get out.
And they had to set their software to accept the key only for authentication.

Sorry....you will have to work it out with the Windows side folks you are dealing with.

Regards,
Rita