The ten-minute net I arm before I touch sshd_config

vradar

I don't edit sshd_config any more without arming the way back first, because the session you are editing from is the same session the edit can take away from you.

Before the edit, not after:

systemd-run --on-active=600 --unit=sshd-net \
/bin/bash -c "cp -a /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && systemctl restart sshd"

Then edit, sshd -t, restart. If a brand-new session gets in, I stop the timer. If I go quiet instead, typo, dropped link, locked out, the box puts itself back in ten minutes with nobody present.

It has to be systemd-run rather than sleep 600 && cp ... &, because a backgrounded job dies with the SSH session. That is precisely the moment you need it alive.

Two things that fooled me before. systemctl is-active only says the process came back up, it says nothing about whether you can still get in, and the only thing that answers that is a fresh session opened from outside. And restarting sshd does not drop sessions that are already open, so the session you are sitting in will happily tell you a broken config is fine.

Ran it on my own production box this morning, PermitRootLogin yes to prohibit-password, 14 containers still up afterwards.

Ten minutes is a guess I never revisited. Anyone here running a shorter timer, or something better than a timer?

skorous

"at now + 10 minutes"

vradar

at now + 10 minutes is shorter and does the same thing, yes. The catch for me is atd: the minimal images I build from don't ship it, so it's one more package installed at the moment I'm trying to change nothing. On a box that already runs atd I'd reach for at.

david3

I usually copy/paste from another good setup. But I don't worry about it, anyway.

I have gotten locked out a few times. It can still be fixed with a vnc console.

vradar

A console only helps while I'm awake and near a laptop. The box stays wrong until I get there, so if I'm out for six hours that's a six-hour window. The timer doesn't beat a console, it just caps the window at ten minutes.

Falzo

usually restarting ssh will not cut off your current session.
so edit, restart and log in parallel into a new session, before logging out the old one could also do the trick...

vradar

Right, the restart itself doesn't drop the session. What bit me was the old session dying on its own mid-check, wifi flap at my end, and by then the new login was already being refused. That's the hole the timer fills; if the parallel login gets in I kill the unit.

flips

I just restart sshd and test before terminating current session. Otherwise I would probably use nohup for a timer if atd wasn't running/installed ...

vradar

nohup works. On a systemd box systemd-run --on-active=10m is the other way, and it survives the shell going away. Worth checking atd is actually running first, since at queues the job and returns 0 even when it isn't, so the net silently isn't there.

teamacc

@Falzo said:
usually restarting ssh will not cut off your current session.
so edit, restart and log in parallel into a new session, before logging out the old one could also do the trick...

I've had boxes that needed a restart in order to change the ssh port. just restarting ssh was not enough.

vradar

The one that bites like that is ssh.socket. On Debian/Ubuntu since 22.10 the socket unit owns the listener, so Port in sshd_config is inert and systemctl restart ssh changes nothing at all. Quick tell: ss -lntp shows systemd holding the port, not sshd.

ehab

i just call @WSS and try again.