我刚刚升级(Linode VM)Ubuntu 9.04到9.10使用do-release-upgrade (以root身份)。 现在,ssh不工作。
起初,我刚刚得到“连接超时”。 所以,我去了Linode的网站,并使用他们的“lish ajax控制台”。 不知道这是如何不同于SSH,因为它使用相同的root密码(仍然有效)。 在那里,我发现文件系统被安装为只读。 我通过执行mount -t ext2 -o rw,remount /dev/hda6 / ,但是仍然没有ssh连接。 我然后(仍然使用Lindes网站上的“lish ajax控制台”)使用命令dhclient eth0 ,现在我得到“连接被拒绝”,而不是“连接超时”,这有点像进步,但不是太多。
所以,我可以说从9.04升级到9.10并不是特别好。 我仍然可以使用Linode的“lish ajax控制台”查看我的所有文件,但是我不知道如何让ssh工作,毫不奇怪,这个服务器上的网站也无法访问。
由于“lish ajax控制台”使用相同的root密码,所以我猜测它仍然有效,至今我所查找的所有文件都没有丢失。 但是,我必须做一些其他的事情才能让ssh再次工作。 有任何想法吗?
ps好的,感谢提示,这里的结果到目前为止:
/etc/init.d/ssh status could not access PID file for sshd /etc/init.d/ssh start Starting OpenBSD Secure Shell server sshd /etc/init.d/ssh status sshd is running
听起来不错,但是当我试图在我得到时:
服务器拒绝分配pty stdin:不是一个tty
我在互联网上search了一下,发现要试试这个:
/sbin/MAKEDEV pty /sbin/MAKEDEV tty
但是,没有改善。
ifconfig eth0
这确认了IP地址(“inet addr:”)是我所期望的。
iptables -I INPUT -p tcp --dport -j ACCEPT bash: iptables: command not found
我发现它没有听说过iptables有点令人惊讶,但是我知道什么。 我只能在auth.log中find这个,不是从现在开始,而是从几个小时前。
root@localhost:/var/log# tail -f /var/log/auth.log Apr 16 15:05:50 li9-111 sshd[10704]: pam_unix(sshd:auth): authentication failure; logname= uid=0 eui d=0 tty=ssh ruser= rhost=60.10.58.156 user=root Apr 16 15:05:52 li9-111 sshd[10704]: Failed password for root from 60.10.58.156 port 32776 ssh2 Apr 16 15:05:58 li9-111 sshd[10706]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156 user=root Apr 16 15:06:00 li9-111 sshd[10706]: Failed password for root from 60.10.58.156 port 33096 ssh2 Apr 16 15:06:03 li9-111 sshd[10708]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156 user=root Apr 16 15:06:05 li9-111 sshd[10708]: Failed password for root from 60.10.58.156 port 33588 ssh2 Apr 16 15:06:11 li9-111 sshd[10710]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156 user=root Apr 16 15:06:14 li9-111 sshd[10710]: Failed password for root from 60.10.58.156 port 33927 ssh2 Apr 16 15:06:16 li9-111 sshd[10712]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=60.10.58.156 user=root Apr 16 15:06:18 li9-111 sshd[10712]: Failed password for root from 60.10.58.156 port 34404 ssh2
在系统日志中,我能find的是:
root @ localhost:/ var / log#tail -f / var / log / syslog
Apr 16 15:05:19 li9-111 mysqld: Active alarms: 0 Apr 16 15:05:19 li9-111 mysqld: Max used alarms: 1 Apr 16 15:05:19 li9-111 mysqld: Next alarm time: 0 Apr 16 15:05:19 li9-111 mysqld: Apr 16 15:05:19 li9-111 mysqld: Begin safemalloc memory dump: Apr 16 15:05:19 li9-111 mysqld: Apr 16 15:05:19 li9-111 mysqld: End safemalloc memory dump. Apr 16 15:05:48 li9-111 dhclient: DHCPREQUEST of 67.18.176.111 on eth0 to 72.14.180.19 port 67 Apr 16 15:05:48 li9-111 dhclient: DHCPACK of 67.18.176.111 from 72.14.180.19 Apr 16 15:05:48 li9-111 dhclient: bound to 67.18.176.111 -- renewal in 35362 seconds.
最后,
root@localhost:/var/log# netstat -ntlp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 891/sshd tcp6 0 0 :::22 :::* LISTEN 891/sshd
非常感谢所有帮助到目前为止,任何进一步的build议是非常感谢。 最后一个注意事项:为防万一以上的事情不会重新启动,我试了一下,结果是一个倒退(没有响应尝试SSH)。 所以,我回到顶端,并试图:
root@localhost:~# /etc/init.d/ssh status * could not access PID file for sshd root@localhost:~# /etc/init.d/ssh start * Starting OpenBSD Secure Shell server sshd [ OK ] root@localhost:~# /etc/init.d/ssh status * could not access PID file for sshd
这似乎也许倒退了一步。 无论如何,任何帮助或build议表示赞赏。
首先确保ssh正在运行,你可以通过
/etc/init.d/ssh status
如果没有运行,则使用相同的命令启动它,但用start来replace状态。
如果这不起作用,请检查您的接口configuration,以确保您连接到正确的IP。
ifconfig eth0
既然你使用dhcp来获得IP,这可能已经改变了。
有可能你的防火墙可能会阻塞它,你可以打开端口22(它应该被默认打开):
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
最后在尝试连接时发布/var/log/auth.log and /var/log/syslog的内容。
那么,问题似乎是一个Linode特定的问题。 在虚拟机的configuration文件中,“内核”设置设置为“最新的2.6 Legacy(2.6.18.8-linode22”),我不得不把它改成“最新的2.6 Paravirt(2.6.38-linode31 )“,然后SSH(和从这个服务器提供的网站)都回来了。
我猜想,linodeconfiguration的内核只能用于比9.10更早的Ubuntu版本。 坦率地说,我认为os升级过程会照顾到这一点,但是我并不是很了解VMconfiguration文件和VM操作系统如何交互,所以我能够陷入困境并不奇怪,我想。
我想也许可以借鉴的一个教训是,如果让你的服务器操作系统远离过时,升级path所需要的奇怪的东西并不总是在最新的文档中,因为我的上帝仍然在旧的版本。 尽pipe如此,在尝试升级到下一个更新的操作系统之前,我将不得不深深吸了一口气,想一想。
我想我的下一个服务器故障的问题,我将需要问服务器操作系统升级策略…