The holes are plugged in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For PHP 8.1 and older there are no regular releases with the fix so far, so the only way out is moving to a supported branch. On a regular server, the package manager takes care of that. Docker is a different story: every container brings its own PHP, and that PHP stays exactly as old as the image.

Which container runs which PHP?

So the first question is: which containers on my little home server actually contain PHP? For Nextcloud or WordPress that’s obvious, for self-built images or small web apps less so. Instead of going through every container by hand, the following loop asks all running containers for their PHP version and compares it with the patched releases right away.

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  case "${v%.*}" in
    8.5) fix=8.5.12 ;;
    8.4) fix=8.4.27 ;;
    8.3) fix=8.3.36 ;;
    8.2) fix=8.2.35 ;;
    *)   fix=99 ;;
  esac
  if [ "$(printf '%s\n' "$fix" "$v" | sort -V | head -n1)" = "$fix" ]; then
    printf '\e[32m%-30s %-8s ok\e[0m\n' "$c" "$v"
  else
    printf '\e[31m%-30s %-8s anfällig?\e[0m\n' "$c" "$v"
  fi
done

The loop silently skips containers without PHP. For all others, the version shows up in green if it is at least at the patch level and in red if it is below. PHP 8.1, 7.x and older also end up in red, because there simply is no fix for them. The red lines say “anfällig?”, German for “vulnerable?”. On my server, the result looks like this:

$ ./php2shell-simple.sh
nextcloud-app-1                8.5.12   ok
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
planetfoss-web                 8.3.33   anfällig?
sisu-web                       8.4.26   anfällig?

So Nextcloud and the test WordPress had already pulled their updates, while PlanetFOSS and the site for Sisu were still lagging behind. By the way, the question mark after “vulnerable” is on purpose. The loop only compares version numbers. If an image uses the PHP package from Debian, Ubuntu or Alpine, the fix may have been backported without the number changing. In that case, only the distribution’s security advisories can tell you more.

For a closer look, there is php2shell-check by EXT IT. The MIT-licensed script is read-only and judges PHP by package versions rather than just the version number, so it also takes backported fixes into account. It looks into Docker containers, FPM pools and old processes that are still running, and on request sends a harmless request to your website. For the containers it needs root or membership in the docker group.

The project page suggests the usual one-liner with curl and sudo bash. For a script that runs with root privileges on my server, I’m not too fond of that. Better download the script together with SHA256SUMS from the releases, check it with sha256sum -c SHA256SUMS, skim through it once and then start it by hand. According to the developers, a “not vulnerable” is no guarantee, by the way:

$ sudo bash php2shell-check.sh https://eure-seite.example

On my home server I ran the script with sudo. As a member of the docker group it would see the containers without root as well, but running processes of other users and some logs would stay hidden. This is how I fetched and started it:

$ curl -fsSLO https://github.com/EXT-IT/php2shell-check/releases/latest/download/php2shell-check.sh
$ chmod +x php2shell-check.sh 
$ sudo ./php2shell-check.sh 

The verdict matches the loop: planetfoss-web with PHP 8.3.33 and sisu-web with PHP 8.4.26 are vulnerable, Nextcloud and the test WordPress are not. On top of that, it found a stopped container from Tuxsucht that my loop had completely missed:

PHP in docker containers
  [ OK ] container      nextcloud-app-1 (nextcloud:35-apache)
         PHP 8.5.12 (fixed from 8.5.12)
[...]
  [VULN] container      planetfoss-web (planetfoss-web:local)
         PHP 8.3.33, fixed in 8.3.36
         -> Update PHP to 8.3.36 or later (container: pull the new image and recreate)
[...]
  [VULN] container      sisu-web (sisu-web:local)
         PHP 8.4.26, fixed in 8.4.27
[...]
  [WARN] container      php83 (stopped, tuxsucht-php)
         stopped, but its image ships PHP 8.3.33: it comes back vulnerable on the next start
[...]
Summary  2 vulnerable, 3 undecided, 12 warnings, 11 ok

