Fix a server that will not connect

SrvYard manages a server over SSH, with a key of its own. When it cannot log in, the server shows a red Disconnected badge, deployments and other actions stop for that server, and your sites keep running on the machine untouched. Nothing is lost: the fix is almost always one of five things outside SrvYard, and the page tells you which to check.

This article follows the order that finds the cause fastest. You will read the reason SrvYard recorded, go through the checklist on the server page, run the two repair commands in your provider's console, correct the address or port, and check the connection again.

Before you begin#

• Access to the machine another way. If SrvYard cannot log in, you need your provider's web console, a rescue shell, or a different SSH key of your own. The repair commands below run there, not in SrvYard.
• The right permission. Seeing the server needs servers:view; the Check connection button and the settings need servers:update. See Roles and permissions.
• Know the state you are in. A server that was working and is now Disconnected is the case in this article. A new server that never got past installing is covered in step 6.

1. Read what SrvYard recorded#

Open Servers and choose the server. The badge next to its name is the state, and a red Connection problem message under the tabs holds the last error SrvYard saw.

1. Disconnected. SrvYard could not log in at its last check. Its sites are probably still serving traffic; check one in a browser before you panic.
2. Connection problem. The error text is the clue. The exact wording varies with the cause. Typical ones:
   • Connection timed out after 15 seconds. Nothing answered on the address and port. The machine is off, the address is wrong, or a firewall drops the traffic.
   • Connection refused. The machine answered, but nothing listens on that SSH port.
   • A message about authentication or the key. The machine answered, but SSH refused SrvYard's key.
   • The server host key changed since SrvYard first connected. Refusing to connect. The machine was rebuilt or replaced. See step 5.
3. Actions. The menu holds the server-level actions; Reset trusted host key appears in it only for the host-key error above.

The Activity tab keeps the history. A line such as "Server harbor-legacy is unreachable" shows when SrvYard first noticed and who or what recorded it, which helps you match it against a provider incident or a change you made.

1. The unreachable entry. The date tells you where to look: a reboot, a resize, a firewall change or a deploy of someone's SSH hardening around that time.

2. Go through the checklist#

Further down the same page, the card Why a server disconnects lists the checks in the order they most often turn out to be the cause.

1. The checklist. In short:
   • The machine is on. A server that was powered off, resized or rebooted at the provider stays disconnected until it is back.
   • Its IP address did not change. Some providers hand out a new address after a power cycle or a resize.
   • SrvYard's key is still in authorized_keys of the SSH user.
   • The SSH port is open in the provider's firewall or security group.
   • The permissions of the .ssh folder are strict enough for SSH to accept the key.
   • Still stuck? Read why SSH refused the key with grep sshd /var/log/auth.log | tail -n 20 on the machine.
2. Authorise SrvYard's key again. A command that puts SrvYard's public key back into authorized_keys. Copy it, open your provider's console, paste it, and press Enter. It only appends a public key; it changes nothing else.
3. Repair the permissions. Fixes the owner and modes of the .ssh folder and file. SSH silently ignores a key file that other users can write to, which is a common reason for "permission denied" after someone ran a recursive chmod.
4. Check connection. Runs the connection test now and shows the result in a moment.

3. Check the firewall in both places#

A closed port is the most frequent cause of a timed out error, and there are two places to look.

1. The note. SSH on port 22 is always allowed in the server's own firewall and the rule cannot be removed, so SrvYard can never lock itself out with its own rules. Deny rules are applied first, though.
2. The SSH row. It is locked and active. So if SSH is blocked, the culprit is outside the machine: your cloud provider's firewall or security group, a network access list, or a tool on the machine such as fail2ban that banned SrvYard's address after failed logins.
3. Sync from server. Reads the rules from the machine, useful once you have changed them by hand.

If you run SSH on a port other than 22, make sure the port on the server page matches (next step) and that the provider's firewall allows it.

4. Correct the address or the port#

If the provider gave the machine a new public address, SrvYard still dials the old one. Scroll to the Settings card on the server page.

1. IP address. Enter the new address. The card notes that changing the address of a ready server re-verifies the connection.
2. SSH port. The port SSH listens on, 22 by default.
3. Save changes. Saves, then check the connection.

Use a documentation address like 203.0.113.10 only in examples: in real life enter the address from your provider's panel.

5. Reset the host key after a rebuild#

SrvYard remembers the machine's SSH host key the first time it connects and refuses to talk to a machine that presents a different one, because that could be someone impersonating your server. If you reinstalled the operating system, restored a snapshot to a new machine or moved the address to another machine, the key really did change.

1. Make sure you changed the machine on purpose and that the address belongs to your server.
2. Open Actions and choose Reset trusted host key. SrvYard forgets the stored key and says "The next connection will trust the host key it sees. Check the connection now."
3. Press Check connection. On a rebuilt machine you may also need to run the Authorise SrvYard's key again command first, because a fresh install has no authorized_keys entry for SrvYard.

6. When installation failed instead#

A server that never became ready shows Installation failed and the card Why installation can fail instead. Provisioning needs:

• A fresh Ubuntu 24.04 or 26.04 (x64) machine with at least 1 CPU, 1 GB of memory and 10 GB of disk, and curl installed.
• SrvYard able to log in as root over SSH with its key, and a provider that does not rewrite /root/.ssh/authorized_keys.
• No firewall, security group or tool such as fail2ban that throttles SSH from SrvYard.
• Nothing else changing packages at the same time, such as automatic updates still running.

Installing on an existing server can overwrite its configuration, so use a fresh machine when you can. After fixing the cause, start the installation again from the server page. See Connect an existing server for the whole procedure.

Troubleshooting#

• The server comes back and goes away again. An unstable network path, or fail2ban banning SrvYard after a burst of logins. Allow SrvYard's address in fail2ban and look at auth.log.
• Check connection says it worked, but the badge stays red. The page shows the state at load time. Reload it; the next scheduled check also refreshes it.
• "Permission denied" even though the key is in place. Run the Repair the permissions command, and check that the home folder itself is not writable by others.
• I changed the SSH port on the machine and now SrvYard cannot connect. Set the same port in Settings, and allow it in the provider's firewall. Keep a console session open while you change SSH settings.
• The sites on a disconnected server still work. Yes: SrvYard only manages the server, it does not serve your sites. Anything SrvYard has to do over SSH, such as deploying, waits until it reconnects.
• I removed SrvYard's key on purpose. Then SrvYard can no longer manage the machine. Add the key back with the command above, or forget the server. See Rename, resize, delete or forget a server.

Related#

• Connect an existing server: the first-time procedure and the access command.
• Open and close ports with the firewall: the rules SrvYard manages on the machine.
• Add SSH keys to a server and to your account: your own keys, separate from SrvYard's.
• Read the server overview: what the page shows when everything is healthy.