Shell and SFTP access

Alongside your control panel you get your own login to the server: the oN.ftp account. You use it two ways — as a shell over SSH (to run commands like drush), and as a file transfer login over SFTP or FTPS (to upload and download files with a program like FileZilla). This page shows you how to connect both ways, how to set up a key so you never have to type a password, and exactly what your shell will and won't let you do.

You don't need any of this to run sites — the control panel does the important work. The shell is here for when you want to move files around or run Drupal commands by hand.

Your login details

Everything you need to connect came in your welcome email. Keep it handy; it's the source of truth. You'll use:

• Host — the server's name, something like server.example.com. It's in your welcome email.
• Port — 22, the normal SSH/SFTP port. You rarely have to type this; most programs assume it.
• Username — your oN.ftp account. oN is your account name (o1, o2, and so on — your host will tell you which is yours), and the .ftp on the end is part of the username, not a typo.
• Password — the one from your welcome email (until you switch to a key, below).

If you can't find the email or the password won't connect, don't retry endlessly — your host can re-send your details. See when you can't connect first; it covers the two things that trip people up most.

Connecting to your shell over SSH

On Linux or macOS, open a terminal and type:

ssh oN.ftp@server.example.com

Replace oN with your account name and server.example.com with your host from the welcome email. On Windows you can do the same in PowerShell, or use a program like PuTTY.

The first time you connect it asks you to confirm the server's fingerprint (type yes), then asks for your password. When you're in, you'll land in your own home directory and see a short welcome banner. You're now in a limited shell — a safe, fenced-off version of a normal shell that can only see your own files.

Have a look around with the commands you'd expect:

ls          # list files
cd static   # move into a folder
pwd         # show where you are

You're free to move around inside your account. You can't step outside it — there's nothing above your home directory for you to reach.

What your shell lets you do

Your limited shell allows a curated set of commands — the ones you actually need for running Drupal sites. Among them:

• Drupal command line — drush (and version-specific drush8, drush10, drush11), plus vdrush for running Drush inside a site's own vendored copy.
• Composer for managing your Drupal dependencies.
• Git for pulling and pushing your code.
• Database tools — mysql, mysqldump, and the faster mydumper / myloader.
• File and archive tools — cp, mv, rm, mkdir, find, grep, sed, tar, gzip / gunzip, unzip, rsync. (scp is not available in the default limited shell — use rsync or your SFTP program to move files; hosts that enable Node.js for your account turn scp on too.)
• Editors — nano, vi / vim for quick edits.
• Backups — mybackup, BOA's self-service backup and restore tool for your own sites and databases.
• passwd to change your own password, and ssh-keygen to make a key.
• curl, wget, ssh for fetching things and connecting out.

If you ever forget what's available, type ? or help at the shell prompt and it lists the allowed commands for you.

What your shell deliberately blocks

