Security hardening
fail2ban end to end, and the PM2 log rotation that stops a disk filling up months after a deploy.
A recorded walkthrough for this page has not been made yet.
01.How It Works
The Security section of a server reads whether fail2ban is installed, whether the daemon answers, whether it starts with the server, and every jail with the failures it has seen, the bans it has made and the addresses banned right now. One button installs it with the server's own package manager, writes the jail, enables the service and confirms the daemon answers afterwards. Shipown manages exactly one file, /etc/fail2ban/jail.d/99-push-ops.conf, rewritten whole each time it saves, so jail.conf and jail.local stay as the distribution left them. The address your SSH session comes from is always in ignoreip, whatever you type, so tightening the sshd jail cannot lock you out. Where failed logins are read from is detected rather than assumed — auth.log on Debian and Ubuntu, secure on the RHEL family, the systemd journal on images without rsyslog, and /var/log/messages on Alpine — because a jail pointed at a file that is not there never starts, which is the usual reason fail2ban looks installed and bans nobody. PM2 log rotation sits in the same section: install and configure pm2-logrotate, choose the size it rotates at, how many old files it keeps and whether they are compressed, or clear what PM2 has already written.
Client-side operations encrypted directly between your desktop and target server.
SSH keys, passwords and API keys are held by the desktop app and encrypted with your OS keychain.