Sure, docker ps only lists running containers, and a stopped container doesn’t accept any requests. But if someone starts it again at some point, the hole is back right away. The script is also very clear about mod_php: all five running containers serve PHP through the Apache module, and the advisory demonstrates a complete attack without login against exactly this setup.

Until you can update, the script suggests a stopgap: set session.upload_progress.enabled=0 and expose_php=0, and keep post_max_size below a quarter of memory_limit. The check from the outside, on the other hand, wasn’t much help. For the two websites, the script only reports that the headers don’t reveal a PHP version and that there is no WAF in front. That says nothing about the patch level, which the script honestly admits.

And how do you update PHP?

Don’t update anything inside the container itself, it would be gone again with the next recreate. Instead, pull the new image in the respective Compose directory and recreate the container with it. For self-built images with their own Dockerfile you need docker compose build --pull, so that Docker also fetches a fresh base image:

docker compose pull && docker compose up -d

Important: of course this only helps if the base image already contains the patched version. According to IT-Connect, the new tags initially even showed up without an image behind them, but by now generic tags such as php:8.3-apache ship the patched PHP. If your Dockerfile pins a fixed version like php:8.4.24-fpm, you have to bump it yourself. Simply run the loop again after the update. Take care of the containers that are reachable from the internet first.

The PlanetFOSS test environment shows what this looks like in practice. Its image is based on php:8.3-apache, and the Dockerfile only adds extensions such as GD and Intl. My deploy script does call docker compose up -d --build, but that doesn’t fetch a new base image, it takes the one from August out of the cache. That’s where the old PHP 8.3.33 came from. Only --pull fetches the fresh version:

$ cd /data/docker/planetfoss
$ docker compose build --pull web
$ docker compose up -d web

After a good minute the new image was ready, and the container ran PHP 8.3.36. The database in the same Compose project stays untouched, because both commands only address the web service. Afterwards the loop shows PlanetFOSS in green, and php2shell-check also reports only sisu-web as vulnerable. The old image is still lying around on disk as a leftover, by the way; docker image prune cleans it up.

$ ./php2shell-simple.sh
[...]
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
sisu-web                       8.4.26   anfällig?

All in all, PHP2Shell is a good example of how self-hosting with Docker is convenient, but the updates don’t come by themselves. heise has collected more details on the vulnerabilities. How to keep containers up to date without a lot of fiddling, I covered in Keeping Docker containers up to date with Dockcheck. How do you keep your containers up to date?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Why Sonos S1 still needs SMB1

I still have two Play:3, a Play:1, and a Connect:Amp on my network. All of them run the S1 software, for which Sonos only ships bug fixes these days. The speakers don’t just play streams, they also play my music collection from the server. According to a discussion in the Sonos forum, however, the S1 devices only have enough resources for SMBv1 – the old hardware simply can’t do more.

Samba, on the other hand, retired the old protocol a long time ago. Since version 4.11, server min protocol defaults to SMB2_02, and according to the Samba project, NTLMv1 authentication has been disabled since version 4.5. The usual guides turn both back on globally with two lines. Sure, the speakers play after that, but they’re not the only ones who get the door held open for them.

If you run an S2 system, you’re off the hook. Sonos added SMBv2 and SMBv3 there with version 13.4.1 in December 2021 and no longer speaks SMBv1 at all. S2 users can leave Samba’s defaults alone. The rest of this article is for everyone who, like me, is still attached to their old speakers and doesn’t want to throw them out over a protocol.

What’s wrong with the quick fix

Samba can only allow SMB1 for the whole server, not for individual shares or devices. Ever since WannaCry exploited a hole in Microsoft’s SMB1 in 2017 at the latest, the protocol has been considered legacy baggage, and NTLMv1 makes it easy for attackers to crack captured logins. If the speaker then logs in with your regular user on top of that, it’s your main password of all things that travels across the network using the weakest method available.

On top of that come lines that people like to copy along while they’re at it. With wide links and allow insecure wide links, Samba follows symlinks even when they point outside the share. Often the entire data directory is shared writable, too. Sure, from the outside a little home server like this is usually locked down. But the same LAN is also home to TVs, smart plugs, and speakers whose software you have no control over.

