Using custom private SSH key for git

When you are working with git, either your private or your company’s git server or with github it is much nicer to be able to push/pull/clone without having to enter the password every time. Furthermore, SSH keys are safer. However, the default option is to keep the private key in ~/.ssh/ folder which is not encrypted (unless your /home folder is encrypted). SSH client has the -i which allows you to specify the location of your private key, but this won’t work with git.

Fortunately there is a way. All you need to do is create one config file (called ‘config’) in ~/.ssh/. Here is how it should look like:

1
2
3
4
host miloske.tk
  HostName miloske.tk
  IdentityFile /home/milos/secure/my-key
  User git

 

Read More

Using LetsEncrypt for automated certificate management

Starting from the 2017, Google Chrome has started marking each site with unencrypted HTTP connection that requires entering credentials as unsafe. I’m sure many webmasters see this as an unnecessary hustle, especially those who don’t care about the security. However, using HTTPS is really easy and nowadays, it’s free. With LetsEncrypt you can even use automated scripts for renewing your certificates, so here’s how to set it up.

First of all, your are going to need an ACME client. You can choose any client from this list. I’ve chosen kelunik/acme-client written in PHP and this is what I’m going to be using for this tutorial. The easiest way to install this on your production server is to download it to /usr/local/bin directory and rename acme-client.phar to acme-client. Now you will be able to call it globally on your server as “acme-client” command. To download it, choose the latest .phar from here.

The next step is to write a YAML config file in /etc/client-yml. Here’s an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# storage for certs
storage
: /etc/secret

server
: letsencrypt

email
: milos.milutinovic@live.com

certificates
:

# milos.pw
- bits
: 4096
paths
:
/var/www/milos.pw/public_html
:
- milos.pw
- user
: www-data
paths
:
/var/www/milos.pw/public_html/
: milos.pw

Once that is done, you can get the your certificates for the first time by running “acme-client auto”. If there were no errors, you will get the certificates in the specified folder.

The next step depends on your web server. In this example I will set up Apache. You will have to edit each vhost config file (this is an example, not a whole file and parts are censored).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#redirect to https
ServerName milos.pw
ServerAlias www.milos.pw
Redirect permanent / https://milos.pw/
ServerName milos.pw
ServerAlias www.milos.pw

ServerAdmin ########
DocumentRoot /var/www/milos.pw/public_html

SSLEngine On
SSLCertificateFile /etc/##########/cert.pem
SSLCertificateKeyFile /etc/#######/key.pem
SSLCertificateChainFile /etc/#####/chain.pem

 

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

After you’ve done editing, test the configuration

1
sudo apachectl configtest

and reload Apache

1
sudo service apache2 reload

Now go to your site. It should redirect http to https and there should be no security errors. If everything went smoothly, congratulations, your visitors can now connect securely to your site and no one can sniff their traffic. If there were errors, leave a comment below and I’ll try helping.

The final step is creating a cron job that will renew the certificates automatically for us. LetsEncrypt certificates are valid for 3 months, so it would be very tedious to do this by hand, not to mention that you can easily forget to do it. Acme-client comes with very nice instructions for doing this.

Read More

Redirecting output of cron jobs

Cron jobs are very useful (indispensable I would say), but a common issue people have with cron jobs is that they are getting mails about errors produced by the scripts run by cron jobs. Also, the output is sent to syslog and this can be a serious problem when you have a script that executes often and produces long error messages.

Simplest solution to this problem is to redirect output of a cron job to /dev/null, which is a sort of a black hole that discards anything written to it. To do this, set you cron jobs like this:

1
* * * * * /home/user/myscript.sh > /dev/null 2>&1

This will redirect both STDOUT (1) AND STDERR (2) to /dev/null.

Sometimes however you want to redirect output to a log file of your choice. In that case, the code would look like this:

1
* * * * * /home/user/myscript.sh >> /var/log/custom/my.log 2>&1

Note that this time we are using “>>” instead of “>” for redirection. The important difference between the two redirection operators is that “>” will overwrite data each time, while “>>” will append them to the file.

Read More