This is a personal cheatsheet I made for getting started with git using a private remote repository. I use this to host my respositories on linux machines on the internet (such as VPSes, or other linux boxes with sshd).

Further reading: Here

To setup git on a machine for the first time:

1. Download git somehow. apt-get install git on ubuntu, and googling for binaries on windows.
2. Run 'git config --global user.email "emailaddress"
3. Run 'git config --global user.name "name"

Setting up a new repo (both server and locally):

Can be done on any machine with git and a shell prompt.

The next few steps is to setup a new repo. This only needs to be done once at the beginning.

1. Appended dev private keys to ~/.ssh/authorized_keys on the server(IF you want key auth)
2. created new folder in home directory called projectname.git on the server
3. cd projectname.git on the server
4. git --bare init on the server
5. Create local repo with: 'git init' (inside project folder, run on your local machine)
6. do: git add somefile (run on your local machine)
7. git commit -m 'initial commit'" (run on your local machine)
8. setup remote push for that repo: git remote add origin username@hostname:~/projectname.git (run on your local machine)
9. do git push origin master to push the new repo. May be prompted for password. (run on your local machine)

Committing versions to the repository

There are three logical steps to making a change of your files reflect on your git repository: These are all done locally.

1. Staging (marking for commit) git add -a - adds all untracked files to staging git add somepath - adds a specific file to staging (you can also do (git add -A_ which addes all changes/files to staging)
2. Commit (adding them to local repository) git commit -m "Commit message goes here" - commits all changes which were staged earlier
3. Push (sending to remote repository) git push origin master - to do if git push doesnt work'

Cloning / Downloading a copy

Downloading the repo can be done with: 'git clone username@hostname:~/projectname.git

In this post, I will go through the basics of internet security, through the lens of hardening a VPS or dedicated server. Unlike other guides, I will not simply tell you a bunch of things to do to make your server more secure. Rather, I will walk your through the principles and the process of hardening, so you can secure the server to your needs and understand what you are doing.

Foremost, its important to understand that security is not absolute. There is no way you can garrantee your server cannot be comprimised. In order to be 100. secure you have to have everythingright, whereas to be comprimised you only need to have one mistake.

So then, good practice is to ensure the amount of effort spent securing your server should balance the damage that will occur in the event of a breach.

There are three main attack vectors that need to be accounted for, for an internet-facing server:

1. Kernel network-handling exploits
2. Network service exploits
3. Authentication guess/brueforce

Kernel network-handling exploits: These attacks make use of a vulnerability in the network-handling code (of the OS) or drivers of your machine. Fortunately, network hardware (and the kernel code) has matured alot, to the point where there arent really any known exploits except for really out-of-date kernels. Regardless, you deal with this kind of attack by keeping your kernel(OS) up to date, and being on the lookout for any security notices. These kind of attacks only really happen on people who havent updated their server for a decade, so really, you dont need to worry much about them. That said; don't be lulled into a false sense of security; always be on the lookout for kernel security notices.

Network service exploits: These attacks make use of a vulnerability in a network service/process/daemon running on your server. Generally, such an attack allows an attacker to do things they wouldnt normally be able to do, or in the event of a serious vulnerability, inject code into the server and take over the machine.

With the exception of guesswork/social engineering, this is where 90. of attacks happen. There are a number of things you can do to reduce your risk of an attack by this vector:

1. Shutdown unnecessary services, and prevent services which do not need to be accessed from the internet, from being accessed from the internet. This reduces the number of services capable of being exploited, which in turn reduces the likelihood of an accessible vulnerability.

2. Consider sand-boxing services such that if they are breached, it is difficult to take over the server and cause more damage.

   • Running the service as a less-privileged user is a good practice.
   • Running the service in a chroot (jail) is also a good idea, if possible. That said, a chroot jail is NOT a sandbox; its another line of defense. (btw, do NOT use BSD jails)

3. Subscribe to the security or announce mailing lists for the services you are running. That way, you will find out very quickly if there is a security issue in one of your services, so you can either: a) shutdown the service, or b)patch/update.

4. Keeping the service up-to-date is not only considered good practice; its a must.

Authentication guess/brute-force: This attack simply attempts to gain access to your server by guessing your credentials. With most servers, SSH is the means of configuration, so a lot of attacks simply bombard your sshd service with lots of login requests.

The easiest way to prevent this kind of attack is to have a strong password. In the case of SSH, you can use keys to authenticate yourself, however such a method is not very convenient, and if you are sure of the strength and that only you know your password, password auth is fine.

So lets look at these kinds of attacks in a little more detail so we can understand the characteristics our password should have.

The first kind of credential-attack is referred to as a dictionary attack. This is where the attacker repeatedly tries common passwords till they get in. So, avoid passwords that consist of up to three words joined together. Also avoid anything which you think someone else would have already thought up; it will be on a password list somewhere.

The second kind of credential-attack is referred to a brute-force attack. This is where the attacker tries every single combination of letters, numbers etc untill the system grants access.

Defending against this attack is done by simply having a password which is so strong, that bruteforcing it would take years. This is achieved by length and by using a variety of letters, numbers, and even symbols. Please see an excellent post about passwords here for more information.

Also, CHANGE your default passwords for everything, and do not use obvious passwords like 'admin', 'password' or '123456'. Such passwords are among the first things attempted in a dictionary attack.

I would like to note that having a random password like dafe3#j2@a is not nessessarily the best solution. Consider a password like mycatwasfluffehandfelldown41bushes. This password is so long that a bruteforce attack is not gonna happen, so wierd and unique that it wont be guessed in a dictionary attack, and, unlike the previous one, I will actually remember it. Dont think that random is the best option; passwords like this are far better for every reason.

Alot of services have configurable settings for allowing logins, such as blocking people who fail to login too many times. Using such settings allow you to prevent bruteforcing and limit dictionary attacks. In the case of SSH, the sshd service does not offer this, so instead consider installing Fail2ban to block repeated credential attackers.