Do really long SSH sessions become insecure?

[Syldorian]

I hope this isn't a dumb question, but it's been bugging me a little bit. From what I understand, SSH uses public-key cryptography to pass a session key for each session, which is used to encrypt the traffic from then on. But wouldn't this become insecure as more and more traffic is passed back and forth, as more ciphertext becomes available? Or does SSH periodically switch to new keys?

I guess I'm mainly asking this because I just discovered shfs, and I'm trying to decide if I need to remount periodically or if SSH will take care of this for me.

Thanks for any replies.
_________________
My photography website: http://www.kratzweb.net

[suso]

Honestly, SSH is not completely secure to begin with. In the sense that given enough computing power, it can be cracked. In the long term, using the same number of key bits will result in insecurity of SSH. But we're talking years as far as that goes.

You're probably concerned more with the short term, like keeping a session open for a week or month. So to answer your question, yes, the keys of the session are regenerated according to this value set in /etc/ssh/sshd_config:

[Syldorian]

Thanks for the reply, suso. And, yes, I realize that SSH can't ever be completely secure. I just want to make sure I"m not doing anything dumb. I seriously doubt anyone's looking at my uber-super-secret traffic, but it's nice knowing that someone can't snoop around incredibly easily.

I'm glad the keys are regenerated periodically, though. I was going to be surprised if something that obvious had been overlooked, but I wanted to make sure. Your help is much appreciated.
_________________
My photography website: http://www.kratzweb.net

[infiniteedge]

i believe that the use of AES 256-bit keys nullifies for the most part any "insecurity" presented by large amounts of traffic going across the line...

The insecurity of SSH comes from key management NOT from its use of session keys. Do you have any idea how long it takes to crack a 256-bit symmetric key? Do you!?

[mirko_3]

Hmmm... I read this on "man sshd_config":

KeyRegenerationInterval
In protocol version 1, the ephemeral server key is automatically
regenerated after this many seconds (if it has been used). The
purpose of regeneration is to prevent decrypting captured ses-
sions by later breaking into the machine and stealing the keys.
The key is never stored anywhere. If the value is 0, the key is
never regenerated. The default is 3600 (seconds).
[/quote]

Note, "in protocol version 1"... why, doesn't this happen with v2?
_________________
Non fa male! Non fa male!

[kashani]

From comp.security.ssh:

"An SSH1 server's ephemeral key is used by that server for _all_ SSH1
connections over a period of about an hour, and then changed. But
within a single session, the session key exchanged using the
ephemeral and permanent RSA keys is constant for the whole session.
There is no `re-negotiation' as such.

In SSH2, the Diffie-Hellman private values are made up fresh in
_every_ SSH2 connection. So it's already better than SSH1 in this
regard. However, there is also a regular key re-negotiation phase
_within_ a long-lasting SSH2 connection, in which a fresh set of
Diffie-Hellman values are generated, the key exchange is repeated
from scratch, and the session key is changed within the same
connection."

And from OpenSSH Portable's ChangeLog 20030401
[snip]
rekeying bugfixes and automatic rekeying:
* both client and server rekey _automatically_
(a) after 2^31 packets, because after 2^32 packets
the sequence number for packets wraps
(b) after 2^(blocksize_in_bits/4) blocks
(see: draft-ietf-secsh-newmodes-00.txt)
(a) and (b) are _enabled_ by default, and only disabled for known
openssh versions, that don't support rekeying properly.
* client option 'RekeyLimit'

kashani
_________________
Will personally fix your server in exchange for motorcycle related shop tools in good shape.