SSH Hostbased encryption

[Duncan Morris]

Andreas,

is there maybe an SHOSTS file on the server side?

On my test systems, I have set up hostbased authentication thus:

on the server (DEVT02)

DEVT02> ty sys$manager:shosts.
ISE216.CPWPLC.NET system
ISE216.CPWPLC.NET morrisd

DEVT02> ty sys$sysdevice:[tcpip$ssh.ssh2]shosts.equiv
ISE216.CPWPLC.NET

DEVT02> dir/sec sys$sysdevice:[tcpip$ssh.ssh2.knownhosts]

Directory SYS$SYSDEVICE:[TCPIP$SSH.SSH2.KNOWNHOSTS]

ISE216_CPWPLC_NET_SSH-DSS.PUB;1
[TCPIP$AUX,TCPIP$SSH] (RWED,RWED,RE,RE)

Within sshd2_config:

IgnoreRhosts no


This combination allows me log into SYSTEM on the server, from either SYSTEM or MORRISD on the client.


Duncan

[Steven Schweda]

I'm with them. In my SSH2_CONFIG file, I
already had:

[...]
AllowedAuthentications hostbased, publickey, password
[...]
IgnoreRhosts no
[...]

I created
SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SHOSTS.EQUIV,
and put the wrong (simple, unqualified) name
("it") into it, and got so far as:

alp $ type ALP$DKA0:[TCPIP$SSH]TCPIP$SSH_RUN.LOG;-1
[...]
Tue 20 14:17:55 INFORMATIONAL: connection from "10.0.0.16"
Tue 20 14:17:56 WARNING: Error trying to access file /sys$sysroot/sysmgr/ssh2/kn
ownhosts/it_antinode_info_ssh-dss.pub.
[...]

On the client side, "ssh -v" mentioned:

debug: SshUnixTcp/SSHUNIXTCP.C:1390: using local hostname it.antinode.info

so I figured that I should change "it" to the
fully qualified "it.antinode.info" in the
SHOSTS.EQUIV file.

I had already copied IT's (the client's)
SYS$SYSDEVICE:[TCPIP$SSH.SSH2]hostkey.pub,
and put it into the server's
SYS$SYSDEVICE:[TCPIP$SSH.SSH2.KNOWNHOSTS]
directory, but apparently someone's fussy
about the name. After I renamed that file to
what seemed to be sought,
IT_ANTINODE_INFO_SSH-DSS.PUB, things worked.
The server log said:

[...]
Tue 20 14:19:11 WARNING: Error trying to access file /sys$sysroot/sysmgr/ssh2/kn
ownhosts/it_antinode_info_ssh-dss.pub.
Tue 20 14:19:11 NOTICE: Hostbased authentication for user system accepted.
[...]

Which was not entirely pleasing, but the
"accepted" part was.

If anyone thinks that this stuff is well
documented, he's kidding himself.

("IT" seemed, at the time, like a good name
for my first Itanium system, and I've always
wanted to use "it's" as a possessive, but I
can see how it (or "it") might get
confusing.)

For the record, on the client ("it"):

IT $ tcpip show version

HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6 - ECO 2
on an HP zx2000 (1.50GHz/6.0MB) running OpenVMS V8.3-1H1

IT $ ssh "-V"
it$dka0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS (V
5.5) 3.2.0 on HP zx2000 (1.50GHz/6.0MB) - VMS V8.3-1H1

and on the server ("alp"):

alp $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2

alp $ ssh "-V"
alp$dka0:[sys0.syscommon.][sysexe]tcpip$ssh_ssh2.exe: SSH Secure Shell OpenVMS (
V5.5) 3.2.0 on COMPAQ Professional Workstation - VMS V7.3-2

[Andreas Aahman]

It works if I add sysuser to sys$manager:shosts.

Which ofcourse is a solution and I guess there's no other way to solve it. It would be best if we could solve it without havind to specify the users in the shosts. file.

Is it at all possible to solve this without using shosts.?

[Duncan Morris]

Andreas,

I suspect that this is simply how "hostbased" authentication was designed.

In general, I use publickey authentication internally, with a common public key for my personal account on several systems.

Duncan

[marsh_1]

hi,

putting in a user name is optional for hostbased authentication as stated in the documentation, reread the manual and double check you are not getting confused about TCPIP$SSH_DEVICE:[TCPIP$SSH]SHOSTS.EQUIV and SYS$LOGIN:SHOSTS.

HTH

[Andreas Aahman]

I cannot find in the manual as why it should not work.

But it's good enough. We can easily add users to the shosts file.

Thanx everyone for the help.

[Steven Schweda]

> [...] We can easily add users to the shosts
> file.

As I said/showed, you don't seem to need to
add _users_ to
"SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SHOSTS.EQUIV".
Adding the (fully-qualified) client host name
was all I needed. I assume that you _can_
add user names, too, but I didn't try that.
(I figured that the whole point of using
"hostbased" was _not_ to worry about
individual users. But what do I know?)

> Jan 20, 2009 20:49:05 GMT 0 pts

> Thanx everyone for the help.

Make up your mind?

[Andreas Aahman]

Adding the users to "SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SHOSTS.EQUIV".
did not solve it.
SSH still did not allow hostbased authentication.

However adding the users to sys$manager:shosts do solve my problem. It still does not take me all the way but it's a good enough solution.

br,
Andreas

[marsh_1]

hi,

what do/did you have in the shosts.equiv file ?

from the manual :-

2. Edit the systemwide trusted hosts file, TCPIP$SSH_DEVICE:[TCPIP$SSH]SHOSTS.EQUIV, to add the fully
qualified name of every SSH client host that will communicate with the server. You can also enter a
specific user name to limit access to that user. For example:
MYHOST.MYLAB.COM
or
MYHOST.MYLAB.COM smith
If the IgnoreRhosts parameter is set to no as in step 1, you can also add the client host and optional user
names to the file SYS$LOGIN:SHOSTS. for a specific user.
If user names are used, those associated with OpenVMS client hosts must be in lowercase; those
associated wih UNIX client hosts must match the account name case as it exists on the UNIX host.

[Andreas Aahman]

The shosts.equiv file contains the host that will connect to the servers.

If I add a username to the shosts.equiv file I still am not allowed to login as system on the remote system, if I'm not logged in as system on the client.

IgnoreRhosts is set to no and if I enter usernames in SYS$LOGIN:SHOSTS.
Everything if fine and dandy.

So to sum it up. If I do not add users in the sys$login:shosts file I cannot log on as system if I'm not logged on as system on the client side aswell.