I got a new Raspberry Pi 4 as I’m looking to consolidate some of my old Pi’s and clean up my servers. To avoid issues with wearing out the SD cards I mount the root file system off an NFS NAS storage server.
Unfortunately I’ve hit a problem with installing Bind9 using the defaults when mounting root via NFS. When starting Bind9 I get the error
named: working directory ‘/var/cache/bind’ is not writable
However, the /var/cache/bind directory is fully writable by the bind account.
Running a few test I verified that the exact same configuration works when the root filesystem is on the SD card. It seems this issue is related to the chroot that the bind9 runs in by default. If I edit /etc/defaults/bind9 and remove “-u bind” from OPTIONS then bind starts. However, its obviously running as root. I’d prefer to have it run as bind.
So far poking around at google hasn’t identified the specific issue. I’m pretty sure it’s somehow related to using chroot on an NFS mounted filesystem.
I’ll post an update if/when I figure out the issue. In the meantime if you hit the same problem you can always run as root 🙁
Many home routers, like the Asus RT-AC68U, offer a web remote administration interface. This interface is useful when you need to manage the router away from home. However, frequently the only authentication mechanism is a single password. The router is thus vulnerable to password guessing on the internet facing administration interface.
The Asus router also offers an SSH interface that allows direct access to the router OS. SSH is a well tested secure interface that offers password and certificate based authentication. While most router settings can be configured by the SSH interface it is not as user friendly as the web administration interface.
Using SSH’s tunneling capability the router can be configured to provide the security of SSH and the user friendliness of the web administration interface over the Internet.
SSH’s tunneling protocol can establish a local end point and proxy that local end point to a securely connected remote end point. We can use this capability to securely tunnel from the Internet via SSH to the routers web administration interface.
This tutorial assumes basic familiarity with SSH and use of public and private keys for SSH authentication.
The router is configured to use a dynamic DNS provider to allocate a DNS name to the external interface of the router.
Configure the router
Configure the router to enable the SSH interface. Ensure that only certificate based authentication is enabled. (If password authentication is enabled then the system is vulnerable to password guessing.) Add in the public keys of any SSH accounts permitted to access the router.
Disable the internet administration interface.
Establish an SSH Tunnel
On a remote machine in a command shell (MacOS, Linux, Unix, Windows with Cygwin, …) setup the SSH tunnel using -L option.
The above command will establish a connection from port 9000 on the localhost to port 8443 on 192.168.0.1 (substitute with the LAN address of your router) via myrouter1234.dyndns-home.com. Where myrouter1234.dyndns-home.com is the internet facing name of your router provided by a Dynamic DNS provider. The -N option instructs ssh to not send any remote commands to the SSH server on the router.
Connect to the Admin Interface
In a browser go to https://localhost:9000 to access the routers admin interface.
To terminate the session simply Ctrl-C to kill SSH in the command shell.