Skip to main content

SFTP & SSH access

SFTP & SSH is where you create the logins you use to transfer files and, where you allow it, open a shell into an environment.

These logins are separate credentials. They are not company members: creating one does not invite anybody to Hosting, and removing a member does not remove a login. One person may have a Hosting account and an environment login; the two are unrelated.

What a login can reach​

Every login reaches the environment's shared application files — all of the environment's application trees, not one application and not one folder — plus a shell where the environment allows it. A login lands in /srv, the root those trees are mounted under.

A login is a trusted maintainer

A login can read and change the application configuration, and that configuration contains the application's own database credentials. Read-only (below) stops writes; it does not hide anything. Do not treat two logins as isolated from each other: they run as the same user and can edit each other's files.

Create a login​

  1. Open Hosting → SFTP & SSH.
  2. Choose Add access user.
  3. Give it a username and a label that says who or what it is for.
  4. Add one or more public keys, a password, or both. A login with neither is refused — it could never sign in.
  5. Save.

The page tells you the scope before you create the login, because the choice is hard to take back: once a login exists it reaches the whole environment.

Keys, passwords, and the environment's protocol​

  • Public keys are the safer choice. Paste the public half of a key pair; the private half never leaves the machine that holds it.
  • Password login is an environment-wide setting, Allow password login. New environments allow it; existing environments keep whatever was chosen for them. A password on a login does nothing while the environment refuses passwords.
  • SFTP only is an environment-wide setting that takes the shell away, leaving file transfer. It restricts the protocol, not the files: an SFTP-only login still sees every application tree.

Changes to these settings restart the environment's access service, which signs out every SFTP, SSH and browser-tool session. Website traffic is unaffected — the sites stay up. Because a restart is the way a key or password change takes effect, the page says so before you save, and a change that has not yet been applied may leave the previous access working for a short while.

Read-only logins​

Marking a login read-only lets it read and download files but not modify them. It still reaches every application in the environment, and it can still read each application's configuration — including that application's database credentials, which are enough to change the database. Read-only is a file permission, not a boundary.

Marking a login read-only or read-write restarts the access service, for the same reason any other change does.

Connection details​

Once a login has been delivered, its page shows everything needed to connect: the host, the port, the username, and copy-ready ssh/sftp commands plus an ~/.ssh/config example.

  • Use the username shown on the page, exactly. A connection made with a different username is refused, and a refused attempt can be hard to trace afterwards.
  • The port belongs to the environment. If the page shows no connection details yet, the login has not been delivered; the status explains what it is waiting for, and the previous access may still work until the change is applied.

The Recent refused logins list shows attempts the environment refused, which is the fastest way to spot a typo in a username or a key that never arrived. The list only covers the current access service's lifetime, so a failed attempt from before a restart will not appear.

Using an SSH key pair​

# On the machine you connect from: create a key pair if you do not have one.
ssh-keygen -t ed25519 -C "you@example.com"

# Copy the public half into the login's key field.
cat ~/.ssh/id_ed25519.pub

Never paste the private key anywhere, including into Hosting.

Member access grants​

A company member's own personal SSH keys can be delivered to an environment through a grant. A grant names the person's account and the environment login their keys should reach. Company membership alone grants nothing: access is an explicit act.

Removing a member does not remove environment logins, and revoking a member's grant does not remove the login it fed. Removing the login is what removes the login.

Next​