[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#458154: Install of debian-4.0r2 on NSLU2

On Jan 1, 2008, at 4:31 PM, Del Merritt wrote:

Geert Stappers wrote:
Op 29-12-2007 om 13:30 schreef Del Merritt:

Rick Thomas wrote:

Also, make sure your ssh-client machine doesn't go to sleep while waiting...

Thanks. I'm trying this out at the moment. Then again, I'm also "here" and the install is 96% complete, so I may actually be around when it finishes, mooting the issue (for me).

With a carbon copy, Cc:, to 458154@bugs.debian.org,
is the bugreport kept up-to-date.

Geert Stappers

Please tell when the install finishes,
preferable to the address of the bugreport.

Adding "ServerAliveInterval 2" to my .ssh/config file allows me to complete the install without further issues. I now have a Linksys "slug" running debian. Huzzah and all that. A "minimal" fix to this would be to document the issue in a way that reminds users to modify their .ssh/config file in this manner if their site's security policy allows it. If it is not permitted for some reason, then if there is a way that the ssh server on the in-progress system can do this keep alive, it might result in fewer surprises and less end-user frustration.

It pays to read the documentation... Look what I discovered while browsing the wiki for an unrelated problem!

As noted at
http://wiki.debian.org/Manual-Howto#head- ac718e22a5cb533439c82a459acd17ba06ac387d There is an option in the server configuration file /etc/ssh/ sshd_config you can set
that will do what you need.

Sets a timeout interval in seconds after which, if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to
   the client.

Maybe this could be set for installations? It's not a good idea to set it for the installed config file, for just the kind of security reasons Del alludes to above. But it could save some long-running installations on difficult to access (physically) machines.


Reply to: