SSH and performance

[Piet Timmers_1]

Question:

We are now using telnet to connect our users to the OpenVMS nodes. A change will be made to use SSH.

Anyone who knows what the impact is on resource usage. We have over 1000 users.

If have searched the internet but this is very hard to find.

Greetings,

Piet

[Ian Miller.]

It appears to me that you get two processes per user login using ssh and only one per user using telnet.

[EdgarZamora_1]

I didn't see any significant impact to system resources except for my console getting flooded with opcom breakin messages and the thousands and thousands of SSH log files being generated during brute force password guessing attacks on the SSH ports (which happened quite often, mostly coming from China).

And yes, I am aware of steps I can take to alleviate these, but there are politics and red tape and other businesses/groups involved, etc, etc. things don't get easily done.

[Jeremy Begg · Accepted solution]

I assume you mean that all 1000 users are going to SSH into your VMS system, which will need to run an SSH server.

In that environment, each login takes up two process slots: one to do the SSH protocol stuff (including encryption) and one for the actual user session. So at the very least you're going to consume around twice as many process slots as you have now, and some extra RAM (around 200-800 pages per session).

In addition, CPU usage will increase because each SSH session must encrypt outgoing traffic (screen updates) and decrypt incoming traffic (keystrokes). How much additional load this is will depend on how active your users are.

Regards,
Jeremy Begg

[Michael Moroney]

A word of caution: I've seen some of the SSH brute force breakin attempts lock up a VMS system by creating maxprocesscnt processes and/or consuming all available memory. There is an SSH maximum settings parameter that limits SSH sessions. I forget its name.

[Steven Schweda]

> There is an SSH maximum settings parameter
> that limits SSH sessions. I forget its
> name.

I use the TCPIP service limit:

ALP $ tcpip show service /full ssh

Service: SSH
State: Enabled
Port: 22 Protocol: TCP Address: 0.0.0.0
Inactivity: 5 User_name: TCPIP$SSH Process: TCPIP$SSH
Limit: 64 Active: 0 Peak: 64
[...]

The SSH attacks on my system always end like
this one:

%%%%%%%%%%% OPCOM 25-JUN-2008 08:56:05.89 %%%%%%%%%%%
Message from user INTERnet on ALP
INTERnet ACP SSH Reject Request - service limit - from Host: 220.92.203.126 Port
: 33015

Of course, if you have more (than roughly
zero) real users, you may need to think a bit
harder about the best limit value.

The usual attack program seems to give up at
the first rejection, and the dead processes
die off in a little while, so any service
denial is usually fairly short.

[Wim Van den Wyngaert]

Also consider :

1) ucx show dev will show 2 connections. So you could run into the maximum bg device limit (also channelnt ?).

2) if users must copy big files (e.g. db dumps) using ssh this will give a heavy load because of the encryption. Consider lowering the encryption number of bits (I didn't test the impact but in zipiing large files it had serious impact lowering /level).

3) 1 user doing type *.log.* caused cpu rate of 4% for encryption only (GS160 with multinet).

4) Any X clients not supporting encryption ? Then use putty.

Wim

[Jon Pinkley]

RE:"3) 1 user doing type *.log.* caused cpu rate of 4% for encryption only (GS160 with multinet)."

What was the effective "baud rate" of this "terminal". If it was on a 9600 bps connetion, then that would be significant. But if on a telnet session from a PC terminal emulator, the encryption data rate would be more significant.

The point being that the type command will normally be i/o bound by the output device, and therefore the speed of the output device will have a large effect on the resources used by SSH encryption.

Jon

[Wim Van den Wyngaert]

Was an X terminal that did a ssh to a GS160. Network 10 Mbit FD. Our stations are too old to have 100 Mbit.

And we have several times a year someone running a program with "debugging messages" that have about the same effect.

Wim