S/KEY sequence?

[Barry Hamill]

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

[Steven Schweda]

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.

[Jim_McKinney]

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

[Barry Hamill]

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?

[Jim_McKinney]

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.)

[Barry Hamill]

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

[Jim_McKinney]

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.

[Steven Schweda]

> 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.

[Jim_McKinney]

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

[Richard Whalen]

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.