HAUNTED HOSTS TUTORIAL FOR RUNNING SPOOKY SERVER DAEMONS
-
The text below describes a simple passwordless login configuration for
`sshd'. This type of login configuration is excellent for providing
kiosk services to server visitors, interesting server easter eggs, or
participation in events like "Haunted Hosts". Creating a configuration
compatible with this last use case will be the tutorial.
So, to participate in "Haunted Hosts", I need to create two
passwordless logins for each the `trick' and `treat' user. The logins
should be very restricted, having the least amount of system services
and privileges required to invoke a forced command to run after login.
User configuration
----------------------------------------------------------------------
I need to create two new users, `trick' and `treat'. I will give them
no password, and no home directory. They will get a shell, which is
necessary to invoke the `ForceCommand' configured for `sshd'.
`doas useradd -d /var/empty -s /bin/sh -p "" trick'
I will also narrow capabilities by assigning these users to a new
login class, `haunted'. This class will be configured with a limited
`PATH'. I will come back and update this article when I figure out how
to do this!
sshd_config
----------------------------------------------------------------------
I define a new `sshd' configuration file in my project's folder. I add
rules sufficient to permit passworldess logins, which is achieved with
`PasswordAuthentication yes' and `PermitEmptyPasswords yes'.
Next, I disable other `sshd' features of TTY, X11, tunneling, and port
forwarding. It's maybe overkill, but I set a timeout for killing the
session if the user hasn't any channel (e.g.: shell, program)
running. Oh, and to especially capture the festive symbols of horror,
I use port `666'. >:)
,----
| Port 666
| HostKey /etc/ssh/ssh_host_ed25519_key
| AuthenticationMethods none
| PasswordAuthentication yes
| PermitEmptyPasswords yes
| PermitTTY no
| PermitTunnel no
| PermitUserEnvironment no
| PermitX11 no
| PermitListen none
| PermitOpen none
| PermitRootLogin no
| UnusedConnectionTimeout 30
| X11Forwarding no
| AllowUsers trick treat
| Match User trick
| ForceCommand /bin/ed
| Match User treat
| ForceCommand /bin/ed
`----
For now, I am forcing `ed' to be invoked for both users. Later, I will
change this to another program.
I test my configuration by invoking `sshd' absolutely:
`doas /usr/sbin/sshd -d -E logs -f sshd_config'
The daemon is kept in the foreground with `-d'. `-E' creates a puts
output into a log file. This log file can be read to debug the
connection. Verbosity can be increased with `-v' flag.
It is necessary to invoke `sshd' with an absolute path. A
StackOverflow post cites this part of the release notes for 3.9 as the
reason:
"Make sshd(8) re-execute itself on accepting a new connection. This
security measure ensures that all execute-time randomisations are
reapplied for each connection rather than once, for the master
process' lifetime. This includes mmap and malloc mappings, shared
library addressing, shared library mapping order, ProPolice and
StackGhost cookies on systems that support such things."
The `-d' flag keeps the daemon in the foreground and provides
debugging output.