Tru64 SSH to Tectia SSH

[hkyeakley]

The client:
Tru64 5.1B Patch Kit 6 running
# ssh -V
ssh: SSH Secure Shell Tru64 UNIX 3.2.0

The Server:
uname -a
Linux 2.6.9-67.0.4.ELsmp #1 SMP Fri Jan 18 05:00:00 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
running
# /opt/tectia/sbin/ssh-server-g3 -V
ssh-server-g3: SSH Tectia Server 5.3.7 on x86_64-unknown-linux-gnu
Build: 21
Product: SSH Tectia Server (with EFT)
License type: commercial


I'm trying to setup the Tru64 box to connect via Public Key to the Linux system.

On Tru64, I generated my key pair thusly:
# ssh-keygen -t dsa

Then I copied my .pub file to the .ssh2 directory on the Linux machine.

Finally, I created an identification file:
# echo "IdKey id_dsa_2048_a" >> ~/.ssh2/identification

Then on the Linux box, I created an authorized_keys in my .ssh2 directory and moved my .pub file into that directory. I then created a file called "authorization" and added the line:
$ cat authorization
Id authorized_keys/id_dsa_2048_a.pub

All files are owned by the correct non root user that I'm trying to set this up for. When I go to connect from my Tru64 host to the Linux host, I get the following:

$ssh -vv
debug: Connecting to , port 22... (SOCKS not used)
debug: Ssh2/ssh2.c:2332: Entering event loop.
debug: Ssh2Client/sshclient.c:1452: Creating transport protocol.
debug: SshAuthMethodClient/sshauthmethodc.c:95: Added "publickey" to usable methods.
debug: SshAuthMethodClient/sshauthmethodc.c:95: Added "password" to usable methods.
debug: Ssh2Client/sshclient.c:1493: Creating userauth protocol.
debug: client supports 2 auth methods: 'publickey,password'
debug: SshUnixTcp/sshunixtcp.c:1231: using local hostname
debug: Ssh2Common/sshcommon.c:541: local ip = 172.25.28.102, local port = 2989
debug: Ssh2Common/sshcommon.c:543: remote ip = 162.58.85.19, remote port = 22
debug: SshConnection/sshconn.c:1957: Wrapping...
debug: SshReadLine/sshreadline.c:3388: Initializing ReadLine...
debug: Remote version: SSH-2.0-5.3.7.21 SSH Tectia Server
debug: Major: 5 Minor: 3 Revision: 7
debug: Ssh2Transport/trcommon.c:1913: lang s to c: `', lang c to s: `'
debug: Ssh2Transport/trcommon.c:1978: c_to_s: cipher aes128-cbc, mac hmac-sha1, compression zlib
debug: Ssh2Transport/trcommon.c:1981: s_to_c: cipher aes128-cbc, mac hmac-sha1, compression zlib
debug: Remote host key found from database.
debug: Ssh2Common/sshcommon.c:342: Received SSH_CROSS_STARTUP packet from connection protocol.
debug: Ssh2Common/sshcommon.c:392: Received SSH_CROSS_ALGORITHMS packet from connection protocol.
debug: server offers auth methods 'gssapi-with-mic,password,publickey,keyboard-interactive'.
debug: Ssh2AuthPubKeyClient/authc-pubkey.c:1602: adding keyfile "/devr002/app/appidevr/.ssh2/id_dsa_2048_a" to candidates
debug: server offers auth methods 'gssapi-with-mic,password,publickey,keyboard-interactive'.
debug: Ssh2AuthClient/sshauthc.c:330: Method 'publickey' disabled.
debug: server offers auth methods 'gssapi-with-mic,password,publickey,keyboard-interactive'.
debug: Ssh2AuthPasswdClient/authc-passwd.c:117: Starting password query...

... and then I'm prompted for my password. I'm not sure where I went wrong. To my knowledge, I am *NOT* running OpenSSH on either box. I'm running from one commercial implementation of SSH to another commercial implementation of ssh.

I would appreciate some insight.

Thank you.

[Steven Schweda]

> Then on the Linux box, [...]

And is this what you need to do with the
Tectia server?

> I am *NOT* running OpenSSH on either box.
> I'm running from one commercial
> implementation of SSH to another commercial
> implementation of ssh.

I don't think that "commercial" is a complete
description of an SSH implementation. I know
nothing, but it seems possible that the
Tectia code is more OpenSSH-compatible than
you seem to think.

I'd start by reading the Tectia
documentation, to see if it even looks in the
"~/.ssh2" directory, for example, and then
investigate key file formats. If nothing
else, generating a key pair on the Linux
system should show you what style of key
files it likes.

I'd also try to find the SSH and/or system
log file where some diagnostic messages may
have been left.

On which system is
"/devr002/app/appidevr/.ssh2/id_dsa_2048_a"?
Any sign anywhere that anyone is looking at
the key files on the Linux system?