3

Occasionally I will see an odd entry like this one in my last ouput:

(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[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

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[5159]: **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.

or

  • 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 hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Any insight or assistance would be appreciated. Thank you.

  • 1
    The login is over X (see TTY is :0). I presume this is some kind of guest session or done from some app. – heemayl Jul 11 '17 at 3:16
  • Hmm, but there should not any X or otherwise guest sessions happening, as this box has those features disabled. – Chev_603 Jul 11 '17 at 5:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.