SSH parameter UserLoginLimit does not seem to work

[Jan van den Boogaard_1]

Hello,

SSH parameter UserLoginLimit does not seem to work.
If I set UserloginLimit = 1 in the demon config, and reboot or restart, I still can login several times under 1 username.

still, the release notes of latest TCPIP ECOs (5.4 ECO7 and 5.6 ECO3) say in the list of solved problems:

13-Jun-2007

Problem:

The SSH server configuration parameter UserLoginLimit was ignored.

Deliverables:

All SSH images

Reference:

TCPIP_BUGS Note 3591

Anybody have an idea?

[Hoff · Accepted solution]

RIng up HP.

Looks like the parameter is still being ignored. (A wag might comment the release note didn't say it was "fixed".)

ssh is not particularly tied into the OpenVMS security and authentication mechanisms.

As a work-around, use the OpenVMS mechanisms or use some local tests in SYLOGIN.COM or LOGIN.COM.

[Don Nutt]

We had a requirement to shutdown all of Telnet to our server and implement SSH exclusively.

(2) ES40 Type 1 EV6 500Mhz 2GB
OpenVMS 7.3-2, TCPIP 5.4 ECO 7 (Currently)
Order/Entry Applicaion written in DEC BASIC (starting in about 1992 on VAX, I think parts were in COBOL but that was before my time here)

We have been using the MAXJOBS parameter in UAF to limit users to a single login by setting the value to 1. Our primary application is very simple and used for Order/Entry. This worked well for us and our application.

Utilizing SSH we ran into an issue. No one could logon. What we discovered is that during login authentication, 2 jobs were running during the login event itself for SSH and users were logged in and promptly logged out. We changed MAXJOBS to 2 or (n+1 where n is the number of logins we limit the bulk of the users to). Here is a snipit of SSH verbose output when MAXJOBS is set to 1.

debug: Ssh2Common/SSHCOMMON.C:372: Received SSH_CROSS_ALGORITHMS packet from co.
debug: Unable to open ssh2/identification
debug: Ssh2AuthClient/SSHAUTHC.C:348: Method 'publickey' disabled.
debug: Ssh2AuthPasswdClient/AUTHC-PASSWD.C:198: Starting password query...
uno4791's password:
debug: Ssh2Common/SSHCOMMON.C:290: Received SSH_CROSS_AUTHENTICATED packet from.
Authentication successful.
debug: Ssh2Common/SSHCOMMON.C:723: num_channels now 1
debug: DISPLAY not set; X11 forwarding disabled.

MAXJOB at n manifests here

debug: Ssh2ChannelSession/SSHCHSESSION.C:1912: received exit signal. signal num"
debug: Ssh2Common/SSHCOMMON.C:697: num_channels now 0
debug: Got session close with exit_status=0
debug: destroying client struct...
Connection to localhost closed.



The n+1 for MAXJOBS has worked well to keep our customers happy and has kept the audit teams happy as well.

For those users that require a greater value in MAXJOBS for reporting, mutiple logins, etc. we haven't had any problems using n+1 and they are the exception here.

PS: We have about 3000 users on this server of which 150-350 will be logged in simultaneously daily.


Don Nutt
Sprint

[Jan van den Boogaard_1]

Hello Don,

Many thanks for sharing your experience with the forum community! For our sites it might be an alternative way to use MAXJOBS (with care).

Jan

[Richard W Hunt]

We looked into this approach some time ago. Our problem was a popular bit of software with a limited number of license credits, and we didn't want someone logging in ten times to run ten copies of this particular tool. If the users were of a particular login type, they would always consume some credits whether they used it or not, and the cost of boosting the license was, at the time, deemed unacceptable. (Meaning nobody wanted to pay for it...)

We found that the best way to limit those users, though also possibly the clunkiest, was to have a little code snippet in SYLOGIN.COM that looks up the user name to see if that user was in the class that had the restrictions. If so, perform a

$ SHOW USER username/OUT=a-temporary-file

Then read the output to see how many jobs the user had (counting this one, of course). You can tell how many interactive, batch, and other jobs this user has in one line. Then apply your restriction rules.

Our system is smaller in user count than yours, so for us it wasn't such a long test to perform. If you do it right, it is almost invisible.

[Jan van den Boogaard_1]

UserLoginLimit DOES work. When TCPIP V5.6 ECO3 or V5.4 ECO7 is installed. The username SYSTEM is an EXCEPTION !! Which makes sense.
In case of other usernames, as soon as you hit the limit, VMS says "access denied", but doesnt say why. Which also makes sense.

Case closed.