ジャーナルドの一部のsshdログエントリがssh.serviceに属していないのはなぜですか?

ジャーナルドの一部のsshdログエントリがssh.serviceに属していないのはなぜですか?

ジャーナルログを確認するためにJournalctlを使用した場合のコマンド出力

journalctl -u ssh.service

そして

journalctl _COMM=sshd

その他。最初のコマンドは、2番目のコマンドで表されるログエントリのサブセットのみを生成します。ただし、最初の場合にのみ表示されるログエントリと両方の場合に表示されるログエントリの間には明らかな違いはありません。以下は、「-o verbose」形式のほぼ同じ2つのログエントリです。どちらの表示にもその_SYSTEMD_UNIT=ssh.service属性がありますが、それ以外はほぼ同じです。_COMM=sshdどちらの場合も、表示された項目とまったく関係のない項目のみが表示される項目もあります。

この行動の理由は何ですか?

私はsshdバージョン「OpenSSH_7.2p2 Debian-2、OpenSSL 1.0.2g」およびsystemd 229を使用してDebianテストを実行しています。

Tue 2016-04-12 06:43:38.498526 CEST [s=0430cdfa7fb2408cbc98dccb31e42ffc;i=17096e;b=d17df7e99dfa496894cc1e5b6314ffa2;m=6a36040f2c;t=530424
    PRIORITY=6
    _UID=0
    _GID=0
    _CAP_EFFECTIVE=3fffffffff
    _SYSTEMD_SLICE=-.slice
    _BOOT_ID=d17df7e99dfa496894cc1e5b6314ffa2
    _MACHINE_ID=05019d58a4004f9f90c1cfbd295b54ca
    _HOSTNAME=homeserver
    _SYSTEMD_CGROUP=/
    _TRANSPORT=syslog
    SYSLOG_FACILITY=4
    SYSLOG_IDENTIFIER=sshd
    _COMM=sshd
    SYSLOG_PID=31025
    _PID=31025
    MESSAGE=Disconnected from 183.3.202.172 port 36152 [preauth]
    _SOURCE_REALTIME_TIMESTAMP=1460436218498526
Tue 2016-04-12 06:43:38.498459 CEST [s=0430cdfa7fb2408cbc98dccb31e42ffc;i=17096d;b=d17df7e99dfa496894cc1e5b6314ffa2;m=6a36040d71;t=530424
    PRIORITY=6
    _UID=0
    _GID=0
    _CAP_EFFECTIVE=3fffffffff
    _BOOT_ID=d17df7e99dfa496894cc1e5b6314ffa2
    _MACHINE_ID=05019d58a4004f9f90c1cfbd295b54ca
    _HOSTNAME=homeserver
    _TRANSPORT=syslog
    _SYSTEMD_SLICE=system.slice
    SYSLOG_FACILITY=4
    SYSLOG_IDENTIFIER=sshd
    _COMM=sshd
    _EXE=/usr/sbin/sshd
    _CMDLINE=sshd: unknown [priv]
    _SYSTEMD_CGROUP=/system.slice/ssh.service
    _SYSTEMD_UNIT=ssh.service
    SYSLOG_PID=31025
    _PID=31025
    MESSAGE=Received disconnect from 183.3.202.172 port 36152:11:  [preauth]
    _SOURCE_REALTIME_TIMESTAMP=1460436218498459

ベストアンサー1

メッセージは、journaldログサービスによって(おそらく)区別されるためです。_COMM

sshd複数のプロセスが実行され、proctitleそれに応じて変更されます。これは混乱する可能性がありますjournald。あなたの例では、[priv]区別は正確ですが[preauth]正確ではありません。 2番目のプロセスも実行中ですが、chroot親プロセス([priv])は彼の代わりにログインする必要があります。

おすすめ記事