解决SSH自动断线,无响应的问题。

ssh_config和sshd_config都是ssh服务器的配置文件,二者区别在于,前者是针对客户端的配置文件,后者则是针对服务端的配置文件。

# 打开

sudo vim /etc/ssh/sshd_config

# 添加

ClientAliveInterval 30

ClientAliveCountMax 6

ClientAliveInterval表示每隔多少秒,服务器端向客户端发送心跳,是的,你没看错。

ClientAliveInterval表示上述多少次心跳无响应之后,会认为Client已经断开。

OpenSSH基于安全的理由,如果用户连线到SSH Server后闲置一段时间,SSH Server会在超过特定时间后自动终止SSH连线。本人习惯长时间连接,需要做如下修改:

1、打开ssh配置文件:# vim /etc/ssh/sshd_config

加入如下两个参数保存就可以:

TCPKeepAlive yes

ClientAliveCountMax 360

注:前一个参数表示要保持TCP连接,后一个参数表示客户端的SSH连线闲置多长时间后自动终止连线的数值,单位为分钟。

2、重启sshd生效:

/etc/init.d/sshd restart

注:此法适用于所有Linux发行版的OpenSSH。ClientAliveInterval是设定SSH强制超时断开的参数

ClientAliveInterval指定了服务器端向客户端请求消息的时间间隔, 默认是0,不发送。而ClientAliveInterval 60表示每分钟发送一次,然后客户端响应,这样就保持长连接了。这里比较怪的地方是:不是客户端主动发起保持连接的请求(如FTerm, CTerm等),而是需要服务器先主动。

另外,至于ClientAliveCountMax,使用默认值3即可。ClientAliveCountMax表示服务器发出请求后客户端没有响应的次数达到一定值,就自动断开,正常情况下,客户端不会不响应。

我的sshd配置是设置/etc/ssh/sshd_config:

TCPKeepAlive yes

ClientAliveInterval 360 #每6分钟(360秒)向client端发个包

ClientAliveCountMax 20 #最多发20次,这样可以保持2小时(7200秒)的连接

一、挖坑

这篇的起因主要是来自上一个问题「iTerm2中ssh保持连接不断开」。

原本以为是个很常见的小问题,随手一搜,解决办法一大堆,试了试可行,就觉得没什么问题了。但,正因为觉得太简单了,在文末去查看了一下服务端配置,想找找问题起因,结果却发现开辟了一个深坑……

查看的默认配置:

$ echo $TMOUT

$

# ...

#TCPKeepAlive yes

# ...

#ClientAliveInterval 0

#ClientAliveCountMax 3

# ...

二、入坑

1、提问

提个问题:既然ssh是空闲过久导致连接超时而断开,那么「ssh默认是多久时间,会自动断开连接?」

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

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

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

2、再问

实在没什么头绪,跑到QQ群问了一番,结果真有大神回应,并且顺利找到了线索!

最后通过各种摸索,终于知道了问题的主要原因,因为连接是可以的,只是会超时断开,根据网络结构来看,问题就可能出现在一下这几个部分[1] :

1. 服务器存在防火墙,会关闭超时空闲连接,或设置了关闭超时空闲连接。

2. 客服端和服务器之间存在路由器,路由器也可能带有防火墙,会关闭超时空闲连接。

3. 客服端存在防火墙,会关闭超时空闲连接。

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

3、追问

为什么会是防火墙呢?根据大神指点:在iptables的一些NAT配置说明里有提到——

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

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分钟空闲就终止你的会话。[3]

通过这段描述(好吧,其实这段我没看得太透彻-0-。看来平时缺少些TCP等的知识细节的积累,对处理问题时的一些方向,线索,还是会有不少的障碍的。),我们就比较能大致想到断开的原因了——

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

三、填坑

总算知道了问题所在。既然如此,那就可以「对症下药」了:让连接「忙」起来,别「闲」着!

方法有几种,选其一即可。

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

这个在上一个问题「iTerm2中ssh保持连接不断开」中有说到的方案。

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 user@host

四、坑不停

上面基本就把现象,原因,处理方法都说得差不多了,不过,这里还要多说两句。

一般来说,不建议修改服务端。会涉及到权限问题,以及安全问题。还是比较推荐修改客服端或工具等的方法。查的过程有看到过说关于抓包看到服务器发包时握手问题的,具体原因……

还有,细心的读者可能还会发现,「三、1」中提到的TCPKeepAlive,其实还有更深一层的意思和相关作用。但这里涉及的TCP心跳包,保活,探测报文等等……

与上面搭配的还有系统变量echo $TMOUT……

对上面提到的防火墙问题,前文提到的QQ群大神又帮忙往下查一查,告知还可以看到一个关于防火墙配置时的参数ip_conntrack_tcp_timeout_established[4],要研究下这个参数以及其所在文件的设置详情……

好吧……总结一下就是,有时从一个比较「小」的坑,可能就这样不知不觉的牵扯到了一堆底层的知识,一不留神就蒙逼了……

不过,这种能够不断的挖掘深坑,坑中有坑,坑复一坑,坑坑向上的感觉,总的来说还是非常有意思的。以后要继续发掘……

对于开头提到的问题,至少目前是可以「见好就收」了。对于期间遇到的一些「既有深度又有广度」的问题,本文无法一一兼顾。一口吃不下一个广西粽,一铲填不平全部的坑,暂时不能一下子研究到位的,还可以保持关注,记录下来。后面有兴趣的话,让我们再慢慢揭开它们的面纱吧。:)

五、参考文档

Linux系统下的ssh使用(依据个人经验总结) (有alive相关的ssh服务端和客服端的配置)

ssh配置讲解大全(里面有详细的debug过程,tcpdump抓包信息)

客户端连接linux经常间隔性断开链接 (点出根源是防火墙问题)

ssh 设置超时时间(文中有一段英文以及翻译,很有价值)

linux 配置防火墙 配置nat转发服务(提到ip_conntrack_tcp_timeout_established,还有防火墙iptables,NAT等配置,值得研究学习)

注释:

http://www.cnblogs.com/whatlonelytear/p/5532433.html ↩

http://www.360doc.com/content/16/0627/16/1157518_571159455.shtml ↩

http://blog.chinaunix.net/uid-10697776-id-3341317.html ↩

http://lilinji.blog.51cto.com/5441000/1129350 ↩

(完)

分类:「 blog 」

发表时间:2017-01-24 14:01:52

最后更新:2017-01-28 20:39:23

转载请注明原作者及出处:「 biubiu - http://bluebiu.com/blog/linux-ssh-session-alive.html 」

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

推荐阅读更多精彩内容