The limited shell is intentionally fenced. This is what keeps your account (and your neighbours') safe, and it's working as designed — not something that's broken:

• No general-purpose shells. You can't launch bash, sh, python, or perl as a shell to run arbitrary programs. The allowed commands are the whole menu.
• No chaining tricks. Stringing commands together with ;, backticks, $( ) or ${ } is blocked. Run your commands one at a time.
• A few Drush subcommands are off-limits. Anything that would run arbitrary PHP or reach outside your sites — such as drush php, drush ev, drush scr, drush sql-create, drush site-install, and drush ssh — is blocked. Everyday Drush (cache clears, database updates, module management, exports) works normally.
• Nothing system-level. You can't see other accounts, touch the web server or database configuration, or reach anything outside your home directory. Those belong to your host.

If you type something that isn't allowed, the shell simply tells you the command is forbidden rather than running it. After a few forbidden attempts in one session it will end the session — just reconnect and carry on. None of this can harm anything; it's a guard rail, not a trap.

If you genuinely need something the shell won't let you do — a system package installed, a service enabled, a setting changed at the server level — that's something your host does. Open a support request and ask them.

Uploading and downloading files (SFTP / FTPS)

For moving files you'll usually want a graphical program rather than the command line. Any of these work well; the settings are the same in all of them:

• FileZilla — Windows, macOS, Linux.
• WinSCP — Windows.
• Cyberduck — Windows, macOS.

Create a new connection with these details from your welcome email:

Connect, and you'll see your home directory. As with the shell, you're locked to your own account: you can move around your files freely, but you can't navigate up and out of your home. That boundary is deliberate — if a transfer program reports a permission error when it tries to go "up" a level, it's the fence doing its job, not a fault.

Your sites' files live under your account, so this is how you'd, for example, drop a new theme into a site or pull down a copy of your files to work on locally.

SFTP vs FTPS. SFTP (over SSH, port 22) is the simplest and what we recommend — it uses the same login as your shell. If your welcome email also lists FTPS, that's an encrypted FTP option some older tools prefer; either is fine. Plain, unencrypted FTP is never offered, and you shouldn't use it anywhere.

Connecting a database tool (Sequel Ace, Workbench)

You can already run mysql and mysqldump right in your shell. But if you'd rather browse your databases in a graphical tool — Sequel Ace or Sequel Pro on macOS, MySQL Workbench, TablePlus, and similar — you can, by pointing the tool through an SSH tunnel on your same oN.ftp login. The tool logs in over SSH the way your shell does, then reaches the database on the server's own loopback address.

In your database tool, look for a connection type called "SSH" (Sequel Ace calls it Connect via SSH), then fill in two groups of details:

The MySQL Host stays 127.0.0.1 on purpose — that's the database's address from the server's point of view, and the SSH tunnel is what carries you there. For the database username, password, and database name, use the credentials for the site you want to open; the quickest way to find a site's connection details is to look at its settings from your shell.

The server only allows this tunnelling to its own local database, not onward to anywhere else — so it's for reaching your own databases, nothing more. If your tool offers plain "Standard" (non-SSH) connection and it won't connect, that's expected: the database isn't exposed directly to the internet, and the SSH tunnel is the supported way in.

Set up a key so you never type a password

A one-time bit of setup that pays off forever: add an SSH key. With a key in place you connect without typing a password for your day-to-day logins — so the 90-day password refresh (see the next section) stops interrupting your sessions. It doesn't switch the refresh off, though: your account password still expires on schedule even with a key in place, so keep the reset emails. Even so, a key is the smoother, safer way to connect, and worth doing early.

1. Make a key on your own computer

If you don't already have one, create a key pair. In a terminal on your own machine:

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

Press Enter to accept the default location. You'll be offered the chance to protect the key with a passphrase — a good idea. This makes two files: a private key (~/.ssh/id_ed25519, keep this secret, never share it) and a public key (~/.ssh/id_ed25519.pub, this is the one you hand over).

2. Add your public key to your account

Because your account uses a limited shell, the usual one-shot ssh-copy-id helper can't install the key for you (the limited shell blocks the remote command it relies on). Use one of these two reliable routes instead:

• Upload it over SFTP. Connect with your file-transfer program (next section), and place the contents of your public key (~/.ssh/id_ed25519.pub) into the file ~/.ssh/authorized_keys in your account — create that file if it isn't there, one key per line. Your .ssh folder already exists and is private to you.
• Send it to your host. Paste the contents of the .pub file into a support request and ask them to add it. Some hosts prefer this and may have set it up for you already.

Once the public key is in ~/.ssh/authorized_keys, connecting is passwordless:

ssh oN.ftp@server.example.com

Never send or upload the private key (~/.ssh/id_ed25519) — only the .pub one.

3. Use the same key in your file-transfer program

Your SFTP program can use the same key, so file transfers also skip the password:

• FileZilla — Edit → Settings → SFTP → Add key file, and pick your id_ed25519.
• WinSCP — convert the key to .ppk with the bundled PuTTYgen, then set it under the session's SSH → Authentication.
• Cyberduck — in the bookmark, choose SSH Private Key and select your key.

The 90-day password reset

For security, your account password expires on a schedule — every 90 days, with a few days' warning first. This applies to SSH, SFTP and FTPS, and it applies even if you use an SSH key: the expiry is set on the account itself, so a key doesn't exempt you from it. This is normal and automatic; it isn't a sign anything is wrong. When it happens, a fresh password is generated for you and emailed to the address on file for your account.

What this means in practice:

• If you use a key (the setup above), your day-to-day logins keep working without interruption — a key login doesn't ask for the password, so you won't be stopped in your tracks the moment it expires. But the password still expires in the background, so keep the reset emails: you'll want a current password on hand if you ever need to reconfigure access or log in without the key. This is the main reason to add a key — it takes the sting out of the refresh, without switching it off.
• If you use a password, one day your saved password will stop being accepted. Check your email for the latest reset notice from the host and connect with the new password. Update it in your SFTP program's saved connection too.

You can also change your password yourself at any time from within your shell with the passwd command; the new one takes effect shortly after.

If a password reset email never arrives, or you're locked out with no key to fall back on, that's a moment to open a support request — re-sending your login details is routine for your host. The full walkthrough is in when you can't connect.

Where to go next

• When you can't connect — the two common reasons a login stops working, and how to fix each yourself.
• Managing your sites — the day-to-day work your shell backs up.
• Glossary for hosted customers — the words you'll keep seeing, explained.
• Reference — settings and values at a glance.