A cautionary story about locking Linux & FreeBSD consumer accounts

Like each different solo developer and sysadmin, I do stuff utilizing ssh. Some stuff is automated utilizing scripts, and others require ssh login. For instance, certainly one of my scripts logs into my Linux and FreeBSD server utilizing public ssh keys and does a specific kind of labor for me. I’ve a devoted consumer account for that objective known as autovivek on Raspberry PI 4 for Ansible and customized script automation. Right here is the way it works:
{rpi4:~}$ ssh autovivek@192.168.2.17 /path/to/taks1
In different circumstances, it sends scripts after which executes them on the distant server named 192.168.2.17. Sounds good, proper? So, once I have to make backups and different duties, I lock down the autovivek consumer account on the server so that it’ll not modify information on disks. For instance, right here is easy methods to lock down a consumer account:
{linux-server:~}$ sudo usermod -L -e 1 autovivek
## OR ##
{freebsd-server:~}$ sudo pw lock -n autovivek

Commercial

A cautionary story about locking Linux and FreeBSD consumer accounts

Nevertheless, I quickly found {that a} consumer named autovivek can nonetheless log into the server and make adjustments regardless of being locked down on each Linux and FreeBSD servers. I foolishly assumed that it might work out of the field. However, boy, I used to be in for a giant shock.

Upon shut inspection on autobox (RPi 4 pc), I discovered that I enabled ssh multiplexing for ssh velocity up a few days again in my ~/.ssh/config file:

Host *
	IdentitiesOnly sure
	ControlPath ~/.ssh/controlmasters/%r@%h:%p
	ControlMaster auto
	ControlPersist sure

What’s SSH multiplexing?

SSH multiplexing is nothing however carrying a number of SSH classes over a single TCP connection. In different phrases, OpenSSH reuses an current TCP connection for a number of concurrent SSH classes. A locked or unlocked consumer account doesn’t matter on the distant machine if a session is already established on the OpenSSH server. It would immediately join utilizing the ssh. Right here is easy methods to discover out if the session is open or not:
{rpi4:~}$ ssh -O test autovivek@192.168.2.17
Here’s what I see:

Grasp working (pid=418156)

After all, the ss command will affirm open session too:
{rpi4:~}$ ss -o state established '( dport = :ssh or sport = :ssh )' | grep 192.168.2.17
Session opened within the background

tcp      0         0             192.168.2.25:ssh          192.168.2.17:22201    timer:(keepalive,1min13sec,0)                                                  
tcp      0         0             192.168.2.25:46412        192.168.2.17:ssh      timer:(keepalive,67min,0) 

On the server-side, there might be an identical session open within the background too:
{linux-server:~}$ ss -o state established '( dport = :ssh or sport = :ssh )' | grep 192.168.2.17
Outputs:

Netid                            Recv-Q                            Ship-Q                                                       Native Handle:Port                                                       Peer Handle:Port                             Course of                            
tcp                              0                                 0                                                            192.168.2.17:ssh                                                        192.168.2.25:41884                             timer:(keepalive,29min,0)    

In different phrases, ss command confirmed that ssh listens within the background on the server when ControlPersist set to sure on consumer aspect within the ~/.ssh/config file. It retains the connection open between the ssh consumer and server to hurry up the operation. And that’s the root reason for my concern. Ah, the thriller solved. From the ssh_config(5) man web page:

1. The ControlPersist directive specifies that the grasp connection ought to stay open within the background (ready for future consumer connections) after the preliminary consumer connection has been closed.
2. If set to no, the grasp connection is not going to be positioned within the background and can shut as quickly because the preliminary consumer connection is closed.
3. One can set it to sure or 0, then the grasp connection will stay within the background indefinitely till killed or closed through a mechanism such because the “ssh -O exit“.
4. If set to a time in seconds, or a time in any of the codecs documented in sshd_config(5), then the backgrounded grasp connection will robotically terminate after it has remained idle with no consumer connections for the desired time.

So, right here is how I solved my drawback.

Learn how to lock Linux and FreeBSD consumer accounts safely and block ssh entry instantly

A locking account shouldn’t be sufficient. It could be finest to cease all processes owned by the consumer named ‘autovivek’. In different phrases, I do that now:
{linux-server:~}$ sudo killall -STOP -u autovivek
In different phrases, the proper process to lock down the account on each Linux and FreeBSD servers is as follows:
{linux-server:~}$ sudo usermod -L -e 1 autovivek # Linux
{freebsd-server:~}$ sudo pw lock -n autovivek # FreeBSD
Then on each servers:
{linux-server:~}$ killall -STOP -u autovivek # STOP all processes owned by the 'autovivek' consumer
After all, you’ll be able to kill it, however I simply wanted to cease them after which when the backup is completed, I unlock the consumer account and resume the session:
{linux-server:~}$ sudo usermod -e -1 -U autovivek # Linux
{freebsd-server:~}$ sudo pw unlock -n autovivek # FreeBSD
Once more, run the killall command on each servers to renew all processes owned by the ‘autovivek’ consumer:
{linux-server:~}$ killall -CONT -u autovivek # Resume session

SIGSTOP and SIGCONT sign

The killall command sends the -STOP (SIGSTOP) sign to cease all processes owned by a consumer named ‘autovivek’. Equally, the -CONT (SIG) sign is used to proceed (resume) the processes owned by a consumer named ‘autovivek’ whether it is at present stopped.

Summing up

Certainly it’s a cautionary story about locking Linux and FreeBSD consumer accounts. Irrespective of how cautious you’re, there’ll at all times be some unwanted effects with optimization. I enabled ssh velocity optimization through multiplexing, and I met with some surprises. Verify the next guide pages utilizing the man command for more information:
$ man sshd_config
$ man ssh_config
$ man ssh
$ man kill
$ man killall
$ man 7 sign
So this jogs my memory of the Unix account elimination process script I developed many moons in the past when the sysadmin deleted the consumer account on HP-UX. First, it would seek for customers’ all cron/at jobs, processes, emails and information owned by the consumer. Then archive all information and delete them.