Server Deploy Wiki

How it works

There are two parts, and you can use either on its own:

Both produce the same result, because the Windows app embeds the exact script it deploys. The repository contains no personal data: users, keys, IPs and everything else come from you when you run it.

Requirements

Installing the app

Download from the Software page:

• MSI installer: installs to C:\Program Files\DarkCipher Systems\Server Deploy with a Start-menu shortcut (desktop shortcut optional). Newer versions upgrade in place; uninstall from Settings › Apps, which also offers to delete your saved profiles.
• Portable zip: unzip anywhere and run DcxDeploy.exe. No install, no admin rights.
• Server script only: just dcx-setup.sh, for running on the server without Windows.

# Silent MSI install / uninstall (elevated)
msiexec /i DarkCipher-Server-Deploy-1.0.2-x64.msi /qn
msiexec /x DarkCipher-Server-Deploy-1.0.2-x64.msi /qn

# Check the download first (compare with the hash on the Software page)
Get-FileHash .\DarkCipher-Server-Deploy-1.0.2-x64.msi

The app isn't code-signed yet, so SmartScreen may warn you. See Signing & Smart App Control.

Tour

Every page of the Windows app, shown with a made-up demo server (203.0.113.10, a documentation IP range) and demo users. Click a screenshot for full size.

The eight pages

The app walks you through eight pages. You can move back and forth freely; everything is validated live and summarised on the Review page.

Profiles save every setting per server (New, Save, Delete, Import, Export). A profile is a standard answers file, so you can export one from the app and use it on a server with --config, or the other way round. Profiles never contain passwords.

On the server only

# Full-screen installer (prefilled from the last run, if any)
sudo bash dcx-setup.sh

# Prefilled from an answers file
sudo bash dcx-setup.sh --config answers.conf

# Unattended: no questions, stops before changing anything if the file has errors
sudo bash dcx-setup.sh --config answers.conf --yes

# Every hardening technique with its id, default and description
bash dcx-setup.sh --list-hardening

# After the first run it is installed as a command
sudo dcx-setup            # change anything later
sudo dcx-setup --check    # checks + Lynis audit only, changes nothing

The menu has the same sections as the app: System, Users (add, edit, keys), SSH & firewall, Server type, Hardening (per group, with descriptions), Load / Save answers, and Review and install. It's safe to re-run: settings are written idempotently, and switching a technique off removes what it added where that's possible.

Answers files

Plain key=value text with sections. Values are taken literally; nothing in the file is executed. Anything you leave out keeps its default (for hardening, the recommended setting). yes/no also accepts true/false, on/off and 1/0. A full example ships as example-answers.conf.

[server]
hostname=web-01
timezone=Etc/UTC
swap_gb=2
ssh_port=22
trusted_ips=203.0.113.10          # space-separated IPs or CIDRs
ssh_anywhere=yes                  # no = only trusted_ips can connect
tcp_forwarding=local              # local | no | yes
authorized_keys=append            # append | replace
extra_ports=51820/udp 8443/tcp
vendor_users=ubuntu linuxuser
reboot_time=04:00
primary_user=alex

[roles]
nginx=yes
extra_packages=htop ncdu
claude_code=no

[hardening]                       # only list what you change
block_usb=yes
aide=no

[user alex]
fullname=Alex Example
shell=/bin/bash
sudo=nopasswd                     # nopasswd | password | none
groups=
key=ssh-ed25519 AAAA… alex@laptop # any number of key= lines
github=alex-example               # and/or fetch github.com/USER.keys
# password_hash=$6$…              # optional (openssl passwd -6)

Unknown sections are ignored, so the [deploy] section the Windows app adds (host, login, key path) doesn't bother the script.

Users & SSH keys

• Every key is validated with ssh-keygen before anything changes; invalid or duplicate keys are rejected.
• authorized_keys is written 0600, owned by the user, in a 0700 .ssh folder.
• Sudo rules go in their own file per user under /etc/sudoers.d/ and are checked with visudo; a broken rule is never installed.
• Passwords are optional. If you set one, the password policy applies (14+ characters by default). You can give a crypt hash ($6$…, $y$…) instead of a plain password.
• The primary user is the admin the app reconnects and tests as, and the user Claude Code is installed for (into ~/.local, with ~/Documents/Projects created).
• At least one user must have sudo; the Review page won't let you deploy without one.

Server types

Every server gets the base: a full upgrade, the core tools (curl, git, rsync, tmux, needrestart, …) and whatever the enabled hardening needs (ufw, fail2ban, auditd, AppArmor profiles, Lynis, …). On top of that:

More server types are coming; see Coming soon.

Hardening catalog

36 techniques in 8 groups. Every one is explained and can be switched off. Thirty-one are on by default; the five marked opt-in can get in the way on some servers, so you choose them. This table is generated from the script itself.

Lockout protection

Locking yourself out of a server is the classic hardening mistake, so the tool is built around avoiding it:

• Validation first: the run refuses to start if no user has sudo, a user can't log in (no key while password logins are off), SSH would be blocked for everyone, or the primary user doesn't exist.
• Warnings for the subtle cases: you're connected from an IP that won't be allowed, your current login will be locked, the SSH port is moving.
• Configs are tested before they're applied: sshd -t, visudo -c and nginx -t must pass before a reload.
• Runs in tmux: the setup carries on if your connection drops when SSH or the firewall changes. Watch it live with sudo tmux attach -t dcx-setup.
• Reconnect and verify: the app reconnects as the new admin on the new port, then tests a fresh login and whether sudo works before telling you to close old sessions.
• Your trusted IPs are never banned by fail2ban and skip the SSH rate limit.

Checks & Lynis

Every run ends with post-checks that confirm each enabled technique actually took effect. Each line is OK, WARN or FAIL, with a total at the end. Examples:

