ssh是Linux系统中常用的远程登陆的命令,有的时候我们通过xshell等远程连接软件使用ssh去登陆远程的服务器的时候,会遇到一些问题。

下面是关于ssh 远程登陆的问题解决方法的总结。(更新中)

常见报错及解决

1.SSH连接时出现Connection refused,如下:

报错如下:
ssh: connect to host 123.123.123.111 port 22: Connection refused

通常是由于22端口未打开、ssh服务未启动或防火墙禁止22端口等原因引起的

解决方法:

【1】启动服务,设置防火墙步骤如下:

<1>.进入该服务器(本地登陆)

<2>.查看ssh服务是否启动
systemctl status sshd

如未启动
systemctl start sshd

<3>.查看端口是否打开
netstat -lnput |grep :22

如未打开,再次启动sshd

<4>测试网络的联通性
ping www.baidu.com (ping外网)

如果ping不通,就检查dns

如果dns无问题,就说明是网络原因,看服务器的网线是否连接或是否有问题

<5>如果能连接外网,就查看服务器的防火墙规则,并开放ssh服务的22号端口(如防火墙未放行ssh的端口)

iptables -L

[1]直接打开端口:
iptables -I INPUT -p tcp --dport 22 -j ACCEPT

[2]永久打开端口

打开防火墙配置文件:
vim /etc/sysconfig/iptables

在iptables文件内容中追加
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

保存配置文件后,重启防火墙:
service iptables restart(centos6)
systemctl restart iptables(centos7)

2.SSH连接时出现Host key verification failed

报错如下:
Host key verification failed

通常是由于访问使用的公钥与服务器记录的差异引起的

ssh服务会把每个曾经访问过计算机或服务器的公钥(public key),记录在~/.ssh/known_hosts
当下次访问曾经访问过的计算机或服务器时,ssh就会核对公钥,如果和上次记录的不同,OpenSSH会发出警告。
而ssh对主机的public_key的检查是有等级的,根据等级执行不同的策略。(StrictHostKeyChecking就是配置等级的参数)

[1]StrictHostKeyChecking=no

最不安全的级别,提示最少,应在相对安全的内网测试时使用。(当连接的服务器的公钥在本地不存在,就会自动添加到文件(默认是known_hosts)中,并且给出警告。

[2]StrictHostKeyChecking=ask

默认的级别。如果连接的服务器的公钥和本地的known_hosts文件中不匹配,就给出提示(Host key verification failed),并拒绝登录。

[3]StrictHostKeyChecking=yes

最安全的级别,如果连接的服务器的公钥和本地的known_hosts文件中的不匹配,就拒绝连接,不会提示详细信息。

解决方法 :

【1】可更改安全选择最低的安全级别。在.ssh/config或/etc/ssh/ssh_config)中配置:

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

(将knownhostfile设为/dev/null),为了方便使用在known_hosts中了)

【2】删除对应ip的在known_hosts相关信息

vim /.ssh/known_hosts

【3】直接删除known_hosts文件
rm known_hosts

3.SSH公私钥正确的情况下免密登录失败

有的时候我们经常会遇到:在服务器上配置ssh公钥后,一段时间可以免密码登录,后来登录时,每次都提示要输入密码。这时我们可以删除known_hosts,重新把id_rsa.pub添加到服务器~/.ssh/authorized_keys下。 如果这个办法也不行,我们(首先考虑是权限问题)要查看日志。

/var/log/auth.log日志中报错如下:
coffeeserver sshd[6761]: Authentication refused: bad ownership or modes for directory /root/.ssh

/var/log/secure日志中报错如下:
Authentication refused: bad ownership or modes for directory /root/.ssh

这些日志都告诉了我们/root/.ssh的目录的权限的配置出现了(权限应为700)

解决方法:

【1】更改目录及文件权限

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4.SSH连接时密码正确,登陆失败,出现Permission denied, please try again

报错如下:
Password authentication failed

Permission denied, please try again

通常是由于/etc/ssh/sshd_config的PasswordAuthentication或PermitRootLogin参数的配置引起的

补充:
还有特殊一种情况,你要连接的这台服务器的ip地址与你局域网中的某台电脑的ip地址一致,造成冲突。(这种情况,无论怎么改都会失败,会让你怀疑自己。解决方法只能是一方改IP或关闭其中一方,先解决冲突问题)

解决方法:

【1】修改相关配置文件

<1>查看本服务器和电脑的防火墙设置,是否打开ssh服务,22端口(一般都是打开的)
如果服务不是打开的要将服务启动,防火墙开放22端口(配置规则看本文目录第1条中)

<2>编辑sshd_config文件

vim /etc/ssh/sshd_config

将PasswordAuthentication前面的#号去掉
将PasswordAuthentication 设为yes

<3> 重启sshd服务

/etc/init.d/sshd restart (centos6)
systemctl restart sshd(centos7)

【2】修改相关配置文件

<1>基本上与上一个方法相同,但编辑sshd_config文件的另一个参数

vim /etc/ssh/sshd_config

将PermitRootLogin前面的#号去掉
将PermitRootLogin设为yes

