Thank you for visiting!
My little window on internet allowing me to share several of my passions
Categories:
- OpenBSD
- vdcron
- My Sysupgrade
- FreeBSD
- Nas
- DragonflyBSD
- fapws
- Alpine Linux
- Openbox
- Desktop
- Security
- nvim
- yabitrot
- nmctl
- Tint2
- Firewall
- VPN
- Project Management
- Hifi
- Alarm
Most Popular Articles:
Last Articles:
Remotely backup a machine with root without exposing the machine
Posted on 2024-10-14 22:06:00 from Vincent in OpenBSD FreeBSD
We would like to perform few rsync on a remote machine to backup some of his important files.
But we do not want PermitRootLogin.
In this blog we will see one of the alternative: forced-commands-only
Introduction
Thanks to a not so well know feature of SSH, we can trigger actions with root account to a remote machine without exposing this machine.
This machine will not be exposed since a login with root password is not allowed. And we will see how to mitigate risks in case your encryption keys are stolen.
So, the ideal solution to perform administrative tasks on a remote machine with a root account.
In this blog we will use it to perform backups via rsync
On the management machine side
On the machine from where we want to trigger actions, we have a couple of elements to prepapre
Like always with ssh, we have to make sure we have encryption keys:
fbsd: ~ $ doas ssh-keygen
We let the default parameters for all options. And we do not provide a password. Management of such password could be done, but is not part of this blog post.
Then we share the public to the remote machine:
fbsd: ~ $ doas cat /root/.ssh/id_rsa.pub | ssh user@server1 "cat >> /home/user/mgmt.pub"
This command grab the public key of the root account on the fbsd machine. I'm doing this because the backup script will be triggered by cron with the root account of this machine.
Replace "user" and "server1" by the adequate values in your case.
We temporarily store this key into the file mgmt.pub
I we will prepare a list of files and folders we do not want to backup:
fbsd: ~ $ doas cat /root/backup_excluded_files
*.core
#/var/log*
/var/cron/log*
#/var/spool/smtpd*
#/var/www/logs*
/var/www/tmp*
/var/www/piwik/tmp/*
/var/run/utmp
/var/db/ntpd.drift
/var/db/locace.database
This file must respect the rules are stated in the manpages for the parameters -exclude-from=.
One rule per line.
As you see, we can comment some rules.
We will comeback on later on this machine since the backup will be trigger from her.
Share key file on the remote server side
On the remote server side, we have to make several actions with the root account
In the sshd config file, which is normally at /etc/ssh/sshd_config, make sure that PermitRootLogin is set to forced-commands-only
PermitRootLogin forced-commands-only
And restart the sshd daemon
server1: ~ # rcctl restart sshd
We can add the public key to the authorized_keys file:
server1: ~ # cat /home/user/mgmt.pub >> ~/.ssh/authorized_keys
server1: ~ # rm /home/user/mgmt.pub
Up to this level, those are the usual manipulations we have to perform between an ssh client and the ssh server.
Force command on remote server
In the ~/.ssh/authorized_keys file of server1, we must add the "command" parameter in front of the ssh key we have just added. In our case, we will do this:
from="1.2.3.4",command="/root/.ssh/valid_ssh.sh" ssh-rsa AAAAB3NzaC1 ...
This says to ssh to trigger the command /root/.ssh/valid_ssh.sh once a client comes with the key associated and from the clientIP.
For our remote backup objective, the file valid_ssh.sh looks like this:
#!/bin/sh
# env >> /tmp/test
case $SSH_ORIGINAL_COMMAND in
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Argghh !!!"
;;
esac
This file must be executable:
server1: ~ # chmod +x ~/.ssh/valid_ssh.sh
This script checks the content of the parameter SSH_ORIGINAL_COMMAND and allows when it starts with "rsync --server".
Indeed, the parameter looks like this if I request a rsync of /etc:
SSH_ORIGINAL_COMMAND=rsync --server --sender -vlogDtpre.iLsfxCIvu . /etc
In any other cases, the script return the message "Arghh !!!". But, this script can be improve with other possible commands. I let you check this sample for Oreilly
If you want to see which is your client's IP, or other parameters, just uncomment the line which will list all parameters in the file /tmp/test
Trigger the backup from the Management machine
From the client machine, let's first see, with root account, what happens with an invalid command:
fbsd: ~ # sh root@server1 ls
Argghh !!!
But if I request a rsync, it works as it should be:
fbsd: ~ # rsync -aH --delete --exclude-from=/root/backup_excluded_files root@server1:/etc /nas/machine/server1
We can now add the backup commands in a daily script or crontab:
rsync -aH --delete root@server1:/etc /nas/machines/server1
rsync -aH --delete root@server1:/root /nas/machines/server1
rsync -aH --delete --exclude-from=/root/server1_backup_excluded_files root@server1:/var /nas/machines/server1
rsync -aH --delete --exclude-from=/root/server1_backup_excluded_files root@server1:/home /nas/machines/server1
As you see the exclude-from file is located on the management machine, but those are files filtered coming from the server1.
Conclusion
Thanks to this "command" and "from" parameters on authorized_keys file, we are allowed to perform actions with root account on a remote machine without exposing this machine.
Feel free to improve the valid_ssh.sh file to other commands.