ssh not populating known_host file

[Rita C Workman]

I'm pulling my hair out. We set up sftp from our HPUX to outside sources (Windows,HP,Linux) with no problems using HPUX Secure Shell ver 4.20.
But I'm trying to set up and internal sftp from HPUX running HPUX Secure Shell ver 4.50 to an internal Windows server running OpenSSH (cygwin) ver 3.8x something and it's not working right.
Seems Windows client is always forced to give password. Noticed that on HPUX side the known_host file is not populating. Not for the user account/.ssh/ and not for the /opt/ssh/etc/ssh_known_host global.

Is there something 'wrong' with ver 4.50 that anyone is aware of?

Here's the message I keep getting:
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: 131/256
debug2: bits set: 522/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/bminside/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug3: check_host_in_hostfile: filename /home/bminside/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug3: check_host_in_hostfile: filename /home/bminside/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug2: no key of type 0 for host edms1
debug3: check_host_in_hostfile: filename /home/bminside/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /home/bminside/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug2: no key of type 2 for host edms1
Host key verification failed.
Connection closed

Really happy to give points...cause I am really tired of playing with this one.

Thanks,
Rita

[Patrick Wallek · Accepted solution]

Hi Rita,

I'll ask the dumb questions --

1) What are the permissions on the known_hosts file and on the .ssh directory? I assume the user has write permission?

2) Do you have the public key from the Unix server in the authorized_keys file (or whatever the Windows equivalent is) on the Windows server?

3) Are you talking compatible SSH Versions? SSH V2 on both sides? (You really don't want to do SSH v1.)

4) When you SSH to the Windows server are you getting prompted to add this server to known_hosts? If not, have you checked known_hosts to see if there is already an (old, perhaps) entry with the same name or IP address of the Windows server?

5) Any firewall on the Windows server that might be blocking SSH?

[Steven Schweda]

> [...] our HPUX [...]

Uh, "uname -a"? (Or should we already know
what "our HPUX" is?)

> Here's the message I keep getting:

When you do what, exactly, where?

Which system is the SSH server, and which is
the client?

> [...] for host edms1

Who is "edms1"?

[Rita C Workman]

Patrick:

1)Permissions 600 and yes the user has rights and is owner
2)Yes
3)I believe they are compatible (note I said believe)
4)We've played it both ways...UNIX as server and Windows as client and visa versa. It seems Windows will populate it's known_host, but UNIX is not for this server.
[NOTE on my standard FTP server it is running ver 4.20 and I do not have theses problems.]
5)No firewall issues between these two servers, they are both on the 'inside'. The other standard FTP, that works, is our outside FTP server.

Steven:

uname -a)HPUX 11.23 PARisc.

When you do what, exactly, where?) When I run sftp -v @edms1

Who is "edms1"?) EDMS1 is the Windows side

=======================
A little more info:

Yes we have tried it with UNIX being the server -and- with Windows being the server.

Yes we have also run ssh-keygen -e -f ~/id_rsa.pub > ~/id_rsa.converted.pub to the public key when I created it on UNIX, just in case Windows didn't like the first one.

Yes the Windows guy set up a file called "authorization" with a couple single liners
saying
KEY id_rsa.converted.pub
KEY id_rsa.pub
=====================================

Thanks,
Rita

[Rita C Workman]

I think I may have it. Long ago we went from ssh ver 4.20 to ver 5.10 and it was a total disaster - it hammered our chroot environment for our outside FTP server.

I found another box, inside, that still had ver 4.20 on it and ran a test. Seems, same user, going to same Windows box will populate the known_host file. But it is still not perfect, cause it keeps requiring us to put in a password. [And NO I did not enter anything for passphrase].

So, I need to downgrade the Secure Shell software on this box. Unless somebody knows a version that works right for sftp and doesn't mess up chroot.

So I still need help ....
We are down to just one question now.....why it isn't reading the key right so we don't have to put a password in. What have I missed?

Thanks,
Rita

[Steven Schweda]

I've never installed or configured SSH on a
Windows system, so I know nothing, but the
messages (on host "edms1") saying "no key of
type X for host "edms1" make it look as if
no one ever generated host keys on host
"edms1".

Eliminating one of these systems may reveal
on which side the problem lies. So, ...

Can you do ssh/sftp from the HP-UX system
to itself (as the problem user, or as some
other user)?

Can you do ssh/sftp from the Windows system
to itself (as the problem user, or as some
other user)?

(I prefer using plain ssh rather than sftp
for debugging, as it's a little simpler. If
your configuration allows only sftp access,
then you may be stuck with it, but that's
probably not a big deal.)

[Horia Chirculescu]

Hello,

Try to install openssh 5.3 on both sides, this problem related to sftp chroot is solved, at least it is working as expected on HP-UX B 11.11 (the server) and Windows XP SP2 (the client)

Best regards,
Horia.

[Rita C Workman]

Horia,

Sorry, I shouldn't have even mentioned the chroot thing. My issue here is not chroot on ssh, it is strictly connecting HPUX to Windows to do sftp transfers passwordless.

Have determined ver 4.20 works ok to populate the known_host file, but still requiring password.

Continuing to work on this and I'll let folks know, unless someone else has the fix.

Yes, points will follow.

Thanks,
Rita

[Steven Schweda]

> [...] but still requiring password.

Non-psychics here still requiring output from
"ssh -v [...]" in that situation, so we might
get some idea of what goes wrong where.

[Steven E. Protter]

Shalom Rita,

From Toledo, Ohio.

I've seen this issue myself with 4.50 openssh.

Its an undocumented feature. It fails under certain circumstances to populate the known_hosts file.

Now here we actually keep a central known_hosts file for all system to use so it doesn't matter. When we add new systems, we use rcs, pull the file to a local disk, and then rcs it back to central location.

Your 4.20 issue with requiring the password even when permissions and ownership is right is also a known issue, though I suspect its windows.

So I'm thinking you for sure need to pick a new and different secure shell version on HP-UX an run a complete set of tests as well.

SEP

[Rita C Workman]

OK..here goes:

For those who may hit this some day.
Secure Shell (ssd) version 4.50 does not populate known_hosts file as Stephen mentions. Closest version that works 4.40

FYI...that pesky chroot issue shows up after 4.20 version and is still there at ver 5.10. I don't know what version they ever got that fixed yet.

With that said. Went on testbox and downgraded to v4.40 and now it would populate the known_host for me. But still was having issue in both directions where the passwd prompt kept coming up. Then, because the Windows guy wouldn't give me that accounts password, he was handling doing the 'ftp' of the id_rsa.pub files. I didn't care if UNIX created them or Windows generated the key. What I discovered was, since he was doing this from his laptop, the files got corrupted in the transfer. When I watched him close and asked to type 'binary' before he 'puts' the file over...voila a measure of success. He ftp'd in binary the file to my UNIX box he generated and I set it in the authorized_keys file also. Now he could connected passwordless to the UNIX box. But UNIX could not do a passwordless connection to Windows. We looked at a couple setting on the Windows ssh_config files and noticed there are setting he should change to make it possible for passwordless. So once he makes those changes we can go both ways.

For now...I don't care cause for production I only need for him to move the files TO UNIX, so I'll just test for return connectivity another time and get that resolved. I'm working the way I need...

Hope my ramblings made some sense.
My issue is fixed and I thank you all for your contributions. They really did help!

Points a comin!
Rita

[Rita C Workman]

THREAD CLOSED