有时我会在输出中看到像这样的奇怪条目last
:
(unknown :0 :0 Tues Jul 4 06:51 - 06:51 (00:00)
Afaik,这种事不应该发生,我找不到任何关于这种情况发生在其他人身上的信息。
我想知道为什么,或者更具体地说,什么会导致这种情况发生?我希望这有一个合理的理由(除了有人通过 sshd 成功利用了我的机器)。
我在 auth.log 文件中搜索了我必须使用的唯一关键字“未知”,并且确实发现了一些与时间范围相匹配的奇怪内容:
# grep --color=auto -A 10 -B 10 "unknown\|Unknown" auth.log.*
auth.log.1-Jul 4 06:51:41 magic gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by (uid=0)
auth.log.1-Jul 4 06:51:41 magic systemd-logind[3291]: New session c1 of user Debian-gdm.
auth.log.1-Jul 4 06:51:41 magic systemd: pam_unix(systemd-user:session): session opened for user Debian-gdm by (uid=0)
auth.log.1-Jul 4 06:51:42 magic CRON[3329]: pam_unix(cron:session): session closed for user logcheck
auth.log.1-Jul 4 06:51:42 magic polkitd(authority=local): Registered Authentication Agent for unix-session:c1 (system bus name :1.21 [gnome-shell --mode=gdm], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
auth.log.1-Jul 4 06:51:52 magic gdm-password]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=user
auth.log.1:Jul 4 06:52:03 magic gdm-password]: pam_unix(gdm-password:session): session opened for user user by (unknown)(uid=0)
auth.log.1-Jul 4 06:52:03 magic systemd-logind[3291]: New session 3 of user user.
auth.log.1-Jul 4 06:52:03 magic systemd: pam_unix(systemd-user:session): session opened for user user by (uid=0)
auth.log.1-Jul 4 06:52:03 magic polkitd(authority=local): Unregistered Authentication Agent for unix-session:c1 (system bus name :1.21, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
auth.log.1-Jul 4 06:52:04 magic polkitd(authority=local): Registered Authentication Agent for unix-session:3 (system bus name :1.47 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.utf8)
auth.log.1-Jul 4 06:55:58 magic gnome-keyring-daemon[5159]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
现在我必须承认,我不太了解 PAM 的工作原理,只是因为我还没有花时间学习它,所以这些消息对我来说相当神秘。然而,最后一个,这个,看起来特别有趣:
auth.log.1-Jul 4 06:55:58 magic gnome-keyring-daemon[5159]: **couldn't allocate secure memory to keep passwords and or keys from being written to the disk**
我有点在黑暗中尝试,但在我看来,也许……(这可能听起来偏执、天真和/或愤世嫉俗,这就是我在这里的原因)我看到了一些暗示的东西以下可能性之一:
- 多年来发生了许多无害的巧合故障,也许这是由于我尝试 ssh 时内存耗尽而发生的?这是一个可疑的解释,因为这台特定的机器有足够的 RAM,而且我很确定上次发生这种情况时我正在睡觉,所以我不相信这是我......但我第一次注意到这一点是在大约 3 年前,并且在几个不同的机器,我的记忆力不是最大的,所以很难确定。
或者
- 比我拥有更多资源、时间、智商和/或金钱的人正在尝试通过我在个人计算机上运行的唯一监听服务来访问我的计算机: sshd 。 (请注意,通常我的 sshd 配置仅侦听本地主机,因此只能通过 tor 网络访问,这使得这变得更加神秘,让我更难相信它是不是某种有针对性的攻击。我对这个理论的问题是,据我所知,没有理由保证这种类型的入侵(从法律上讲,因为我只是另一个试图在地球上诚实生活的人))。
我很难弄清楚什么(如果有的话)合理的理由可以解释这些奇怪的错误。我在几个运行 openssh-server 守护进程的不同 Linux(基于 Debian)系统中注意到了这一点。如果这有帮助的话,我的 sshd 配置通常如下所示:
Port 222
ListenAddress 127.127.127.127:222
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
# Insecure ancient DSA
#HostKey /etc/ssh/ssh_host_dsa_key
# Not certain whether we ought to trust elliptic curve or NIST
#HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 4096
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 90
PermitRootLogin no
StrictModes yes
# Never use this deprecated crap
RSAAuthentication no
PubkeyAuthentication yes
# lock down to this group
AllowGroups ssh-users
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
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
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
# extra logging info for sftp
Subsystem sftp /usr/lib/openssh/sftp-server -f auth -l info
UsePAM yes
# hardened ciphering
MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
任何见解或帮助将不胜感激。谢谢。