topic Re: S/KEY sequence? in Operating System - OpenVMS

S/KEY sequence?

Barry Hamill — Wed, 27 Sep 2006 16:01:52 GMT

Moving a MicroVax 3100 to a new location and had to change the IP address to from 10.0.2.1 to 10.0.1.1 - now, if I try to telnet to it from the other LAN (10.0.2.0), i see:

S/KEY sequence not found
User authorization failure

right after I enter my user name but before I can enter a password, and then the session is disconnected. I'm guessing this is something like I have to tell it what networks to trust, but I don't know how to do so. Any help appreciated.

yrs., BH

Re: S/KEY sequence?

Steven Schweda — Wed, 27 Sep 2006 16:33:41 GMT

It might help to know which IP package
you're using. Google suggests that it may be
MultiNet, as that one seems to offer some
S/Key stuff (about which I know nothing). If
so, it might pay to pore over the MultiNet
Administrator's Reference manual, and/or look
for MultiNet-specific support channels.

Re: S/KEY sequence?

Jim_McKinney — Thu, 28 Sep 2006 07:46:26 GMT

My guess... MultiNet; and that you've got the ACCESS service enabled. If so, the cure (presuming that you really don't want this service enabled and that you can log in via the console) would be to

$ mu conf/serv
SERVER-CONFIG> disable access
SERVER-CONFIG> exit
$ subm/user=system/nolog multinet:start_server

Re: S/KEY sequence?

Barry Hamill — Thu, 28 Sep 2006 09:46:20 GMT

Thanks to both of you for the quick response.

Yes, it's Multinet. Sorry, I should have mentioned that. I have a lot more experience with Unix, Cisco, Adtran, etc., and don't always know what info is relevant with OpenVMS.

I can log in via console, and from anywhere on the same network as the MicroVax. If I disable the service, won't I only be able to log in from the console?

Re: S/KEY sequence?

Jim_McKinney — Thu, 28 Sep 2006 10:34:52 GMT

The ACCESS service is your secure-key interface. Disabling that service will just suppress the S/KEY challenge during login. It's been a while since I've dealt with this but I think that in addition to disabling the service you'll need to either delete or rename MULTINET:START_ACCESS.COM so that it isn't executed automaticly by MULTINET:START_MULTINET.COM during system startup. (MULTINET:START_ACCESS.COM is created when you configure the ACCESS service - if you're not using S/KEY you don't need it.)

Re: S/KEY sequence?

Barry Hamill — Fri, 29 Sep 2006 12:40:34 GMT

Well, I tried that, and this happened:

Username: [me]
Error opening connection to Secure/IP authentication server
User authorization failure
Username:

So, now I'm looking for a Secure/IP manual. At least I've still got console and LAT access.

BH

Re: S/KEY sequence?

Jim_McKinney — Fri, 29 Sep 2006 13:21:09 GMT

It's been quite a while since I've explored this - so I'm guessing as I don't have system where I can experiment right now. I presume that you haven't rebooted?? If you have then ignore the following.

I suspect that the implemtation of this service may involve a dedicated server process. If that was the case then restarting the master server would not impact it. You should examine the output of SHOW SYSTEM and see if there is something called ACCESS_SERVER or similar. If so you'll need to terminate it - there may also be associated system logical names that need deassigning. If this is the case you might find it simplest to reboot (unless you can find the correct "MU NETC ACCESS SHUT" or whatever incantations to politely shut it down). With the service disabled and the startup file renamed or deleted a reboot should put you back in the state you desire. Sorry I can't be definitive here... without actually observing what you've got my memory isn't good enough.

Re: S/KEY sequence?

Steven Schweda — Fri, 29 Sep 2006 19:31:09 GMT

> So, now I'm looking for a Secure/IP manual.

Google led me to:

http://www.process.com/tcpip/mndocs/MN%20v5.0%20Admin%20Reference/Pref.htm
http://www.process.com/tcpip/mndocs/MN%20v5.0%20Admin%20Reference/httoc.htm
http://www.process.com/tcpip/mndocs/MN%20v5.0%20Admin%20Reference/Ch02.htm
http://www.process.com/tcpip/mndocs/MN%20v5.0%20Admin%20Reference/Ch08.htm

Of course, I don't know your MultiNet version,
so this may be the wrong manual for you, but I
assume that there's more to be found at
process.com.

Re: S/KEY sequence?

Jim_McKinney — Sat, 30 Sep 2006 19:02:39 GMT

It also strikes me that this is likely implemented via the LGI_CALLOUTS LOGINOUT hook. If you haven't rebooted you might check the sysgen parameter LGI_CALLOUTS. If its value is 1 then you might see if there is an LGI$LOGINOUT_CALLOUTS logical name - that would be the executable that is invoked during login.

If you find that there is a hook defined for MultiNet's ACCESS service then you can disable it on the fly by

$ mcr sysgen
SYSGEN> set LGI_CALLOUTS 0
SYSGEN> write active
SYSGEN> exit

Re: S/KEY sequence?

Richard Whalen — Mon, 02 Oct 2006 09:00:25 GMT

The MULTINET:START_ACCESS.COM file may define a number of logicals (/system/executive):
MULTINET_ACCESS_CLIENT_ONLY
MULTINET_ACCESS_SERVER_ADDRESS
MULTINET_ACCESS_SERVER_PORT
MULTINET_ACCESS_LOCAL_DEVICES
MULTINET_LOGIN
MULTINET_ACCESS_NETWORK_LOGIN
MULTINET_ACCESS_MUTUAL_AUTHENTICATION
MULTINET_ACCESS_FTP
MULTINET_ACCESS_ALLOW_DECNET_LOGIN
MULTINET_ACCESS_ALLOW_DECTERM_LOGIN
MULTINET_ACCESS_TICKET_LIFETIME
MULTINET_ACCESS_ALLOW_SHOW_KEY
MULTINET_ACCESS_CALLOUTS_DEBUG
MULTINET_ACCESS_KERBEROS_PRINCIPAL
LGI$LOGINOUT_CALLOUTS
MULTINET_LGISHR

As mentioned above, the sysgen parameter lgi_callouts can be set.

From the problem description so far, I would guess that the access server is no longer reachable. The system could have been set up to function as its own access server.
$ MULTINET CONFIGURE/ACCESS
ACCESS-CONFIG>show server-address
If that shows your old IP address, then you can change it to the new address (or 127.0.0.1) and follow the instructions on restarting the access server.

Re: S/KEY sequence?

Barry Hamill — Wed, 04 Oct 2006 14:59:22 GMT

Thanks again for the many responses.

Several people assumed wrongly that I hadn't rebooted, so I didn't try those suggestions. LGI_CALLOUTS (whatever that is) says current=1, default=0. If I'm feeling lucky, I may try that suggestion.

Multinet configure /access ; show server-access replies "?Not confirmed." That can't be good. I tried setting that to 127.0.0.1, but still got the "S/KEY sequence not found" thing. Grrr.

I changed the default-method to plaintext-passwords, and for obvious reasons, the s/key thing went away. I'm debating now how much more time to spend on this - any system is hackable, but this one is pretty invisible to the world beyond my WAN; no one is going to log into it except from behind my firewall or connected via VPN. Anyone got any strong feelings about plaintext passwords?