Tenkai
Sign inStart for free

What Tenkai does to secure your servers

See how Tenkai restricts access to a new server, what it checks daily, and which security tasks you still handle.

Tenkai sets up SSH key access, a firewall and an encrypted network between your servers. It checks SSH policy daily. You keep root access and choose when to install operating system updates and reboot.

This gives you a security baseline without handing over your servers. It is not a full security audit, and Tenkai does not repair SSH or firewall changes for you.

What server setup closes on a new server1/7

Scene 1 of 7: Start with an exposed server

This example starts with SSH passwords enabled, no firewall and old packages. Your server's operating system image may already restrict access. The diagram uses SSH port 22.

Who can log in

Tenkai and your team use separate SSH keys:

  • Tenkai logs in as tenkai, with a key and sudo password generated for each server. It encrypts the private key in its database. Decrypting the private SSH key requires access to both Tenkai's database and its application encryption key.
  • Team members log in as root with SSH keys that an owner or admin authorizes. Tenkai receives only their public keys. Owners and admins can also open a root terminal in Tenkai without a personal SSH key.

Existing keys stay on the server. Deleting a key or removing a team member queues removal of keys Tenkai authorized. They work until removal succeeds. Retry failed removals when the server returns.

Tenkai records the server's host key fingerprint at enrollment and refuses later connections if that key differs.

Server setup writes the SSH policy in /etc/ssh/sshd_config.d/00-tenkai-hardening.conf:

PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

This disables password and keyboard-interactive logins and allows root to use a key. sshd takes the first value it reads, so the file comes before 50-cloud-init.conf. Setup fails if sshd -T reports a different default policy. The daily check also evaluates Match rules, within the limits below.

What the firewall lets in

Server setup enables ufw, allows outgoing traffic and denies incoming traffic by default. It adds rules for:

  • SSH on the port where the server accepted Tenkai's connection;
  • HTTP and HTTPS on TCP ports 80 and 443;
  • WireGuard on UDP port 51820, from the other cluster nodes' network endpoints.

Setup removes broad Swarm port rules, but keeps other existing rules. Review those too. A provider firewall must also allow the traffic you need.

On the Pro and Team plans, the host exposure check reads ufw every day and lists on the server's Firewall tab what Tenkai did not set up: ufw turned off, a rule that opens a port, and a process outside Docker that listens on a public address, with whether ufw lets it in. The check changes nothing.

Swarm and the cluster registry use WireGuard between nodes. These are not public port allowances. See What the firewall opens.

Docker-published ports can bypass ufw. Do not rely on it to protect a port you publish yourself. Tenkai lists unrecognized Swarm services under unmanaged services, but not containers started with docker run.

Managed services publish no ports themselves. External access uses a separate relay on the edge node, limited to your chosen duration and source addresses.

A web application can expose an additional TCP port through the edge node. That port is public and has no source filter. The application must authenticate clients and handle encryption itself.

What blocks attacks on your web applications

On a paid plan, you can turn on CrowdSec protection for a cluster. CrowdSec runs on the edge node and reads the HTTPS requests to your web applications. An address that scans for admin pages, tries passwords on a login page or looks for known flaws gets a 403 from every web application of the cluster. CrowdSec shares that address with its community, and blocks the addresses the community reports.

CrowdSec filters only the HTTPS requests to your web applications. The TCP ports of your web applications pass through Traefik as raw TCP, which CrowdSec does not filter. SSH does not go through Traefik at all: for SSH, Tenkai relies on key-only logins instead.

How the packages stay up to date

Setup upgrades the image's packages unless dockerd is already installed. It removes no packages, keeps modified configuration files and never reboots.

Tenkai refreshes package lists daily. Its agent reports pending updates every six hours, counting security updates when it can identify them. The update count comes from the available package lists. It does not prove that the server is up to date.

An owner or admin installs OS updates from the upkeep tab. Docker Engine and held packages are excluded. Reboots are separate. Move and reboot moves web applications without kept files and workers to other nodes first, when those nodes accept workloads and have room. Databases, kept files and scheduled job runs stay on the rebooting node and stop. Move the edge node before rebooting it to keep public traffic flowing.

Tenkai does not configure automatic OS updates or disable those the image already runs. It can update its own agent automatically, unless you turn that off for the cluster.

How Tenkai checks SSH every day

The SSH hardening check connects as tenkai and runs sshd -T -C with sudo. It checks the SSH rules for root and tenkai using an example external source address and the server address and port used by Tenkai.

The SSH tab of the server shows the result:

  • Not checked yet: no observation yet.
  • Matches the baseline: every assessed setting matches for those connections.
  • Drift detected: an assessed setting differs or is missing. The tab shows which one.
  • Impossible to verify: the latest attempt failed to connect, get sudo access or read the policy. A failed check never counts as a match.
  • Stale: the last observation is at least two days old, with no later failure to report.

Health lists servers with drift or failed checks. An owner or admin can also choose Check now on the server's SSH tab.

The check changes nothing. Fix the reported policy on the server, then check again. A match does not prove the policy for every user, group or source address. The firewall has its own check, described above.

What stays with you

  • Plan OS updates and reboots. Maintain Docker Engine separately, since an update can restart containers.
  • Limit root access. Protect private SSH keys with a passphrase. Owners and admins can reveal the tenkai sudo password once, so store it securely.
  • Review changes you make as root. Tenkai checks the SSH settings above and, on the Pro and Team plans, the ufw rules and host ports, not every change.
  • Keep your application's code, dependencies and secrets safe.
  • Decide whether to block repeated SSH login attempts. CrowdSec protection covers only your web applications.

When another option suits better

  • If you need a hardened image, intrusion detection or central login logs, Tenkai's baseline is not enough. Add the tools you need without breaking Tenkai's SSH and sudo access.
  • If you want someone else to maintain the operating system, a hosted PaaS may fit better. Tenkai keeps the servers under your control, including when you update and reboot them.

Go further