sshfail2banFedora 23 Serverのバージョンをインストールし、ユーザー設定に加えてsamba管理上の作業はほとんどありませんでした。
ある日、システムが完全にロックされていて、ssh_exchange_identification: read: Connection reset by peerインターネット検索をしてメッセージを見つけました。ssh_exchange_identification：読み取り：ピアによる接続のリセット
だから私はfail2ban禁止に関連していると仮定しています。大きな問題ではありません。ただ「物理的に」マシンにログインしてリセットするだけです。これを試した後、私のコンソール水に浸るログメッセージが含まれています（「systemd.service何かを読むことしかできません」という覚えていません）。この洪水によりログインできなくなりました。資格情報の入力を開始すると、ログ・メッセージが印刷され、資格情報がリセットされると破損します。
強制的に再起動する必要がありました。リセットボタンを押すか、本機の電源ボタンを長押しします。
問題の根本原因を把握し、何が間違っているのかを把握したかったときにログ破棄をしました。しかし、理由が見つからないようです。
これにより、journalctl --since 2016-04-10次のような結果が得られます。
Apr 10 12:19:32 Server smartd[620]: Device: /dev/sdc [SAT], 47 Currently unreadable (pending) sectors
-- Reboot --
Apr 11 20:27:53 Server systemd-journal[148]: Runtime journal is using 8.0M (max allowed 81.0M, trying to leave 121.5M free of 802.5M available → current limit 81.0M).
問題が始まったと仮定し、ハード再起動を実行するまですべてのログを削除しました。 （/dev/sdcドライブを受け取った後、ドライブでこのエラーが発生しました。）
私も読んでいます。https://freedesktop.org/wiki/Software/systemd/Debugging//var/log/messagesログを確認する必要があります。
私が見ることができる関連部分は
Mar 6 18:52:49 Server audit: USER_AUTH pid=3435 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/sbin/sshd" hostname=183.3.202.108 addr=183.3.202.108 terminal=ssh res=failed'
Apr 11 20:28:46 Server rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting
Apr 11 20:39:15 Server rsyslogd-2177: imjournal: 91404 messages lost due to rate-limiting
Apr 11 20:39:15 Server dnf: repo: using cache for: rpmfusion-free
これは91404のログメッセージがあることを知らせます。しかし、私はそれらのどれも見つけることができませんでした。みんな私が知っている限り、それは捨てられました。
私のシステムが正確に「壊れた」ものが何であるかを知りたい場合は、ログを保存できる他の場所にありますか？それとも、同じ問題が再び発生しないように星に祈る必要がありますか？
ベストアンサー1
注：私の疑いを確認するための追加の証拠はありません。これは単なる仮説的な推測です。
「読み取り専用」の内容があると言われました。システムがディスク（またはケーブルまたはSATAインターフェイスなど）から回復できない破損またはハードウェア障害を経験した可能性があり、追加の損傷/損傷を防ぐために、ルートファイルシステムを読み取り専用で再マウントしてください。
できるだけ早く実行する必要がある最も重要なことは1.バックアップが最新であることを確認します。 2. ディスクを徹底的にテストします（例：テストパスsmartctl）。それ以外の場合は失敗する可能性があります。
しかし、ロギングの問題に戻って：
ルートファイルシステム（または/var/log）が読み取り専用の場合、ディスクにログは書き込まれません。
ログメッセージを転送できる他のシステムがある場合は、ローカルファイルとリモートシステムの両方にログするようにrsyslogを設定することをお勧めします。このシステムは、リモートシステムにも同じサービスを提供できます。
ganeshたとえば、私のシステム（と）の両方にkali次のものがあります/etc/rsyslog.d/00remote.conf。
$ModLoad imudp # provides UDP syslog reception
$UDPServerAddress 0.0.0.0
$UDPServerRun 514
if $fromhost-ip == '127.0.0.1' and $syslogfacility-text == 'kern' then @kali
上記のファイルですganesh。 onで置き換えられているkaliことを@kali除いて同じです@ganesh。
これにより、kernローカルホストで発生したすべての施設ログエントリがリモートロギングホストに転送されます。 IPアドレス解決は、リモートロギングループの競合を防ぎます。
代わりに、ベースロギングをrsyslog含むリモートロギングを設定するために使用できる他の方法があります。これは数年前に必要なときに試した最初の方法です。動作し、シンプルで変更する必要はありませんでした。まだです。 tcpudpこのサイトを検索他の方法と詳細についてはこちらをご覧ください。
ちなみに、ファイアウォールがUDPポート514に入ってくるトラフィックをブロックしていることを確認してください。