When you can't connect

Every so often your SSH, SFTP or FTPS connection stops working from one day to the next. Almost always it's one of two harmless things, and you can fix both from your own computer in a couple of minutes. This page walks you through each one.

If neither of these fits, skip to When it really isn't you.

The "host key has changed" warning

You try to connect and instead of a login you get a big warning like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

The wording is alarming, but the cause is almost always ordinary. Your SSH program remembered the server's identity ("host key") from the last time you connected, and the server is now presenting a different one. That happens whenever your host rebuilds or moves the server — a fresh machine has a fresh key, so your computer notices the change and stops to check with you first. That's your SSH program doing its job.

The quick fix

You just need to forget the old, remembered key so your computer can learn the new one. How you do that depends on what you connect with.

If you connect from a terminal (macOS, Linux, WSL):

Run this on your own computer, replacing the address with the one you actually connect to:

ssh-keygen -R your-server.example.com

That removes the stored key for that server from your local ~/.ssh/known_hosts file. Then connect again as normal:

ssh o1.ftp@your-server.example.com

You'll be asked to confirm the new key — type yes and you're back in.

If your host gave you a custom SSH port, or you also connect by IP address, forget those forms too:

ssh-keygen -R '[your-server.example.com]:2222'   # custom port
ssh-keygen -R 198.51.100.42                      # by IP address

If you use a graphical client, there's no command — you just tell the program to forget the saved key:

  • FileZilla — when it warns about the changed key, tick "Always trust this host" (or the equivalent) and accept. It replaces the old key.
  • WinSCP — accept the new key when prompted, or go to your saved site and clear the stored host key so it re-learns on the next connection.
  • Cyberduck — accept the new fingerprint when it asks; it updates the stored one.
  • PuTTY (Windows) — click Yes on the "host key changed" alert to update PuTTY's cache for that server.

After you accept once, the warning is gone for good — until the next time the server is genuinely rebuilt.

Before you accept: a 30-second safety check

Accepting a new key is safe when you know why it changed. So do this one quick check first:

  1. Confirm with your host that the server really was rebuilt or moved recently. If yes, you're done — go ahead and accept.
  2. If you want to be thorough, the warning shows you a fingerprint (a short string like SHA256:abc123…). Ask your host what the new server's fingerprint should be and check that the two match.

If your host says the server was not rebuilt and the fingerprint does not match what they expect, don't accept it — close the connection and mention it to your host. That's the rare case the warning is really there for. In everyday use, right after a rebuild, it's completely normal and the quick fix above is all you need.

Your password stopped working

Your SFTP, FTPS or SSH password worked yesterday and today it's rejected — and you know you didn't change it. This is almost always the automatic 90-day password refresh.

For security, passwords on your account are refreshed every 90 days. This applies to SSH, SFTP and FTPS alike. It's automatic — you don't have to do anything to trigger it, but you do get a new password when it happens.

Getting your new password

  1. Check your email. When your password is refreshed, a notification with the new one is sent to the email address on file for your account. Look for a recent message from your host (check spam/junk too).
  2. Update your saved password in your SSH/SFTP/FTPS client with the new one and reconnect.

If you can't find the email, or the address on file is out of date, that's a quick one for your host to sort out — contact your host and ask them to resend or reset your password. Setting the password itself happens on the server, so it's something they do for you; you don't run anything to reset it yourself.

Tip: use an SSH key so this bothers you less

If you connect over SSH or SFTP a lot, an SSH key is much smoother than typing a password — you set it up once and you're not entering a password every time. Because a key login doesn't ask for the password, the 90-day refresh stops interrupting your day-to-day sessions. It doesn't switch the refresh off, though — your account password still expires every 90 days even with a key in place (see the caveat below).

Setting a key up is a one-time job, and it's covered step by step in Shell and SFTP access: you create the key on your own computer with ssh-keygen, then get its public half onto your account. One thing worth knowing up front — because your login is a limited shell, the usual one-shot ssh-copy-id command can't install the key for you the way it would on an ordinary server. Instead you either add the key from inside your shell by hand, or simply send the public key to your host and ask them to install it — a routine request. The sibling page walks through both routes.

One honest caveat: a key makes day-to-day logins painless, but the 90-day refresh still runs on the account password in the background. So keep an eye on those password-refresh emails anyway — you'll want a current password on hand if you ever need to reconfigure access.

Where does the username come from? Throughout this page o1.ftp is just an example — your own login is your account name followed by .ftp (for example o5.ftp). Your host tells you the exact username, server address and port when your account is set up. See Shell and SFTP access for the full connection details.

When it really isn't you

If you've tried the fixes above and still can't get in — the warning keeps coming back after you accept the new key, or your brand-new password is rejected too, or the server simply doesn't respond — then it's most likely something on the server side that you can't see or change from your account.

That's not a failure on your part, and there's nothing for you to fix on the machine itself: contact your host or operator and describe exactly what you see (the error message, which client you use, and roughly when it started). They can check the server and the firewall from their side and get you back in.

Related