Ssh常见问题集
2010-08-21 12:48:02 
阿炯
登录认证过慢的解决办法
超时断开连接的解决办法
自动登录问题集
用户登录失败后的锁定与解锁
中高危漏洞集合
手动升级sshd后一例登录后拒绝访问的故障
登录认证过慢的解决办法
通过ssh登录到linux,登录认证的时间总要用掉10多秒甚至20多秒，可以对sshd服务器进行相关操作来解决此问题。
方法一 关闭ssh的gssapi认证
vim /etc/ssh/ssh_config
注释掉如下两行
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
方法二 关闭ssh的UseDNS
vim /etc/ssh/sshd_config
注：ubuntu的sshd_config文件没有UseDNS参数,而据我了解,其它类*NIX、*BSD操作系统的sshd_config都有UseDNS参数，且它们缺省都是"UseDNS yes"，
那估计ubuntu的sshd_config虽然没有UseDNS，那它缺省也是"UseDNS yes"了
于是，在sshd_config末尾处插入如下行
UseDNS no
然后执行指令"/etc/init.d/ssh restart"，重启ssh服务，使配置生效。
经测试，使用此方法后，服务器的认证时间大大缩短，原来其登录认证一般耗时在10秒以上15秒左右，而经过此修改，ubuntu的登录认证时间将会缩短在3秒以内。
超时断开连接的解决办法
OpenSSH在使用的时候，几分钟不在终端上不操作的话就会自动断开连接，这是出于安全的考虑，但对于需要长时间使用的用户来说很麻烦，每次都要重新连接。解决方法如下：
将/etc/ssh/sshd_config中的“ClientAliveInterval”设置取消注释，并把0改为一个较小的数值即可。
echo 'ClientAliveInterval 30
ClientAliveCountMax 6' >> /etc/ssh/sshd_config && /etc/init.d/ssh reload
具体说明参看下面的解释：
ClientAliveInterval
Using an OpenSSH server's ClientAliveInterval, it is possible for the ssh server to send periodic "keep alive" messages to the ssh client, keeping the connection open indefinitely. This is useful when a firewall or other packet filtering device drops idle connections after a certain period of time. Note that this is different from the KeepAlive directive in ssh_config.
From the sshd_config manpage:
ClientAliveInterval
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. This option applies to protocol version 2 only.
Example (send "keep alive" messages every 5 minutes) on Red Hat Linux:
1. Add ClientAliveInterval 300 to /etc/ssh/sshd_config
2. Reload the sshd server configuration with /sbin/service sshd reload
Note: you may want to configure the ClientAliveCountMax value in sshd_config to set the number of times that "keep alive" messages are sent. If ClientAliveCountMax number of "keep alive" messages are not acknowledged by the ssh client, the connection is terminated by the ssh server. The default value of 3 should be sufficient for most users.
注意：您可能需要配置ClientAliveCountMax，这个sshd_config中的值来设置“keep alive”消息被发送的次数。如果ClientAliveCountMax数量的“keep alive”消息不被ssh客户端所响应，那么ssh服务器将终止连接，默认值3应当满足大部分用户。
仔细总结有多种发现原因，环境变量TMOUT引起，ClientAliveCountMax和ClientAliveInterval设置问题或者甚至是防火墙的设置问题，所以可以这么尝试：
1, echo $TMOUT
如果显示空白,表示没有设置，等于使用默认值0，一般情况下应该是不超时，如果大于0，可以在如/etc/profile或主目录中相关文件中将它设置为0.
2. ClientAliveInterval
在/etc/ssh/sshd_config中增加ClientAliveInterval 60，ClientAliveInterval指定了服务器端向客户端请求消息的时间间隔，默认是0，不发送；而ClientAliveInterval 60表示每分钟发送一次，然后客户端响应，这样就保持长连接了。这里不是客户端主动发起保持连接的请求，而是需要服务器先主动。
另外,至于ClientAliveCountMax, 使用默认值3即可，ClientAliveCountMax表示服务器发出请求后客户端没有响应的次数达到一定值,，就自动断开， 正常情况下，客户端不会不响应。
3. 启用ssh客户端的 keepalive
putty -> Connection -> Seconds between keepalives ( 0 to turn off )，默认为0，改为60。
xshell -> Connection -> Keep Alive 页面中也有相关设置(这个在建立新会话属性时是默认开启的，不过在实际使用过程中并没有生效，还是要在服务器上进行设置)。
上述3个方法应该能解决问题，如果不行，请参考sshd_config的man手册。在修改了ssd_config 重置ssh server:'/etc/rc.d/init.d/sshd reload'。
手动升级sshd后一例登录后拒绝访问的故障
登录能成功，但立马退出，留下一句：
/bin/bash: Permission denied
排查方向：检查selinux，acl，pam等可能的地方。在终端下为ssh指令多加几个'-v'可提升日志输出等级。
可能看到密码与key这些均没有问题，难道正是相关目录或文件的权限被修改了？
如'/bin/bash'本身及其上级目录的权限，用户家目录及其其下的.ssh目录及其中的文件权限。可通过getfacl命令查看目录的访问ACL。sshd的主要配置：
PermitRootLogin、PubkeyAuthentication、PasswordAuthentication
确认这些无误后，检查一下selinux的状态：
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31
可以看到SELinux已启用，状态显示服务处于强制执行模式。
SELinux 可能会阻止应用程序的正常运行。如果出现以下情况，服务将拒绝访问：
文件标签错误。
不兼容的应用程序尝试访问被禁止的文件。
服务在不正确的安全策略下运行。
检测到入侵。
如果发现服务未正确运行，请检查 SELinux 日志文件。日志位于/var/log/audit/audit.log中。最常见的日志消息标有AVC。如果找不到任何日志，请尝试查看/var/log/messages。如果auditd守护程序未运行，系统会将日志写入该文件。
暂时禁用 SELinux，请在终端中输入以下命令：
setenforce 0
该指令可以使用permissive而不是 0。此命令将 SELinux 模式从target改为permissive。
从目标模式转变为许可模式，再通过ssh就可以登录主机系统了。若修改其侦听端口可能也会导致同样的问题。
超时断开连接的解决办法
自动登录问题集
用户登录失败后的锁定与解锁
中高危漏洞集合
手动升级sshd后一例登录后拒绝访问的故障
登录认证过慢的解决办法
通过ssh登录到linux,登录认证的时间总要用掉10多秒甚至20多秒，可以对sshd服务器进行相关操作来解决此问题。
方法一 关闭ssh的gssapi认证
vim /etc/ssh/ssh_config
注释掉如下两行
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
方法二 关闭ssh的UseDNS
vim /etc/ssh/sshd_config
注：ubuntu的sshd_config文件没有UseDNS参数,而据我了解,其它类*NIX、*BSD操作系统的sshd_config都有UseDNS参数，且它们缺省都是"UseDNS yes"，
那估计ubuntu的sshd_config虽然没有UseDNS，那它缺省也是"UseDNS yes"了
于是，在sshd_config末尾处插入如下行
UseDNS no
然后执行指令"/etc/init.d/ssh restart"，重启ssh服务，使配置生效。
经测试，使用此方法后，服务器的认证时间大大缩短，原来其登录认证一般耗时在10秒以上15秒左右，而经过此修改，ubuntu的登录认证时间将会缩短在3秒以内。
超时断开连接的解决办法
OpenSSH在使用的时候，几分钟不在终端上不操作的话就会自动断开连接，这是出于安全的考虑，但对于需要长时间使用的用户来说很麻烦，每次都要重新连接。解决方法如下：
将/etc/ssh/sshd_config中的“ClientAliveInterval”设置取消注释，并把0改为一个较小的数值即可。
echo 'ClientAliveInterval 30
ClientAliveCountMax 6' >> /etc/ssh/sshd_config && /etc/init.d/ssh reload
具体说明参看下面的解释：
ClientAliveInterval
Using an OpenSSH server's ClientAliveInterval, it is possible for the ssh server to send periodic "keep alive" messages to the ssh client, keeping the connection open indefinitely. This is useful when a firewall or other packet filtering device drops idle connections after a certain period of time. Note that this is different from the KeepAlive directive in ssh_config.
From the sshd_config manpage:
ClientAliveInterval
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. This option applies to protocol version 2 only.
Example (send "keep alive" messages every 5 minutes) on Red Hat Linux:
1. Add ClientAliveInterval 300 to /etc/ssh/sshd_config
2. Reload the sshd server configuration with /sbin/service sshd reload
Note: you may want to configure the ClientAliveCountMax value in sshd_config to set the number of times that "keep alive" messages are sent. If ClientAliveCountMax number of "keep alive" messages are not acknowledged by the ssh client, the connection is terminated by the ssh server. The default value of 3 should be sufficient for most users.
注意：您可能需要配置ClientAliveCountMax，这个sshd_config中的值来设置“keep alive”消息被发送的次数。如果ClientAliveCountMax数量的“keep alive”消息不被ssh客户端所响应，那么ssh服务器将终止连接，默认值3应当满足大部分用户。
仔细总结有多种发现原因，环境变量TMOUT引起，ClientAliveCountMax和ClientAliveInterval设置问题或者甚至是防火墙的设置问题，所以可以这么尝试：
1, echo $TMOUT
如果显示空白,表示没有设置，等于使用默认值0，一般情况下应该是不超时，如果大于0，可以在如/etc/profile或主目录中相关文件中将它设置为0.
2. ClientAliveInterval
在/etc/ssh/sshd_config中增加ClientAliveInterval 60，ClientAliveInterval指定了服务器端向客户端请求消息的时间间隔，默认是0，不发送；而ClientAliveInterval 60表示每分钟发送一次，然后客户端响应，这样就保持长连接了。这里不是客户端主动发起保持连接的请求，而是需要服务器先主动。
另外,至于ClientAliveCountMax, 使用默认值3即可，ClientAliveCountMax表示服务器发出请求后客户端没有响应的次数达到一定值,，就自动断开， 正常情况下，客户端不会不响应。
3. 启用ssh客户端的 keepalive
putty -> Connection -> Seconds between keepalives ( 0 to turn off )，默认为0，改为60。
xshell -> Connection -> Keep Alive 页面中也有相关设置(这个在建立新会话属性时是默认开启的，不过在实际使用过程中并没有生效，还是要在服务器上进行设置)。
上述3个方法应该能解决问题，如果不行，请参考sshd_config的man手册。在修改了ssd_config 重置ssh server:'/etc/rc.d/init.d/sshd reload'。
手动升级sshd后一例登录后拒绝访问的故障
登录能成功，但立马退出，留下一句：
/bin/bash: Permission denied
排查方向：检查selinux，acl，pam等可能的地方。在终端下为ssh指令多加几个'-v'可提升日志输出等级。
可能看到密码与key这些均没有问题，难道正是相关目录或文件的权限被修改了？
如'/bin/bash'本身及其上级目录的权限，用户家目录及其其下的.ssh目录及其中的文件权限。可通过getfacl命令查看目录的访问ACL。sshd的主要配置：
PermitRootLogin、PubkeyAuthentication、PasswordAuthentication
确认这些无误后，检查一下selinux的状态：
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31
可以看到SELinux已启用，状态显示服务处于强制执行模式。
SELinux 可能会阻止应用程序的正常运行。如果出现以下情况，服务将拒绝访问：
文件标签错误。
不兼容的应用程序尝试访问被禁止的文件。
服务在不正确的安全策略下运行。
检测到入侵。
如果发现服务未正确运行，请检查 SELinux 日志文件。日志位于/var/log/audit/audit.log中。最常见的日志消息标有AVC。如果找不到任何日志，请尝试查看/var/log/messages。如果auditd守护程序未运行，系统会将日志写入该文件。
暂时禁用 SELinux，请在终端中输入以下命令：
setenforce 0
该指令可以使用permissive而不是 0。此命令将 SELinux 模式从target改为permissive。
从目标模式转变为许可模式，再通过ssh就可以登录主机系统了。若修改其侦听端口可能也会导致同样的问题。