Discussion:
Multinet v5 ssh login failure
(too old to reply)
Dan Foster
2004-09-02 06:55:25 UTC
Permalink
I'm seeing a behavior that I don't quite understand with Multinet v5.0
on an OpenVMS/Alpha 7.3-1 system.

I can't call this one in to support, and it isn't really that critical
since things work. :) So it's just more of a curiosity, really.

If I do a ssh v2 login to SYSTEM on my VMS box, dubhe... it says there's
a login failure since last login and at the same time, the following
OPCOM message appears on OPA0:

%%%%%%%%%%% OPCOM 1-SEP-2004 23:38:47.52 %%%%%%%%%%%
Message from user AUDIT$SERVER on DUBHE
Security alarm (SECURITY) and security audit (SECURITY) on DUBHE, system id: 1025
Auditable event: Network login failure
Event time: 1-SEP-2004 23:38:47.52
PID: 0000021A
Process name: SSHD 0000
Username: system
Remote nodename: <a remote IP address>
Remote node id: <a remote node ID>
Remote username: SSH:SYSTEM
Status: %LOGIN-F-USERAUTH, error accessing authorization record

Yet I don't see either message when I do a ssh v1 login.

I'm not sure I understand what exactly is special about ssh v2 vs v1 for
%LOGIN-F-USERAUTH such that ssh v1 logins don't trigger this? Is it
something to do with password lifetime/expiration checks?

Is there a way to pin down what exactly ssh v2 is trying to do with
respect to the user authentication information?

I know it's trying to access a record, but it's not clear which record
nor why the access attempt failed.

Of note: the system is freshly installed, and right now, the only
modifications to it are:

a) It has five key 7.3-1 ECOs applied (and rebooted after each)
Latest version of each ECO: RMS, UPDATE, PCSI, XFC, LAN.

b) Multinet 5.0 is the only third party layered product installed.
No add'l LPs has been installed for the base system, either.

c) No modifications has been made to the base install other than
for starting Multinet, DECnet, and SYS$BATCH... defining key
systemwide logicals (eg SYSUAF), as well as adding a single
user account.

d) No DECwindows running, and system has already been AUTOGEN'd
for proper Multinet operation.

-Dan
Dan O'Reilly
2004-09-02 12:39:44 UTC
Permalink
If you're using the standard "vanilla" template for SSH2_CONFIG and
SSHD2_CONFIG, then what's going on is that there are likely authentication
methods being tried for which your system and/or user isn't correctly
configured. The default methodologies are to try publickey first, then
password. If the publickey mechanism hasn't been correctly configured,
then you'll see a login failure because of that.

You have a few options:

1. Correctly configure publickey (there's an example in the MN books).
2. Add the "StrictIntrusionLogging No" line to SSH2_DIR:SSHD2_CONFIG.
3. Modify the AllowedAuthentications keyword to allow only the
authentication methods you want.
Post by Dan Foster
I'm seeing a behavior that I don't quite understand with Multinet v5.0
on an OpenVMS/Alpha 7.3-1 system.
I can't call this one in to support, and it isn't really that critical
since things work. :) So it's just more of a curiosity, really.
If I do a ssh v2 login to SYSTEM on my VMS box, dubhe... it says there's
a login failure since last login and at the same time, the following
%%%%%%%%%%% OPCOM 1-SEP-2004 23:38:47.52 %%%%%%%%%%%
Message from user AUDIT$SERVER on DUBHE
Security alarm (SECURITY) and security audit (SECURITY) on DUBHE, system
id: 1025
Auditable event: Network login failure
Event time: 1-SEP-2004 23:38:47.52
PID: 0000021A
Process name: SSHD 0000
Username: system
Remote nodename: <a remote IP address>
Remote node id: <a remote node ID>
Remote username: SSH:SYSTEM
Status: %LOGIN-F-USERAUTH, error accessing authorization
record
Yet I don't see either message when I do a ssh v1 login.
I'm not sure I understand what exactly is special about ssh v2 vs v1 for
%LOGIN-F-USERAUTH such that ssh v1 logins don't trigger this? Is it
something to do with password lifetime/expiration checks?
Is there a way to pin down what exactly ssh v2 is trying to do with
respect to the user authentication information?
I know it's trying to access a record, but it's not clear which record
nor why the access attempt failed.
Of note: the system is freshly installed, and right now, the only
a) It has five key 7.3-1 ECOs applied (and rebooted after each)
Latest version of each ECO: RMS, UPDATE, PCSI, XFC, LAN.
b) Multinet 5.0 is the only third party layered product installed.
No add'l LPs has been installed for the base system, either.
c) No modifications has been made to the base install other than
for starting Multinet, DECnet, and SYS$BATCH... defining key
systemwide logicals (eg SYSUAF), as well as adding a single
user account.
d) No DECwindows running, and system has already been AUTOGEN'd
for proper Multinet operation.
-Dan
------
+-------------------------------+----------------------------------------+
| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |
+-------------------------------+----------------------------------------+
Dan Foster
2004-09-02 15:13:44 UTC
Permalink
Post by Dan O'Reilly
If you're using the standard "vanilla" template for SSH2_CONFIG and
SSHD2_CONFIG, then what's going on is that there are likely authentication
methods being tried for which your system and/or user isn't correctly
configured. The default methodologies are to try publickey first, then
password. If the publickey mechanism hasn't been correctly configured,
then you'll see a login failure because of that.
Ahhh! That was indeed it; thanks! (Works great now.)

-Dan

Loading...