[Info-vax] OpenVMS SSH to freeSSHd on Windows

[Neil Rieck]

On Nov 11, 10:12 pm, Sum1 <n... at here.com> wrote:
> Hi All
>
> Having fun - not - trying to get this going.  And yes, it is a
> requirement that the server-end is freeSSHd.
>
> I believe that freeSSHd used OpenSSH as a protpcol base and uses RSA
> keys for authentication.  I have configured the server end and can
> access it using passwords from Windows, OSX and VMS.  I have generated
> 1024-bit RSA key pairs on Windows and OSX and can use them to
> authenticate to the server without a password.  I cannot get VMS to
> authenticate with public keys.  OVMS 8.3, TCP/IP 5.6 with all the SSH
> compenentry sitting at 5.6-9
>
> I have tried generating keys using:
> - ssh-keygen -t dsa fred
> - ssh-keygen -t dsa -b 1024 fred
> - ssh-keygen -t rsa fred
> - ssh-keygen -t rsa -b 1024 fred
>
> One by one, I have copied them to the server and tried to use them -
> nothing!  Extensive Googling suggests that it is an inconsistency
> between SSH/SSH2/OpenSSH - but I don't know where….and 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.
>
> 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?

It has been a while since I did this between OpenVMS (using the
TCPware stack) and Windows but let me mention five points common to
most platforms:

1) The SSH connection procedure will allow two accounts to connect
without going through a system supported authorization method "so it
has been made really complicated" on purpose. Remember that the
private key at the local end is combined with an associated public key
at the remote end to become "the password". To disable future
connection events, you must delete one of the keys (or their
associated entries. See below)

2) It is not enough to just generate the keys, you need to add entries
for your "private" keys in a file named "identification." (no
extension) like so:

idkey SSH_BOB_ON_NODE_12
idkey entry2
idkey entry3

Note: one reason for this is to prevent hackers from just dropping a
file into this directory then using it. During a connection event,
only these private keys will be offered and tried.

3) You need to add entries for the other guy's "public" keys in a file
named "authorization." (no extension) like so:

key SSH_ALICE_ON_NODE_34.PUB
key entry2.PUB
key entry3.PUB

Note: one reason for this is to prevent hackers from just dropping a
file into this directory then using it. During a connection event,
only these public keys will be offered and tried.

4) Repeat steps 2 + 3 at the remote end.

5) You need to be careful with file protections. Enabling all of them
(including world) would allow hackers to make unauthorized changes. If
either the SSH config file (common or local) is set like this
"StrictModes yes" then connections will be aborted if any file
protections are too liberal.

http://www3.sympatico.ca/n.rieck/docs/openvms_notes_ssh2.html

Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/