Reduce the File Size of PDF Documents with Preview on OS X

The PDF file format is ubiquitous for good reason, mostly because it allows for perfect preservation of a documents formatting, text, and other elements. However, sometimes PDF can be quite bloated and a file that should be not more than 200KB can suddenly be 1.5MB for no obvious reason. Adobe’s Acrobat X has functions to reduce/optimise the size of a pdf. On OSX you can achieve the same with Preview.

For PDF files that have not been optimized yet, the Preview app in OS X can often reduce the file size considerably by passing it through an export filter.

While it works great for text heavy files, it’s not a perfect solution for image-heavy slides. The “Reduce File Size” Quartz filter will indeed drastically shrink the file size of a pdf but the great savings in size come at a price. It will also make the slides look thoroughly awful. This is because the filter achieves its file size reduction by scaling all the images down by at least 50% and to no more than 512 pixels on a side, plus it uses aggressive JPEG compression. So not only will the images suffer from compression artifacts, they will also tend to get that lovely up-scaling blur.

Fortunatenly, anyone can create their own Quartz Filter with the ColorSync Utility shipped with OSX. The following zip file: PDF compression filters contains various files that reduce the file size while trying to minimise the amount of artifcats introduced in the images. It’s nowhere near as aggressive as the default Quartz-Filter.

The ColorSync Utility will by default save your own Quartz Filters in the following directory: /Users/YourName/Library/Filters/.

In order for the Filters to appear in the Save AS/Export menu the *.qfilter files need to be moved into the following directory

/Library/PDF Services/ Notice not in home folder (~/) but system-wide.

Afterwards the filters will appear in the dropdown menu of the export function:
Screenshot 2014-11-28 13.43.34

Limiting ssh user to SFTP using restricted shell

This is a follow up to the recent article about restricting ssh login to sftp. Back then I showed you how to restrict an ssh user who can login into a system by configuring openssh to prevent user logins of users associated with a specific group.

To do things differently I will show you an alternative and in my personal opinion easier way of restricting a ssh user to sftp. rSSH is a restricted shell that can be used with OpenSSH to only allow sftp and scp. It also includes support for rsync, rdist and cvs. This enables the creation of shell users without providing them full login access to the server except for transferring files.

First, make sure that the rssh package is installed (can be found in the usual repository). Since Debian is still my favourite distro I use aptitude. Use the equivalent on yours (yum, zypper etc.)

# aptitude install rssh
The following NEW packages will be installed: rssh
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 65.8 kB of archives. After unpacking 185 kB will be used.
Get: 1 wheezy/main rssh amd64 2.3.3-6 [65.8 kB]
Fetched 65.8 kB in 0s (752 kB/s)
Preconfiguring packages …
Selecting previously unselected package rssh.
(Reading database … 137643 files and directories currently installed.)
Unpacking rssh (from …/rssh_2.3.3-6_amd64.deb) …
Processing triggers for man-db …
Setting up rssh (2.3.3-6) …

In order to restrict a user to SFTP the rssh shell needs to be configured as the login shell for the user. The following example adds a new user bubu to the system with the shell set to /usr/bin/rssh

# useradd -m -d /home/bubu -s /usr/bin/rssh bubu
# passwd bubu

To change the shell of an existing shell use either usermod or the chsh command. Whichever you prefer.
# usermod -s /usr/bin/rssh <old-user-name>
# usermod -s /usr/bin/rssh chris2

# chsh -s /usr/bin/rssh chris2

Afterwards, if you try logging in via ssh or sftp you will receive a similar response to this since by default rssh locks down the system completely leaving the user without any sort of access.

$ sftp

$ ssh


[bash]’s password: TYPE-THE-PASSWORD
Linux 3.13-0.bpo.1-amd64 #1 SMP Debian 3.13.10-1~bpo70+1 (2014-04-23) x86_64 GNU/Linux
Last login: Sun Nov 16 07:03:04 2014 from localhost
This account is restricted by rssh.
This user is locked out.
If you believe this is in error, please contact your system administrator.
Connection to closed.

The default action for rssh is to lock down any access. To adjust the default setting edit the rssh.conf file. Append or uncomment the following two lines: allowscp, allowsftp:

# vi /etc/rssh.conf

# Leave these all commented out to make the default action for rssh to lock
# users out completely…



The user should be able to login into the system now:

$ sftp
Connecting to…’s password:
sftp> pwd
Remote working directory: /home/bubu

Bootable OS X 10.10 Yosemite USB installation drive

With the announcement of new iPads and iMacs and a refreshed Mac mini, Apple also released the final version of OSX 10.10 after multiple public betas. In case you are setting up multiple Macs or need an offline installer for older Macs that do not support “Internet Recovery” you can create an USB Installer. You will need the following:

  • A Mac with OSX Mavericks/Yosemite installed
  • 8GB or larger USB flash drive – preferably USB 3.0 if your Mac supports it
  • OSX 10.10 Installer from the AppStore in the Appllications folder.
  • Administative Access to your Mac (No restricted account)

Beware: All date on the USB key will be deleted (create a backup if necessary)