A dedicated user just for Sonos

The most important step is a dedicated user that exists only for the speakers and isn’t allowed to do anything else. It needs neither a home directory nor a shell; Samba only knows it for logging in. You set the password once and don’t use it anywhere else, because with NTLMv1 you should consider it semi-public. Creating it from scratch takes two commands:

$ sudo useradd -r -M -s /usr/bin/nologin sonos
$ sudo smbpasswd -a sonos

If you already have a user the speakers log in with, trim it down with usermod. It loses its shell and gets / as its home directory and a locked Unix password. Logging in to Samba uses the separate password from smbpasswd and keeps working regardless. If your speakers have been using your regular user so far, however, you’re better off creating a new one:

$ sudo usermod -s /usr/bin/nologin -d / sonos
$ sudo passwd -l sonos

The smb.conf

The configuration allows SMB1 and NTLMv1 but fences in everything around it. Samba only listens on the LAN interface and not on Docker bridges or VPN tunnels. Guests are kicked out, there are no printers, and every share gets a list of users who are allowed in. You’ll of course have to adapt the name of the network interface (enp0s25 on my machine) and the paths to your system:

[global]
   workgroup = WORKGROUP
   server string = bender
   server role = standalone server

   # Sonos S1: nur SMB1 + NTLMv1
   server min protocol = NT1
   server max protocol = SMB3
   ntlm auth = ntlmv1-permitted

   # nur LAN und lokal, nicht auf den Docker-Bridges
   interfaces = lo enp0s25
   bind interfaces only = yes

   map to guest = never

   # keine Drucker
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

[homes]
   browseable = no
   writable = yes
   valid users = %S
   invalid users = sonos

[musik]
   path = /data/musik
   browseable = yes
   read only = yes
   valid users = sonos anna ben lena

[data]
   path = /data
   writable = yes
   valid users = anna ben

By the way, ntlmv1-permitted is just the more descriptive name for the old yes. The [musik] share (German for music) is read-only; sonos and the family, here anna, ben, and lena, are allowed to read it. Even if someone cracks the speaker’s login, all they get is the music. Only anna and ben can access [data], wide links doesn’t appear anywhere, and symlinks therefore stay within their share.

The line invalid users = sonos under [homes] matters, too. This share offers every user their home directory, and for the speaker user that’s the root directory after the usermod above. Without that line, there would be a writable share \\bender\sonos covering the entire system. What actually works there is still governed by file permissions, but directories like /tmp are open to everyone.

If you can’t set up the Sonos library from scratch right now, there’s also an intermediate step without a separate music share. In that case, add sonos to the valid users of the existing share and also set read list = sonos. The speaker can then still read everything the file permissions allow, but can’t write anything. In the long run, though, a separate share is clearly the better choice.

Before you activate the new file, have testparm check it. It complains about typos and unknown options before Samba trips over them. Then restart the service – on Arch it’s called smb, on Debian and Ubuntu smbd. Open connections drop briefly, but mounted shares on your computers usually reconnect on their own:

$ sudo testparm -s
$ sudo systemctl restart smb

The music library in the Sonos app

Finally, add the share as a music library in the S1 app. Open Settings and go to Music Library and Music Library Setup. Enter the share in Windows format as the path, i.e. \\bender\musik, followed by the user sonos and its password. Sonos then indexes the collection, which can take a while for large libraries.

Checking the result

smbstatus shows you whether everything works as intended. The Protocol Version column tells you who is connected with which protocol. Regular computers should keep connecting via SMB3 – my notebook, for example, uses SMB3_11 – and only the speakers show up with NT1. A guest login without a password, on the other hand, should bounce off with NT_STATUS_ACCESS_DENIED when you try it with smbclient from another computer:

$ sudo smbstatus -b
$ smbclient -N //bender/data -c ls

Don’t let the output of the second command mislead you. The line “Anonymous login successful” sounds like an open door, but it only concerns the connection to the server itself, which a client uses to fetch the list of shares, for example. The second line is what counts, because nobody gets into the share itself without a user name and password:

