I recently wrote a hook for Known (subsequently merged into the core) that converts twitter links to an embedded representation.

This was handy for a few folk, so I figured it’d be sensible to add similar functionality to my OEmbed Enabled embedded posts plugin for Known. The plugin will now attempt to use OEmbed to extract a representation of any Known post you link to into a rendered version.

Because allowing connections to just any OEmbed endpoint is a security risk, I’ve configured the plugin so that the Admin needs to whitelist domains/urls first (your current domain is automatically whitelisted).

Theoretically this could be used to whitelist non-Known sites that support oEmbed, although I’ve not extensively tested this so YMMV. Have fun!

» Visit the project on Github...


We all know how important it is to secure web servers with encryption. As I’ve mentioned before, port 80 HTTP should be considered deprecated at this point!

Just as important (potentially more so), but often overlooked, is to ensure that your email server is also secure.

STARTTLS is a technology that lets you start an encrypted session during a standard SMTP connection. In the same way as HTTPS secures web, STARTTLS will secure email in transit from your mail client to the server, and from server to server. This makes it much harder to passively read the traffic, and having more encrypted traffic on the internet is only ever a good thing.

This only protects email in transit from server to server of course, so this is not a replacement for end to end encryption methods like PGP, but it does complement it… and since most email is still sent insecurely, this adds extra security without requiring your users do any extra work.

It’s easy to set up (for Exim at least), and it transparently runs on port 25, so there’s no reason not to!

Generate your keys

As with web, you’ll need a server key and certificate file.

For my public mail and MX relay servers, I decided to use valid certificate authority certificates. Clients, and some relaying servers, will throw a certificate error for self signed certificates, but others will not. Better safe than sorry, and since I already had a valid certificate on my site for the server in question, I simply recycled the certificate.

If this is your internal server, you can use a certificate signed by your own certificate authority, supported by the machines in your organisation.

The default exim configuration expects to find certificates in /etc/exim4/exim.key and /etc/exim4/exim.crt.

Enable TLS

The basic STARTTLS configuration by simply editing exim4.conf.template and setting MAIN_TLS_ENABLE = yes in the tlsoptions section. Restart exim and you should have STARTTLS support enabled.

As with a web server, you can configure ciphers etc at this stage. On my server at least, the defaults seemed reasonably strong, but as we learn which ciphers have been compromised by GCHQ and the NSA, we might need to tweak these.

Test your configuration

Next, you should test your configuration.

To do this, the simplest way is to use a program called swaks, which you should find in your distro’s package library.

Should produce a result something like…

If you get an error when starting TLS examine your exim log for the cause.

Like many people out there who have servers, I use cross site backups for the purposes of disaster recovery.

While I also use “proper” backup software as well (which maintains a historic delta of changes, among other things), I’m a big fan of redundancy, so like many other server administrators out there, I also perform regular site to site copies using Rsync over SSH.

Rsync, for those who aren’t familiar, is a file copy tool, which, after the first copy, will only send changes during subsequent updates. This makes it a very efficient tool, especially when used over an internet connection. SSH stands for Secure Shell, and is an encrypted connection between two computers.

Anyway, to enable rsync from server A to server B, it is common to perform the login via key. This means that on Server A you’d generate a SSH keypair for your backup user, then copy the public key that was generated into the ~/.ssh/authorized_keys file for your backup user on Server B. There’s a good guide to doing that here.

Because rsync is going to be executed automatically via cron script, it is necessary to create the key file without a password.

Backups are running, so what’s the big?

Ok, so the key for your backup user isn’t password protected, but that doesn’t mean that anybody can log in as that user, they’d still need to have a copy of the cryptographic key.

If someone is able to break into Server A and steal your backup user’s key, they will be able to log in to Server B as that user. If that user is a non privileged user, that isn’t absolutely terrible (although they could, for example, read your /etc/passwd file, or anything else you’ve not locked down) and you can revoke this key at any time. However, since strength in depth and compartmentalisation are two concepts you should always remember when building a secure system, it’d be nice if it was possible to do something about it.

Thankfully there is.

Jail time

The solution is to configure Server B’s ssh client to place the backup user’s sessions into what’s called a “Jail” using a Linux tool called chroot. When the backup user logs in, they will not have access to any other parts of the system, other than what’s in their jail cell.

It’s a little fiddly to set up, but most of the hard work is done by SSH.

  • First, install chroot: apt-get install dchroot debootstrap
  • Configure your SSH server
    • Open up /etc/ssh/sshd_config
    • Make sure there’s a line that says
    • At the end of the file, tell SSH to create a chroot jail for your backup user:

      Note, because of the way chroot works, you’ll need to make sure the chroot directory is owned by ROOT, even if it’s actually the home directory of your backup user.
    • Save, and restart your SSH server.

This gets you part of the way, you should now be able to SFTP into Server B using your backup user, and a normal SSH session will be refused. When connected, you will be restricted to the location set in ChrootDirectory.

Unfortunately, rsync needs more than this, and in order to copy files it’ll need access to the shell (I’m assuming bash), as well as the rsync application itself, together with whatever libraries are required.

Therefore, it becomes necessary to create a partial chroot image in the backup user’s chroot directory. You could do this the traditional way (e.g. by using something like debootstrap), which will create a mirror of your base operating system files in the chroot jail. However, this generally takes a few hundred megabytes at least, and if all you want is to copy some files, you don’t want to give access to more than you need.

Instead, I opted to create a skeleton chroot jail by hand.

The goal here is to mirror the filesystem of your server inside the chroot jail, so that if a file exists in /foo/bar, then you need to copy it to /home/backup-user/foo/bar, and make sure it’s owned by root.

  • Copy bash from /bin/bash to the directory /home/backup-user/bin/
  • Copy rsync (on my system this was in /usr/bin)
  • Next, you need to copy the symbolic link libraries to which these files are linked against. You can use the tool ldd to interrogate the executable and get a list of files to copy, e.g:
    Copy the files which have directories into the appropriate locations, e.g. /lib/x86_64-linux-gnu/libtinfo.so.5 should go into /home/backup-user/lib/x86_64-linux-gnu/
  • Do the same for /usr/bin/rsync

All being well, your rsync backups from Server A should now function as before, however the backup user will not be able to touch anything outside of the chroot jail.

Hope that’s useful to you!