<2>重启sshd服务

/etc/init.d/sshd restart (centos6)
systemctl restart sshd(centos7)

5.SSH连接时出现Permission denied, please try againssh_exchange_identification: read: Connection reset by peer

报错如下:
Permission denied, please try againssh_exchange_identification: read: Connection reset by peer

原因是由于所访问的服务器启用了tcp_wrapper,拒绝接受该ip或网段发起访问的服务,可能是限制了ip或是网段

解决方法:

【1】修改发起访问端的ip或网段

该方法在无法进入被访问端服务器时使用,但可用率不高,因为大多少情况下是对网段进行限制并开放某些IP。

建议联系 系统管理员解除限制或放开该IP或网段

<1>查看本机的ip或网段

<2>修改一个正在使用的网卡的配置文件

vim /etc/sysconfig/network-scripts/ifcfg-eth0
(重点修改IPADDR,NETMASK,GATEWAY,将其修改为新网段的IP)

TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
NAME=eth0
DEVICE=eth0
ONBOOT=yes
IPADDR=10.10.10.10
NETMASK=255.255.254.0
GATEWAY=10.10.10.254
DNS1=.8.8.8.8

<3> 重启网卡

service network restart(centos6)
systemctl restart network(centos7)

【2】进入被访问端解除限制或放开IP

<1>进入/etc/hosts.allow中进行修改

(123.123.123.123此处代表发起访问端的IP)

vim /etc/hosts.allow

追加
sshd:123.123.123.123:allow

或仅注释一行
#sshd:123.123.123.123:deny

或注释所有规则,并添加
sshd:all:allow

更多的设置方法如下:
https://blog.csdn.net/GX_1_11_real/article/details/89452719

6.连接服务器时,提示要输入密码,成功推送过公钥到服务器后,再次连接仍提示要输入密码

解决方法如下:
https://blog.csdn.net/GX_1_11_real/article/details/101520070

问题 :能ping通 Linux 服务器 但是 ssh 不上 解决 方法 这个 问题 花了我20分钟去查资料,网上写的 解决 方法 也是五花八门,不过,总算 解决 了,分享出来和大家一起学习。 服务器 正常,PING也能PING通。但是就是 SSH 不上 啊, 出现 这种 问题 ,最大的可能就是防火墙没有关闭。 解决 方法 : 一、开启 SSH 以root用户 登录 Linux ,打开终端,运行: /etc/init.d/ ssh d restrat 二、关闭防火墙 1、在终端运行 setup 2、选择 firewall 回车 3、按tab键切换到disablede项,然后按空格键选择,然后再按tab键
Linux 防火墙没有关闭,导致 SSH 连接失败(关闭防火墙) Linux SSH 服务没有启动,查看是否启动 SSH 服务 SSH 服务启动后,仍然连接 不上 ,需要确认是否是 SSH 服务得端口 问题 ,核对连接端口( /etc/ ssh / ssh d_config)
pcy@pcy:~/. ssh $ sudo ssh root@180.76.140.72 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
而我们只需要将有 问题 的文件删除,然后重启服务即可,命令如下: rm -rf /etc/ ssh / ssh *key //删除/etc/ ssh /下 ssh 开头key结尾中间爱啥啥的文件 systemc...
1. struts2整合spring4,action无法注入 这是一个困扰我一个上午的 问题 ,纠结地让我怀疑起我是不是不适合干这一行。 网上各种资源都找了,也怀疑是版本 问题 ,试了各种版本,甚至还把官方文档从头到尾看了几遍,然而还是没有找到 问题 所在。 最后这个 问题 莫名其妙地就 解决 了,发现是jar的冲突 问题 : struts2引用了一个javaasist包,而hibernate同样也应用了一个不同
Ping 10.0.0.7 : 排查 客户端到 服务器 端的线路 问题 ,ping是常用的网络连通性检查工具 tracert –d 10.0.0.7 : tracert路由追踪命令,也可以检查路是否畅通,-d是不进行反向解析 第2步: SSH 服务是否有 问题 telnet 10.0.0.7 22 :判断 SSH 服务器 默认的22端口是否打开(客户端执...
如果您确认root账户未被禁用,但是在尝试使用root账户 登录 出现 密码 错误 ,您可以尝试以下 几种 方法 : 1. 确认密码是否正确,可能是您输入的密码 错误 。可以在本地使用su命令切换到root账户,以确保您的密码是正确的。 2. 确认是否启用了键盘布局,如果您的键盘布局不是英文,可能会导致您输入的密码与实际密码不符。可以尝试打开键盘布局并重新输入密码。 3. 确认是否启用了Caps Lock键或Num Lock键,这些键可能会导致您输入的密码与实际密码不符。请确保这些键处于正确的状态。 4. 如果您使用的是 SSH 密钥对进行 登录 ,可以尝试使用其他用户 登录 系统,然后检查/root/. ssh /authorized_keys文件夹中的密钥是否正确,或者尝试将密钥重新添加到该文件夹中。 如果以上 方法 无法 解决 问题 ,您可以尝试使用其他账户 登录 系统,并检查系统日志文件,以便找到更多有用的信息。