Linux使用ssh超时断开连接的真正原因

最近使用 ssh 连接服务器的时候,经常一段时间没有操作就断开了(即无法正常操作,键盘输入无反应),一直以为这是服务器的保护措施,直到一次用公司电脑连接的时候,并没有出现这种问题,于是陷入了沉思.....

1.提问

提个问题:如果按照原来的想法,既然ssh是空闲过久导致连接超时而断开,那么「ssh默认是多久时间,会自动断开连接?」

结果翻遍大半个搜索引擎……全都是诸如「如何设置,才能让ssh不超时自动断」这样的鬼title,而且大部分都是互相抄,复制粘贴的内容……而我想问的问题是「到底多久超时」,却没人说过……或者说,其实跟本没有ssh超时这一说?!

再提个问题:如果ssh默认设置都没有限制,那「为什么ssh会断开连接?」

vim /etc/ssh/sshd_config
# ...
#ClientAliveInterval 0
#ClientAliveCountMax 3
# ...

本以为是ssh自动断开超时连接的,但通过配置看到,默认值中并没有做任何限制,那么理论上,ssh的连接是不会断开的。那到底是谁,干了这件「坏事」

2.线索

既然是这样,为何公司电脑和家里的电脑变现不同呢?

最后通过各种摸索,终于知道了问题的主要原因,因为连接是可以的,只是会超时断开,根据网络结构来看,问题就可能出现在一下这几个部分:
1. 服务器存在防火墙,会关闭超时空闲连接,或设置了关闭超时空闲连接。
2. 客服端和服务器之间存在路由器,路由器也可能带有防火墙,会关闭超时空闲连接。
3. 客服端存在防火墙,会关闭超时空闲连接。

原来,问题出在防火墙!!

3.深究

为什么会是防火墙呢?在iptables的一些NAT配置说明里有提到——

4.3.6 State match 状态匹配扩展要有内核里的连接跟踪代码的协助,因为它是从连接跟踪机制中得到包的状态的。这样我们就可以了解连接所处的状态。它几乎适用于所有的协议,包括那些无状态的协议,如ICMP和UDP。针对每个连接都有一个缺省的超时值,如果连接的时间超过了这个值,那么这个连接的记录就被会从连接跟踪的记录数据库中删除,也就是说连接就不再存在了。这个match必须有-m state作为前提才能使用。状态机制的详细内容在章节状态机制中。

NAT firewalls like to time out idle sessions to keep their state tables clean and their memory footprint low.
NAT防火墙喜欢对空闲的会话进行超时处理,以确保它们状态表的干净和内存的低占用率。
Some firewalls are nice, and let you idle for up to a day or so; some are gestapo and terminate your session after 5 minutes.
一些防火墙比较友好,允许你的空闲会话时间为一天甚至超过一天;另一些却如盖世太保,5分钟空闲就终止你的会话。

通过ssh连接后,客户端和服务端长时间没响应时,在两方机器设置中均没任何限制,但在各自的防火墙,或是中转网络连接路由的防火墙中,出现了「闲置超时断开」的缺省机制!

4.解决方法

1、修改服务端配置(不建议)

TCPKeepAlive yes #表示TCP保持连接不断开
ClientAliveInterval 300 #指定服务端向客户端请求消息的时间间隔,单位是秒,默认是0,不发送。设置个300表示5分钟发送一次(注意,这里是服务端主动发起),然后等待客户端响应,成功,则保持连接。
ClientAliveCountMax 3 #指服务端发出请求后客户端无响应则自动断开的最大次数。使用默认给的3即可。
(注意:TCPKeepAlive 必须打开,否则直接影响后面的设置。ClientAliveInterval 设置的值要小于各层防火墙的最小值,不然,也就没用了。)

注意:最后要重启sshd服务才生效
sudo /etc/init.d/ssh restart

修改服务端的配置往往会比较麻烦,也涉及到权限问题,以及安全问题。还是比较推荐下面的方法。

2、修改客户端配置

vim ~/.ssh/config

Host *
    ServerAliveInterval 60

Host * #表示需要启用该规则的服务端(域名或ip)
ServerAliveInterval 60 #表示没60秒去给服务端发起一次请求消息(这个设置好就行了)
ServerAliveCountMax 3 #表示最大连续尝试连接次数(这个基本不用设置)

3、修改连接工具的配置

通过改变连接工具的一些默认配置,把keepalive的配置打开起来即可:

  • secureCRT:会话选项 - 终端 - 反空闲 - 发送NO-OP每xxx秒,设置一个非0值。
  • putty:Connection - Seconds between keepalive(0 to turn off),设置一个非0值。
  • iTerm2:profiles - sessions - When idle - send ASCII code.
  • XShell:session properties - connection - Keep Alive - Send keep alive message while this session connected. Interval [xxx] sec.

当然,用这个办法的副作用也是有的,比如iTerm2会出现一些并不想输入的字符、vim会有些多余字符插入等等,这些情况就按个人的需要酌情取舍了。

4、连接参数-o

ssh -o ServerAliveInterval=30 root@host

5、关闭防火墙

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 160,387评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,845评论 1 298
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 110,091评论 0 246
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,308评论 0 214
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,662评论 3 288
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,795评论 1 222
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 32,008评论 2 315
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,743评论 0 204
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,466评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,687评论 2 249
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,181评论 1 262
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,531评论 3 258
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,177评论 3 239
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,126评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,902评论 0 198
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,862评论 2 283
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,734评论 2 274

推荐阅读更多精彩内容