每天都会拒绝 ssh 密钥

每天都会拒绝 ssh 密钥

我的 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

相关内容