Category Archives: Debian 9 Stretch

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")

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.