Strict host key checking on second connection

[harryseldon]

I've just installed Co:Z Batch SFTP for the first time. I made my initial configuration changes, edited a copy of the SFTPSAMP member from the SAMPJCL library for our environment and ran it. Everything worked beautifully. I tried resubmitting the job and each step is now getting Host key verification failed with the error that no host key is known for the system. I didn't make any changes to the SFTPSAMP member between runs. I did, however, move my Co:Z installed data sets off the volume group they were installed on to a different volume group that houses our production data. I'm running my copy of the SFTPSAMP member from my personal PDS so it wasn't affected by the move. I've verified that the host I'm trying to connect to is in the known_hosts file maintained for sftp. I'm not sure why I'm getting the error. Has anyone seen this before or maybe see a problem I'm not recognizing? The full error:

CoZBatchÝN¨: Copyright (C) 2005-2009 Dovetailed Technologies LLC. All rights reserved.
CoZBatchÝN¨: version 2.1.1 2012-03-16
CoZBatchÝI¨: executing progname=login-shell="-/bin/sh"
Connect using SSH defaults (keys)...
Executing: /usr/local/coz/bin/cozsftp -oConnectTimeout=60 -oServerAliveInterval=60 -oStrictHostKeyChecking=yes -b-
<user>@<host>
Co:Z SFTP version: 2.1.1 (5.0p1) 2012-03-16
Copyright (C) Dovetailed Technologies, LLC. 2011. All rights reserved.
No RSA host key is known for <host> and you have requested strict checking.

Host key verification failed.

Ý25.739¨ Connection closed
CoZBatchÝI¨: returning rc=exitcode=255

Here's the previous run's success on the same step:

CoZBatchÝN¨: Copyright (C) 2005-2009 Dovetailed Technologies LLC. All rights reserved.
CoZBatchÝN¨: version 2.1.1 2012-03-16
CoZBatchÝI¨: executing progname=login-shell="-/bin/sh"
Connect using SSH defaults (keys)...
Executing: /usr/local/coz/bin/cozsftp -oConnectTimeout=60 -oServerAliveInterval=60 -oStrictHostKeyChecking=yes -b-
<user>@<host>
Co:Z SFTP version: 2.1.1 (5.0p1) 2012-03-16
Copyright (C) Dovetailed Technologies, LLC. 2011. All rights reserved.
cozsftp> lzopts mode=text
mode=text
cozsftp> get sftptesting.txt //DD:MYDD
Fetching /ducetest/sftptesting.txt to //DD:MYDD
ZosDatasetÝI¨: Opening dataset DD:MYDD for write
ZosDatasetÝI¨: Closing dataset //DD:MYDD - 30 bytes received, 1 records written
CoZBatchÝI¨: returning rc=exitcode=0

[harryseldon]

Just to be safe I moved my Co:Z installed data sets back to the original volume groups and reran my job. It failed with the same error. So I guess the question is how it could run fine the first time and then fail to find the host key on subsequent runs.

[dovetail]

You have StrictHostKeyChecking=yes, so:

- if you don't have a host key for the host in either the user's $HOME/.ssh/known_hosts or /etc/ssh/ssh_known_hosts, then the connection will fail

- if you set StrictHostKeyChecking=no, then it will automatically accept the host key into the user's $HOME/.ssh/known_hosts but only if there isn't already another key for this host. If there is already another key in known_hosts that doesn't match, then the connection will fail.

I'm not sure what is going wrong - were you using the same userid? the the same LPAR (Unix filesystems)?

To diagnose:

1) login to the same LPAR with the same userid that you are using

2) issue these command under a Unix shell:

Code: Select all

ssh-keyscan -t rsa my.hostname.com
ssh-keyscan -t dsa my.hostname.com

this will print the host's rsa and dsa public keys. You need at least one of these; I tend to prefer rsa.

3) check your ~/.ssh/known_hosts file
- the .ssh directory should have permissions 700
- the known_hosts file should have permissions 600
- see there is a line for the same host name or ip address. If the key is different, then remove it and verify with the hosts' administrator that you are seeing the correct host key from ssh-keyscan (that there is not a server-in-middle-attack)

4) check your /etc/ssh/ssh_known_hosts file
- is should have permissions 644
- see there is a line for the same host name or ip address. If the key is different, then remove it and verify with the hosts' administrator that you are seeing the correct host key from ssh-keyscan (that there is not a server-in-middle-attack)

5) if neither file has the host's public key, then you can either make a connection interactively with StrictHostKeyChecking=ask (the default) and then accept the key (into .ssh/known_hosts), or you can manually put it into either file, like this:

Code: Select all

ssh-keyscan -t dsa my.hostname.com >> /etc/ssh/ssh_known_hosts

You can also search a known_hosts file for a host's public key using these commands:

Code: Select all

ssh-keygen -F myhost.com   # searches the user's .ssh/known_hosts
ssh-keygen -F myhost.com -f /etc/ssh/ssh_known_hosts

You should also search to see if you have entries for the ip address of the host:

Code: Select all

ssh-keygen -F 192.168.0.1   # searches the user's .ssh/known_hosts
ssh-keygen -F 192.168.0.1 -f /etc/ssh/ssh_known_hosts

[harryseldon]

Thanks for the reply. It looks like my problem with strict host key checking was due to a permissions mismatch on my known_hosts file. That partition has a tighter security setup than others at our site. All our ssh files on that partition are owned by a service account that's used to run batch jobs. I noticed that when I turned off strict host key and reran the jobs that I was getting a new known_hosts created in my personal home directory because my account didn't have explicit read access to known_hosts (my account has root access but the file owner has a different UID). I'm still not sure why it worked the first time but I found that making a copy of my known_hosts file in /etc/ssh alleviated the problem while allowing me to keep the check in place. Testing is back under way and looking great!

[Bohatyaor]

If the key is different, then remove it and verify with the hosts' administrator that you are seeing the correct host key from ssh-keyscan (that there is not a server-in-middle-attack)????

[hnoor0077]

I moved my Co:Z installed data sets back to the original volume groups and reran my job. It failed with the same error.....

[dovetail]

hnoor0077, you are replying to an old thread from 2012, and it is not clear that your problem is related.

Please consider starting a fresh thread and post more details on the symptoms of your problem.