INVALID KEY

[jack.weatherford]

Having failed to get connected using passwords we move on to attepting to use keys.
after generating and exchanging the public key on ZOS when we attempt to connect we see this messages in the log.
key_type_from_name: unknown key type '-----BEGIN'.
key_type_from_name: unknown key type '-----END'.
identity file /u/sms1jmw/.ssh/ssh_host_dsa_key type 2.
Remote protocol version 2.0, remote software version OpenSSH_5.3.
match: OpenSSH_5.3 pat OpenSSH*.
Enabling compatibility mode for protocol 2.0.
Local version string SSH-2.0-OpenSSH_5.0.
fd 4 setting O_NONBLOCK.

and then get a disconnect.
cant find anything to explain this.

[dovetail]

Regarding your previous problem (connecting using passwords):
http://dovetail.com/forum/viewtopic.php?f=8&t=1352

Did you do what was suggested? Did you get the ssh client trace for it?

I also should mention that if it fails that the problem might be only identified on the server. For server messages, look in the log messages from SSHD. The actual location will be configured based on your syslogd settings (/etc/syslog.conf)

Regarding the trace above, I don't see any indications of the error - these are normal trace messages. So, again, you should look at the server log.

[jack.weatherford]

Regarding your PASSWORD suggestion. I am at an offsite location and can only access the ZOS system via TN3270 and the firewall rules will not let me connect directly to UNIX unless I am within the network so PuTTy is not an option. Wish it were. I also dont have access to the server logs.
The suggestion you made was valid and I had attempted something similar but was locked out.
That is why they requested i attempt to setup for keys instead.

[dovetail]

The symptom of your problem indicates that the server has a problem with the connection and is just dropping it.
In these cases, SSHD will normally log a warning message to syslogd. You said that you were able to put your public key on the server, but you don't have access to its logs?

[jack.weatherford]

The admin on the remote server reviewed the logs and said that the connection was being dropped because we were running a verison of SSH that was not compatable with their server.
They are running
openssh-server-5.3p1-84.1.el6.x86_64

from our job log I get this
Co:Z SFTP version: 2.4.1 (5.0p1) 2013-06-24

running native SSH via batch gives me this level
OpenSSH_5.0p1, OpenSSL 0.9.8k 25 Mar 2009

does anyone see a compatatility problem here.

[dovetail]

It would be helpful to see the exact messages from their server. I am not aware of any inherent incompatibilities between OpenSSH 5.0 and 5.3.
It is more likely because of an incompatibilities of things like the supported crypto algorithms configured as supported between the client and the server (a configuration incompatibility).

[jack.weatherford]

thank you for the reply. Getting information from them is like pulling teeth.

[jack.weatherford]

Moving on to the next hurdle.
I have finally gotten the keys setup correctly (maybe) and user A can submit a batch job on our mainframe and successfully connect to the server using the keys and issue commands such as pwd and ls -al and cd.
but user B submitting the exact same job get a 255 and the connection is rejected.
I can see from the trace messages and debug that the same key file is being used by both A and B and the userid being passed to the server is the same in both cases.

I am missing something here but for the life of me cant figure our what.
Can someone give me any suggestions.

[dovetail]

You don't mention what kind of user key that you are using -

- a RSA/DSA private key in the Unix file system?
- a RSA/DSA private key in a RACF/SAF keyring?

For example, if a private key in a file, IBM Ported Tools OpenSSH will not use it unless it has the permission bits 600 and is owned by the z/OS userid. So it is often diffcult to share a private key file without making a copy for the second userid.

But these are just guesses. It is difficult to say much without seeing your log/trace messages (with -vvv)

[jack.weatherford]

I think your guesses are right on.
We are using RSA keys from HFS files and user A is the owner of the file. We created copies of the keys for user B and made them the owner.The permission bits on the .pub are 644 and 600 on the private key.
User B will test again but it sounds like the ownership bit may be the answer.
The log just says that a key was sent and that is all no errors.
this is the debug messages
debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

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

debug2: input_userauth_pk_ok: fp 37:32:80:92:73:f8:d9:d1:3e:5e:f7:6d:73:dc:5d:2e

debug3: sign_and_send_pubkey

debug2: we did not send a packet, disable method

debug1: No more authentication methods to try.

debug3: __catgets: NLS setup complete (1), using message catalog openssh.cat

FOTS1373 Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Ý88.156¨ Connection closed

[dovetail]

If you made a copy of the private key, changed its owner and made the permissions 600 then it should work.

I can't tell from the log but I assume that you are logging into the same remote userid?

[dovetail]

If you are going to try to use keys with OpenSSH, I recommend that you review the video and slides from:

"IBM Ported Tools OpenSSH - Key Authentication"
http://dovetail.com/webinars.html

[jack.weatherford]

Thanks for your feed back. The key ownership was the issue and once the correct owner was set we were able to connect.
With that out of the way the user will begin working on scripts/transfers.
This is a great product and despite my stupidity does what it promises.