• sshd config valid; password and keyboard-interactive logins off; public key only; root login off; AllowUsers set; modern ciphers only
• each user's key present with 0600 permissions; passwordless sudo actually works where configured; sudoers syntax valid
• root and vendor accounts locked; password policy, sudo logging, su and cron restrictions in place
• firewall active with default deny and the right ports; fail2ban running with the sshd and recidive jails
• network and kernel sysctls set; core dumps off; rare modules and USB storage blocked; /dev/shm noexec
• nginx running, version hidden, bare IP gets nothing, and the jail really hides /etc/shadow from nginx
• unattended upgrades, AppArmor, persistent journal, auditd rules, time sync and swap

With Lynis on, a full Lynis audit runs last and reports its hardening index (out of 100) with the top warnings and suggestions. Re-run everything at any time, without changing anything, with sudo dcx-setup --check or the app's Run checks button.

After setup

1. In a new terminal, log in as your admin on the new port, then check sudo -n true && echo sudo-ok.
2. Web server? Point your domain's DNS at the server, add a site under /etc/nginx/sites-available (root under /var/www), then run sudo certbot --nginx -d example.com.
3. Reboot when convenient to load an upgraded kernel. /tmp tmpfs and disabling IPv6 take full effect after a reboot.
4. Change anything later with sudo dcx-setup; it starts from your last answers.

Useful audit searches: sudo ausearch -k identity, -k sudoers, -k sshd, -k root-commands. Every sudo command is also logged in /var/log/sudo.log.

Files & logs

Privacy & secrets

• No telemetry. The app talks only to your server (over your own ssh.exe) and, if you ask it to, to github.com/<user>.keys.
• Passwords are never saved. Profiles, the server's saved answers and exported files never contain them. A sudo password is sent over the SSH connection's input, never on a command line.
• The uploaded answers are destroyed: the copy used for the run (which can contain passwords) is shredded on the server when the run finishes. It lives in a root-only 0700 folder in the meantime.
• Host keys: new servers are trusted on first use (StrictHostKeyChecking=accept-new); a changed host key is always refused.
• Your keys stay yours: only public keys are ever uploaded. The app uses your private key through ssh.exe and never reads or copies it.

Troubleshooting

Coming soon

• More server types beyond nginx, so one tool can build more kinds of server.
• More configuration options for each part of the setup.
• More hardening techniques. Because the app's Hardening page is generated from the script's catalog, new techniques appear in the app automatically.

Have something you'd like to see? Suggest it or ask on Discord.

Dev environment

• Windows 10/11 with the .NET 8 SDK.
• For the MSI: the WiX 5 tool, restored from the repo's tool manifest (dotnet tool restore).
• An Ubuntu 24.04+ VM or throwaway VPS to test the script. bash -n dcx-setup.sh for a syntax check.

Building

cd ServerDeploy-src
dotnet build windows\DcxDeploy      # debug build
.\build.ps1                         # dist\: MSI, portable zip, dcx-setup.sh, example-answers.conf

Release builds are a single self-contained DcxDeploy.exe (no .NET install needed), built with no debug symbols and with source paths mapped away so nothing from the build machine ends up inside.

Project layout

Deploy architecture

1. The app writes an answers file from the profile and packs it with the embedded dcx-setup.sh and dcx-launch.sh into an in-memory tar.gz.
2. One ssh call pipes the bundle into tar -xzf - in ~/.dcx-deploy (umask 077). No scp, no temporary files on your PC.
3. sudo dcx-launch.sh start checks the upload folder, moves it to /root/dcx-deploy (0700), starts dcx-setup.sh --config answers.conf --yes in the tmux session dcx-setup, and tails the log back over the same SSH connection.
4. The app parses the stream (steps, OK/WARN/FAIL lines and the markers below) to drive the progress bar and log colours.
5. If the stream drops, the app probes the new admin login first (then the original one) and runs dcx-launch.sh follow, which replays the log from the start.
6. When the run ends, the launcher shreds the answers file, and the app tests a fresh login as the primary user.

Log protocol

Lines starting with @@DCX- are machine-readable markers; everything else is human-readable log.

Adding a hardening technique

1. Add one line to the catalog between the HARDENING CATALOG markers in dcx-setup.sh: id|on|Category|Title|Description (no | in the description).
2. Implement it in the matching apply_* function inside if hon id; then … fi, and remove what it adds in the else branch where you can.
3. Add a check to post_checks (chk for must-pass, chkw for warnings).
4. Rebuild the app: its Hardening page, answers files and validation pick the technique up from the embedded script automatically.

Adding a server type

1. Add a setting to [roles]: a CFG_* default in reset_config, parsing in set_global, writing in save_config.
2. Add its packages in apply_packages and an apply_<role> step, registered in apply().
3. Open its ports in apply_firewall, add checks to post_checks, and a menu entry in tui_roles.
4. In the app, add the property to Profile, read and write it in Answers.cs, and add it to the Server type page.

Release process

1. Bump <Version> in windows/DcxDeploy/DcxDeploy.csproj (and DCX_VERSION in the script if it changed).
2. Run build.ps1. Never change the MSI's UpgradeCode, or upgrades stop working.
3. Test on a fresh Ubuntu server: a deploy from the app, a menu run and --check.
4. Before publishing, every file is privacy-audited: the source, the server script, the unpacked MSI and an uncompressed build of the app are scanned, and publishing stops if anything personal is found.

Contributing

• MIT-licensed: fork, modify and redistribute with the copyright and licence notice intact.
• Keep it generic: never commit real IPs, hostnames, usernames or keys. Use the demo values from example-answers.conf.
• Every new technique needs a description, an off switch and a check.
• Questions or patches: email or Discord.