shit i did it again

Hi again me in the future (my one and only RSS subscriber), I'm here once again to sing praises to small tech.

Cloud services are ungodly. I don't like being so abstracted away from my data, and having a data-management service literally being called "the cloud" elevates that fear tenfold. As such, I've been getting into homelabbing over the past couple of weeks and I'd like to let you in on one of the best (godly) document management systems ever: git.

git: an explanation

git is a VCS created because of the development hell known as the early linux kernel (hyperbole). It's fully decentralized, simple, and can handle many devices well. This has allowed it to become not only the standard in software development projects, but also a great tool for managing personal documentation and files that you want to keep across multiple devices.

"Why can't I just use GitHub?"

Hosting your own git instance may seem laborious, and it might be tempting to just go with the easy alternative that everyone uses (I mean, I'm using it to host this website, so there's that). Remember, though, that the entire reason you wanted to escape cloud services in the first place was the anxiety around giving your personal data to some tech company based in the west coast. If your data is private and personal, you want to contain it solely to devices you can trust (in this case, a LAN).

Enter Home Server

In order to host a local git instance, we need a machine to host it on. This could be pretty much anything: an old laptop you had lying around, an honest-to-god station, or your own workstation. It would be best to connect this machine to your network via ethernet, but a wireless contact will work fine.

Next, and while this is not required, it's extremely recommended, you want to install some flavor of linux on your server. GNU*/Linux is the de facto server operating system: it's stable, minimal, fast, open, and everything that windows markets itself as being. For a server I would recommend installing Debian, but other distros such as Ubuntu or even NixOS (although if you feel like you're up to put nixOS on a server then you likely don't need this blog) work too. For the rest of the blog, I'm going to assume that you're running debian, but the instructions are easily applicable to other distros.

Setting up ssh

for the remainder of this blog, the prefix # means that you're running with root permissions (e.g. sudo)

To more easily interact with your server, you want to set up ssh to allow your main workspace to run commands in your home server.

Server-side

We first install the ssh server on your debian system:

We then need to start the ssh daemon on your server; run the following command:

This will start up the ssh daemon whenever you restart your computer, while also starting the ssh daemon now.

Before you go back to your main computer, take note of our server's local IP address:

This will output some junk, but the only thing we need to worry about is the tab labelled inet under your specific network device. If you connected via ethernet, it should say something along the lines of link/ether right underneath the device that you want (if you're connecting wirelessly, then your device should be called something like wlan0)

example output

We're going to use this IP address (192.168.0.10) for the rest of the post, but keep note of your own output and use that instead of what's put here

Client-side

To connect to this ssh server on your home computer, you need to install the openssh client. On debian, it should be pre-installed:

(arch systems)

(fedora systems)

(... etc, you get the idea)

Connecting Remotely

To connect to the server, we want to access whatever user you've created on your operating system remotely by using the ip address we got earlier:

(replacing user with whatever your server's home user is, of course)

This will prompt you to enter your password, and you're in!

For our case, we want to connect to our server via public key authentication, which involves creating a public-key-private-key pair for our home server and main workstation.

On your server, enter into /etc/ssh/ssd_config with root permissions. There are 3 variables we want to change here

Uncomment these 3 lines, and set them to the following:

• Port (any number besides 22. this guide will assume a port of 6789) | (with some exceptions, but most numbers over 5000 will work), this will help prevent against malicious actors trying to attack your server, as they will automatically try to enter via port 22.
• PubkeyAuthentication yes | This enables pubkey authentication
• PasswordAuthentication no | Disables password authentication, as you will be authenting with your key pair

Save and quit, but do not restart the ssh daemon, we still need to generate a key to use

We now want to generate the key. In your main computer, type the following:

Enter a name for your key preceded by the path "~/.ssh/" (I'm going to assume that you entered ~/.ssh/server). Enter whatever passphrase you deem fit (it's unwise to enter nothing, but if you want to you can), and make sure to save / remember said password.

This will generate a keypair in your ~/.ssh directory (~/.ssh/server.pub and ~/.ssh/server). To copy this over to your home server, run the following command:

We now restart the ssh daemon on your remote connection:

Exit your connection, and re-enter it with the following command to see if it worked:

After you've entered your password for the pubkey, you're in! Again!

One More Thing - ssh configuration

Before we set up our git instance, we need to configure our ssh to automatically connect to the port and use the pubkey that we want.

We do this by setting ssh's behavior for when it connects to an IP address. To do this, enter or create the ~/.ssh/config file:

This allows us to simply pass the IP address and user that we need to connect to without putting in that extra nonsense.

git time

Alrighty then, after all that ssh stuff we're ready to set up the git instance. The first thing we need to do is install git:

create a user that stores our data named git (for convention reasons). The home directory of git doesn't matter (/git, /var/git, etc) that much:

We want to log into git's user, so type the following:

This will put you in git's home directory (in our case /git). We then need to copy the keys that we generated earlier into the ssh directory of this user (after making it ofc):

Making our repo

ive switched personage on this post more times than i can count

Final stretch; the last thing we need to do is actually make our repo. It's common practice to suffix our repo name with .git, so let's make a directory for our repo called "freedom.git".

Next step is to initialize the git repository:

This will create an empty branched called "master", which'll be used for this remote branch only.

Now that this repository is created, we can exit out of the remote connection to your server. You can now go to whatever directory you wish to clone your repo. The way we clone a repo onto our machine is by referencing the ssh address of the git user followed by the repo name:

If everything has worked out, then it should prompt you to enter a password, and voila!

Before you start typing away, we need to branch off the master branch to actually push to the remote repo:

After adding what you'd like, commit your changes with git commit

All of the changes that we made are only stashed locally, so we need to push it to the remote repository for other devices to pull those changes

In order to pull changes that have been pushed to the remote repository by other devices, simply type

To get them into your local repo. Congrats!

Alright, what's next?

This has scratched the surface for stuff that you can do with git (if you want something to look into right now, look into .gitignore), but this core loop of pushing and pulling and fiddling where necessary works as a very satisfying substitution to the grip on your data that cloud services have.

For a more concrete answer, you should copy your key over to other devices that you plan to push and pull onto repositories that you create, which can be done using some of the previous instructions. Anyway, this has gotten to be fairly long, so safe travels and happy homelabbing!