<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: SSH and performance in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219650#M56600</link>
    <description>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.</description>
    <pubDate>Wed, 25 Jun 2008 19:41:22 GMT</pubDate>
    <dc:creator>Michael Moroney</dc:creator>
    <dc:date>2008-06-25T19:41:22Z</dc:date>
    <item>
      <title>SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219646#M56596</link>
      <description>Question:&lt;BR /&gt;&lt;BR /&gt;We are now using telnet to connect our users to the OpenVMS nodes. A change will be made to use SSH.&lt;BR /&gt;&lt;BR /&gt;Anyone who knows what the impact is on resource usage. We have over 1000 users.&lt;BR /&gt;&lt;BR /&gt;If have searched the internet but this is very hard to find.&lt;BR /&gt;&lt;BR /&gt;Greetings,&lt;BR /&gt;&lt;BR /&gt;Piet</description>
      <pubDate>Fri, 20 Jun 2008 07:56:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219646#M56596</guid>
      <dc:creator>Piet Timmers_1</dc:creator>
      <dc:date>2008-06-20T07:56:35Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219647#M56597</link>
      <description>It appears to me that you get two processes per user login using ssh and only one per user using telnet.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 20 Jun 2008 08:23:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219647#M56597</guid>
      <dc:creator>Ian Miller.</dc:creator>
      <dc:date>2008-06-20T08:23:30Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219648#M56598</link>
      <description>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).&lt;BR /&gt;&lt;BR /&gt;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.</description>
      <pubDate>Fri, 20 Jun 2008 17:23:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219648#M56598</guid>
      <dc:creator>EdgarZamora_1</dc:creator>
      <dc:date>2008-06-20T17:23:53Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219649#M56599</link>
      <description>I assume you mean that all 1000 users are going to SSH into your VMS system, which will need to run an SSH server.&lt;BR /&gt;&lt;BR /&gt;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).&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;Jeremy Begg</description>
      <pubDate>Mon, 23 Jun 2008 02:02:50 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219649#M56599</guid>
      <dc:creator>Jeremy Begg</dc:creator>
      <dc:date>2008-06-23T02:02:50Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219650#M56600</link>
      <description>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.</description>
      <pubDate>Wed, 25 Jun 2008 19:41:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219650#M56600</guid>
      <dc:creator>Michael Moroney</dc:creator>
      <dc:date>2008-06-25T19:41:22Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219651#M56601</link>
      <description>&lt;!--!*#--&gt;&amp;gt; There is an SSH maximum settings parameter&lt;BR /&gt;&amp;gt; that limits SSH sessions. I forget its&lt;BR /&gt;&amp;gt; name.&lt;BR /&gt;&lt;BR /&gt;I use the TCPIP service limit:&lt;BR /&gt;&lt;BR /&gt;ALP $ tcpip show service /full ssh&lt;BR /&gt;&lt;BR /&gt;Service: SSH&lt;BR /&gt;                           State:     Enabled&lt;BR /&gt;Port:               22     Protocol:  TCP             Address:  0.0.0.0&lt;BR /&gt;Inactivity:          5     User_name: TCPIP$SSH       Process:  TCPIP$SSH&lt;BR /&gt;Limit:              64     Active:        0           Peak:        64&lt;BR /&gt;[...]&lt;BR /&gt;&lt;BR /&gt;The SSH attacks on my system always end like&lt;BR /&gt;this one:&lt;BR /&gt;&lt;BR /&gt;%%%%%%%%%%%  OPCOM  25-JUN-2008 08:56:05.89  %%%%%%%%%%%&lt;BR /&gt;Message from user INTERnet on ALP&lt;BR /&gt;INTERnet ACP SSH Reject Request - service limit - from Host: 220.92.203.126 Port&lt;BR /&gt;: 33015&lt;BR /&gt;&lt;BR /&gt;Of course, if you have more (than roughly&lt;BR /&gt;zero) real users, you may need to think a bit&lt;BR /&gt;harder about the best limit value.&lt;BR /&gt;&lt;BR /&gt;The usual attack program seems to give up at&lt;BR /&gt;the first rejection, and the dead processes&lt;BR /&gt;die off in a little while, so any service&lt;BR /&gt;denial is usually fairly short.</description>
      <pubDate>Wed, 25 Jun 2008 21:11:58 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219651#M56601</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2008-06-25T21:11:58Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219652#M56602</link>
      <description>Also consider :&lt;BR /&gt;&lt;BR /&gt;1) ucx show dev will show 2 connections. So you could run into the maximum bg device limit (also channelnt ?).&lt;BR /&gt;&lt;BR /&gt;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).&lt;BR /&gt;&lt;BR /&gt;3) 1 user doing type *.log.* caused cpu rate of 4% for encryption only (GS160 with multinet).&lt;BR /&gt;&lt;BR /&gt;4) Any X clients not supporting encryption ? Then use putty.&lt;BR /&gt;&lt;BR /&gt;Wim&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 30 Jun 2008 13:24:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219652#M56602</guid>
      <dc:creator>Wim Van den Wyngaert</dc:creator>
      <dc:date>2008-06-30T13:24:46Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219653#M56603</link>
      <description>RE:"3) 1 user doing type *.log.* caused cpu rate of 4% for encryption only (GS160 with multinet)."&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Jon</description>
      <pubDate>Mon, 30 Jun 2008 18:58:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219653#M56603</guid>
      <dc:creator>Jon Pinkley</dc:creator>
      <dc:date>2008-06-30T18:58:25Z</dc:date>
    </item>
    <item>
      <title>Re: SSH and performance</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219654#M56604</link>
      <description>Was an X terminal that did a ssh to a GS160. Network 10 Mbit FD. Our stations are too old to have 100 Mbit.&lt;BR /&gt;&lt;BR /&gt;And we have several times a year someone running a program with "debugging messages" that have about the same effect.&lt;BR /&gt;&lt;BR /&gt;Wim</description>
      <pubDate>Tue, 01 Jul 2008 07:09:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/ssh-and-performance/m-p/4219654#M56604</guid>
      <dc:creator>Wim Van den Wyngaert</dc:creator>
      <dc:date>2008-07-01T07:09:34Z</dc:date>
    </item>
  </channel>
</rss>

