Category Archives: Debian 8 Jessie

Upgrading Debian 8 Jessie to Debian 9 Stretch

If configuration files are changed the old version will usually be copied to a backup file (*.dpkg-old). Nevertheless it is a good idea to make a system backup yourself before upgrading.

Description how to upgrade



  • Device names stay the same (eth0, ...). Debian 9 only uses a new naming scheme for new installations.

Bacula 7.4.4

  • So far I had no problems to connect bacula-fd v7.4.4 to a bacula server v7.0.5

FreeRadius 3.0.12

  • Major upgrade from version 2. The configuration will not be automatically merged. You have to do this manually.
  • Basic configuration stays pretty much the same. Some configuration variables have been renamed or moved to a different position.
  • New configuration directories:

ejabberd 16.09

Postfix 3.1.4

  • Had no problems with a basic configuration and a couple of virtual mailbox domains.

amavisd-new 2.10.1-4

  • Almost no changes from previous version 2.10.1-2

spamassassin 3.4.1

  • No need to change anything if you have a default installation


  • New user/group "courier". File permissions need to be adjusted:
  • Some configuration changes (pid file, certificates location, etc.)

ntp 4.2.8p10

  • No longer subject to DRDoS Amplification Attack
  • Option "limited" added (to default restriction in configuration file)
  • Source restriction added (to configuration file)

OpenSSH 7.4

  • Major upgrade from version 6.7
  • No longer subject to ssh client roaming problem (s. Qualys Security Advisory)
  • New "AddKeysToAgent" client parameter (a private key that is used during authentication will be added to ssh-agent)
  • Default for "PermitRootLogin" changed from "yes" to "prohibit-password".
  • Default for "UsePrivilegeSeparation" changed from "yes" to "sandbox"
  • Default for "UseDNS" changed from "yes" to "no"
  • New option to require 2 different public keys for authentication; may be used for two-man rule / four-eyes principle (s. "AuthenticationMethods=publickey,publickey")

PAM authentication per application (Debian 8 Jessie)

PAM is the default authentication mechanism in Linux. It is very flexible and powerful, and even allows you to configure different authentication options for each application. In this example we will use the PAM module "pam_listfile" which is already included in the standard package "libpam-modules".

The application name has to match the name of the file under /etc/pam.d . So for example for application "abc" you have the following PAM configuration file /etc/pam.d/abc :

auth required onerr=fail item=group sense=allow file=/etc/group.allow
@include common-auth
@include common-account
@include common-password
@include common-session

The first line only authenticates users that are member of any group listed in /etc/group.allow. The contents of /etc/group.allow may only contain a single line and looks like this:


This will allow only members of the group "abc_group" to login to application "abc". After adding the new configuration files, make sure to always test your PAM settings with pamtester:

# id bob
uid=1003(bob) gid=1003(bob) groups=1003(bob)
# pamtester abc bob authenticate
pamtester: Authentication failure
# usermod -aG abc_group bobpamtester abc bob authenticate
pamtester: successfully authenticated

First the user "bob" is not member of the group "abc_group". pamtester fails to authenticate the user even if you provide the right password. Then after adding "bob" to the group "abc_group" authentication succeeds.



Randomness in KVM virtual guests

Virtual guests have viewer entropy than physical machines because of viewer hardware events.

$ cat /proc/sys/kernel/random/entropy_avail

