ssh登录时间久或登陆后报错

情况1

问题描述:

ssh登录时间很久,登录后出现'abrt-cli status' timed out 的报错

问题原因:

.lock文件被锁导致

执行systemctl status abrtd.service可以看到被锁的.lock

ssh登录时间久或登陆后报错_第1张图片

处理方式: 

ps -ef | grep pid 找到被锁的进程kill掉  kill -9 pid

重新登录即可

如果业务对abrtd没有特殊需求,为避免重启后再次出现该问题,建议关闭abrtd avahi-daemon服务。

systemctl stop abrtd

systemctl disable abrtd

情况2:

如果使用sshIP登录缓慢,可以在命令行加入GSSAPIAuthentication=no参数。一般这类问题以前遇到最多的是dns设置以及打开了SSAPIAuthentication认证。解决办法:

1、检查是否启动dns,检查/etc/resolv.conf存在外网的DNS。

2、再次取消/etc/resolv.conf的注解,尝试还是缓慢。实际上如果你使用sship登录出现缓慢,DNS设置已经排除了。

如果配置了dns可以参考如下:

sed -i ‘s/GSSAPIAuthentication yes/GSSAPIAuthentication no/g’ /etc/ssh/sshd_config

sed -i ‘/UseDNS yes/ a UseDNS no’ /etc/ssh/sshd_config

systemctl restart sshd

GSSAPIAuthentication 当这个参数开启( GSSAPIAuthentication yes )的时候,通过SSH登陆服务器时候会有些会很慢,但有的服务器又不慢,这个问题是什么造成的 ??

还有就是在登陆慢的服务器上,修改这个 (GSSAPIAuthentication no )为关闭的时候,慢得就恢复正常。

作用 : 是否允许使用基于 GSSAPI 的用户认证。默认值为”no”。仅用于SSH-2

服务器端启用了GSSAPI。登陆的时候客户端需要对服务器端的IP地址进行反解析,如果服务器的IP地址没有配置PTR记录,那么就容易在这里卡住了。 

1.UseDNS选项基本上是无用的

UseDNS选项基本上是无用的。如果客户端计算机在Internet上,则很有可能它们没有任何反向DNS,它们的反向DNS无法解析转发,或者它们的DNS除了IP地址已经告诉您的“属于此ISP”之外,不提供任何信息。

2.DNS仅用于日志记录。它可以用于身份验证

在典型配置中,DNS仅用于日志记录。它可以用于身份验证,但仅当在sshd配置中指定IgnoreRhosts no时。这是为了与使用rsh的旧安装兼容,在rsh中,您可以说“名为darkstar的计算机上名为bob的用户可以作为alice登录,而不显示任何凭据”(通过在~alice/.rhosts中写入darkstar bob)。只有信任所有可能连接到ssh服务器的计算机,才是安全的。换言之,这是非常罕见的可用的安全方式。

根据测试 只需要修改/etc/ssh/sshd_config的  UseDNS no 就不会缓慢了。

情况3:

ssh登录缓慢或者systemd-login进程cpu 100%

某些机器ssh登录缓慢的情况,特别是运行几年的机器。

由于systemd的低版本(42.17e)一次不能处理太多的会话(session),时间长了,会耗尽主机内存,并导致org.freedesktop.logind and org.freedesktop.systemd模块崩溃。

你可能感兴趣的:(linux,ssh,运维,linux,服务器)