Safe Change

Safe Change edits a config file on a server the way a careful administrator would: a diff, the server’s own check, a look at what the change does to the login you are using, a backup, and an optional way back that lives on the server itself.

Ways into the review sheet #

Every remote save lands in one review sheet, whichever view is in front.

When Farabi’s draft drops an operation, the sheet says why, for example that a model may not set ForceCommand.

What the sheet checks #

The kind of file comes from its path, never from a model.

Beside the server’s check, the sheet shows sshd’s effective settings for this login before and after. An edit sshd reads the same way, because a value set earlier or in an included file wins, is marked no effect.

Findings #

Code’s findings appear in red when:

• The login you are using would be refused: its user, group, method or root login.
• sshd would stop listening where you came in, or the new port is taken.
• Forwarding goes off for hosts that jump through this one, named.
• SFTP goes.
• A directive runs commands or widens privilege: ForceCommand, AuthorizedKeysCommand, AuthorizedKeysFile, TrustedUserCAKeys, Banner, NOPASSWD, Exec*=, pam_exec and similar.
• Half the file is deleted.

The green line Your current login still works after this change shows only when nothing blocks. Farabi’s summary, if you use it, comes after all of that, is labelled advisory, and never changes a button.

Privileges #

• Apply needs root or passwordless sudo (sudo -n). Sudo passwords are not handled yet. The sheet says so and, when your login can write the file, offers a plain upload as that login, unchecked.
• When checks cannot run at all, for example on an SFTP-only login or a server without a POSIX shell, the plain upload stays. For a file that can lock you out, it asks you to type the host’s name.
• Only safe folders. As root or with sudo, Gatesys SSH writes only into a folder no other user can change (owned by root, not writable by others). A file in any other folder is not applied.
• Links are resolved first, as root. One that points at a secret or at another kind of file is refused before anything is read.

Apply a change #

Click Apply with safety net (or install with a backup only, where allowed). One script, on one channel, over standard input:

1. Stages the new file and checks it against the server copy you reviewed. If the server copy changed since, it is refused and you are asked to Recheck.
2. Runs the server’s check.
3. Backs up the current file.
4. Arms the safety net, if you chose it.
5. Installs the new file atomically, keeping owner and mode, running restorecon where it exists, and acting on the real file behind a symlink.
6. Checks the live config and reloads.

Backups go to /var/backups/gatesys/<hash of the path>/<name>.<utc>.bak, mode 0600 in a 0700 folder, five kept per file, with free space checked first. The backup just made is never the one pruned.

If a check fails after install, the backup is restored at once and your edit goes back to waiting, with its copy. If even that put-back fails, the sheet says so and the safety net stays armed to restore at its time.

The safety net #

The safety net arms a restore on the server itself before the install, so a change that locks you out undoes itself.

1. Choose the window: 1, 3 or 10 minutes. The default is 3, set in Settings › Safety › Config changes › Safety net window.
2. Apply. The server arms a systemd transient timer, or where there is none, a detached watchdog.
3. Gatesys SSH logs in again, fresh, and asks New login works. Keep this change? The title bar’s chip counts down, and a notification comes a minute before the end.
4. Click Keep to confirm. If you do nothing, the server puts the old file back when the window ends.

The safety net is built for Linux with systemd; the watchdog is best effort elsewhere.

How Keep and the restore settle #

Keep and the restore race for one state file on the server, and a rename is atomic, so exactly one wins. Keep then stops only the timer, never a restore already running. It counts as confirmed only when the state file says kept and the file is still what Gatesys SSH installed. Otherwise the chip reads, for example, Not confirmed — the server restores at 14:32, with Retry.

• Keep closes ten seconds before the restore, and is never offered for a change whose fresh login failed.
• The restore puts the backup back only if the file is still exactly what Gatesys SSH installed. A file someone changed inside the window is left alone.
• A few seconds after the restore time, Gatesys SSH asks the server what it did and tells you, without a reconnect.
• If the host drops off, the chip says so and your edit keeps its copy. The next connect reads what happened: restored, kept, not restored because the file changed, or a reboot inside the window.

When the safety net is required #

After a port change, Keep offers to update the saved host’s port (on by default). A firewall may still block the new port: Gatesys SSH warns, and never opens ports.

The fresh login #

The fresh login proves the change did not lock you out:

• It dials only the target, through a channel on the live session’s hop in front of it, so no bastion signs you in again.
• It uses only the method and key that logged the live session in. It never prompts for a host key and never retries a password or a key.
• On a new port it accepts only the host key already trusted for the old one, and saves it only after a confirmed Keep.
• When it fails, Hop Doctor’s reading says why and the old file is put back at once.
• After two failed fresh logins to a server in ten minutes, a third is refused, so a guard like fail2ban does not ban this computer.

One change per host #

While one change is applying or waiting for Keep, another change to the same server waits, even through a different saved login to the same host and port, and the sheet says which. On a server that allows only one channel, New tab and Split ask first, since a new terminal may take the channel Keep needs.

What Farabi sees #

Only with Pro, the assistant on, and Settings › Safety › Config changes › Review config changes on:

• For a review: the diff’s hunks, at most 3 KB. For a draft: the file’s active lines, at most 6 KB, and the sshd keywords Farabi may use. Past those sizes, no call is made.
• Always redacted line by line: passwords, tokens, requirepass, preshared and private keys (known from the whole file) and password hashes. Scanned by the Injection Shield and fenced as data.
• Never reviewed: key files and password files such as *.key, *.pem and /etc/shadow.
• Off this computer, only with your consent. A cloud API, an agent CLI, a model on your network or through a tunnel gets nothing until you allow that destination once in the sheet. Even then, saved hosts, addresses, paths, ports and quoted text go as placeholders. Login names go as written. Forget config-file consents in Settings asks again.

On the record #

The audit log’s Change filter shows each apply with its line counts, the server check’s result, the backup’s path, the safety net and a short hash of the diff; each Keep, revert and restore; and a port update on Keep. A sudo read is logged under SFTP, and a Farabi draft or review under AI with the provider and model. The file, the diff and the model’s words are never logged.

Quitting and updating #

While a change waits for Keep, Restart to update waits too and says why. Quitting asks: Keep and quit, or quit and let the server restore. A change whose window ended while its host stayed away no longer holds quit or updates, and can be forgotten from its sheet.