sshd的Ubuntu 9.10，并且可以使用登录名和密码成功连接到它。我已经配置了RSA密钥登录名，现在按预期已具有“服务器拒绝了我们的密钥”。好的，现在我要检查sshd日志以找出问题。我已经检查过/etc/ssh/sshd_config，它有SyslogFacility AUTH
LogLevel INFO
好。我正在看
/var/log/auth.log，...它是空的O_O。将Loglevel更改为VERBOSE无济于事-auth.log仍然为空。有什么提示可以检查sshd日志吗？#1 楼
如果此刻没有其他人正在使用该系统，那么您可以做我在这种情况下所做的事情：停止sshd服务（至少我已经能够这样做了通过ssh登录）
手动启动sshd并添加一些-d选项以获得更多详细的调试输出。除非您有一些时髦的事情，否则应该使用正确启动时使用的相同键和配置
评论
在远程服务器上停止SSHD是一个非常糟糕的主意。这可能在大多数情况下可以解决某些（或大多数）设置的问题，但是如果出现任何问题-您的连接，任一端的电源，健忘等-您都无法使用。这是个坏消息。
–失败
2012年11月21日18:58
好吧，应该指出，手动停止服务后才能启动该服务的唯一方法是可以对其进行某种其他访问，例如另一个非SSH远程连接，或者您正坐在它的前面。
–斯潘塞·威廉姆斯
2015年4月23日在16:32
这如何回答这个问题？我通过网络搜索登陆这里，希望学习如何检查SSHD日志文件，而不是什么对某些问题有用的内容...该死，我希望Stack Exchange网络上的读者能够阅读并回答眼前的问题，而不是他们想成为的问题...
–user145545
15年8月23日在16:00
您可以在另一个端口上启动另一个sshd。连接到那个。然后停止主sshd并在端口22上启动新的sshd。如果发生任何故障，请使用DRAC或云管理重新启动该盒。您应该在启动时启动sshd吗？别担心。
–布鲁诺·布鲁诺斯基（Bruno Bronosky）
17年2月17日在14:43
@JoelESalas社区不决定接受哪些答案。
–卡巴斯德
18年2月4日在13:10
#2 楼
根据以上评论创建答案，并归功于@Prof。地狱的Moriarty和@Eye这里记录了SSH身份验证失败
/var/log/auth.log 以下内容应该只给您与ssh相关的日志行
grep 'sshd' /var/log/auth.log 在日志的最后500行中查看sshd条目：
tail -n 500 /var/log/auth.log | grep 'sshd' 或在测试时跟踪日志输出：
tail -f -n 500 /var/log/auth.log | grep 'sshd' 评论
这个答案。其他带有绿色箭头的答案是虚假的。更改箭头。
–user54883
2014年8月4日在23:58
为什么不使用tail -f ...实时监视它？较大的日志文件会不会有问题？
– ingh.am
2015年2月2日，12：12
更少的+ F ...将实时“尾巴”，并且比尾巴强大得多
–northben
2015年5月7日15:45
lnav甚至比少/尾更好
–Wayne Werner
16年1月13日在18:17
附言：如果您的服务器是Red Hat（如CentOS），则sshd / login记录日志的路径为/ var / log / secure（也请检查/ var / log文件夹以获取特定日期的日志文件）。看到这个答案：serverfault.com/questions/465833/…
–布赖恩·赫勒金（Brian Hellekin）
18年1月5日在16:25
#3 楼
如果可以轻松尝试再次失败的连接，一种简单的方法是在免费端口（例如2222）上启动SSH服务器：/usr/sbin/sshd -d -p 2222
，然后重试连接使用：
ssh -p 2222 user@host
通过使用不同的端口
-p 2222，我们不必停止主SSH服务器，这可以将我们拒之门外。另请参见：https://unix.stackexchange.com/a/55481/32558
评论
最佳选择之一，特别是如果您仅具有对服务器的SSH访问权限时。通过停止ssh服务器来调试连接将使您退出会话。只需在其他端口上启动新的ssh守护程序，然后使用该端口测试登录名即可。
–阿蒂拉·安塔尔（Attila Antal）
19-10-15在19:38
@AttilaAntal小更正：停止sshd不会终止活动的ssh会话。如果出现问题，此方法是一个很好的预防措施，但是从理论上讲，您可以通过ssh轻松停止并重新启动sshd。
–派克·肯普（Parker Kemp）
20年2月9日，下午3:35
@ParkerKemp不会终止连接，如果一切正常，重新启动守护程序后，您应该可以继续使用它。但是，问题将是守护程序由于某种原因而无法启动。然后，活动会话将下降。
–阿蒂拉·安塔尔（Attila Antal）
20年10月10日在15:35
#4 楼
如果要查看有关sshd的所有日志消息，请运行以下命令：grep -rsh sshd /var/log |sort
评论
日志将从3月14日19:52:04之类的条目开始，这些条目不包括年份并且不容易排序（尽管您可能会幸运地使用sort --month-sort，前提是您不必跨越年份之间的界限）。日志文件本身已经被排序，因此您只需要以正确的顺序进行扫描即可。同样，在具有大量日志的系统上，递归grep -r调用将非常慢。没有理由额外扫描HTTPD日志之类的内容。
–亚当·卡兹（Adam Katz）
17年8月14日在17:27
thx，我不知道我使用的是哪种口味，但这帮助我找到了/ var / log / secure（我实际上最终将命令更改为grep -Rsl sshd / var / log，但是将+1改为了出现）。
– WEBjuju
19/12/4在0:01
尾-5000f / var / log / messages | grep -i sshd
–水泡花生
20-2-16在18:26
#5 楼
您可以tail -f /var/log/auth.log 评论
欢迎使用ServerFault。你读过这个问题吗？他没有在该文件中获取数据。如果其中没有任何数据，则使它无用。
–小鸡
17年11月10日在1:56
@chicks这很有趣。得票最多的答案几乎是一样的..
– Qback
18年2月9日在7:27
评论
您检查系统日志配置了吗？我没有运行Ubuntu，但是它可能会将AUTH功能重定向到另一个日志文件。也许/ var / log / messages吗？如何检查系统日志配置？不幸的是，我不是一个很好的Linux系统：(。cat / var / log / messages | grep ssh什么也没显示:( ..
你是对的。 /etc/syslog.conf将AUTH重定向到/var/logauth.log。请写下您的答案，以便我可以接受:)
在我的服务器上，sshd记录到/ var / log / secure。这是在/etc/rsyslog.conf中以“ authpriv。*”开头的行中配置的。
authpriv ??我们应该怎么知道这与sshd有什么关系？ :-)