I am trying to connect to my linux box via ssh from my windows machine using putty. I am able to connect to it successfully with sshd running on my linux box.

The problem which i am facing is that, the public key generated by sshd expires after a certain time period and the connection closes.

link|improve this question
1  
SSH public keys are not generated by sshd, they don't expire, and even if they did expire it would not result in a connection closure (as they are checked only when you first connect). What symptoms are you actually seeing, without any such conjecture? – bdonlan Dec 7 '11 at 6:46
feedback

migrated from stackoverflow.com Dec 10 '11 at 1:34

This question came from our site for professional and enthusiast programmers.

2 Answers

As far as I know SSH public keys do not expire.

Either side of the SSH connection can initiated a symmetric-key re-exchange. From RFC 4253:

9.  Key Re-Exchange

Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when
not already doing a key exchange (as described in Section 7.1).  When
this message is received, a party MUST respond with its own
SSH_MSG_KEXINIT message, except when the received SSH_MSG_KEXINIT
already was a reply.  Either party MAY initiate the re-exchange, but
roles MUST NOT be changed (i.e., the server remains the server, and
the client remains the client).

Key re-exchange is performed using whatever encryption was in effect
when the exchange was started.  Encryption, compression, and MAC
methods are not changed before a new SSH_MSG_NEWKEYS is sent after
the key exchange (as in the initial key exchange).  Re-exchange is
processed identically to the initial key exchange, except for the
session identifier that will remain unchanged.  It is permissible to
change some or all of the algorithms during the re-exchange.  Host
keys can also change.  All keys and initialization vectors are
recomputed after the exchange.  Compression and encryption contexts
are reset.

It is RECOMMENDED that the keys be changed after each gigabyte of
transmitted data or after each hour of connection time, whichever
comes sooner.  However, since the re-exchange is a public key
operation, it requires a fair amount of processing power and should
not be performed too often.

More application data may be sent after the SSH_MSG_NEWKEYS packet
has been sent; key exchange does not affect the protocols that lie
above the SSH transport layer.

As a result of the recommendation of key changes after every gigabyte or hour, I would expect putty to handle this flawlessly. However, there's always the chance that there's a bug in either the server or client -- check to see if updates are available for your server or client?

link|improve this answer
feedback

SSH public keys are used only for connection establishment. They also have no expiration date attached (unlike SSL and PGP keys), and so cannot 'expire after a certain time period'; even if they did, since they're only used for the initial connection, this would not terminate the connection.

There is a concept of a 'key re-exchange' in SSH, in which the ephemeral shared secret keys (NOT public keys) are cycled periodically. However this happens after a long time period (about once an hour) or after a large amount of data (about once every gigabyte of data transferred) is transferred, and both OpenSSHd and PuTTy handle this re-exchange just fine, so it's unlikely to be the cause of your problems.

If your ssh connection is terminating after a certain amount of time of inactivity, and you are connecting through a typical home router, your home router may be terminating the inactive connection. You can fix this by forcing SSH to send periodic keepalives. Add this to your sshd_config:

ClientAliveInterval 30

This will instruct the server to ping the client after 30 seconds of inactivity; this will suffice to keep the connection active in the router as well.

You can also configure this on the client side, by adding to your ~/.ssh/config:

ServerAliveInterval 30
link|improve this answer
feedback

Your Answer

 
or
required, but never shown