Using the Disk Utility format the Stick so it contains 1 HFS+ Partition and uses the GUID partitoning scheme (not the default MBR)

DiskUtility Partition Table

Leave the name “Untitled” as it is for now and format it using the Mac OSX Extended (Journaled) filesystem.

Open command line terminal and enter the following command


sudo /Applications/Install\ OS\ X\ –volume /Volumes/Untitled –applicationpath /Applications/Install\ OS\ X\ –nointeraction


This command will erase the disk and copy over all necessary installation files. After a while the USB key will automatically be mounted and the volume will soon load the OSX installer. Additionally, a recovery partition has been created that may come in handy if the hard drive dives and not internet connection is available.

Permitting SFTP file access while denying shell login

When you google on how to configure remote file access on linux most tutorials and how-tos will guide you towards ftp (file transer protocol) which has existed for ages and is well supported across all devices from mobile to desktop. However using FTP in these day and age without securing it using SSL is kind a naive. User credentials are sent over in clear-text and I don’t have to tell you that sooner or later the credentials will be compromised and your data might be at risk.

FTP similar to Telnet was never a protocol designed with security in mind. There are several solutions to FTP’s shortcomings. As mentioned, you can use FTP in combination with SSL or you can use SSH’s File Transfer Protocol SFTP for securily transferring data using the SSH network protocol.

In general, SSH is used for securely logging into a system remotely. By default, every user with SSH access automatically also has SFTP file access. The issue with simply adding a user to the system for SFTP access is that they also automatically receive shell-access. This grants them the right to run processes and potentially administer your system you may not wish them to run on your server. This tutorial will show you how to add a user to your system without granting them shell permissions but still allowing them file-access.

First, if you haven’t yet installed the openssh server yet, do so now (prepend every command with “sudo” if not logged-in as root):

# apt-get install openssh-server

Once the ssh-server is installed we need to add a user we wish to only allow SFTP access. Add a new usegroup to consolidate multiple users that should only receive SFTP access:

# addgroup sftponly

Next, edit the ssh-daemon configuration file: /etc/ssh/sshd_config (you can use vim or whaever editor you prefer)
Look for the following line:

Subsystem sftp /usr/lib/openssh/sftp-server

and replace the line with this instruction (you can also simply comment out the above line using # and insert the following line below):

Subsystem sftp internal-sftp

At the end of the same file add the following lines to restrict the access of the users bleonging to the sftponly user-group:

# Rules for sftponly group
Match group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

Save the file and restart the ssh-daemon via:

# /etc/init.d/ssh restart

Next, create the directory which the users will be jailed too:

# mkdir /srv/sftponly/

Optionally you can use a mount-bind to map a specific filesystem into that folder. My share is located at /mnt/fs and I use mount-bind to map the shared-folder to sftponly:

# mount –bind /mnt/fs /srv/sftponly/

Add a new user to the system and specify the previously created group as the user’s primary group. Disable shell-login and don’t create a home directory. See man-pages about adduser for more information about the available command-line switches:

# adduser –home /srv/nfs4/fs/ –no-create-home –ingroup sftponly –disabled-login <username>

Set a password for the new user:

# passwd <username>

In order for the user to be chrooted (jailed) to the specified directory the user’s home directory must be owned by root as well as only be writable by root:

# chown root:root /srv/sftponly/

In case you are not able to log-in using the newly added user or even worse if the user is not getting jailed it’s best to check the auth.log in /var/log/auth.log

Apr 20 12:34:04 fs sshd[12015]: Server listening on port 22.
Apr 20 12:34:04 fs sshd[12015]: Server listening on :: port 22.
Apr 20 12:34:09 fs sshd[12018]: Accepted password for <username> from port 54493 ssh2
Apr 20 12:34:09 fs sshd[12018]: pam_unix(sshd:session): session opened for user <username> by (uid=0)
Apr 20 12:34:09 fs sshd[12023]: fatal: bad ownership or modes for chroot directory "/srv/sftponly"
Apr 20 12:34:09 fs sshd[12018]: pam_unix(sshd:session): session closed for user<username>
Apr 20 12:34:25 fs sshd[12029]: Accepted password for <username> from port 54494 ssh2
Apr 20 12:34:25 fs sshd[12029]: pam_unix(sshd:session): session opened for user username by (uid=0)
Apr 20 12:34:25 fs sshd[12037]: fatal: bad ownership or modes for chroot directory "/srv/sftponly"
Apr 20 12:34:25 fs sshd[12029]: pam_unix(sshd:session): session closed for user <username>
Apr 20 12:37:02 fs sshd[12076]: Accepted password for <username> from port 54516 ssh2
Apr 20 12:37:02 fs sshd[12076]: pam_unix(sshd:session): session opened for user <username> by (uid=0)
Apr 20 12:37:02 fs sshd[12081]: fatal: bad ownership or modes for chroot directory "/srv/sftponly"
Apr 20 12:37:02 fs sshd[12076]: pam_unix(sshd:session): session closed for user <username>


In my case the specific user wasn’t getting jailed because the permissions on the root-folder were not correctly set. Make sure the home directory is owned by root and not the user itself.

Remove write permissions from others:

# chmod go-w /srv/sftponly/