$ smbclient -N //bender/data -c ls
Anonymous login successful
tree connect failed: NT_STATUS_ACCESS_DENIED

On my server it looks like this: The speaker in the bedroom reads as sonos via NT1, while the notebook is connected with SMB3_11 and a signed connection. That’s exactly how it should be, because the old protocol stays limited to the devices that can’t do anything else. The other speakers only show up while they’re actually accessing the library:

$ sudo smbstatus -b

Samba version 4.25.0
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
732192  sonos        sonos        192.168.0.60 (ipv4:192.168.0.60:38427)    NT1               -                    -                    
711090  anna         anna         192.168.0.191 (ipv4:192.168.0.191:52826)  SMB3_11           -                    partial(AES-128-CMAC)

And in the long run?

Of course, I’m still not entirely happy with SMB1. My server already runs bonob, which brings Navidrome into the Sonos app as a music service. If the music comes through that, no speaker needs a Samba share anymore, and SMB1 could go for good. But if you can’t do without Sonos’s built-in library, the restricted setup is a good compromise in my view.

All in all, the clean approach only costs you one user and a few extra lines in smb.conf. The speakers play just as well as with the quick fix, except that they no longer offer a path to the rest of the server. How did you hook up your old Sonos speakers? Is SMB1 still running on your network, too, or did you switch to S2 long ago?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Why are so many places missing from GNOME Weather?

GNOME uses the libgweather library for location selection. It contains a large database of cities and weather stations. The location data lives in the file Locations.xml. On top of that, libgweather can use OpenStreetMap’s Nominatim geocoding service to search over the internet.

Not every place makes it into the static database, though. As a rule of thumb, GNOME names cities with at least 100,000 inhabitants. The limit isn’t rigid: smaller places can be included too, for example if they have regional importance or if there is no larger city nearby that could serve as an alternative. GNOME describes the current criteria and how to contribute in its documentation.

UPDATE August 12, 2026: The original script is offline by now. I therefore point to a current fork that is available as a gist on GitHub.

If you still want to use your small hometown directly in GNOME Weather, you can fall back on a script. The original script by Julian Fairfax is no longer available. A maintained fork exists, though, as a gist on GitHub. The script looks up the place you want via OpenStreetMap and then adds it to the GNOME Weather settings.

Adding your own locations to GNOME Weather

You don’t need to install the script, since you’ll usually only need it once. First download it from the gist, then make it executable:

$ <strong>wget https://gist.githubusercontent.com/dotbanana/1dc4d95d644ce72ab8741d6886b86acc/raw/add-location-to-gnome-weather.sh</strong>
$ <strong>chmod +x add-location-to-gnome-weather.sh</strong>

Then run the script:

$ <strong>./add-location-to-gnome-weather.sh</strong>

The script asks for the place you want and runs a search via Nominatim. It then shows you the entry it found, so you can check whether it picked the right place:

$ <strong>./add-location-to-gnome-weather.sh</strong>
Type the name of the location you want to add to GNOME Weather: Ravensburg
If this is not the location you wanted, consider adding search terms
Are you sure you want to add Ravensburg, Verwaltungsverband Mittleres Schussental, Landkreis Ravensburg, Baden-Württemberg, Deutschland? &#91;y/n] : y
Adding location

After you confirm, the script creates the location directly in the GNOME Weather settings. The current fork supports both a regular installation and the Flatpak version of GNOME Weather. Afterwards, the new location should show up in the app’s location list.

How does GNOME Weather store locations?

The locations selected in GNOME Weather are stored via GSettings. The script sets the key org.gnome.Weather locations. For a regular installation it uses gsettings; for the Flatpak version it runs the command inside the Flatpak environment.

If you want to remove a location added this way, you can edit the stored settings with the dconf Editor, for example. The relevant entry is located at org.gnome.Weather. The format of the stored location data isn’t exactly user-friendly, so be careful when you do this.

The current solution isn’t particularly elegant, but it works reliably. GNOME has since extended the location database with an online search via Nominatim, so the library can also find places that aren’t in the static database. The script uses exactly that and then transfers the place it found into the settings GNOME Weather uses.

