North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical


  • From: Steven M. Bellovin
  • Date: Fri Apr 28 23:02:14 2000

In message <[email protected]>, Chris Cappuccio 
>On Fri, 28 Apr 2000, Mr. James W. Laferriere wrote:
> | 
> | 
> | 	Hello Dylan,  Knew this was coming .  But I'd hoped that 
> | 	the supported platforms would have been a little larger .
> | 	Just the 7200 & UP .  Seems cisco thinks ssh puts a bit
> | 	of load on a cpu ?  I can't see that for just a terminal
> | 	session though .  Twyl,  JimL
> | 
>The ssh server should optimally generate new keys every so often (every few

Disable that feature; you probably don't need it in this situation.

Here's what's going on.  Stock sshd generates a new, relatively
short, RSA key pair once an hour.  This key is used to exchange
the session key that actually protects the data.  Your normal
public/private key pair (the stuff that's in your identity and files) is used to authenticate the exchange, rather
than to transmit the session key.

Why that whole song and dance?  The idea is to approximate a
cryptographic property known as "perfect forward secrecy".  Perfect
forward secrecy says that if, some time in the future, your machine
is compromised, the enemy can't read past traffic.  In this case,
since that RSA key pair is discard hourly, and that is the only
key that can decrypt the session key, our old traffic is protected.
It's only readable if the machine is penetrated while that key is

Now -- in this case, the generator of that key is the router itself.
If the bad guys have enough control of the router to pry out a
private RSA key -- a key for which there is no conceivable need
for any API or CLI way to read -- those same bad guys can pry anything
else they want out of the router, including its enable password.  They can
also change the configuration to make it possible to log back in without
going through complicated shenanigans.  The real purpose of that feature
of sshd is to protect access to a multiuser system, where there's much
more risk of compromise, and where more general secrets might be protected
by the connection.

As for the expense of ssh -- the big issue is login, when a lot of public
key operations are taking place.  But even output is rather expensive,
since it's doing a 3DES operation for each eight output bytes.  Worse
yet, if the output is passed to the sshd piece a byte at a time, it will
do a 3DES operation for each byte.  That almost certainly happens for
each keystroke, but most people don't type enough or fast enough for that
to be an issue.