Ah righty. So the old-school way (my way) of doing this is indeed to set up ssh and then use rsync over shh to do the sync. I am guessing that this is sort of along the lines you need. WARNING - I don’t do this every day or anything, so I tend to just work my way through logically. This is a summary of how I usually do it.
To do that: you set up sshd on the desktop and will run rsync from your laptop, probably on a timer or something like that. I am guessing you’re using a fairly modern Debian-based Linux from the fact you are using “apt” - is that right? I would have guessed that on your desktop all you needed was:
apt install -y openssh openssh-server rsync
and on your laptop
apt install -y openssh rsync
Unfortunately it’s a bit difficult for me to test - I would need to use a container & they all have ssh set up as a server already
The next step is that you EITHER need to create a private key OR tweak the sshd setup to allow passwords. My own preferred route, 'cos I only do this once every few years & have to re-learn it every time, is to tweak the setup to allow passwords. Once I have it working I go back to fix it to work with private keys. So I start by allowing password authentication in /etc/ssh/sshd_config
for my user “itsme”:
Match User itsme
PasswordAuthentication yes
Then I restart the sshd service because these services are written by folk whose lost their sense of perspective of what makes a service work properly a loooong time ago. The approved recipe for restarting services varies from system to system and is written for fashion reasons every six months. It’s probably:
sudo service restart sshd
Then I try connecting from a terminal on the desktop to itself! Because you don’t want to bash your head against firewall issues before you get it working locally. This usually involves persuading the sshd to allow my normal account permission to use ssh. I usually just allow PAMAuthentication. Again editing /etc/ssh/sshd_config
UsePAM yes
And then I keep plugging away until I have successfully logged in from the desktop to the desktop with …
ssh itsme@localhost
Once that is working I then try the same command from my laptop. And at that point I probably find that I need to punch a hole through the firewall, which is pretty tedious. What you have to do there is totally distribution dependent.
After that, it’s usually plain sailing. As this is a LAN based thing, you could just carry on with passwords. But most people want to run with private keys. So you generate an RSA private key … there’s a nice description here: https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/
This also creates a public key. That’ll be called something like: id_rsa.pub
. The ‘pub’ part tells you its the public bit that can be safely shared. So you move that part onto your desktop (using scp
at this point!) and then stuff it in the right folder - which rather depends on the version of ssh. You probably want to put it somewhere like ~itsme/.ssh/authorized_keys2
on the desktop because that’s where the ssh-daemon is gonna look for the authorized-keys of the account itsme
.
Then it is the rigmarole of switching off Password Authentication (comment out the line in /etc/sshd/sshd_config) and seeing if you can log in from your laptop still.
If you can, basically you are sorted. At which point I reach for Evernote and I write down exactly what I did. The recipe is usually stale after a year but it helps me get up and running next time.