O que poderia significar um usuário 'desconhecido' na saída do 'último' comando?

Question

Ocasionalmente, vejo uma entrada estranha como esta na minha last ouput:

(unknown :0           :0               Tues Jul  4 06:51 - 06:51  (00:00)

Afaik, isso não deve acontecer nunca, e não consigo encontrar nenhuma informação sobre isso acontecendo com mais ninguém.

Eu gostaria de saber por que, ou mais especificamente, o que causaria isso? Espero que exista uma razão legítima para isso (além de alguém ter explorado minha máquina com sucesso via sshd).

Eu pesquisei os arquivos auth.log para a única palavra-chave com a qual eu tive que trabalhar, 'unknown' e encontrei algo curioso que correspondia ao prazo:

# 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

Agora devo admitir, não entendo muito sobre como o PAM funciona, simplesmente porque é algo que ainda não aprendi a aprender, então essas mensagens são bastante secretas para mim. No entanto, o último, este, parece particularmente interessante:

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**

Estou espécie de tomar uma facada no escuro aqui, mas parece-me que talvez ... (e isto pode soar paranóico, ingênuo, e / ou cínico, é por isso que estou aqui) Eu estou vendo algo que sugere uma dessas possibilidades:

• muitas falhas coincidentes inofensivas ao longo dos anos, talvez isso aconteça devido a ram maxed fora quando eu estou tentando ssh em? Esta é uma explicação duvidosa como esta máquina em particular tem mais de memória RAM suficiente e eu tenho certeza que eu estava dormindo quando esta última ocorreu então eu não acredito que isso foi me ... mas eu primeiro percebeu isso cerca de 3 anos, e em vários máquinas diferentes, e minha memória não é a maior, por isso é difícil dizer com certeza.

ou

• alguém com mais recursos, tempo, QI e / ou dinheiro do que eu possuo está tentando obter acesso à (s) minha (s) máquina (s) através do único serviço de escuta que já executei em uma máquina pessoal: sshd. (Note-se que normalmente a configuração do sshd só escuta no localhost e, portanto, só deve ser acessível através da rede Tor, que torna isso ainda mais misterioso, e mais difícil para mim acreditar que é não algum tipo de alvo ataque. O problema que tenho com esta teoria é que não há nenhuma razão que eu estou ciente de que justificasse este tipo de intrusão (legalmente falando, porque eu sou apenas mais um cara tentando fazer uma vida honesta no planeta Terra)).

Estou tendo dificuldade em descobrir quais, se houver, razões legítimas podem explicar esses erros estranhos. Eu observei isso em vários sistemas Linux (baseados em Debian) diferentes executando o daemon openssh-server. Se isso ajuda em tudo, minha configuração para o sshd parece tipicamente algo assim:

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

Qualquer informação ou ajuda seria apreciada. Obrigado.