SFTP from iSeries to iSeries
Last Post 10 Feb 2012 12:01 PM by mygoodname. 14 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
mygoodname
New Member
New Member
Posts:75

--
06 Feb 2012 01:20 PM

Set up SSH on one system and am able to access it and perform SFTP requests from my PC using PuTTY.

Set up SSH on second systems and can also SFTP from my PC.

Cannot seem to make it work from one iSeries to another.

I set up the users, generated the keys, copied the public keys onto the opposite systems and appended them to the authorized_keys file in the .ssh directories.

Both user profile names are less than 9 characters long.

When I log on to the first system (with the user I have generated and shared the keys for) and attempt to open an SFTP session to the second system using THAT profile, I get the following log.  I have listed only the debug1 messages for space:

 

OpenSSH_4.7p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /QOpenSys/QIBM/ProdData/SC1/OpenSSH/openssh-3.8.1p1//etc/ssh_config

debug1: Connecting to icidev1 [10.112.103.4] port 22.

debug1: Connection established.

debug1: identity file /home/HNSTWAR/.ssh/id_rsa type 1

debug1: identity file /home/HNSTWAR/.ssh/id_dsa type 2

debug1: Remote protocol version 1.99, remote software version OpenSSH_4.7

debug1: match: OpenSSH_4.7 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.7

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

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

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

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'icidev1' is known and matches the RSA host key.

debug1: Found key in /home/HNSTWAR/.ssh/known_hosts:1

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering public key: /home/HNSTWAR/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Offering public key: /home/HNSTWAR/.ssh/id_dsa

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: No more authentication methods to try.

Permission denied (publickey,password,keyboard-interactive).

Connection closed

 

Does anyone have any ideas?  Can't find enough information to interpret the log on my own.

Thanks.

Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16341
Avatar

--
06 Feb 2012 01:58 PM

 All your log tells us is that it didn't accept the key in id_rsa or the key in id_rsa.

For some reason, your id_rsa.pub file on the server is not installed (or not installed correctly).

mygoodname
New Member
New Member
Posts:75

--
07 Feb 2012 06:12 AM

Started over.

Removed the authorized_keys, and id files from the /home/'user'/.ssh directories on both systems. Remove copies of received keys from /home/'user' directories on both systems.

Regenerated new rsa keys for both users (QSH, ssh-keygen -t rsa -N "").

FTP'd the id_rsa.pub keys from the .ssh directories to the /home/'user' directories on the opposing systems (FTP, BIN, NAM 1, PUT).

On each system, I used QSH, and added the id_rsa.pub files from the /home/'user' directory to the authorized_keys file in the .ssh subdirectory.

Manually compared the key on system 1 against the entry in the authorized_keys file on system 2, and vice versa.

Tried transfer again with same result.

Then I backtracked to SSH and tried to connect from one system and can successfully do so
  
For the record, I can succesfully connect and execute commands as user1 on system1 if I use PuTTY. I can also do the same for user2 on system2 using PuTTY.                                                      

 

mygoodname
New Member
New Member
Posts:75

--
07 Feb 2012 06:51 AM

