Occasionally I will see an odd entry like this one in my
(unknown :0 :0 Tues Jul 4 06:51 - 06:51 (00:00)
Afaik, this should not happen ever, and I cannot find any information about this happening to anyone else.
I would like to know why, or more specifically, what would cause this to happen? I hope that there is a legitimate reason for this (other than someone successfully exploited my machine via sshd).
I searched the auth.log files for the only keyword I had to work with, 'unknown', and did find something curious that matched the time frame:
# 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: 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: 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: 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: couldn't allocate secure memory to keep passwords and or keys from being written to the disk
Now I must admit, I do not understand much about how PAM works, simply because it's something I have not taken the time to learn yet, so those messages are fairly cryptic to me. However, the last one, this one, looks particularly interesting:
auth.log.1-Jul 4 06:55:58 magic gnome-keyring-daemon: **couldn't allocate secure memory to keep passwords and or keys from being written to the disk**
I am sort of taking a stab in the dark here, but it would appear to me that perhaps... (and this may sound paranoid, naive, and/or cynical, that's why I am here) I am seeing something which hints toward one of these possibilities:
- many harmless coincidental glitches over years, maybe this happens due to maxed out ram when I trying to ssh in? This is a dubious explanation as this particular machine has more than enough RAM and I am pretty sure I was asleep when this last occurred so I do not believe this was me... but I first noticed this about 3 years ago, and across several different machines, and my memory is not the greatest, so it's hard to say for sure.
- someone with more resource, time, IQ, and/or money than I possess is trying to obtain access to my machine(s) via the only listening service I ever run on a personal machine: sshd . (Note that typically my sshd configuration only listens on the localhost and thus should only be accessable over the tor network, which makes this even more mysterious, and harder for me to believe that it's not some sort of targeted attack. The problem I have with this theory is that there is no reason I am aware of that would warrant this type of intrusion (legally speaking, because I am just another guy trying to make an honest living on planet Earth)).
I am having a hard time figuring out what, if any, legitimate reasons may explain these strange errors. I have noticed this across several different Linux (Debian based) systems running the openssh-server daemon. If this helps at all, my configuration for sshd looks typically something like this:
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 firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,email@example.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,firstname.lastname@example.org KexAlgorithms email@example.com,diffie-hellman-group-exchange-sha256 Ciphers firstname.lastname@example.org,email@example.com,firstname.lastname@example.org,aes256-ctr,aes192-ctr,aes128-ctr
Any insight or assistance would be appreciated. Thank you.