The fork by dotbanana is therefore a practical solution for everyone whose hometown can’t be selected through GNOME Weather’s regular search. Since both GNOME Weather and libgweather keep evolving, this behavior may change in the future. As of now, the script also works with the Flatpak version of GNOME Weather.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

In this post, I’ll show you how to create such a script. As an example, I want to demonstrate how to convert images to WebP without having to open an image editor. For that, I use cwebp, a powerful tool for converting images to the WebP format, and Zenity to provide a graphical dialog for entering image sizes.

Why WebP?

WebP is a modern image format that compresses better than JPG or PNG without noticeably hurting image quality. It is especially useful for web developers and bloggers, since it reduces page load times and improves performance.

Preparation: Installing the required packages

Before you start with the script, make sure the required programs are installed. If they aren’t, you can install them on Debian-based distributions like Ubuntu or TUXEDO OS with the following command:

### Unter Arch Linux, Manjaro und Co.
$ <strong>sudo pacman -S libwebp zenity</strong>
### Unter Ubuntu, Debian und Co.
$ <strong>sudo apt install webp zenity</strong>

Creating the WebP conversion script

Create a new script in the Nautilus scripts folder:

$ <strong>mkdir -p ~/.local/share/nautilus/scripts</strong>
$ <strong>gedit ~/.local/share/nautilus/scripts/ConvertToWebP</strong>

Now paste the following code into the file and save it:

#!/bin/bash

# Überprüfen, ob cwebp und zenity installiert sind
if ! command -v cwebp &> /dev/null; then
    zenity --error --text="cwebp ist nicht installiert."
    exit 1
fi

# Benutzer nach Breite und Höhe fragen
input=$(zenity --forms --title="Bildkonvertierung nach WebP" 
    --text="Gebt die gewünschte Breite und Höhe ein (0 für Originalgröße):" 
    --add-entry="Breite" 
    --add-entry="Höhe")

# Falls der Benutzer abbricht, das Skript beenden
if [ -z "$input" ]; then
    exit 1
fi

width=$(echo "$input" | cut -d '|' -f1)
height=$(echo "$input" | cut -d '|' -f2)

# Falls keine Werte eingegeben wurden, Standardwerte setzen
width=${width:-0}
height=${height:-0}

# Alle ausgewählten Dateien verarbeiten
for file in "$@"; do
    if [ -f "$file" ]; then
        output="${file%.*}.webp"
        
        if [[ "$width" -eq 0 && "$height" -eq 0 ]]; then
            # Keine Skalierung, direkt konvertieren
            cwebp "$file" -o "${file%.*}.webp" >/dev/null 2>&1
        else
            cwebp -resize "$width" "$height" "$file" -o "${file%.*}.webp" >/dev/null 2>&1
        fi
    fi
done

Setting permissions

For the script to run, it has to be marked as executable. You do that with:

$ <strong>chmod +x ~/.local/share/nautilus/scripts/ConvertToWebP</strong>

Using the script in Nautilus

Once the script is created, it is available right away in the Nautilus file manager. Select one or more images, right-click them, go to Scripts, and choose ConvertToWebP.

The script now converts all selected image files in common formats to WebP and reduces their size while keeping the aspect ratio. If cwebp is not installed, it shows an error message. Alternatively, you can enter the target width and height in pixels.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

On GitHub, I recently stumbled across the PiShrink script, which does exactly that. The little program takes a Pi image, reduces the partition size to the necessary minimum and also adds a script to the archived system that automatically expands the partition to the maximum available space on the next boot on real hardware. This way, you can quickly shrink the image of a Raspbian system from several gigabytes to a few hundred megabytes – without much effort. You also save time when restoring, since the file system automatically expands to its full size again the first time the Raspberry Pi boots.

$ mkdir ~/bin
$ wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh -P ~/bin
$ chmod +x ~/bin/pishrink.sh

Since PiShrink is a simple Bash script, installing it isn’t particularly complicated: you just download the script and set the execute permission. Personally, I put scripts like this in the ~/bin directory in my home folder. The system should automatically add this folder to your user’s $PATH, so you can run the command from anywhere without specifying a path. If that’s not the case for you, there are plenty of guides online on extending the environment variable (the linked article refers to Ubuntu, but the procedure is very similar on other distributions).

