Servers and SSH

A server is set up once and used by every site on it. The wizard asks one question per step, checks each answer, and never guesses at the one that matters most: whether the machine you reached is the machine you meant.

Adding a server

Servers in the rail, then Add server. Five steps:

1. Details. A short name of your choosing (this is what you type from now on), the server address (a hostname or IP), the username, and the port if it is not 22. Your hosting company sent these in the welcome email, usually under something like "SSH access".
2. Identity. The app reads the server's fingerprint and shows it. Compare it with what your host publishes; if they match, accept. This is what stops a connection to the wrong machine, and it is the one step the app will not do for you.
3. Key. The app uses a key rather than a password. It offers to make one, or use one you already have; the public half is shown so you can copy it.
4. Access. Getting the public key onto the server, one of three ways: let this app do it (with your password, once), run one command yourself (shown, with a copy button), or paste it in your host's panel (most panels have an SSH keys page).
5. Done. A test connection, then the server is saved to your ~/.ssh/config.

Where servers are stored

In ~/.ssh/config, the same file your terminal reads. Anything you add there by hand appears in the app; anything the app adds works in your terminal. Nothing about a server is stored anywhere else, and no credential ever leaves your computer.

Testing

Each server row has a Test button that connects and reports what it found: reachable or not, and whether tar, WP-CLI, php and mysqldump are there.

Passwords

The app connects with keys, not passwords. A password is used at most once, in the Access step, to install the key. If your host only allows passwords, the wizard's paste it in your host's panel route still works.