Dear maintainer,
minor update: The apparmor config I included in the original message was not
working.
I currently use
------------- 8< -------------------------------------------
include <tunables/global>
profile sslh /usr/sbin/sslh flags=(attach_disconnected, complain) {
include <abstractions/base>
include <abstractions/nameservice-strict>
include <abstractions/hosts_access>
capability net_bind_service,
capability setgid,
capability setuid,
capability sys_chroot,
capability sys_resource,
/usr/sbin/sslh pix,
network tcp,
unix (send) type=stream,
@{etc_ro}/hosts.deny r,
@{etc_ro}/hosts.allow r,
@{etc_ro}/sslh/** r,
owner @{run}/sslh/sslh.pid rw,
}
------------- 8< -------------------------------------------
Using this, I see no complains in the log. However, after a few hours, sslh
stops to accept ssh connections.
I see in the log:
------------- 8< -------------------------------------------
Jun 12 21:53:34 xxx sslh[599939]: accepted fd 4
Jun 12 21:53:34 xxx sslh[630938]: writing deferred on fd -1
Jun 12 21:53:34 xxx sslh[630938]: probing for ssh
Jun 12 21:53:34 xxx sslh[630938]: probed for ssh: PROBE_MATCH
Jun 12 21:54:00 xxx sslh[630938]: connection from unknown(CLIENT_IPADDRESS):
access denied
------------- 8< -------------------------------------------
Calling `tcpdmatch ssl CLIENT_IPADDRESS` shows it is granted.
The log seems normal, the only message that stands out is:
------------- 8< -------------------------------------------
Jun 12 16:37:16 xxx sslh[599939]: accepted fd 4
Jun 12 16:37:16 xxx sslh[620603]: common.c:339:getpeername:107:Transport
endpoint is not connected
Jun 12 16:37:16 xxx sslh[620603]: sslh-fork.c:114:connect: Transport endpoint
is not connected
------------- 8< -------------------------------------------
(I actually noticed that it no longer works at about 17:35, it did work at some
time between 13:00 and 16:37)
After restarting sslh, it immediately works again, until it breaks a few hours
later.
As reference, here’s my config (IP addresses redacted):
------------- 8< -------------------------------------------
# SSLH configuration
# NOTE: The following values are overridden by the start script!
#
# foreground: true;
# inetd: false;
# user: "sslh";
# pidfile: "/var/run/sslh/sslh.pid";
# Custom config follows
# Do not resolve hostnames.
numeric: true;
# verbose-connections: 3;
verbose-connections: 9;
verbose-config-error: 9;
verbose-connections-try: 9;
verbose-connections-error: 9;
verbose-fd: 9;
verbose-probe-info: 9;
verbose-probe-error: 9;
verbose-system-error: 9;
verbose-int-error: 9;
listen:
(
{
host: "PUBLIC_IPv4";
port: "443";
}
);
protocols:
(
# That's why we are here ...
{
name: "ssh";
service: "ssh";
host: "PUBLIC_IPv4";
port: "22";
keepalive: true;
tfo_ok: true;
log_level: 1;
},
# TLS is forwarded to HTTPs (could be something else but we do not
care).
{
name: "tls";
host: "127.0.0.1";
port: "443";
log_level: 0;
},
# On timeout, forward to HTTPs.
{
name: "timeout";
host: "127.0.0.1";
port: "443";
}
);
------------- 8< -------------------------------------------
HTH,
Daniel
On Tue, 02 Jun 2026 11:07:01 +0200 =?utf-8?q?Daniel_H=C3=B6pfl?=
<[email protected]> wrote:
Package: sslh
Version: 2.1.4-1+b1
Severity: important
Tags: upstream
Dear maintainer,
I use sslh to have both, HTTPs and SSH on one port.
I also monitor the network to detect suspicious requests and I use other
services to regularly update my /etc/hosts.deny.
This file is owned by user/group root and uses 0644 as access rights:
-rw-r--r-- 1 root root 723080 Jun 2 08:57 /etc/hosts.deny
Since I upgraded to Trixie, sslh fails to perform its job due to:
warning: cannot open /etc/hosts.deny: Permission denied
For now, I fixed it by adding the following /etc/apparmor.d/usr.sbin.sslh:
------------- 8< -------------------------------------------
#include <tunables/global>
profile named /usr/sbin/sslh flags=(attach_disconnected) {
#include <abstractions/hosts>
}
------------- 8< -------------------------------------------
I think the same problem is documented upstream:
https://github.com/yrutschle/sslh/issues/450
I assume the sslh package should either include a similar apparmor config or
(better) upgrade to a upstream version that fixes the bug.
-- System Information:
Debian Release: 13.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.90+deb13.1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sslh depends on:
ii adduser 3.152
ii debconf 1.5.91
ii init-system-helpers 1.69~deb13u1
ii libc6 2.41-12+deb13u3
ii libcap2 1:2.75-10+deb13u1+b1
ii libconfig11 1.7.3-2
ii libev4t64 1:4.33-2.1+b1
ii libpcre2-8-0 10.46-1~deb13u1
ii libsystemd0 257.13-1~deb13u1
ii libwrap0 7.6.q-36
ii update-inetd 4.53
Versions of packages sslh recommends:
ii apache2 [httpd] 2.4.67-1~deb13u2
