SSH2 on VMS

[robert70]

Hello,
We have an Alpha DS20E running VMS 7.3-2.
Trying to connect to a UNIX server with publice key encryption.

some system details below....

DAVE$ set def dkb0:[sys0.sysmgr.ssh2]
DAVE$ ssh2 "-V"
dave$dkb0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS
(V5.5) 3.2.0 on COMPAQ AlphaServer DS20E 666 MHz - VMS V7.3-2

steps taken so far

1.produced the 2 keys with.......

DAVE$ run DAVE$DKB0:[VMS$COMMON.SYSEXE]TCPIP$SSH_SSH-KEYGEN2.EXE
Generating 2048-bit dsa key pair
7 o.oOo.oOo.oO
Key generated.
2048-bit dsa, system@DAVE.HBEU_AD, Wed Feb 17 2010 16:14:56
Passphrase :
Again :

Key is stored with NULL passphrase.
(You can ignore the following warning if you are generating hostkeys.)
This is not recommended.
Don't do this unless you know what you're doing.
If file system protections fail (someone can access the keyfile),
or if the super-user is malicious, your key can be used without
the deciphering effort.
Private key saved to ssh2/id_dsa_2048_b
Public key saved to ssh2/id_dsa_2048_b.pub

2.
created a file called IDENTIFICATION in my SSH" subdirectory with the following line in it

idkey id_dsa_1024_a

created a file called AUTHORIZATION in my SSH" subdirectory with the following line in it

idkey id_dsa_1024_a.pub

3.emailed the .pub key to the administrator of the UNIX box - he set things up at his end - he has assured me

The connection didnt work so I suggested he tried a conversion of the UNIX file with

ssh-keygen -i -f id_dsa_1024_a.pub >> authorized_keys2

still not working get I this................

$ ssh2 ftpjcqt@host
warning: Could not read public key file /SYS$SYSROOT/sysmgr/ssh2/id_dsa_1024
ftpjcqt's password:

no password setup for ftpjcqt so fails.

any help please

[Joseph Huber_1]

Just some guesses:
(1)
Public key saved to ssh2/id_dsa_2048_b.pub
but
idkey id_dsa_1024_a

ssh searching for the wrong key ?

(2)
If (1) is not the answer, there could be a problem with the sys$manager directory search list:

apparently You created the key under the SYSTEM login:
is the key created in sys$common:[sysmgr.ssh2] ?
If yes, copy it to sys$sysroot:[sysmgr.ssh2],
or better use a different account, which has no search list home directory.

[robert70]

sorry the 1024 2048 difference is a typo
my apologies
ive tried copying to the other directory either as you suggested no difference

[robert70]

switched the verbose on and I get this
replaced all IP's with "host"

.............................

DAVE$ ssh2 "-v"cqt@128.11.56.61
dave$dkb0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: FATAL: Cipher qt@128.11.5
6.61 is not supported.

%TCPIP-F-SSH_FATAL, non-specific fatal error condition
DAVE$ ssh2 "-v" ftpjcqt@host
debug: Ssh2/SSH2.C:1906: CRTL version (SYS$SHARE:DECC$SHR.EXE ident) is V7.3-2-0
0
debug: SshAppCommon/SSHAPPCOMMON.C:322: Allocating global SshRegex context.
debug: SshConfig/SSHCONFIG.C:3332: Metaconfig parsing stopped at line 4.
debug: SshConfig/SSHCONFIG.C:861: Setting variable 'VerboseMode' to 'FALSE'.
debug: SshConfig/SSHCONFIG.C:3240: Unable to open ssh2/ssh2_config
debug: Connecting to host, port 22... (SOCKS not used)
debug: Ssh2/SSH2.C:2872: Entering event loop.
debug: Ssh2Client/SSHCLIENT.C:1608: Creating transport protocol.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:101: Added "hostbased" to usable met
hods.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:101: Added "publickey" to usable met
hods.
debug: SshAuthMethodClient/SSHAUTHMETHODC.C:101: Added "password" to usable meth
ods.
debug: Ssh2Client/SSHCLIENT.C:1649: Creating userauth protocol.
debug: client supports 3 auth methods: 'hostbased,publickey,password'
debug: SshUnixTcp/SSHUNIXTCP.C:1378: using local hostname DAVE.HBEU_AD
debug: Ssh2Common/SSHCOMMON.C:546: local ip = host, local port = 50095
debug: Ssh2Common/SSHCOMMON.C:548: remote ip = host, remote port = 22
debug: SshConnection/SSHCONN.C:2290: Wrapping...
debug: SshReadLine/SSHREADLINE.C:3670: Initializing ReadLine...
debug: Remote version: SSH-2.0-OpenSSH_4.2
debug: OpenSSH: Major: 4 Minor: 2 Revision: 0
debug: Ssh2Transport/TRCOMMON.C:1828: All versions of OpenSSH handle kex guesses
incorrectly.
debug: Ssh2Transport/TRCOMMON.C:2268: lang s to c: `', lang c to s: `'
debug: Ssh2Transport/TRCOMMON.C:2333: c_to_s: cipher aes128-cbc, mac hmac-sha1,
compression none
debug: Ssh2Transport/TRCOMMON.C:2336: s_to_c: cipher aes128-cbc, mac hmac-sha1,
compression none
debug: Remote host key found from database.
debug: Ssh2Common/SSHCOMMON.C:347: Received SSH_CROSS_STARTUP packet from connec
tion protocol.
debug: Ssh2Common/SSHCOMMON.C:397: Received SSH_CROSS_ALGORITHMS packet from con
nection protocol.
debug: server offers auth methods 'publickey,password,keyboard-interactive'.
debug: Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1682: adding keyfile "/SYS$SYSROOT/sy
smgr/ssh2/GMS_id_dsa_2048_b" to candidates
debug: server offers auth methods 'publickey,password,keyboard-interactive'.
debug: Ssh2AuthClient/SSHAUTHC.C:377: Method 'publickey' disabled.
debug: server offers auth methods 'publickey,password,keyboard-interactive'.
ftpjcqt's password: dClient/AUTHC-PASSWD.C:250: Starting password query...

