The Hotel Hero

Notes by a Sysadmin

Cluster | Philosophy | Stack

Rclone - continued part IV

June 5, 2023 | Stack

The first idéa I had with this part IV, was to add Restic to the Rclone Backup server. But, due to higher complexity (It should be easy to backup and recover) and not least that it seems like Restic would need to be implemented on the host with Rclone (multiple instances). I skipped the idéa.

So, for now.

Using certificates to connect to external servers

In general we want to do different stuff to try and avoid bruteforce ssh attack on servers exposed to the internet.

So, to let Rclone access a remote server to carry out it's backup job. We could start by creating a new certificate on the backup server.

There is more in depth information at Rclone: (basically there are 2 maybe 3 options)

ssh-keygen (and you could set different parameters, eliptic curv is most secure but can from time to time be unsupported on different servers)

Basically the above command would deliver a certificate (private and public file, idrsa +

ls ~/.ssh/
authorized_keys  id_rsa  known_hosts  known_hosts.old

Either you have an existing user (or create a backup-user) on the remote server and copy the content of "" to the remote server and users file (at the end of the file):


Alternatively you copy this from the backup server to the remote host:

ssh-copy-id -i /path/to/ user@server_ip

After this we are able to login without password. Now we want to apply that private key to Rclone's config file (we could refer rclone to the original file, but then we would have to back that up too or keep it in a password manager and remember that our config file is encrypted with a password.)

The key needs to be a one-liner with \n as character.

awk '{printf "%s\\n", $0}' < ~/.ssh/id_rsa

Setup a new remote, skip "password" and use "key_pem" instead:

key_pem> -----BEGIN OPENSSH PRIVATE KEY-----\nc5BivnNxaC2rZ........

leave "key_file" empty. (that if you want to point to the key)

The rest I also choose the default option, I think the password for encryption is seen as a separate protection feature in OpenSSH. So, I don't provide any password here.

Last but not least

One thing that you also should consider beside this last backup is your PC. Everything in your "/home/username/." should be considered. From time to time we also have important settings elsewhere on our machine. But, a good practis seems to be keeping important stuff here (/home/user/*) and configuration else where might be keept in a remote git repository considered as configuration changes.

Devices ex. USB sticks. I have a tendency to be forgotten, they could contain your password manager file etc. Maybe make a calendar reminder to back these things up.

The backup server it self

The reason why i startet part III and VI here two years after Part I and II. Is actually that my SD-card on the old backup server (Raspberry pi) got bust. For some time I did'nt have the time or entusiam for setting it up again and try to recover it, if possible at all. But, as I lost some other data on one of my servers I saw the value of have full control of the automatic backup process and decided it was time to do it the right way again. Documenting everything and making it a routine to backup all vital data, including the backup server it self.

So, what is important to backup.

  1. ~/.config/rclone/rclone.conf (our whole configuration is password encrypted)
  2. I have all my individual bash jobs under ~/backup/* (I push changes to a private git repository)
  3. And you may put a in the ~/backup dir, that describes /etc/profile and your crontabs. 

We could probably encrypt the volume (crypt) and find a way to figure out how to decrypt the rclone.conf again. But, depending on where you are backing up. The biggest secret the rclone.conf file is encrypted and basically if the location you store your backup at is secured you should be safe. If you are storing your backup at Alibaba, Azure, GCP, AWS, I would say that you should do more, including using the "salt" option and encrypt all backups. Are you using a EU compliant and owned provider (GDPR compliant by law), you could be a bit less rigorous. But, with quant computing and the most powerful states that show no signs of holding back on industrial espionage (companies are bound by law to cooperate in this task) the above mention corporations are notorious for breaching the big C (confidentiality). I am just a realist here, everything else is wish full thinking.



I'm a Sysadmin, network manager and cyber security entusiast. The main purpose of this public "notebook" is for referencing repetitive tasks, but it might as well come in handy to others. Windows can not be supported! But all other OS compliant with the POSIX-standard can (with minor adjustments) apply the configs on the site. It is Mac OSX, RHEL and all the Fedora based distros and Debian based (several 100's of OS's), all the BSD distros, Solaris, AIX and HP-UX.