我的 Debian 服务器上运行 OpenSSH 服务器已经有几周了,现在当我第二天登录时,它突然拒绝我的 ssh 密钥,我每次都必须手动添加一个新密钥。
不仅如此,我还启用了“使用明文密码进行隧道传输”选项,并且非 root(使用 root 登录被禁用)帐户也被拒绝。
我不知道为什么会发生这种情况,并且我找不到任何可以解释它的 ssh 选项。
- 更新 -
我刚刚将调试级别更改为 DEBUG。但在此之前,我在 auth.log 中看到了很多以下内容
Feb 1 04:23:01 greenpages CRON[7213]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 1 04:23:01 greenpages CRON[7213]: pam_unix(cron:session): session closed for user root
...
Feb 1 04:36:26 greenpages sshd[7217]: reverse mapping checking getaddrinfo for nat-pool-xx-xx-xx-xx.myinternet.net [xx.xx.xx.xx] failed - POSSIBLE BREAK-IN ATTEMPT!
...
Feb 1 04:37:31 greenpages sshd[7223]: Did not receive identification string from xx.xx.xx.xx
...
我的 sshd_conf 文件设置是:
# Package generated configuration file
# See the sshd(8) manpage for details
# What ports, IPs and protocols we listen for
Port xxx
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel DEBUG
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM no
ClientAliveInterval 60
AllowUsers myuser
答案1
我的第一个猜测是,这是客户端计算机上的 ssh-agent 的问题。下次发生这种情况时,请ssh-add -l
在客户端上运行并查看是否有任何密钥报告为已加载。如果没有,请尝试
eval `ssh-agent`
ssh-add
添加它们,然后尝试 ssh 进入服务器。如果成功,则说明问题已经解决。您可以关注这些说明用于在 Debian 启动时自动执行 ssh-agent。
另一个可以尝试的方法是,当你通过 ssh 进入服务器时,使用以下命令调高日志记录级别:
ssh -vvv server.example.com
并查看调试输出以确定失败的位置。在服务器上,/var/log/auth.log
或者/var/log/messages
可能会提供一些线索,特别是如果您/etc/ssh/sshd_config
在服务器上编辑,将调试级别更改为 DEBUG,然后kill -HUP
服务器 ssh 进程强制其重新加载其配置。这将在服务器日志中放入更多信息供您查看。请记住在解决问题后将日志记录级别调回原位。
答案2
我猜你可能在 ssh 进入或退出时遇到正向查找或反向查找问题。对于这两个系统,请确保你可以进行正向/反向查找,并且你的名字不会同时匹配。
IE
dig sys_hostname.domain.dom 结果:10.10.10.1
dig -x 10.10.10.1 结果:sys_hostname.domain.dom