...................................

[Steven Schweda]

> [...] conversion [...]

Perhaps a good idea, depending on the
(unidentified) software on the other end.

> ssh-keygen -i -f id_dsa_1024_a.pub >> authorized_keys2

Which left what, exactly, in
"authorized_keys2"? (And is that the file
where the SSH server there will be looking?
Not plain "authorized_keys"? And in which
directory? "ls -lA"?)

What is this "the UNIX box", and what's the
SSH software there?


> debug: Ssh2AuthPubKeyClient/AUTHC-PUBKEY.C:1682: adding keyfile "/SYS$SYSROOT/sy
> smgr/ssh2/GMS_id_dsa_2048_b" to candidates
> debug: server offers auth methods 'publickey,password,keyboard-interactive'.
> debug: Ssh2AuthClient/SSHAUTHC.C:377: Method 'publickey' disabled.

Apparently the remote server hates your
public key data. And who, by the way, is
this "GMS_id_dsa_2048_b" key file?

> 2.
> created a file called IDENTIFICATION in my SSH" subdirectory with the following line in it

You seem to be the only one who believes
this. And what's an 'SSH"' subdirectory?

As usual, it might help if you showed some
actual evidence instead of mere assertions of
"facts". For example:

ALP $ set default sys$login
ALP $ type [.ssh2]identification.
IdKey SYSTEM_NPP_ID_DSA_1024_A
ALP $

Now we _know_ what's in _my_
"~/ssh2/identification" file. We have only
your word for what's in yours. And your SSH
client seems to disagree with you.

[Thomas Ritter]

The unix side need the file in OpenSSH format in the [.ssh] subdirectory.
The VMS, being the client, needs the key registered in [.ssh2]identification.

$ typ [.ssh2]IDENTIFICATION.
IdKey ID_DSA_2048_A

[John Gillings]

Roger,

You will probably have to play with the format and attributes of the key files on one or both systems.

Generate dummy keys on both source and destination systems. Compare the text files and try to reconcile any differences. Key files are "just text", but different systems seem to want them in slightly different formats.

[Steven Schweda]

> Apparently the remote server hates your
> public key data. [...]

And, of course, there may be other
interesting stuff in the system logs on "the
UNIX box", especially if the key file format
there is defective.

[robert70]

for steve my key data is

DAVE$ set default sys$login
DAVE$ type [.ssh2]identification.
idkey GMS_id_dsa_2048_b

[robert70]

unfortunately i dont have admin access to the unix box so not sure many details about this.

[Thomas Ritter]

You dont need admin access. It's your file and subdirectory. Login and type out the contents. Maybe the results will provide another clue why PKA is not functioning.

[Steven Schweda]

> DAVE$ set default sys$login
> DAVE$ type [.ssh2]identification.
> idkey GMS_id_dsa_2048_b

Yeah, I guessed that from the "-v"
diagnostics. But that does not agree with
the rest of your description, like, say:

> created a file called AUTHORIZATION in my
> SSH" subdirectory with the following line
> in it
>
> idkey id_dsa_1024_a.pub

leaving me confused (more than usual).

> unfortunately i dont have admin access to
> the unix box so not sure many details about
> this.

I assume that someone does.

> You dont need admin access. It's your file
> and subdirectory. [...]

He and I seem to be talking about different
things.

When you assemble a coherent narrative, which
includes some useful information, please post
it.

[robert70]

originally the key was the 1024 but i re-ran and sent over the 2048 key - sorry for the confusion

[Steven Schweda]

> [...] - sorry for the confusion

Fine, but if you look back through this
thread, you should be able to find a
particular character used repeatedly: "?".
Generally, it follows a question, which was
intended to elicit an answer. These answers
seem to be pretty sparse.

It's nice if you "sent over" the right key
file, but, with my weak psychic powers, I
can't see what happened to it after that, so
I have no way of knowing which data are where
on the (still unidentified) remote system,
where potential problems include such things
as wrong file, wrong name, wrong place, wrong
format, wrong owner, wrong permissions, and a
host of others. If your session transcript
is still relevant, then my comments about
are, too. And that includes the need for
information about and/or from the remote
system.

[robert70]

ok

[bgr]

On VMS

VMS $ @sys$manager:tcpip$define_commands
VMS $ ssh_keygen -b 1024 -t dsa
VMS $ scp ID_DSA_1024_A.PUB user@linux:.ssh

On linux

linux $ ssh-keygen -i -f ID_DSA_1024_A.PUB >> authorized_keys
linux $ ssh-keygen -t dsa #-- generate key on linux
linux $ ssh-keygen -x -t dsa > user-linux.pub #-- convert to IETF SECSH format
linux $ sftp scp user@vms
sftp> cd ssh2
sftp> put user-linux.pub

On VMS

VMS $ edit [login.ssh2]authorization.;
KEY user-linux.pub
VMS $ edit [login.ssh2]identification.;
IdKey ID_DSA_1024_A
VMS $ ssh_agent
VMS $ ssh_add
VMS $ ssh user@linux

[Steven Schweda]

> Feb 18, 2010 12:23:32 GMT 0 pts

To get more satisfactory advice, you might
try providing more satisfactory information.