拒绝SSH连接 – 使用故障恢复控制台进行debugging

我发现了很多关于debugging为什么不能通过SSH连接的问题，但是他们似乎都要求你仍然可以访问系统 – 或者说没有任何事情可以做。在我的情况下，我不能直接访问系统，但是我可以使用恢复控制台访问文件系统。

所以情况就是这样：我的提供者今天做了一些内核更新，并且在这个过程中也重启了我的服务器。由于某种原因，我无法通过SSH连接了，而是得到一个SSH：连接到主机mydomain.de端口22：连接被拒绝

我不知道是否sshd只是没有运行，或者是否（例如iptables）阻止我的SSH连接尝试。我查看了日志文件，/ var / log中没有任何文件在ssh中包含任何提及，而/var/log/auth.log是空的。在内核更新之前，我可以很好地login并使用证书，以便每次从本地计算机连接时都不需要密码。

我到目前为止所尝试的是：

我在/etc/rc*.d/中查看/etc/init.d/ssh脚本的链接，发现没有。所以我期待着sshd在启动时不能正常启动。由于我无法在我的系统中运行任何程序，我不能使用update-rc来更改它。我尝试使用ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd手动创build一个链接，并重新启动服务器 – 这并没有解决问题。我不知道是否可以这样做，在rc6.d中创build它是否正确以及K09是否正确。我只是从Apache复制。
我也试图改变我的/etc/iptables.rules文件，以允许一切：

 ＃由iptables-save v1.4.0于2009年12月10日18:05:32生成
 *撕裂
 ：准备接受[7468813：1758703692]
 ：input接受[7468810：1758703548]
 ：正式接受[3：144]
 ：OUTPUT ACCEPT [7935930：3682829426]
 ：获得承认[7935933：3682829570]
承诺
 ＃2009年12月10日星期四18:05:32完成
 ＃由iptables-save v1.4.0于2009年12月10日18:05:32生成
 *过滤
 ：INPUT ACCEPT [7339662：1665166559]
 ：正式接受[3：144]
 ：OUTPUT ACCEPT [7935930：3682829426]
 -Ainput-i lo -j接受
 -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
 -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
 -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
 -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
 -A INPUT -m conntrack -ctstate RELATED，ESTABLISHED -j ACCEPT
 -Ainput-p tcp -m tcp --dport 80 -j ACCEPT
 -A INPUT -p tcp --dport 8080 -s localhost -j ACCEPT
 -Ainput-m限制 - 限制5 / min -j LOG  - 日志前缀“iptables denied：”--log-level 7
 -Ainput-j接受
 -A FORWARD -j接受
 -A OUTPUT -j ACCEPT
承诺
 ＃2009年12月10日星期四18:05:32完成
 ＃由iptables-save v1.4.0于2009年12月10日18:05:32生成
 * NAT
 ：预备接受[101662：5379853]
 ：获得承认[393275：25394346]
 ：输出接受[393273：25394250]
承诺
 ＃2009年12月10日星期四18:05:32完成

我不确定这样做是正确的还是完全没有任何影响的。我也没有在/ var / log中的任何文件中发现任何iptables的提及。

那我还能做什么？感谢您的帮助。

ps：按照lain的build议添加crontab行后，我可以在文件/var/logauth.log中find以下内容

 3月7日21:13:58 mysubdomain sshd [64900]：debug1：sshd版本OpenSSH_5.3p1 Debian-3ubuntu5
 3月7日21:13:58 mysubdomain sshd [64900]：debug1：读取PEM私钥完成：键入RSA
 3月7日21:13:58 mysubdomain sshd [64900]：debug1：检查黑名单文件/usr/share/ssh/blacklist.RSA-2048
 3月7日21:13:58 mysubdomain sshd [64900]：debug1：检查黑名单文件/etc/ssh/blacklist.RSA-2048
 3月7日21:13:58 mysubdomain sshd [64900]：debugging1：私人主机密钥：＃0types1 RSA
 3月7日21:13:58 mysubdomain sshd [64900]：debug1：读取PEM私钥完成：typesDSA
 3月7日21:13:58 mysubdomain sshd [64900]：debug1：检查黑名单文件/usr/share/ssh/blacklist.DSA-1024
 3月7日21:13:58 mysubdomain sshd [64900]：debug1：检查黑名单文件/etc/ssh/blacklist.DSA-1024
 3月7日21:13:58 mysubdomain sshd [64900]：debugging1：私人主机密钥：＃1types2 DSA

