SSH performance, CPU speed...

  I've had trouble getting conserver to open 32 SSH sessions
to individual ports on a Cyclades ACS-32. SSH does take a
lot of resource on both devices, and (if you plan to keep
those sessions active for long periods) can require a lot
of RAM (especially if you tickle a memory leak, since the
sessions aren't closing, and relinquishing memory).

  Cary Roberts (at TellMe) as thought about this, and he's
tried talking to vendors about the idea, but so far the
vendors aren't keen on the idea. The idea is, that the
console servers (CS) should accept SSL or SSH tunnels,
and the idea plays out like this;

  The conserver host would open a single SSH session to
  CS #1, and then tunnel certain ports (say 10001-10032)
  to CS #1 (to ports 7001-7032, for this example).

  The conserver would open a second SSH session to CS #2,
  and tunnel ports 10033-10064 to CS #2 ports 7001-7032...

  Now, conserver would look for all of these ports, and use
  one tunnel per CS to encrypt all the sessions for each CS,
  instead of needing to have [24|32|48] SSH sessions per CS.
  This would reduce loads on the CSs, as well as the conserver.

  I'm testing with fairly low-end hardware, because I don't
need to stress-load the CSs that I'm testing. In my real-world
test, the conserver was also the mail host, syslog host, and
a busy apache server, plus a few other tasks. The CSs were
having some trouble, but the host was also slow trying to open
all of those sessions. It was ugly, and we quickly wired a
small management net to connect 4 CSs to 3 hosts, with a small
8-port switch. This keeps the in-the-clear sessions from
the curious and/or malicious, and reduced the SSH load on
the conserver (since users still need to SSH in to get to
the console client app ;-).

  My thought? More CPU in the CS is OK, but you may also
need more CPU on your conserver host (or whatever box is
going to originate all of those SSH sessions to the CSs).

     Best regards,

         -Z-