[Info-vax] OpenVMS SSH to freeSSHd on Windows

[Sum1]

On 2011-11-12 04:31:54 +0000, Steven Schweda said:

> On Nov 11, 9:12 pm, Sum1 <n... at here.com> wrote:
> 
>> [...] I cannot get VMS to
>> authenticate with public keys.
> 
>    "I cannot" is not a useful problem description.  It does
> not say what you did.  It does not say what happened when you
> did it.
> 
>> [...] OVMS 8.3, TCP/IP 5.6 with all the SSH
>> compenentry sitting at 5.6-9
> 
>    Actual output from, say:
>       tcpip show version
>       ssh "-V"
> might be more helpful/informative/reliable.

Seriously, you mean that when I tell you it is v5.6 and that the 
components are all 5.6-9, that doesn't tell you enough.  OK, well then 
here is the output for you, which tells you less than I did.  Sorry to 
seem crabby, but what are you after apart from the versions….?

TCPIP> sho ver

  HP TCP/IP Services for OpenVMS Alpha Version V5.6
  on an AlphaServer DS10L 466 MHz running OpenVMS V8.3   


>> I have tried generating keys using:
>> [...]
> 
>    Where?  The TCPIP SSH software can't use OpenSSH-format
> key data.  After:
>       @ SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM
> you can generate some SSH2 key files using SSH_KEYGEN.  Then,
> you can compare those to what you've been trying to use, and
> see how different they are.
> 
>> [...]  One by one, I have copied them to the server and
>> tried to use them - nothing!
> 
>    And "nothing" is what that tells me about what you did, or
> what happened when you did it.

freeSSHd server refused to accept the OpenVMS certificate

> 
>> [...]   Extensive Googling [...]
> 
>    Did Google tell you about the value of adding "-v" (or
> "-vv", ...) to a failing "ssh" command?  Some actual
> diagnostic output might be more helpful than "nothing" in
> diagnosing this problem.
> 
>    All that Web searching should have told you that common
> SSH problems (other than key data format differences) include
> various file ownership and permission/protection settings.
> (No information about which did I see in your problem
> description.)
> 
>> [...] the suggestions
>> to vonvert the keys on the server-side won't work, as
>> freeSSHd doesn't provide anything other than a server - no
>> ssh commands.
> 
>    Which suggestions, exactly, were those?  You shouldn't
> need any "ssh commands".  An OpenSSH ssh-keygen program
> should have a "-e" option which would tell it to convert an
> OpenSSH key file to the SSH2 (aka "SECSH") format.  (And/or a
> "-i" option to go the other way.)

In the document 
http://burnz.wordpress.com/2007/10/17/how-to-make-ssh2-work-with-openssh/ 
it states that if you are using a SSH2 client (I assume the VMS one is) 
and an OpenSSH server (I assume freeSSHd is), then "Run the OpenSSH 
version of ssh-keygen on the server to convert the SSH2 public key to 
into the format needed by OpenSSH".

This seems to suggest that the conversion must happen on the server - 
as I stated elsewhere, there are *NO* SSH commands on the server….there 
is only a SSH daemon/service - nothing else.  freeSSHd is a 
self-contained, server only small-footprint package.
> 
>> Connecting to the freeSSHd server using certificates
>> generated by True64 works fine.  I wonder if I could just
>> copy them onto the VMS machine and use them?
> 
>    With my weak psychic powers, I don't know exactly how you
> did what on your Tru64 system.  On _my_ Tru64 system, the SSH
> software seems to use the same SSH2 format as my VMS+TCPIP
> uses, so I'd expect no conversion to be necessary when moving
> key data between those systems.

Well, it doesn't - it is a completely different version of SSH 
apparently - or so the True64 people tell me and I am not a True64 user.
> 
>    I'm sorry if you're frustrated, but neither my sorrow nor
> your frustration is so valuable as an accurate and detailed
> problem description.
> 
>    I've never heard of freeSSHd, so I know nothing about it.
> Perhaps other VMS users would be in the same situation.  If I
> need to know anything about it, then you might consider
> providing a pointer to some documentation, as I may be too
> lazy to look very hard to find it.