拒绝连接表明sshd没有运行。尝试从命令行以debugging模式运行sshd以查看是否有任何错误消息。

/usr/sbin/sshd -f /etc/ssh/sshd_config -D -d

编辑：

由于您没有权限运行上面的内容，请将其放入@reboot cron作业中

加

 @reboot root /bin/mkdir -p -m0755 /var/run/sshd && /usr/sbin/sshd -f /etc/ssh/sshd_config -d &>/var/log/sshd_debug

进入/etc/crontab

Ubuntu sshd要求存在/ var / run / sshd目录。

您可以尝试将日志logging（SSHstream量）添加到防火墙规则并重新启动计算机。这样，你应该能够validation你的数据包是否到达目的地（因此sshd不工作）。

至于这部分：

我尝试使用ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd手动创build一个链接，并重新启动服务器 – 这并没有解决问题。

运行级别6用于重新启动，所以这不是你感兴趣的.K09sshd中的K是为了杀死。 ;-)尝试使用odk提到的解决scheme，看看会发生什么。

我尝试使用ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd手动build立链接，并重新启动服务器 – 这不能解决问题

你几乎是对的。 K *名称导致服务停止。 S *名称导致服务启动。

rc6.d用于在进入运行级别6时控制子系统，这意味着“重启”。

你希望在运行级别3（普通多用户）和5（多用户+ X）上启动服务。将/etc/rc.3d/S90sshd和/etc/rc5.d/S90sshd符号链接到/etc/init.d/sshd这会导致在系统启动时启动sshd。

我知道了。首先，非常感谢大家的帮助！

对于那些正在浏览类似问题的档案：最初的问题是没有设置/etc/rc*.d/链接，这个sshd没有在启动时运行。我修复这个问题的很多尝试都因为工作方式而被破坏了：当我创build链接的时候

 $ cd /repair/etc/rc3.d/
 $ ln -s ../init.d/ssh S20sshd

对于所有的运行级别来说都是相似的，在恢复模式下创build的链接完全是完美的。但是，当我终于能够重新使用上面描述的破解工具时，我可以看到所有的链接都被破坏了

 $ ls /etc/rc3.d/
 ...
 lrwxrwxrwx 1 root root 10 2011-03-08 09:51 S20sshd  - > init.d / ssh
 ...

所以现在相对的链接指向某处错了。

为了解决这个问题，我在另一个init脚本的顶部添加了一行（注意：HACK !!!）

 /etc/init.d/ssh启动

这工作正常，并允许我重新login。然后我删除了所有断开的链接，并创build新的，使用update.rc。

再次非常感谢你的帮助！

我尝试使用ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd手动build立链接，并重新启动服务器 – 这不能解决问题

尝试将链接添加到/etc/rc6.d，而不是添加到rc3.d（ln -s /etc/init.d/ssh /etc/rc3.d/S99sshd）

你写道，你有文件系统的写入权限，可以更改文件和修改防火墙规则。

我假定您也可以将系统重新启动到正常工作模式。

在这种情况下，我build议首先省略尝试使SSH服务器正常工作，并使用NetCat实用程序在高端口上公开一个简单的远程shell。

你必须：

检查你的系统是否安装了netcat，以及哪个版本（例如，Fedora派生的版本与Debian版本完全不同），并且它们在命令行选项上有很大不同
如果没有，静态编译它从源（一个静态二进制不会需要任何额外的库），并将其上传到您的文件系统。使用GAPING_SECURITY_HOLE编译选项编译它，以便“-e”选项可用
select一个应该监听的端口号（比如1234），并添加一个防火墙规则，只允许从你的客户端IP访问该端口（否则你会打开一个巨大的安全漏洞）
使它从一个初始化脚本（rc.local？）开始，并在暴露Bash shell的背景下运行，例如： nohup nc -l -p 1234 -e '/bin/bash' &

通过这种方式，您将获得一个简单的远程root shell， 并且无需任何身份validation （危险！），您可以使用netcat或telnet远程连接到它（ nc your.server.address 1234 ）。

只要记住要杀掉它并从系统启动脚本中删除它，一旦你的SSH服务器工作！