1. Give the hub machine a fixed address on your network (a DHCP reservation on your router).

2. On your router, forward one TCP port to the hub machine's port 2022 (the listen setting). The outside port can be 2022 or something else.

3. Give it a name. A DNS name such as hub.example.com is better than an IP address: members don't have to change anything if your address changes.

4. Tell the hub:

doorhub set public_host hub.example.com
doorhub set public_port 2022

5. From outside your network, check the port answers:

ssh -p 2022 test@hub.example.com

It should ask for a password and refuse it. That's the hub: it doesn't allow shells, so this is the expected result.

Only the hub's port needs to be open. The Synchronet RLogin port (513) does not: the hub reaches it on the same machine.

• Members can only open RLogin tunnels. Shell, exec, subsystems (SFTP), remote port forwarding and every other SSH request are refused. Whatever address a connector asks to reach, the hub only ever talks RLogin to its own door BBS.
• A member can only send players with its own tag. A connection claiming another tag is refused and logged.
• A disabled member is refused at the next session, even through an open tunnel.
• Each member can have at most max_sessions_per_bbs players on at once (10 by default).

• Member passwords are random, 32 characters long, and stored only as bcrypt hashes. Player passwords from member BBSes are stored the same way.
• The door BBS passwords for hub users are random and stored in players.json. Like the whole hub folder, it should be readable only by the hub's account (the Linux steps set the folder to 700).
• Failed logins are logged (Login refused for “name” from address) and each takes two seconds; a connection gets three tries. With long random passwords, guessing isn't practical. fail2ban can watch the log lines if you want to block repeat offenders.
• The host key host_ed25519 identifies your hub. Keep it secret and back it up. If you lose it, every member's connector refuses the new key until they delete their doorhub_known_hosts.

Doors run on your Synchronet as ordinary users, with the same limits as any caller. Treat hub players like callers: a door that lets a caller reach a shell or files is just as risky through the hub. If you'd rather keep hub players away from your main BBS entirely, run a separate Synchronet just for the hub.

• The connector listens on 127.0.0.1 by default, so only the BBS machine can use it.
• It checks the hub's key against the one it saved the first time, so it can't be fooled into sending players to a different server.
• The connector's ini holds the BBS's hub password; it should be readable only by the BBS account.