SSH限制

简介

SSH (OpenSSH) 提供到远程主机的安全加密连接。如果用户有有效的 AIX® 帐户,就可以通过 SSH 连接。但是,对于任何关注安全性的系统来说,很可能需要限制某些用户或主机通过 SSH 连接指定的系统。SSH 提供两种限制用户访问的机制:Deny 和 Allow 属性。这些关键词基于用户和组列表。还可以使用 TCP Wrappers 阻止来自已知或未知主机的 SSH 连接。我建议使用 TCP Wrappers 按主机名/域或 IP 阻止主机,并且使用 sshd_config 实现基于用户/组的访问控制。

根据安装的 SSH 变体不同,可以在两个地方找到配置文件和 SSH 守护进程。对于 AIX OpenSSH,配置文件在 /etc/ssh 中,SSH (sshd) 守护进程在 /usr/sbin/sshd 文件中。

对于其他 OpenSSH 类型,配置文件通常在 /usr/local/etc 中,SSH (sshd) 守护进程在 /usr/local/sbin/sshd 中。

用 TCP Wrappers 限制 SSH

TCP Wrappers 用于阻止或允许从 inetd 启动的基于 TCP 的应用程序,比如 telnetFTP 服务。根据规则,SSH 不从 inetd 启动。如果希望通过 TCP Wrappers 控制 SSH 访问,就需要把 libwrap.a 复制到 LIBPATH 指向的目录中(对于第三方应用程序,这个目录是 /usr/local/lib)。TCP Wrappers 守护进程是 tcpd

查看 /var/adm/messages 文件,可能会找到 SSH 连接尝试。这些可能是来自您的网络中本地机器的完全无恶意的连接尝试,也可能是来自未知主机的强力连接尝试。应该进一步研究这些条目。如果发现有非法访问尝试,就应该阻止它们。尽管可以使用 sshd_config 文件阻止主机,但是我建议使用 TCP Wrappers 阻止主机,因为这是阻止到达的 TCP 连接的主要机制。

TCP Wrappers (tcpd) 通过读取两个文件决定应该允许还是拒绝到达的 TCP 连接。这两个文件是:

/etc/hosts.allow
/etc/hosts.deny

对这两个文件的修改是动态的。这两个文件中的模式匹配规则控制拒绝或允许什么。这些规则既可以很复杂,也可以很简单。首先搜索 hosts.allow。如果找到匹配的模式,就允许连接,或者更准确地说,tcpd 死亡,让真正提供服务的守护进程接管。然后在 hosts.deny 中搜索匹配的模式。如果找到匹配,tcpd 就拒绝此连接访问系统。简单地说,这意味着先应用 hosts.allow 规则,然后应用 hosts.deny 规则。一般的做法是先允许您信任的主机,然后拒绝所有其他主机。

现在,我们通过一些示例了解 TCP Wrappers 如何控制对主机的 SSH 访问。假设我们属于 drwho.com 域,希望只允许属于这个域的用户通过 SSH 连接。可以使用以下规则来实现:

# cat hosts.allow
sshd : .drwho.com

# cat hosts.deny
ALL : ALL

为了进一步细化前面的示例,我们仍然允许来自 drwho.com 域的所有连接,同时也允许以下 IP 地址范围 172.24.11., 172.24.12.(IP 地址末尾的点号表示要匹配点号后面的任何内容)。注意,在下面的示例中,每个模式由逗号分隔。

# cat hosts.allow
sshd: .drwho.com , 172.24.11. , 172.24.12.

有时候,希望允许域中的所有主机,但是某些主机除外。例如,一个系统是生产系统,不希望允许从开发系统连接它。下面的规则允许前面示例中允许的所有主机,但是以下主机除外:dev01dev02

# cat hosts.allow
sshd: .drwho.com , 172.24.11. , 172.24.12. , EXCEPT dev01, dev02

还可以在 hosts.allowhosts.deny 文件中使用 username@hostname 格式。例如:

dxtans@dev01

可能必须提供 FQDN(完全限定的域名)。为了查明这一点,在消息文件中查看 TCP Wrappers 如何解析主机名,然后相应地修改 hosts.allow 文件。

对于 username@host 格式,我喜欢用 sshd_config 文件控制访问。这是因为这样就可以使用 TCP Wrappers 只为 telnetFTP 等基于 TCP 的服务进行主机身份验证,只用 ssh_config 文件为 SSH 进行用户/组身份验证。从系统管理员的角度来看,这样更容易管理主机和用户访问控制。

要想通过 syslog 把连接记录在 /var/adm/messages 中,在 /etc/syslogd.conf 中必须有以下条目之一:

*.info /var/adm/messages

*.auth /var/adm/messages

必须重新启动 syslogd,修改才能生效:

# refresh -s syslogd

在消息文件中,成功连接的典型条目(在这里,用户 dxtans 来自属于 drwho.com 域的主机 tardis)如下:

May 25 19:04:46 rs6000 auth|security:info sshd[245928]: Accepted password for dx``tans from tardis port 49371 ssh2

由于应用了 hosts.allow 文件中的规则,来自主机 dev01 的用户的连接尝试被拒绝,其消息如下:

May 25 19:11:12 rs6000 auth|security:info sshd[270484]: refused connect from dev01

用 sshd_config 限制连接

sshd_config 中,有四个条目:

AllowUsers
AllowGroups
DenyUsers
DenyGroups

如果没有这些关键词,只需根据需要创建它们。必须只创建您需要的关键词,以免出现不可靠的结果。AllowUsers 和 DenyUsers 列表是由空格分隔的有效用户名,AllowGroups 和 DenyGroups 只能是现有的有效组。按以下次序匹配模式:DenyUsers,AllowUsers,DenyGroups,AllowGroups

sshd_config 文件的任何修改要到重新启动 sshd 之后才会生效,如下所示:

# stopsrc -s sshd
# startsrc -s sshd

如果在 AllowUsers 列表中设置用户 ID,那么只有这些用户可以通过 SSH 连接。对于 DenyUsers 列表也是如此,只拒绝 DenyUsers 列表中包含的用户访问。同样的规则也适用于组列表。如果同时使用允许列表和拒绝列表,就非常让人迷惑,所以不要这样做。应该根据自己的安全需求,只使用允许列表或拒绝列表之一。

如果用户在系统上有帐户,但是在 AllowUsers 列表中没有他们的用户 ID,就拒绝他们访问。同样的规则也适用于 DenyUsers 列表。现在来看一个示例,假设 AllowUsers 列表包含以下内容:

AllowUsers bravo charlie mother oscar delta echoa hotel juliet papa ukflag

如果用户 alpha 尝试通过 SSH 访问,那么该访问会遭到拒绝,因为这个用户名没有出现在 AllowUsers 列表中。

login as: alpha
alpha@rs6000's password:
Access denied
alpha@rs6000's password:
Access denied
alpha@rs6000's password:

通过查看 /var/adm/messages 文件确认这一点,这里的消息表明在 AllowUsers 列表中没有列出用户 alpha。

Jun 22 18:43:41 rs6000 auth|security:info sshd[270552]: User alpha from tardis 
not allowed because not listed in AllowUsers
Jun 22 18:43:41 rs6000 auth|security:info sshd[270552]: Failed none for invalid
user alpha from tardis port 49617 ssh2

现在看看 DenyUsers 列表,假设这个列表包含以下内容:

DenyUsers bravo charlie mother oscar delta echoa hotel juliet papa ukflag

现在,只要用户在系统上有帐户,而且其用户名没有在 DenyUsers 列表中列出,就允许他们通过 SSH 访问。

如果用户 alpha 尝试通过 SSH 访问,那么允许此用户访问,因为他的用户名没有包含在 DenyUsers 列表中。可以通过查看消息文件确认这一点:

Jun 22 18:52:48 rs6000 auth|security:info sshd[250040]: Accepted password for 
alpha from tardis port 49634 ssh2

但是,如果 DenyUsers 列表中包含的用户 bravo 尝试通过 SSH 访问,其访问会遭到拒绝:

login as: bravo
bravo@rs6000's password:
Access denied
bravo@rs6000's password:

同样,可以通过查看消息文件检查拒绝的原因:

Jun 22 18:54:03 rs6000 auth|security:info sshd[245962]: User bravo from tardis 
not allowed because listed in DenyUsers
Jun 22 18:54:03 rs6000 auth|security:info sshd[245962]: Failed none for invalid
user bravo from tardis port 49635 ssh2

要保持简单。使用 AllowUsers 列表只允许您希望的用户访问。拒绝其他所有用户;不需要添加 DenyUsers 列表。

为了避免模式匹配产生出乎意料的结果,我强烈建议不要同时使用组列表和用户列表,而是只使用用户列表(允许或拒绝)或组列表(允许或拒绝)之一。

现在看看不适当的设置会造成怎样的混乱,假设设置了以下条目:

AllowUsers alpha
DenyUsers bravo charlie mother oscar delta echoa hotel juliet papa ukflag

考虑到模式匹配次序,我们现在可以声明,对 DenyUsers 列表中包含的用户都不授予任何访问权,只允许用户 alpha 访问。对于这种情况,我建议只使用 AllowUsers 列表。如果用户 ID 没有在允许列表中列出,就不能连接,无论拒绝列表包含哪些用户。

同样的原则也适用于组。假设设置了以下条目:

AllowGroups water
DenyGroups nossh

water 组的成员是:

# lsgroup -a users water
water users=delta,echoa,golf,plutt

现在,如果用户 dxtans(staff 和 admin 组的成员)

# id dxtans
uid=203(dxtans) gid=1(staff) groups=205(admin)

尝试连接,那么访问会失败,在 /var/adm/messages 中会记录以下条目:

Jun 30 19:50:26 rs6000 auth|security:info sshd[278732]: User dxtans from tardis
not allowed because none of user's groups are listed in AllowGroups

这是因为 dxtans 不在允许列表中,也不在拒绝列表中。

创建一个不允许通过 SSH 访问的用户组可能有好处,因为这会减少维护工作量,然后创建一个允许通过 SSH 访问的用户组。例如,假设有一个称为 nossh 的组,其中包含不允许通过 SSH 访问的用户:

# lsgroup -a users nossh
nossh users=golf,hotel,india,julie

sshd_config 文件中,有以下条目:

DenyGroups nossh

现在,属于 nossh 组的所有用户都被拒绝访问。例如,当属于 nossh 组的用户 golf 尝试通过 SSH 访问时,在消息文件中可以看到以下消息:

Jun 22 19:40:36 rs6000 auth|security:info sshd[278778]: User golf from tardis 
not allowed because a group is listed in DenyGroups

如果系统上的用户很多,使用组列表可能比用户列表更合适。

控制 root 访问

在处理来自远程主机的直接 root SSH 访问时,我建议最好限制能够作为 root 用户通过 SSH 连接的主机。这种方式让管理员可以控制 root 用户能够从哪里通过 SSH 连接,由此控制远程 root 连接。

为了通过 sshd_conf 文件控制用户和主机的访问,可以使用以下格式:root@root@

需要查看 SSH 在 /var/adm/messages 文件中采用什么格式,主机是解析为短主机名还是长主机名。查明这一点之后,只需在 AllowUsers 列表中加入相应的条目。如果不确定是短主机名还是长主机名(因为这取决于发起 SSH 连接的操作系统),那么最好同时包含这两种形式。

例如,要想只允许来自主机 tardis(属于 drwho 域)的 root 访问,可以使用以下设置:

AllowUsers root@tardis root@tardis.drwho.com

当然,在真实环境中,上面的列表还包含其他用户。

如果您有一台部署服务器,且只有该部署服务器上的 root 用户(在上面的示例中)可以从一个指定主机通过 SSH 和 SCP 访问所有客户机,那么非常适合采用以上方法。

自动生成用户列表

自动生成用户列表作为允许或拒绝列表是有好处的。随着时间的推移,经常会添加和删除用户,所以很容易忘记更新列表。应该生成什么列表呢?我建议只生成允许列表。判断用户是否不在 AllowUsers 列表中更方便。如果用户不在此列表中,就拒绝访问。按照什么规则允许用户进入 AllowUsers 列表呢?先考虑用户的属性是否表明他可以执行远程 rlogin/telnet (rlogin=true),然后考虑为什么不允许他通过 SSH 访问。采用这个规则就会立即排除所有系统和应用程序所有者帐户,只留下普通用户。