PiShrink compresses Raspberry Pi images

You should now be able to call the PiShrink script directly in the terminal with a bold pishrink.sh. Without an image, the script merely shows its syntax. In the end, calling it comes down to specifying an image file and, optionally, a second file name if PiShrink should leave the original Raspberry Pi image untouched. If you only specify one file name, PiShrink edits that image directly.

The only switch, -s, matters if you want to shrink the image of a Pi system that isn’t based on Raspbian – for example the Kodi distributions LibreELEC or OpenELEC. More precisely, the switch tells PiShrink not to expand the system automatically on the next boot. To do this, PiShrink normally adds a command to the /etc/rc.local file, which Raspbian runs automatically at boot. However, this file doesn’t exist on LibreELEC (and some other distributions).

### Show PiShrink's help:
$ pishrink.sh
Usage: /home/toff/bin/pishrink.sh [-s] imagefile.img [newimagefile.img]
### Shrink an existing Pi image:
$ sudo pishrink.sh raspberry-pi.img
### Shrink the image and keep the original:
$ sudo pishrink.sh raspberry-pi.img raspberry-pi_pishrink.img
### Disable automatic expansion of the partition:
$ sudo pishrink.sh -s raspberry-pi.img raspberry-pi_small.img

So how does it all come together? As an example, I’m using a current installation of Raspbian Lite on a 16 GB SD card. You insert it into the card reader, determine the device ID with lsblk and then back up the image to the hard disk with dd. The image file then sits on the hard disk as raspberry-pi.img, around 16 GB in size – even though the image is actually mostly empty. Apart from the Raspbian system and a few configuration files, there’s no other data on the system.

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sdd      8:48   1  14.9G  0 disk
├─sdd1   8:49   1    63M  0 part /run/media/[...]/boot
└─sdd2   8:50   1  14.8G  0 part /run/media/[...]/0aed834e-8c8f-412d-a276-a26
$ sudo dd if=/dev/sdd of=~/raspberry-pi.img
15894831104 bytes (16 GB, 15 GiB) copied, 210 s, 75.7 MB/s
31116288+0 records in
31116288+0 records out
15931539456 bytes (16 GB, 15 GiB) copied, 210.459 s, 75.7 MB/s
$ ls -alh ~/raspberry-pi.img
-rw-r--r-- 1 root root 15G Feb 24 21:48 raspberry-pi.img

Then you call PiShrink accordingly – since this is a Raspbian system, I leave out the -s option. PiShrink first copies the image (so make sure there’s enough free space), mounts the copy in a temporary directory under /tmp and then reduces the size of the image: from just under 16 GB originally to only about 1.6 GB. The effect you achieve naturally depends on how much real data was stored on the Raspberry Pi’s SD card.

$ sudo pishrink.sh raspberry-pi.img raspberry-pi_pishrink.img
Copying raspberry-pi.img to raspberry-pi_pishrink.img...
Creating new /etc/rc.local
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop2: 35832/959616 files (0.2% non-contiguous), 321790/3872384 blocks
resize2fs 1.43.4 (31-Jan-2017)
resize2fs 1.43.4 (31-Jan-2017)
Resizing the filesystem on /dev/loop2 to 382429 (4k) blocks.
Begin pass 2 (max = 40814)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 119)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 3178)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop2 is now 382429 (4k) blocks long.

Shrunk raspberry-pi_pishrink.img from 15G to 1.6G
$ ls -alh raspberry-pi*
-rw-r--r-- 1 root root  15G Feb 27 11:08 raspberry-pi.img
-rw-r--r-- 1 root root 1.6G Feb 27 11:30 raspberry-pi_pishrink.img

Restoring a shrunk Pi image

