DevOps AgentDocs
Start free

Servers

When a server will not connect

Every connection error explained, with the fix for each one.

The connection test says what went wrong in plain words. Here is each message, what it really means, and what to do.

"We couldn't reach the server."

Nothing answered at that address at all. Three usual causes:

  1. A typo in the IP address. Check it character by character against your hosting dashboard. 167.99.12.34 and 167.99.12.3 are both valid-looking addresses.
  2. The server is switched off. Open your hosting dashboard and confirm it says running / active. Servers get suspended for unpaid invoices too.
  3. A firewall is blocking us. If your server or your host's firewall only allows SSH from certain addresses, our connection is refused silently. You need to allow SSH (port 22) from the internet, or ask whoever manages the firewall to allow it.

For AWS EC2, this is nearly always the security group: it needs an inbound rule for TCP port 22.

"The server answered, but nothing is listening on that port."

The machine is alive but there is no SSH service on that port.

  • Check the port. If you changed it from 22, confirm the number. If you did not change it, set it back to 22.
  • SSH may be switched off. Use your host's web console (most dashboards have "Console" or "VNC") to log in directly and start it: systemctl start ssh or systemctl start sshd.

"That address doesn't exist."

The name could not be looked up at all.

  • A typo in the domain name.
  • The domain does not point anywhere yet, or points somewhere else. DNS changes can take a few hours to spread.

Use the IP address instead. It always works and removes the question.

"The server refused this username and password."

The address is right and SSH answered — it just did not accept the login.

  1. Check the username. It is root on most new servers, but ubuntu on AWS Ubuntu, ec2-user on Amazon Linux, sometimes admin or debian.
  2. Check the password. Most hosts let you reset the root password from their dashboard. Do that and try the new one.
  3. The server may not accept passwords at all. Many providers — and every security-hardened server — turn password login off and accept only keys. Your host's dashboard will say so. You need the key file: see SSH keys.

"The server refused this key."

The key was readable but the server did not accept it.

  1. The server has to already know this key. Its public half must be in the ~/.ssh/authorized_keys file of the user you are connecting as. Use the one your host or your developer set up for this server.
  2. Check the username. Keys are per user. A key installed for ubuntu will never work for root.
  3. If the key has a passphrase, fill it into the Key passphrase field.

"This key is protected by a passphrase."

Either fill in the Key passphrase field, or — if you already did — the passphrase does not match this key. Try again, or use the key that goes with the passphrase you have.

"This isn't a private key we can read."

The text is not a private key we can parse.

  • Paste the whole file, including the -----BEGIN …----- and -----END …----- lines.
  • The .pub file is the wrong one. You need the file without .pub.
  • If the file came through a chat app or an email, it may have been reformatted. Ask for it again as an attachment, and use Upload a key file.

Detail: SSH keys explained.

The card says "Can't connect" after it used to work

The server was saved with details that worked once, and the background health check can no longer get in. Common reasons:

  • The server is down or rebooting. Check your hosting dashboard.
  • The password was changed on the server, or the key was removed from authorized_keys. Update the stored login with ⋮ → Edit.
  • A firewall rule changed, or the server's IP changed. A rebuilt or resized server often gets a new IP.
  • The server ran out of disk, which can stop new logins being accepted. Use your host's console to look.

The exact error from the last attempt is written on the card, which usually names the cause.

A session ends by itself

SSH sessions are closed after 30 idle minutes. Nothing is wrong — click back into the server and it reconnects. Sessions are also dropped when our app restarts, for example after a deployment.

Still stuck

Email support@devops-agent.io with:

  • the exact message you saw,
  • your hosting company,
  • whether you can log in yourself with a terminal or their web console.

That last one is the most useful thing you can tell us: if you cannot get in either, the problem is on the server, not here.