Say a friend or relative wants to install Fedora, but there are some wrinkles that make them less confident about running the installer themselves. For instance, they might want to save existing content without swapping out the hard drive, which involves shrinking filesystems, not for the inexperienced. This article walks you through a process that allows you to help them install remotely.

Naturally, they need to trust you a lot for this procedure (and you them), since they are giving you total access to the machine. I’ll call them “the client.”

Step 1. They need to download the Live Media from https://getfedora.org and write it to a USB stick. I used the Cinnamon Spin, but nothing in this article should be specific to a Desktop Environment. You’ll need to talk them through all this if needed. There are also instructions on getfedora.org.

Step 2. The client inserts the USB drive into the machine to be installed and boost from USB. The exact steps to enable USB boot are device specific, and beyond the scope of this article. You may want to make sure the client has access to their product documentation. Or you can ask them for the make and model number of their system, and look up the docs on the internet.

Step 3. Have them connect to the internet via local Wifi or Ethernet, and have them run Firefox to check that it is working. Send them to this very article, so they can copy and paste relevant commands when you tell them to if needed.

Step 4. Now have them start a terminal from the menu.

[liveuser@localhost-live ~]$ passwd

Changing password for user liveuser.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

[liveuser@localhost-live ~]$ sudo systemctl start sshd

[liveuser@localhost-live ~]$ ifconfig

Sshd will not allow remote logins with an empty password, so this step assigns a password, which the client will need to share with you. I suggest a series of simple but random words.

The Live media includes pidgin (or a similar chat client for other DEs). It would be helpful to have the client start pidgin and login to a trusted server. I suggest installing jabberd on a Fedora server with a public IP, and allowing open registration. I’ll skip the details for this article. With the client on pidgin with SSL on an XMPP server you trust/control, you can share the password more securely than over the phone. (Installing OTR would be yet another step to talk them through.)

Now the order of business is to let you connect securely to the client machine. Have the client share the output of the ifconfig command with you. If he has a public IP4 or IP6, and you can connect to it, you can skip to step 6. You can also save steps if they are on a LAN that doesn’t block ethertype 0xfc00 and other Cjdns nodes are on the LAN — but that’s unlikely enough we’ll skip the details.

Step 5. If you are here, your client is in “IP4 NAT jail”, and you need to help him escape by setting up a VPN. The simplest VPN to setup is Cjdns, but since you don’t want to talk the client through setting even that up, you’ll also need a trusted machine accessible via IP4 on which you can give the client an unprivileged shell account for bootstrapping. Have the client login to your server with an SSH remote tunnel:

[liveuser@localhost-live ~]$ ssh -R8022:localhost:22 username@shared.example.net

The authenticity of host 'shared.example.net' can't be established.

ECDSA key fingerprint is SHA256:kRfekGaa456ga34tddrgg8kZ3VmBbqlx6vZZwhcRpuc.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'shared.example.net' (ECDSA) to the list of known hosts.

username@shared's password:

Last login: Wed Jan 23 18:15:38 2019 from 2001:db8:1234::1019

[theirlogin@shared ~]$

Now you can login to their machine and install Cjdns. Login to shared.example.net and then into the client machine:

[yourlogin@shared ~]$ ssh -p8022 liveuser@localhost

liveuser@localhost's password:

Last login: Wed Jan 23 18:16:36 2019 from ::1

[liveuser@localhost-live ~]$

Install and configure Cjdns on the client, using these instructions if you are not already familar, and also on your own workstation if you haven’t already. You could skip installing cjdns-tools and cjdns-selinux on the client since this is a temporarily setup. But you’ll need the tools to help debug any glitches.

Run ifconfig tun0 and copy the client’s Cjdns VPN IP to your local /etc/hosts file with a suitable nickname. I’ll use the nickname h.client for this article.

[you@yourworkstation ~] $ sudo su -

# echo fc3f:26b0:49ec:7bc7:a757:b6eb:1eae:714f h.client >>/etc/hosts

Verify that you can login to liveuser@h.client from your workstation, and then you can logout of your tunnel login.

Step 6. Install x2goserver on the client. Tigervnc would be lighter weight for a limited machine, but x2go easily connects to the liveuser desktop so they can see what you are doing for education and transparency. Some spins include a built-in remote desktop feature as well, but I like x2go.

Run x2goclient on your workstation, and create a new session:

Session name: h.client

Host: h.client

Login: liveuser

Session type: Connect to local desktop

Now you can do your expert stuff while the client watches. For shrinking existing partitions, I recommend installing gparted and running it before the live install.

Step 7. When the Live Install is finished, the newly installed root filesystem should still be mounted as /mnt/sysimage. Double check, then copy the cjdns config to the new system and enable sshd. Incoming port 22 should be open by default.

[liveuser@localhost-live ~]$ sudo cp /etc/cjdroute.conf /mnt/sysimage/etc

[liveuser@localhost-live ~]$ sudo systemctl --root=/mnt/sysimage enable sshd

You should also install cjdns (or whatever VPN you used instead) on the new system so that the client doesn’t need to do the SSH rigamarole again after rebooting.

[liveuser@localhost-live ~]$ sudo dnf install cjdns --installroot=/mnt/sysimage

[liveuser@localhost-live ~]$ sudo systemctl --root=/mnt/sysimage enable cjdns

Step 8. You should now be ready to reboot! If something goes wrong, your client can boot from the Live Media and do the SSH routine from step 5 again so you can diagnose what went wrong.

Photo by Steve Johnson on Unsplash.