以下内容假设您重新安装的计算机openssh-server和您正在ssh使用的计算机是不是“Ubuntu”,即您通过 访问的机器ssh me@Ubuntu。

以下内容假设您重新安装的计算机openssh-server和您正在ssh使用的计算机是不是“Ubuntu”,即您通过 访问的机器ssh me@Ubuntu。

出现了非常奇怪的行为ssh。我的 ssh-server 运行正常,配置ufw(防火墙)也正常。但是,似乎我无法将其ssh作为服务或通过进行管理/etc/init.d/ssh

我特意重新安装了openssh-server以确保我的小配置调整不会/etc/ssh/sshd_config造成问题。

Ubuntu:~/$ sudo /etc/init.d/ssh status

Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh status

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the status(8) utility, e.g. status ssh
ssh stop/waiting

Ubuntu:~/$ sudo service ssh status
ssh stop/waiting

但我可以正常使用 ssh(无论是从 Ubuntu [localhost] 还是其他计算机 [远程],假设计算机的名称是 Ubuntu)

otherComputer:~/$ ssh me@Ubuntu
me@Ubuntu's password:
me@Ubuntu:~/$

非常令人沮丧,不知道问题出在哪里。我正在运行gnome-keyring以管理我的ssh-agent和密钥,但这不应该干扰ssh-server服务。

答案1

@alex-l 对我的回答是正确的:

(以 root 身份)

 service ssh status
service ssh stop

然后检查端口是否启动(22)

netstat -nat

就这样

你可以做的另一件事是检查ereytinh是否正常,那就是从其他机器上

ssh -v user@ubuntu-machine

答案2

以下内容假设您重新安装的计算机openssh-server和您正在ssh使用的计算机是不是“Ubuntu”,即您通过 访问的机器ssh me@Ubuntu


我认为您的问题是混淆了 ssh 守护进程和 ssh 客户端之间的区别。ssh 守护进程 ( ) 是允许您或其他人进入守护进程所运行的计算机的sshd程序。运行时,您正在向 发出命令,即启动或停止或其他操作。sshsudo service ssh <whatever>sshd

ssh 的另一部分是 ssh 客户端。这是您在终端中运行时启动的程序。这是一个独立的程序,它与在名为“ ”的计算机上运行的 ssh 守护程序连接。要正常工作,它要连接的计算机上必须运行 ssh 守护程序,但不必在自己的计算机上运行 ssh 守护程序。ssh [email protected]host.namessh

这一切意味着您的计算机运行正常。ssh只要有网络,您就可以连接到远程服务器。

事实上,您可能应该openssh-server从计算机中删除该软件包,因为如果它没有被使用,它只会带来安全风险。

答案3

值得了解的是,据我所知,“service ssh [stop|status]”命令适用于 /var/run/sshd.pid 中标识的进程,但如果它们不匹配,则可以通过运行“sudo netstat -lpn |grep ssh”来识别实际的进程监听,这就是造成混淆的原因。

在我的计算机上看到的是:-

root@babypuss:/var/www/middletier# ls /var/run/sshd.pid
/var/运行/sshd.pid
root@babypuss:/var/www/middletier# cat /var/run/sshd.pid
10959
root@babypuss:/var/www/middletier# ps ax |grep sshd
10959?Ss 0:00 /usr/sbin/sshd -D

如果 pid 不匹配,则(以 root 身份)终止正在运行的 sshd 进程,然后使用“service ssh start”重新启动它,以查看会发生什么。

但正如之前所说,如果在 Ubuntu 机器上,您可以运行“ps ax |grep sshd”并且看不到任何正在运行的内容,然后通过“netstat -lpn |grep 22”断言没有任何东西在端口 22 上监听,以检查它是否不是某种 xinet 类型的服务。如果真的没有任何东西在监听,那么最可能的问题是您从其他地方连接的机器不是您正在查看的机器(因此请检查@otherComputer 上的 /etc/hosts 文件)。

如果您有 90% 的把握它正在连接到您认为的机器,那么请在每台机器上使用“netstat -n |grep -v ^unix”仔细检查,以识别实际的连接以及连接时在 @Ubuntu 上运行的 shell。

如果您真的看不到监听服务,那就要当心了。它可能是一个 rootkit。尝试关闭计算机并尝试重新连接,以确保您连接到您担心的机器。

相关内容