3

I want to grant root access temporarily from ip 1.2.3.4, just for the current session (until next sshd or server restart)

I could add this to sshd_config, and then remember to remove it:

AllowUsers [email protected]

but is there better way? Can I change the current settings of the currently running sshd daemon, without editing the config file ?

3
  • currently running sshd daemon: Do you really mean the running sshd process, keeping the same PID while options change? Or is it more about existing ssh session not being terminated?
    – cachius
    Dec 7, 2022 at 12:08
  • A running sshd will not change its configuration (SIGHUP will re-run it). You could use a debugger to tweak a running sshd, but I doubt this would be more than a proof-of-concept.
    – Uriel
    Dec 8, 2022 at 14:17
  • By default all users are allowed access. Adding an AllowUsers x@y will only allow x@y and NO other users. So how are you currently denying that root login, with PermitRootLogin set to something, or with a DenyUsers?
    – meuh
    Dec 8, 2022 at 17:20

3 Answers 3

4
+50

and then remember to remove it

Remove it right away, so there is nothing to remember, nothing to forget. I mean:

  1. Edit sshd_config, save changes.
  2. Restart the daemon.
  3. Immediately edit sshd_config back, save changes.
  4. Do not restart the daemon.

This way the currently running (i.e. newly started) daemon uses your temporary config, because it's the config it has read; but a future daemon will use the regular config because the config file is already edited back. The temporary config is no more, except in memory of the currently running daemon, so only until next sshd or server restart, exactly as you want.

(1) and (3) can be done conveniently from within a single instance of a text editor, without exiting the editor, if only you can do (2) from another console. If your text editor provides "undo" then use it to cancel the risk of mistake while editing back.

Notes:

  • sshd from OpenSSH rereads its configuration file when it receives a hangup signal, SIGHUP, by executing itself with the name and options it was started with. Regardless if sshd of OpenSSH was started as systemd service or otherwise, this method should work.

  • Restarting (or even stopping) sshd does not affect existing connections.

3

In FreeBSD, therc system provides a mechanism for passing flags to the sshd daemon, namely to set the sshd_flags variable prior to starting/restarting sshd. The rc system will look for files names /etc/rc.conf.d/sshd/* and source all such files on any 'service sshd' invocation. That makes it fairly trivial to create a one-time unique filename in the correct directory, restart the service, delete that unique filename, and we're done.

To my admittedly limited knowledge, Linux lacks a dedicated directory into which one can place any number of arbitrarily-named files for the purpose of configuring a specific daemon's run-time behavior. I tried to mimic FreeBSD's mechanism in (Ubuntu) Linux by modifying /etc/default/ssh to search for and source files from a specific location (/etc/default/ssh.tmp.*) but had no success. Generally on the Linux systems I have available at hand, it seems that /etc/default/ssh nominally has:

# Default settings for openssh-server. This file is sourced by /bin/sh from
# /etc/init.d/ssh.

# Options to pass to sshd
SSHD_OPTS=

On some systems it seems the key variable name here is OPTIONS, so check your systemd service file for sshd to be certain.

Given that Plan A didn't work, I lowered my expectations and went with Plan B, which is essentially the same as modifying your sshd_config except that since by default /etc/default/ssh has no content, it is perhaps a tad safer to append your desired runtime options there than is it to muck with your /etc/ssh/sshd_config file. Further, since the syntax of /etc/default/ssh is shell syntax, once can feel relatively safe that by appending an altered value of SSHD_OPTS any previous assignment of SSHD_OPTS will be overridden for the next invocation, and then will be restored once /etc/default/ssh.safety is renamed back to /etc/default/ssh.

# cat << EOF > test.sh
cp -p /etc/default/ssh /etc/default/ssh.safety
printf 'SSHD_OPTS='\''-o "AllowUsers [email protected]"'\''\n' >> /etc/default/ssh
service sshd restart
mv /etc/default/ssh.safety /etc/default/ssh
EOF

So starting from:

# service ssh status
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-12-08 16:36:00 PST; 51s ago
  Process: 43364 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 43367 (sshd)
    Tasks: 1 (limit: 9830)
   CGroup: /system.slice/ssh.service
           └─43367 /usr/sbin/sshd -D

...snip...

And:

# cat /etc/default/ssh 
# Default settings for openssh-server. This file is sourced by /bin/sh from
# /etc/init.d/ssh.

# Options to pass to sshd
SSHD_OPTS=

Then with:

# cat test.sh
cp -p /etc/default/ssh /etc/default/ssh.safety
printf 'SSHD_OPTS='\''-o "AllowUsers [email protected]"'\''\n' >> /etc/default/ssh
service ssh restart
mv /etc/default/ssh.safety /etc/default/ssh

We can:

# sh test.sh
# service ssh status
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-12-08 16:37:42 PST; 3min 2s ago
  Process: 54918 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 54923 (sshd)
    Tasks: 1 (limit: 9830)
   CGroup: /system.slice/ssh.service
           └─54923 /usr/sbin/sshd -D -o AllowUsers [email protected]

...snip...

Notice here that sshd is running with our desired short-term command-line options!

Also notice that /etc/default/ssh is back to its unaltered state:

# cat /etc/default/ssh 
# Default settings for openssh-server. This file is sourced by /bin/sh from
# /etc/init.d/ssh.

# Options to pass to sshd
SSHD_OPTS=

Which means that the next time we:

# service ssh restart

We will see:

# service ssh status
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2022-12-08 16:43:56 PST; 7s ago
  Process: 44890 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 44896 (sshd)
    Tasks: 1 (limit: 9830)
   CGroup: /system.slice/ssh.service
           └─44896 /usr/sbin/sshd -D

Back to the bare, stock sshd service.

Again, this is essentially the same trick as modifying /etc/ssh/sshd_config except that if sshd_config gets mucked up or deleted (or even renamed), you may have a harder time recovering from that than from a similarly hosed /etc/default/ssh file. Since /etc/default/ssh is by default empty, you can simply rm it in the worst case to get sshd back to running the way it was before you started trying to play clever tricks.

0

Write your own Unit file mysshd.service pointing to a different sshd_config file with all needed changes, and start it. Include a Conflicts=sshd.service so that the proper sshd service is stopped. Only one of the two services can run at a time. When the proper sshd service is restarted, mysshd will be stopped.

You can also add -o options to the ExecStart= and use the original sshd_config file, as done below. They will be considered first. (This example is extracted from the output of systemctl cat sshd. This may differ on other distributions).

cat >/etc/systemd/system/mysshd.service <<\!
[Unit]
Description=my let root in OpenSSH server daemon
Conflicts=sshd.service
[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY -o 'AllowUsers [email protected]'
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
!
systemctl daemon-reload
systemctl start mysshd

The elephant in the room is that adding an AllowUsers x@y allows only that user and no others.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .