Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Stop annoying session keep alive message in ssh login

Tags:

macos

ssh

I was trying to change some settings in my MAC for keeping my connection alive for long time. Before it was logging out automatically after some idle time with message "Write Failed: Broken pipe". Now after I changed the setting I am getting annoying message every time to the logged in terminal using ssh

debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1

How can I remove this message to appear on my terminal (MAC), or else I can go back to my previous setting?

like image 460
Swapnil Shailesh Srivastawa Avatar asked Mar 17 '16 04:03

Swapnil Shailesh Srivastawa


4 Answers

You are receiving these messages because you have set ClientAliveInterval on the server. The server sends keep-alive packets to the client when the connection stays idle for the specified interval. To prevent these messages:

  • On the server, increase ClientAliveInterval to a sufficiently high number (e.g. 480 seconds) to prevent connection timeout without flooding your logs.

  • On the client, set ServerAliveInterval to a number lower than the server's ClientAliveInterval. This will cause the client to keep the connection alive without ever triggering the server's keep-alive timeout.

like image 116
dragon Avatar answered Nov 05 '22 08:11

dragon


Have a look in one of two places:

1) On the mac in ~/.ssh/config - There could be debug flags set in there

2) On the server, as there could be debit flags set there too

like image 44
Adrian Sluyters Avatar answered Nov 05 '22 08:11

Adrian Sluyters


(Easy summary of other answers/comments):

Run in terminal of Mac, replacing 5 with number of seconds less than interval between new messages appearing on screen:

echo " ServerAliveInterval 5" >> ~/.ssh/config

You may check if ServerAliveInterval line is already there before that:

cat ~/.ssh/config | grep ServerAliveInterval

(if you see a line, then edit instead).

Will take effect on next run of ssh.

like image 2
Alexei Martianov Avatar answered Nov 05 '22 10:11

Alexei Martianov


You are getting these messages because the server has ClientAliveInterval which is not set to 0 (the default).

Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) 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.

Solutions

Server: set ClientAliveInterval to 0

The simplest solution is to remove the ClientAliveInterval on the server, it defaults to 0 and no messages are sent.

Alternatively, set the value to 0.

Where?

You typically do this by editing the servers sshd_config which is likely in /etc/ssh/sshd_config. The changes take affect the next time the daemon is started.

Notes

For hosted service, it may be a bad idea to set ClientAliveInterval to 0. Mainly because it can keep the host running unnecessarily and waste money.

Client: set ServerAliveInterval to a lower value than the servers ClientAliveInterval

If you don't have access to the server, or you want to configure clients differently. You may set the ServerAliveInterval to a value that is lower than the ClientAliveInterval. Then the ssh client will periodically send messages which reset the server timeout.

Where?

You typically do this by the editing the clients ssh_config which is likely in ~/.ssh/config.

Notes

Setting the ServerAliveInterval lower than the ClientAliveInterval is, for most intents and purposes, the same as not having one. You won't get messages in your terminal.

Nevertheless, it allows for interesting configuration. You can open different ssh connections, some which timeout and some which don't when used in conjunction with ClientAliveCountMax where the server closes the connection it has sent n messages.

This doesn't prevent server messages from ever being sent. For example, if the package was dropped or severe delay caused the message to arrive late, the server will still send a message.

Filter, ignore the messages

Presumably the messages are sent to stderr. Redirect and/or filter stderr is probably another viable route.

like image 1
CervEd Avatar answered Nov 05 '22 08:11

CervEd