在典型的系统上,所有系统帐户和应用程序所有者应该是不可登录的。因此,只能通过 su 或 sudo 访问这些帐户。

只在处理特殊事件时手动编辑列表,比如在应用程序交付期间进一步允许(或拒绝)临时访问。清单 1 演示一种实现方法。首先确定 sshd_config 文件的位置,这样就知道要更新的 SSH 版本。接下来,收集主机上 rlogin 属性为 true 的所有用户,但是不包括 root 用户。然后,读取 /tmp/ssh_ignore 文件,从生成的用户列表中删除匹配的所有用户。使用 ssh_ignore 文件让管理员能够方便地控制哪些用户不应该出现在 sshd_config 文件中的允许用户列表中。

此文件的格式如下:

user1
user2
user..

然后,提取 sshd_config 文件中的 AllowUsers 列表并与生成的用户列表进行对比。如果有不同之处,就更新 sshd_config 文件。注意,列表包含 root@tardis 的短名称和长名称。正如前面提到的,这意味着只有来自主机 tardis 的 root 用户可以通过 SSH 访问。如果 sshd_config 有任何变动,就重新启动 SSH 服务并向管理员发送电子邮件,通知 sshd_config AllowUsers 列表的变动。

此脚本假设已经存在 AllowUsers 列表条目,而且列表至少包含部署服务器的条目,比如:

AllowUsers root@tardis root@tardis.drwho.com

这是主机名, root 用户只能从这个主机连接。在此示例中,列表同时包含短主机名和长主机名(主机名是 tardis)。根据自己的需要修改脚本,把主机 tardis 替换为自己的主机。可以用您喜欢的调度程序每天运行此脚本一次,从而及时更新用户列表。

清单 1. pop_user_allow_ssh
#!/bin/sh
#set -x 
# pop_user_allow_ssh
# populate UserAllow entries in sshd_conf
# if rlogin is true 
 
host=$(hostname)
log=/opt/dump/ssh_pop.log
>$log
 
if [ -f /usr/local/etc/sshd_config ]
  then
   sshd_conf="/usr/local/etc/sshd_config"
fi
  
if [ -f /etc/ssh/sshd_config ]
  then
   sshd_conf="/etc/ssh/sshd_config"
fi
 
 
echo " on ${host}: ssh config to use: [$sshd_conf]" | tee -a $log
 