Still /dev/random and /dev/urandom work as expected. /dev/random blocks more often if used within a virtual guest with tools like ssh-keygen, but produces reliable results. If you are dependent on /dev/random to work faster, try to switch to /dev/urandom, or use the hosts hardware RNG (s. virtio-rnd, http://

Despite its reputation, /dev/urandom is as reliable as /dev/random (s., even with low entropy. If in doubt, test it with rngtest (found on Debian Jessie 8 in package "rng-tools").

$ cat /dev/urandom | rngtest -c 5000
rngtest: FIPS 140-2 successes: 4996
rngtest: FIPS 140-2 failures: 4

This failure rate is acceptable for regular use of KVM guests.

Be careful not to exclusively use hardware RNGs. See current discussion about the use of Intel's RDRAND in linux kernel and openssl versions.

Because of concerns about the ability to audit this new Intel processor feature introduced with the Ivy Bridge CPU architecture, support was dropped in openssl completely. Openssl version 1.0.2 adds support of RDRAND again, but only in combination with other entropy sources.

That's how the current linux kernel works as well (XOR operation of RDRAND data with other entropy sources, s.

Software RNGs are at least debatable. The most famous one is probably haveged. See discussion here: . If you want to use haveged, use it only in combination with rngd, as rngd combines it with other entropy sources.

So far there is no need to change anything about RNGs in KVM guests. The only thing to worry about is the seeding of /dev/urandom at system startup. In most modern linux distributions, /dev/urandom is seeded with random numbers at system startup. The seed is produced by a system service and stored on disk during system shutdown.

In Debian (starting from Debian 8 Jessie) this service is called "systemd-random-seed" and the disk file for the seed is "/var/lib/systemd/random-seed".

Starting with kernel 4.8, a new DRBG algorithm is used to fill /dev/urandom: ChaCha20
ChaCha20 is supposed to work better and faster than the previous DRBG SP800-90A. Yet another reason to use /dev/urandom. Debian 9 Stretch e.g. uses kernel 4.9 and therefore ChaCha20.

The flow for /dev/urandom seems to be something like this:
external entropy sources (physical)  ->  entropy pool  ->  DRBG  ->  /dev/urandom


Important things to note:

Whenever you clone a KVM guest or make a snapshot, the random seed file stays the same. Thus the initial seeding of /dev/urandom does not change making its output more predictable. To avoid this problem, you might want to restart the service a couple of times before or after cloning a guest or making a snapshot.


Unattended-Upgrades with Debian Jessie 8

The package "unattended-upgrades" comes pretty handy for automatic security updates. Nevertheless there are a couple of settings you have to be aware of.

First you have to install the package "unattended-upgrades" of course. It installs a binary called "unattended-upgrades" which is run daily by the apt cron job:

After that you have to not only enable unattended-upgrades but also the periodic update of your packages . Create the following file:


APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Update-Package-Lists "1";

"1" means updating and running unattended-upgrades every day.

There are a couple of more options. Take a look at the following files:



Secure download for Debian

The basic idea  for downloading the Debian installation image in a secure way is this:

  1. Download the Debian public key from
  2. Using that key you verify the signature of checksum file of the ISO image.
  3. With the checksum file you check the downloaded iso image to see if it is the original file and has not been changed or tampered with.

Here are the steps to take:

0. Most important: Make sure to follow this procedure on a computer that is secure and that you fully trust. Otherwise all of the following steps are pretty much useless.

1. Download the Debian public key:
gpg --keyserver hkp:// --recv-keys 6294BE9B

Make sure the key has really been imported in your public gpg keyring:
gpg --fingerprint -k

The "--fingerprint" option shows the fingerprint of the just imported key. Compare it with the fingerprint on the official Debian website:
Make sure to double check the SSL certificate of that website in your browser.

2. Download the checksum file for the ISO image and the corresponding signature file:

Check the validity of the checksum file:
gpg --verify SHA512SUMS.sign

3. Check the validity of the downloaded ISO image file:
sha512sum -c SHA512SUMS


Browser blank page / white page with php script (WordPress, etc.)

I recently had a completely white / blank browser page when I tried to reset my WordPress password. It was from a local WordPress installation on my Debian 8 Jessie server. I was resetting my password for the admin login. It turned out that there was a problem with my php.ini settings. I had to add the following paths to the open_basedir variable:

open_basedir = /usr/share/php:/usr/share/php5

When resetting the WordPress password, WordPress includes some php files to send a reset email in wp-includes/pluggable.php:

require_once ABSPATH . WPINC . '/class-phpmailer.php';
require_once ABSPATH . WPINC . '/class-smtp.php';

The problem is that with the standard wordpress package on Debian 8 Jessie, class-phpmailer.php and class-smtp.php are symbolic links to /usr/share/php/... . If this path is not included in open_basedir, the php script just terminates without sending any error messages. I couldn't find anything in the apache logs either. The browser showed a blank page.

This might also be a problem with other php web applications. So if you experience a similar situation (no output of php script, blank page) you might want to check the open_basedir variable in you php.ini and make sure that all required / included php files and symbolic links are part of it.

If you have any ideas how to find out if a php script is trying to include a file outside of open_basedir, please leave a comment.


CSL 300 Mbit/s wifi adapter with Debian 8 Jessie

The CSL 300 Mbit/s wifi adapter is available at Amazon and is an inexpensive wifi USB adapter for Linux. It supports 802.11 b/g/n, WPA2, and has an external antenna adapter.

It identifies as follows with "sudo lsusb":

Bus 003 Device 002: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter

The loaded kernel module is "r8712u" (check with "sudo lsmod | grep r8712u").

To make it work with Debian Jessie, all you need to do is to install the standard Debian package "firmware-realtek". The output in "kern.log" after installing the package and plugging in the USB adapter should look something like this:

Sep 27 13:50:37 computername kernel: [    9.617950] r8712u: module is from the staging directory, the quality is unknown, you have been warned.
Sep 27 13:50:37 computername kernel: [    9.618985] r8712u: Staging version
Sep 27 13:50:37 computername kernel: [    9.619009] r8712u: register rtl8712_netdev_ops to netdev_ops
Sep 27 13:50:37 computername kernel: [    9.619014] usb 4-2: r8712u: USB_SPEED_HIGH with 4 endpoints
Sep 27 13:50:37 computername kernel: [    9.619553] usb 4-2: r8712u: Boot from EFUSE: Autoload OK
Sep 27 13:50:37 computername kernel: [   10.284174] usb 4-2: r8712u: CustomerID = 0x000a
Sep 27 13:50:37 computername kernel: [   10.284178] usb 4-2: r8712u: MAC Address from efuse = 20:ac:3f:b9:b9:b9
Sep 27 13:50:37 computername kernel: [   10.284181] usb 4-2: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
Sep 27 13:50:37 computername kernel: [   10.284258] usbcore: registered new interface driver r8712u
Sep 27 13:50:37 computername kernel: [   10.348992] usb 4-2: firmware: direct-loading firmware rtlwifi/rtl8712u.bin