Skip to main content

SSH

SSH gives you the same shell as the Terminal page, from your own machine: your login user, your home directory, your files, and your resource limits.

sftp, scp, rsync, git, and a desktop database client all use SSH too, so one setup serves many tools.

Two things a connection attempt doesn't tell you
  • The port is probably not 22.
  • Your panel password doesn't work.

The SSH page shows both, with a ready-made command for your account. Take the details from there rather than assuming them.

The SSH page​

The page is reference material:

  • the hostname, port, and username
  • the connection command
  • how to generate a key and install it
  • examples for file transfer and tunnels
  • the fingerprints of the server's host keys
Keys are managed elsewhere

A key is a way into your account, so it sits with your other credentials on Password & Security → SSH Keys. The Manage SSH Keys button at the top of the SSH page takes you there.

The port​

For safety, your provider can move your server's SSH port away from 22. That changes nothing about what you do, only what you type:

ssh -p PORT [email protected]
sftp -P PORT [email protected]
Mind the capital letter

ssh uses -p. sftp and scp use -P.

Rather than remembering the port, record the server once in ~/.ssh/config on your own machine:

Host server.example.com
    HostName server.example.com
    User you
    Port PORT
    IdentityFile ~/.ssh/id_ed25519

Every tool that calls ssh then takes the port from that file, including sftp, scp, rsync, git, and most graphical clients.

Some tools, e.g. Navicat and DBeaver, ask for the port in their own dialog. The database page prints ready-made connection strings with the right port in them.

Passwords​

Where your provider made the server stricter, sshd accepts public keys only; both password methods are off. There's no password prompt to answer: the server refuses the connection instead. The SSH page says which of the two applies to your server.

The first key isn't a circular problem

You never need SSH to install a key:

  • The SSH Keys page installs it for you, with the file permissions sshd needs.
  • The Terminal is a second way.

Both authenticate through your panel session, not SSH, so they still work if you lose your key.

Manage the authorized keys​

Security → SSH Keys lists each key's type, SHA-256 fingerprint, and comment, and lets you remove one. Adding or removing a key asks you to confirm your identity, as a password change does.

Paste the public half

That's the contents of ~/.ssh/id_ed25519.pub, the file with the .pub suffix. The private half never leaves your machine; the panel has no use for it.

The panel accepts Ed25519, RSA, ECDSA, and the sk-* variants for a security key. Ed25519 is the right default for a new key:

ssh-keygen -t ed25519 -C "you@your-laptop"

A key line can carry the standard authorized_keys option prefix before the key type, to limit what the key can do, e.g. restrict, no-pty, from="10.0.0.0/8", or command="…". The panel handles a quoted value with spaces exactly as sshd does, so a forced command survives a list and a save unchanged.

If you also edit the file by hand​

The keys are your login user's ~/.ssh/authorized_keys, and nothing stops you from editing it over SSH. The panel rewrites the whole file each time you add or remove a key, with two consequences.

Comment lines aren't kept

The panel ignores comment lines when it reads the file, so they're gone after your next change through the panel.

A line the panel can't read stops it from working on the file

Rather than show a wrong list, the SSH Keys page says it couldn't read the file and stops you from adding a key, so a save can't replace the contents.

Fix the line over SSH or in the Terminal and the page works again. Nothing is lost meanwhile; the panel leaves the file exactly as you wrote it.

Verify the server​

The first time you connect, SSH asks you to confirm the server's identity and prints a fingerprint. The SSH page lists the same fingerprints, one per host key type, so you can compare instead of answering yes without evidence.

The panel also publishes the fingerprints in DNS as SSHFP records. With a resolver that validates DNSSEC, your client makes the check itself and doesn't ask you:

ssh -o VerifyHostKeyDNS=yes -p PORT [email protected]

File transfer and tunnels​

sftp and scp use the same key and port, so once ssh works, both work. A desktop file-transfer client connects the same way.

ssh -L forwards a local port over the connection, which is how a desktop tool reaches a database. A database listens on the server's private network, never on the Internet. The forwarded connection opens as you, so it gives you nothing your shell doesn't already have.

One thing that looks like SSH and isn't

A share gives a folder to one of your domain users. It uses a separate SFTP service on port 2222, with that user's own password. Nothing on this page affects it: none of your keys are involved, and its port doesn't move.

What SSH doesn't change​

  • A process still belongs to the session that started it, and the system stops it when your last session ends. See long-running processes.
  • The elup and eldown transfer commands only work inside the browser terminal. They drive your browser, not the connection.