# check if we need to run..any user adds/deletes
pre=`grep -w ^AllowUsers $sshd_conf`
pre=$(echo $pre | sed s/root@tardis.drwho.com//g |sed 
s/root@tardis//g|sed s/AllowUsers//g)
curr=$(lsuser -a rlogin ALL |grep true| grep -v root| awk '{print $1}')
 
# check for ignores - do NOT add to allow list
if [ -f /tmp/ssh_ignore ]
 then
cat /tmp/ssh_ignore|while read user
 do
   new_curr=$(echo $curr | tr ' ' '\n' | grep -v '^'$user'$' | tr '\n' ' ')
    echo "[$user]"
   curr=$new_curr
 
 done
fi
   echo "curr [$curr]"
  echo "pre [$pre]"
 
echo $curr >/tmp/curr.txt
echo $pre >/tmp/pre.txt
diff /tmp/curr.txt /tmp/pre.txt 2>&1
if [ $? = 0 ]
  then
   echo "no user adds/deletes detected on system"| tee -a $log
   exit 0
   else
    echo "changes detected..re-populating" |tee -a $log
fi
 
cp $sshd_conf $sshd_conf.bak
 
sed '/AllowUsers/d' $sshd_conf >$sshd_conf.$$
echo "AllowUsers root@tardis root@tardis.drwho.com" $curr >>$sshd_conf.$$
mv $sshd_conf.$$ $sshd_conf
stopsrc -s sshd
sleep 2
startsrc -s sshd
 
# next determine change and  email out change
>/tmp/curr.txt2
>/tmp/pre.txt2
cat /tmp/curr.txt|tr " " "\n" |
 while read name
 do
 echo $name >>/tmp/curr.txt2
 done 
 
 cat /tmp/pre.txt| tr " " "\n" |
 while read name
  do
  echo $name >>/tmp/pre.txt2
  done
  
diff /tmp/pre.txt2 /tmp/curr.txt2 >/tmp/allow_diff.txt
changelist=$(cat /tmp/allow_diff.txt | egrep "<|>" | sed 's/[<>]//g')
 
list="admins@drwho.com"
 
 
mail -s "`hostname` allowed users sshd_config change" $list <<mayday
Host: `hostname`
SSH: $sshd_conf
The following users have been either added or deleted in AllowUsers:
 
$changelist
 
mayday

调试

要启用调试,消息文件提供的信息是不够的。在客户端,可以在通过 SSH 连接时使用详细(v)选项,v 越多,输出越详细:

ssh -vv -l <login> <hostname>

在服务器端,停止 sshd 服务,然后带调试选项启动它。调试(d)意味着输出更详细。在进行连接时,sshd 将终止。然后需要在调试模式下再次重新启动它(如果需要进一步测试的话),或者通过 startsrc 命令以正常方式重新启动它。使用以下命令在调试模式下启动:

# /usr/sbin/sshd -dd

如果在尝试通过 SSH 连接时发现了问题,而且问题的原因不明,那么我建议同时使用客户机和服务器调试方法诊断问题。

在调试模式下启动 sshd 的典型输出如下:

# /usr/sbin/sshd -dd
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 277
debug2: parse_server_config: config /etc/ssh/sshd_config len 277
debug1: sshd version OpenSSH_5.0p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
…..
debug2: parse_server_config: config reprocess config len 277
User bravo from rs6000 not allowed because listed in DenyUsers
input_userauth_request: invalid user bravo

如果在调试模式下启动 sshd,会在标准输出中报告 sshdsshd_conf 中找到的错误。如果用 startsrc 命令启动 sshd,在 sshd_conf 中找到的错误会显示在 /var/adm/messages 文件中。还可以使用以下方法检查最后存在的状态(可以判断配置是否有问题):

# /usr/sbin/ssh -t
# echo $?

但是,在诊断与 SSH 相关的问题时,应该首先使用调试方法。

结束语

SSH 可以提供到远程主机的安全加密连接。但是,对于到达的连接请求,需要加以限制。可以使用 TCP Wrappers 和 sshd_config 中的 Allow/Deny 列表实现前瞻性的安全保护。

分类: ssh | 留下评论

ssh无法启动 (code=exited, status=255)

服务器运行了一些脚本后,突然发现无法ssh了。

root@X61T:/home/liang# service sshd restart
Job for ssh.service failed because the control process exited with error code.
See "systemctl status ssh.service" and "journalctl -xe" for details.

使用systemctl检查状态

Systemd是一个系统管理守护进程、工具和库的集合,用于取代System V初始进程。Systemd的功能是用于集中管理和配置类UNIX系统。在Linux生态系统中,Systemd被部署到了大多数的标准Linux发行版中,只有为数不多的几个发行版尚未部署。

常用的systemctl命令:

systemctl list-unit-files                               列出所有可用的单元
systemctl list-units                                     列出所有运行中单元
systemctl --failed                                        列出所有失败单元
systemctl status firewalld.service           检查某个单元或服务是否运行
systemctl list-unit-files --type=service    列出所有服务(启用和禁用)
systemctl start httpd.service                    启动
systemctl restart httpd.service                 重启
systemctl stop httpd.service                     停止
systemctl reload httpd.service                 重载服务
systemctl status httpd.service                  检查状态

检查一下ssh.service的状态

root@X61T:/home/liang# systemctl status ssh.service

发现

Process: 3448 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
Process: 3445 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
......
Jan 30 08:18:03 X61T systemd[1]: Starting OpenBSD Secure Shell server...
Jan 30 08:18:03 X61T systemd[1]: ssh.service: Main process exited, code=exited, status=255/n/a
Jan 30 08:18:03 X61T systemd[1]: Failed to start OpenBSD Secure Shell server.
Jan 30 08:18:03 X61T systemd[1]: ssh.service: Unit entered failed state.
Jan 30 08:18:03 X61T systemd[1]: ssh.service: Failed with result 'exit-code'.
使用journalctl访问内部的数据
root@X61T:/home/liang# journalctl -u ssh.service

Jan 30 08:18:03 X61T systemd[1]: Starting OpenBSD Secure Shell server...
Jan 30 08:18:03 X61T systemd[1]: ssh.service: Main process exited, code=exited,
Jan 30 08:18:03 X61T systemd[1]: Failed to start OpenBSD Secure Shell server.
Jan 30 08:18:03 X61T systemd[1]: ssh.service: Unit entered failed state.
Jan 30 08:18:03 X61T systemd[1]: ssh.service: Failed with result 'exit-code'.

systemd尝试提供一套集中化管理方案,从而统一打理全部内核及用户级进程的日志信息。这套系统能够收集并管理日志内容,而这也就是journal。journal的实现归功于journald守护进程,其负责处理由内核、initrd以及服务等产生的信息。

对比一下 init.d 和 systemd :

service daemon-----------------------> rsyslog -----------------------------------> /var/log

systemd ----------> systemd-journald ---> ram DB ----> rsyslog ----> /var/log

     当 systemd 启动后,systemd-journald 也会立即启动。将日志存入RAM中,当rsyslog 启动后会读取该RAM并完成筛选分类写入目录 /var/log 。内核启动过程将消息写入到结构化的事件日志中(数据库),默认情况下重启后删除syslog 的信息也可以由 systemd-journald 转发到 rsyslog 中进一步处理默认情况下,systemd 的日志保存在 /run/log/journal 中,系统重启就会清除,这是RHEL7的新特性。通过新建 /var/log/journal 目录,日志会自动记录到这个目录中,并永久存储。rsyslog 服务随后根据优先级排列日志信息,将它们写入到 /var/log目录中永久保存常规操作systemd提供了自己的日志系统(logging system),称为 journal。使用 systemd 日志,无需额外安装日志服务(syslog)。

读取日志的命令:

# journalctl

重要:显示所有的日志信息,notice或warning以粗体显示,红色显示error级别以上的信息

显示最后行数的日志:

# journalctl -n

显示最详细信息:

# journalctl -f

提示:其实它很像tailf命令,默认显示十行。随着匹配日志的增长而持续输出。只显示错误、冲突和重要告警信息

# journalctl -p err..alert

提示:也可以使用数字表示哟。
显示指定单元的所有消息:

# journalctl -u netcfg

重要:一般 -u 参数是 systemctl status 调用的参数之一(journalctl -l 可查看所有)提示:如果希望显示 kernel 的信息需要使用 journalctl -k 进行内核环缓存消息查询。

显示从某个时间 ( 例如 20分钟前 ) 的消息:

# journalctl --since "20 min ago"

# journalctl --since today

# journalctl --until YYYY-MM-DD

显示本次启动后的所有日志:

# journalctl -b

不过,一般大家更关心的不是本次启动后的日志,而是上次启动时的(例如,刚刚系统崩溃了)。可以使用 -b 参数:

journalctl -b -0 显示本次启动的信息

journalctl -b -1 显示上次启动的信息

journalctl -b -2 显示上上次启动的信息

journalctl -b -2 只显示错误、冲突和重要告警信息

显示特定进程的所有消息:

# journalctl _PID=1

1. \_COMM 显示特定程序的所有消息,例如:``journalctl /usr/lib/systemd/systemd``
2. \_EXE 进程的可执行文件的路径
3. \_PID 进程的PID
4. \_UID 运行该进程用户的UID
5. _SYSTEMD_UNIT 启动该进程的 `systemd` 单元
提示:以上筛选条件可组合使用,例如:journalctl _SYSTEMD_UNIT=sshd.service _PID=1182

显示更多输出方案:

# journalctl -o short|short-iso|short-percise|short-monotonic|verbose|export|json|json-pretty|json-sse|cat

进入ssh debug模式

root@X61T:/etc/init.d# /usr/sbin/sshd -d

debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2l  25 May 2017
debug1: private host key #0: ssh-rsa SHA256:yXduj8mTB9Lte+8TNQZPaqHtphuCgTcR18BY9jhY7sY
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:kzdqml9P9ocCIKrNalil5lKOZtY9Eshrn6ntfFKEkFk
debug1: private host key #2: ssh-ed25519 SHA256:nAcGxV9POMZeJxyqOWVsWu1s/WrvQSyhNDj0sQa90KY
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
debug1: Bind to port 22 on ::.
Bind to port 22 on :: failed: Address already in use.
Cannot bind any address.

发现居然22端口被占用了
netstat查出是谁在占用。
root@X61T:/etc/init.d# netstat -apn

列出所有端口 (包括监听和未监听的)
netstat -a                   列出所有端口
netstat -at                   列出所有tcp端口
netstat -au                  列出所有udp端口
列出所有处于监听状态的 Sockets
netstat -l              只显示监听端口
netstat -lt                  只列出所有监听 tcp 端口
netstat -lu                  只列出所有监听 udp 端口
netstat -lx              只列出所有监听 UNIX 端口
显示每个协议的统计信息
netstat -s                  显示所有端口的统计信息
netstat -st                  显示TCP端口的统计信息
netstat -su                  显示UDP端口的统计信息
在netstat输出中显示 PID 和进程名称
netstat –pt
命令如下:
netstat -pan | grep 5623
#其中5623位端口号
netstat 中参数选项
-a或--all:显示所有连线中的Socket;
-A<网络类型>或--<网络类型>:列出该网络类型连线中的相关地址;
-c或--continuous:持续列出网络状态;
-C或--cache:显示路由器配置的快取信息;
-e或--extend:显示网络其他相关信息;
-F或--fib:显示FIB;
-g或--groups:显示多重广播功能群组组员名单;
-h或--help:在线帮助;
-i或--interfaces:显示网络界面信息表单;
-l或--listening:显示监控中的服务器的Socket;
-M或--masquerade:显示伪装的网络连线;
-n或--numeric:直接使用ip地址,而不通过域名服务器;
-N或--netlink或--symbolic:显示网络硬件外围设备的符号连接名称;
-o或--timers:显示计时器;
-p或--programs:显示正在使用Socket的程序识别码和程序名称;
-r或--route:显示Routing Table;
-s或--statistice:显示网络工作信息统计表;
-t或--tcp:显示TCP传输协议的连线状况;
-u或--udp:显示UDP传输协议的连线状况;
-v或--verbose:显示指令执行过程;
-V或--version:显示版本信息;
-w或--raw:显示RAW传输协议的连线状况;
-x或--unix:此参数的效果和指定"-A unix"参数相同;
--ip或--inet:此参数的效果和指定"-A inet"参数相同。

root@X61T:/etc/init.d# service rsync stop

root@X61T:/etc/init.d# /usr/sbin/sshd -d

debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2l  25 May 2017
debug1: private host key #0: ssh-rsa SHA256:yXduj8mTB9Lte+8TNQZPaqHtphuCgTcR18BY9jhY7sY
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:kzdqml9P9ocCIKrNalil5lKOZtY9Eshrn6ntfFKEkFk
debug1: private host key #2: ssh-ed25519 SHA256:nAcGxV9POMZeJxyqOWVsWu1s/WrvQSyhNDj0sQa90KY
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.

root@X61T:/etc/init.d# service rsync stop

root@X61T:/etc/init.d# service ssh start

root@X61T:/etc/init.d# service rsync start

root@X61T:/home/liang# journalctl -u ssh.service

Jan 30 09:21:38 X61T systemd[1]: Starting OpenBSD Secure Shell server...
Jan 30 09:21:38 X61T sshd[6526]: Server listening on 0.0.0.0 port 22.
Jan 30 09:21:38 X61T sshd[6526]: Server listening on :: port 22.
Jan 30 09:21:38 X61T systemd[1]: Started OpenBSD Secure Shell server.

搞定。

下面的资料是为什么Rsync会占用22端口

留下来参考

RSync with a non-standard SSH Port

解决Rsync使用非默认端口SSH问题

分类: ssh | 留下评论

ssh

vi /etc/ssh/sshd_config

  • #PermitRootLogin yes
  • PermitRootLogin no

vi /etc/ssh/sshd_config

  • X11Forwarding yes

shell:

  • xhost +                     //允许服务器的的x11界面连接过来
  • ssh -X foo@ip     //-X参数表示转发X11数据
分类: ssh | 留下评论