Should I be worried about /bin/sync when exposing my SSHD server to the internet?

2

I'm preparing to expose my server to the internet and would like to be as secure as I can be. I've taken security through obscurity measures such as changing from the default port 22, I've made sure root login is disabled, and I'm looking over who can log in. This final part is what has me slightly concerned:

I understand any login directed to /bin/false or /usr/sbin/nologin will be either refused or immediately exited. So I know not to worry about these. However, when running the command:
cat /etc/passwd | grep -v /bin/false | grep -v /usr/sbin/nologin

I get the following output:

root:x:0:0:root:/root:/bin/bash  
sync:x:4:65534:sync:/bin:/bin/sync
will:x:1000:1000:will,,,:/home/will:/bin/bash  

I've been trying to look up what sync is used by or how it works to no avail. I assume there likely isn't an entry point from remote logins to the user 'sync' but... What is this? Do I need to need to do anything to ensure it isn't a security risk and what is it used for?

Will

Posted 2020-01-11T20:09:53.343

Reputation: 23

Answers

2

There is this question on Unix & Linux SE: Why does Debian set the login shell of user sync to /bin/sync?

The only answer is upvoted, accepted, and the author is highly reputable. The answer states:

This is documented in /usr/share/doc/base-passwd/users-and-groups.txt.gz:

sync

The shell of user sync is /bin/sync. Thus, if its password is set to something easy to guess (such as ""), anyone can sync the system at the console even if they have no account on the system.

This is really a historical artifact, I wouldn't expect a sync user to be set up in this way nowadays. In the past it would be useful to have such a user so that people with physical access to a console (e.g. in a server room or a lab full of workstations, as you'd find in universities) could reduce the risk of data loss when shutting down a system (to recover from a rogue process or simply to use the workstation, if it had been left locked by its previous user). Unix systems before Debian tended to have a sync user and a shutdown user with which you could actually shut a system down properly without knowing the root password. (On our Sun SPARCstations we'd just STOPA boot...)

In Linux OSes I use (Debian, Kubuntu) the user sync has * as encrypted password in /etc/shadow. See man 5 shadow:

If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).

So there is nothing to worry about. It's just an artifact. Nowadays you cannot log in via SSH as sync (try it) unless your setup was substantially altered (e.g. like this: Login to SSH with no password and no ssh-key?).

Kamil Maciorowski

Posted 2020-01-11T20:09:53.343

Reputation: 38 429

I actually saw this post early on in my search but didn't fully make the connection to /bin/sync being completely insignificant. I believe I was thrown off by the placement of the quote in the responses first paragraph, and your explanation drew it out in a way a complete beginner could understand. – Will – 2020-01-12T19:06:25.227