On Thu, Jul 29, 2004 at 05:23:12PM +0100, Christian Smith wrote:
> Stick to SSHv2. Performance of my IPX sucks when exchanging keys at ssh
> session startup, but once thats done, I don't notice any performance
> problems even when using port rediraction for X.

Most differences between SSHv1 and SSHv2 protocols are in the initial
handshake; the asymmetric cryptographic algorithms used in SSHv2 provide
better theoretical security (in an academic sense, not really in
practice) but use more cpu. Once the session has been established, data
transfers boil down to the usual symmetric encryption and MAC; SSHv1 and
SSHv2 (and SSL also, for that matter) are quite similar in that respect.

What may have an impact on performance is the choice of the algorithm.
3DES is quite slow when implemented in software (it is optimised
for hardware implementations) and this can be a bottleneck for high
bandwidth transfers (e.g., scp over ethernet -- the bottleneck can even
be demonstrated with 1 GHz PCs over 100baseT links). If possible, try to
use a faster algorithm, such as AES (aka Rijndael) or Blowfish. But this
really does not matter for interactive login sessions, even on very slow
machines, because such session do not use more than a few kilobytes per
second of bandwidth at most (when scrolling).



Most usages of SSH can be replaced with a VPN without loss of security.
It so happens that when connecting from a client machine to a server
machine, you actually trust both machines to be free from root-class
compromise (if root is a bad guy, the ssh or sshd binaries can be
bugged and leak information or modify data). What you get is a simple
point-to-point secure tunnel.

A correct VPN can be established with IPsec; that's what I do between
my home server/gateway and my office gateway. Those two machines
maintain an ESP tunnel with a shared secret key stored in both machines
(the secret key has been chosen randomly and transfered within an SSH
session). Thus, I can establish direct connections between my office
machines and my home machines with simple insecure protocols such as RSH
or FTP. Session establishment is then very fast. Bandwidth is good also,
because encryption and decryption is performed directly in the kernel,
without any roundtrip to userland (not that it matters much actually,
since my home external connection is a 512/128 Kbits ADSL link).

I nonetheless maintain active SSH servers so that I can contact my
machines from just any random connected machine.


	--Thomas Pornin