Discovered that one of the profiles had an invalid job description (didn't exist), so I had it changed and tried again.  This is the full log:

OpenSSH_4.7p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /QOpenSys/QIBM/ProdData/SC1/OpenSSH/openssh-3.8.1p1//etc/ssh_config
debug3: RNG is ready, skipping seeding
debug2: ssh_connect: needpriv 0
debug1: Connecting to system1 [10.112.103.4] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /home/USER1/.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/USER1/.ssh/id_rsa type 1
debug1: identity file /home/USER1/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug2: fd 4 setting O_NONBLOCK
debug3: RNG is ready, skipping seeding
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,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-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
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-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc 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: 120/256
debug2: bits set: 511/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/USER1/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/USER1/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'system1' is known and matches the RSA host key.
debug1: Found key in /home/USER1/.ssh/known_hosts:1
debug2: bits set: 488/1024
debug1: ssh_rsa_verify: signature correct
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/USER1/.ssh/id_rsa (2002fa30)
debug2: key: /home/USER1/.ssh/id_dsa (0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
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/USER1/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/USER1/.ssh/id_dsa
debug3: no such identity: /home/USER1/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
Connection closed

 

mygoodname
New Member
New Member
Posts:75

--
07 Feb 2012 09:29 AM

Found these comments in the sshd_config file. This is the default out-of-the-box.

Does it need to be changed?

#RSAAuthentication yes

#PubkeyAuthentication yes

#AuthorizedKeysFile .ssh/authorized_keys

Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16341
Avatar

--
07 Feb 2012 12:17 PM
How are you making this work with Putty?  (Putty uses a completely different key format.)
mygoodname
New Member
New Member
Posts:75

--
07 Feb 2012 12:34 PM
Let me clarify. I can use sftp with PuTTY as long as I use a password. I generated the keys for PuTTY and copied the OpenSSH-compatible public key into a txt document, uploaded it to my home directory and appended it to the /.ssh/authorized_keys file. It appended as a single long string of characters very much like the keys that the iSeries generated, but even PuTTY won't connect with it. I get the "Server refused our key" message.

Does the sshd_config file have anything to do with it? Again, it looks like the config file is nothing more than a collection of comments.
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16341
Avatar

--
07 Feb 2012 03:33 PM

Okay, so to recap: 

  • Keys don't work.  
  • They don't work from OpenSSH on IBM i.
  • They don't work from Windows on PuTTY.
  • We don't know why.

You suggested the sshd_config file.

  • Mine is the "stock" one.  (The one IBM installs, I haven't changed it.) 
  • Keys work fine for me.
  • You aren't doing anything fancy, so why would you want to change it?

I wish we had more information about why it's failing.  All we know is that the server is rejecting the key.  We don't have a log from the server (only one from the client) so we don't know why it's rejecting them.

Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16341
Avatar

--
07 Feb 2012 03:34 PM
Have you checked authorities?   It's important that *PUBLIC does not have read authority to the .ssh directory, or the files within that directory.
mygoodname
New Member
New Member
Posts:75

--
07 Feb 2012 03:39 PM
Followed the steps in IBM's OpenSSH redbook - checked authorities from QSH and they match the example.
mygoodname
New Member
New Member
Posts:75

--
08 Feb 2012 08:49 AM

These are the authorities on my directories.  The dates on the .ssh key files don't match, but that's because I inadvertently deleted the .pub file this morning and pulled it back from the other system.

ls -al /home/user1 
 
drwxr-s--- 3 USER1 0 8192 Feb 7 11:45 . 
drwxrwsrwx 84 QSYS 0 57344 Feb 6 11:31 .. 
-rw------- 1 USER1 0 322 Feb 6 12:56 .sh_history 
drwx--S--- 2 USER1 0 8192 Feb 8 10:25 .ssh 
-rwxr-x--- 1 USER1 0 411 Feb 7 07:50 user2_rsa.pub
-rw-rw-rw- 1 USER1 0 6254 Feb 7 07:57 newtest.txt 
-rwxr-x--- 1 USER1 0 227 Feb 7 11:45 putty.pub 
-rwxr-x--- 1 USER1 0 52 Feb 7 09:02 script.txt 
-rw-rw-rw- 1 USER1 0 81 Feb 7 09:03 test.txt 

ls -al /home/user1/.ssh 
 
drwx--S--- 2 USER1 0 8192 Feb 8 10:25 . 
drwxr-s--- 3 USER1 0 8192 Feb 7 11:45 .. 
-rw------- 1 USER1 0 637 Feb 7 11:47 authorized_keys 
-rw------- 1 USER1 0 1675 Feb 7 07:53 id_rsa 
-rwx------ 1 USER1 0 412 Feb 8 09:41 id_rsa.pub 
-rw-r--r-- 1 USER1 0 402 Feb 6 12:33 known_hosts 

mygoodname
New Member
New Member
Posts:75

--
08 Feb 2012 09:39 AM
Tried an SSH connection in debug mode but all I can see is that the public key was rejected.
/QOpenSys/usr/sbin/sshd -p 2222 -d -vvv 
sshd: illegal option -- v 
OpenSSH_4.7p1, OpenSSL 0.9.7d 17 Mar 2004 
usage: sshd [-46Ddeiqt] [-b bits] [-f config_file] [-g login_grace_time] 
 [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u le
n] 
$ 
/QOpenSys/usr/sbin/sshd -p 2222 -d 
debug1: sshd version OpenSSH_4.7p1 
debug1: private host key: #0 type 0 RSA1 
debug1: read PEM private key done: type RSA 
debug1: private host key: #1 type 1 RSA 
debug1: read PEM private key done: type DSA 
debug1: private host key: #2 type 2 DSA 
debug1: rexec_argv[0]='/QOpenSys/usr/sbin/sshd' 
debug1: rexec_argv[1]='-p' 
debug1: rexec_argv[2]='2222' 
debug1: rexec_argv[3]='-d' 
debug1: sshd QWTCHGJB: rc=0 avail=0 msgid= 
debug1: Bind to port 2222 on 0.0.0.0. 
Server listening on 0.0.0.0 port 2222. 
debug1: Bind to port 2222 on ::. 
Server listening on :: port 2222. 
Generating 768 bit RSA key. 
RSA key generation complete. 
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 
debug1: sshd QWTCHGJB: rc=0 avail=0 msgid= 
debug1: inetd sockets after dupping: 3, 3 
debug1: audit connection from xx.xxx.xxx.xx port 29041 euid 7313 
Connection from xx.xxx.xxx.xx port 29041 
debug1: Client protocol version 2.0; client software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH* 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-1.99-OpenSSH_4.7 
debug1: list_hostkey_types: ssh-rsa,ssh-dss 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: client->server aes128-cbc hmac-md5 none 
debug1: kex: server->client aes128-cbc hmac-md5 none 
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received 
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT 
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: KEX done 
debug1: userauth-request for user user1 service ssh-connection method none 
debug1: attempt 0 failures 0 
Failed none for user1 from xx.xxx.xxx.xx port 29041 ssh2 
debug1: audit event euid 7313 user user1 event 3 (SSH_failnone) 
debug1: userauth-request for user user1 service ssh-connection method publickey 
debug1: attempt 1 failures 1 
debug1: test whether pkalg/pkblob are acceptable 
debug1: temporarily_use_uid: GetPH *current rc=0 avail=0 msgid= 
debug1: temporarily_use_uid: GetPH pw_name user1 rc=0 avail=0 msgid=
 
debug1: temporarily_use_uid: SetPH rc=0 avail=0 msgid= 
debug1: trying public key file /home/USER1/.ssh/authorized_keys 
debug1: In Function:user_key_allowed2 AD CALLING FUNCTION :restore_uid 
debug1: restore_uid: SetPH rc=0 avail=0 msgid= 
debug1: restore_uid: ReleasePH prevHandle rc=0 avail=0 msgid= 
debug1: restore_uid: ReleasePH profileHandle rc=0 avail=0 msgid= 
debug1: temporarily_use_uid: GetPH *current rc=0 avail=0 msgid= 
debug1: temporarily_use_uid: GetPH pw_name user1 rc=0 avail=0 msgid=
 
debug1: temporarily_use_uid: SetPH rc=0 avail=0 msgid= 
 
debug1: trying public key file /home/USER1/.ssh/authorized_keys2 
debug1: restore_uid: SetPH rc=0 avail=0 msgid= 
debug1: restore_uid: ReleasePH prevHandle rc=0 avail=0 msgid= 
debug1: restore_uid: ReleasePH profileHandle rc=0 avail=0 msgid= 
Failed publickey for user1 from xx.xxx.xxx.xx port 29041 ssh2 
debug1: audit event euid 7313 user user1 event 6 (SSH_failpubkey) 
debug1: userauth-request for user user1 service ssh-connection method keyboard-interactive 
debug1: attempt 2 failures 2 
debug1: keyboard-interactive devs 
debug1: auth2_challenge: user=user1 devs= 
debug1: kbdint_alloc: devices '' 
Failed keyboard-interactive for user1 from xx.xxx.xxx.xx port 29041 ssh2 
debug1: audit event euid 7313 user user1 event 5 (SSH_failkbdint) 

mygoodname
New Member
New Member
Posts:75

--
10 Feb 2012 06:33 AM
Immediate problem solved.

This morning, I noticed that every file in my .ssh directory was encoded using CCSID 819, EXCEPT for the authorized_keys file which was set to 37.

Solved the problem by deleting the file, then using the cp command to put the first key in.

What I can't figure out is why the shell commands for generating the keys used one CCSID and the cp command in the same shell session used another.

Any thoughts?
Scott Klement
Editorial Staff Member
Editorial Staff Member
Posts:16341
Avatar

--
10 Feb 2012 11:51 AM

What commands did you run when you copied the file?   Were they run in QShell or PASE?

mygoodname
New Member
New Member
Posts:75

--
10 Feb 2012 12:01 PM
Opened the session using QSH.  That was the problem.  Too much research and too many articles got mixed up in my head.  If I had simply stuck with CALL QP2TERM everything would have been okay.
You are not authorized to post a reply.

Acceptable Use Policy