As a test, the Raspbian system originally installed on a 16 GB SD card is to move to a microSD card with only 8 GB. To do this, I write the image shrunk with PiShrink back to the new card with dd, insert it into the Raspberry Pi and boot the shrunk system. To make full use of the available storage space, the system automatically reboots once during the first boot. After that, you land in the familiar Raspbian system – a df -h shows that the system now uses the entire SD card.

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sdd      8:48   1   7.4G  0 disk
├─sdd1   8:49   1    63M  0 part /run/media/[...]/boot
└─sdd2   8:50   1   7.3G  0 part /run/media/[...]/0aed834e-8c8f-412d-a276-a26
$ sudo dd if=raspberry-pi_pishrink.img of=/dev/sdd bs=1M; sync
1560+1 records in
1560+1 records out
1636684288 bytes (1.6 GB, 1.5 GiB) copied, 116.203 s, 14.1 MB/s

pi@raspberrypi:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  990M  6.0G  14% /
devtmpfs        459M     0  459M   0% /dev
tmpfs           463M     0  463M   0% /dev/shm
tmpfs           463M  6.2M  457M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           463M     0  463M   0% /sys/fs/cgroup
/dev/mmcblk0p1   63M   21M   42M  33% /boot

If you back up a Raspberry Pi system that isn’t based on Raspbian and has no /etc/rc.local – such as the Kodi distributions LibreELEC or OpenELEC mentioned above – error messages appear when shrinking it with PiShrink. The reason: by default, PiShrink tries to add a command to this file that later expands the partition automatically. To avoid this, you have to use the -s option. That way, you can shrink the image successfully even without an rc.local.

### Error messages when shrinking a LibreELEC image:
$ sudo pishrink.sh libreelec.img
[...]
md5sum: /tmp/tmp.4ornQ3Va4y/etc/rc.local: No such file or directory
/home/[...]/bin/pishrink.sh: line 63: [: !=: unary operator expected
[...]
### LibreELEC, OpenELEC and co. are better shrunk like this:
$ sudo pishrink.sh -s libreelec.img
Skipping autoexpanding process...
e2fsck 1.43.4 (31-Jan-2017)
/dev/loop2: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop2: 861/1810432 files (1.0% non-contiguous), 252448/7235584 blocks
resize2fs 1.43.4 (31-Jan-2017)
resize2fs 1.43.4 (31-Jan-2017)
Resizing the filesystem on /dev/loop2 to 49976 (1k) blocks.
Begin pass 2 (max = 15759)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 884)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 143)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop2 is now 49976 (1k) blocks long.

Shrunk libreelec.img from 7.5G to 563M

However, the restored system then doesn’t expand automatically, because LibreELEC (and, as far as I know, OpenELEC too) offers no option in its menus to manually expand the data partition to the full card size. The internal resizing routine only kicks in on a freshly copied first installation, as you can see in the script. To make full use of the partition anyway, the only option is to fix it up manually with a partitioning tool such as GParted. On Linux, GParted is readily available; Windows users can use the tool via a live CD or live USB stick.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

When establishing a connection via SSH, the SSH client usually stores the public SSH key of the remote system together with its hostname and IP address in the file ~/.ssh/known_hosts in the current user’s home directory on the client machine. Among other things, this is done to prevent man-in-the-middle attacks, in which an attacker pretends to be the target machine in order to phish your login credentials. However, this security measure also kicks in when there is no threat at all: for example, when you set up a Pi from scratch and try to log in via SSH again. In such a case, SSH reports WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED in big letters.

SSH after reinstalling the system

$ grep 192.168.111.100 ~/.ssh/known_hosts
raspberrypi,192.168.111.100 ecdsa-sha2-nistp256 AAAAE2...ABBBBqf

$ ssh pi@192.168.111.100
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Please contact your system administrator.
Add correct host key in /home/toff/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/toff/.ssh/known_hosts:10
ECDSA host key for 192.168.111.100 has changed and you have requested strict checking.
Host key verification failed.

You could now open the file ~/.ssh/known_hosts in a text editor and delete the offending line 10 from the list by hand, but there is a better way: with ssh-keygen -R IP-address, you remove the key from the file with a single command, so the next time you connect, you start from scratch – and have to confirm the key just like the very first time you connected to this machine. This also works if you use the hostname instead of the IP address to connect. To be on the safe side, the command copies the old state to ~/.ssh/known_hosts.old in the same directory.

$ ssh-keygen -R 192.168.111.100
# Host 192.168.111.100 found: line 10
/home/toff/.ssh/known_hosts updated.
Original contents retained as /home/toff/.ssh/known_hosts.old

$ ssh pi@192.168.111.100
The authenticity of host 'raspberrypi (192.168.111.100)' can't be established.
ECDSA key fingerprint is SHA256:6rR+0/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.111.100' (ECDSA) to the list of known hosts.
pi@192.168.111.100's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Apr 22 08:40:10 2016 from 192.168.178.57

Forcibly terminating an SSH connection

If you are logged in to a remote machine via SSH and shut it down with shutdown, halt or reboot, the system doesn’t kill the SSH connection abruptly. It stops the SSH server cleanly during shutdown, so you end up back in the terminal of the client machine and can keep working in the same terminal window. Now, I – and surely other Pi tinkerers too – like to unplug the Raspberry Pi and plug it back in to restart it quickly and painlessly. This is certainly not ideal for the integrity of the data on the memory card, but if I’m going to set up the system on it from scratch anyway, I don’t much care.

The downside is that SSH usually hangs in the terminal when you do this – after all, you just pulled the chair out from under it. You could now kill the SSH process or close the terminal window and open it again, but there is a clean solution for this situation, too: SSH knows a number of escape sequences that let you manage the current SSH session. You get an overview of the available commands if you type ~? on a new line in the terminal. To be on the safe side, simply press Enter once beforehand.

pi@raspberrypi:~ # ~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

The first sequence shown in the help is exactly the function we’re looking for: if you type ~. as text during an SSH session, you terminate the current SSH connection, no matter what. This doesn’t only work with a session that is still active and working (which you could close with exit at any time anyway), but also when, for example, you cut the power to the Pi and nothing happens in the terminal anymore. Here, too, it can help to press Enter once more before the actual command. Otherwise the escape sequence may come to nothing.

Pausing and resuming an SSH connection

The escape sequences can do other handy things, too. For example, you can suspend an SSH connection and resume it later without having to use a terminal multiplexer such as screen or tmux. If a process takes longer than expected, you can park the connection this way while the process on the remote machine keeps running. Unlike with the two terminal multiplexers mentioned, you don’t have to think ahead that the task might take longer and start them as a precaution. The corresponding sequence is the somewhat cryptic ~^Z, where the caret doesn’t stand for a character but for the Ctrl key. So you type ~ and then press Ctrl+Z. You then land back in the terminal of the machine on which you originally ran ssh. From there, you can pick up the connection again by typing fg and pressing Enter.

If you work on a “truly” remote system over the internet, the connection may well drop. On the one hand, this is because the server terminates the connection after a period of inactivity; on the other hand, your own network infrastructure (read: the router) may interfere. However, you can prevent the timeout with a keep-alive function. Depending on the situation, you can either configure the SSH server accordingly (which of course requires root privileges) or call SSH with the appropriate parameters right away. In that case, you don’t need any special privileges on either system.

Keep-alive on the server side

### Default keep-alive settings:
$ grep Alive /etc/ssh/sshd_config
#TCPKeepAlive yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
### Edit the SSH server configuration:
$ sudo nano /etc/ssh/sshd_config

### In the end, the relevant lines should look like this:
$ grep Alive /etc/ssh/sshd_config
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 3

### Restart the SSH server once:
$ sudo systemctl restart sshd

Keep-alive on the client side

### Keep the SSH connection alive from the client side
$ ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=1 pi@raspberrypi

In the first case, the setting applies to all users who want to log in to the system via SSH. As a rule, you should therefore only make this change if all users actually need it. Most of the time, though, you only need keep-alive in exceptional cases, so it makes sense to set the option only when needed when calling ssh. For me, this is the case with a web service I can log in to via SSH, for example. If I start long-running backups there, my router terminates the connection before the backup process can report success. With the keep-alive settings mentioned above, however, that’s no longer a problem.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.