Fix "ssh_init: host does not exist" in FileZilla and SSH

What does "ssh_init: host does not exist" actually mean?

ssh_init: host does not exist points to the destination-name stage of the connection, before FileZilla can authenticate to the SSH server. Exact wording can differ between FileZilla versions and the SSH components they use, so the surrounding message-log lines still matter. The first technical question remains the same: can the configured host be resolved to an address that the client can try to reach?

An SFTP session passes through several independent stages. The client first needs a hostname or IP. A hostname must be resolved. Then the client opens a TCP connection to the configured SSH port. Only after that can SSH exchange protocol information and host keys, followed by password or public-key authentication and finally the SFTP subsystem.

Suppose FileZilla reports that the host does not exist and, in the same Windows session, Resolve-DnsName returns NXDOMAIN. At that point the private key is irrelevant. The computer still has no destination address to which the key could be presented.

The replacement error after a fix is often more useful than the original one. If FileZilla now reaches a host-key prompt, hostname resolution and the TCP connection have already moved forward. If it reports Permission denied, the server was reached and authentication is now the layer to troubleshoot.

What should you check in the first five minutes?

Start with the FileZilla destination and stop at the first failed test. The short route is Host and Protocol, DNS resolution, the provider-supplied IP, the SSH port, and then OpenSSH. Each step should answer a specific question rather than simply produce another error message.

Use the first failed test as your branch point

Three short examples show why the order matters.

nslookup server.example.com

*** server.example.com: Non-existent domain

Resolve-DnsName server.example.com

Name       : server.example.com
IPAddress  : 203.0.113.20

Connection established.
...
Permission denied

The exact command output varies by operating system, but the boundary between stages does not. If DNS returns no address, stay with DNS. If DNS returns the expected address and TCP fails, move to the network or SSH service. If SSH reaches authentication, stop debugging the hostname.

This is also why changing five settings at once makes troubleshooting slower. A result such as "DNS returns 203.0.113.20, but TCP/2222 times out" is actionable. "I changed the password, DNS server, port, key, and FileZilla profile and it still fails" is not.

Is FileZilla using the correct hostname, protocol, and port?

Before changing system DNS, confirm what FileZilla is actually trying to reach. A one-character typo, a copied remote directory, or an old Site Manager entry can make a valid account look broken before the SSH server is contacted.

Check the Host field before anything else

The Host field must identify the SSH/SFTP server. Depending on the hosting setup, that may be a name such as server.example.com, a dedicated SSH hostname, or an IP address supplied by the provider.

Do not assume that the public website hostname must also be the SFTP hostname. A site can open at www.example.com while SSH is served from ssh.example.com, a VPS node name, or another endpoint entirely.

Check the literal value character by character when the error appears immediately. Look for an accidentally pasted remote path such as /home/example/public_html, a misspelled subdomain, a hostname copied from another server, or whitespace introduced during copy and paste. Rebuilding a heavily edited Site Manager entry from the documented connection details is often quicker than trying to remember which field was changed months ago.

Protocol: SFTP - SSH File Transfer Protocol
Host: server.example.com
Port: 2222
User: exampleuser

A URL such as sftp://server.example.com may be accepted in some FileZilla input contexts. For troubleshooting, Site Manager is clearer: select SFTP explicitly and keep the destination hostname or IP separate from the protocol selection.

Verify that FileZilla is using SFTP, not FTP or FTPS

SFTP runs over SSH. FTP and FTPS are separate protocols and may use different endpoints, ports, usernames, and authentication methods. When the hosting panel provides SSH/SFTP access, select SFTP - SSH File Transfer Protocol.

Saved Site Manager entries are easy to mix up when the same account has separate FTP and SFTP endpoints. A profile may look almost correct because the username is familiar while the protocol and host still belong to another service.

Confirm the SSH port instead of assuming port 22

Port 22 is the standard SSH port, but the configured service port is authoritative. Some servers expose SSH on another port, and hosting panels often show that value next to the server hostname.

A wrong port generally causes a later failure such as timeout or refusal rather than a true hostname-resolution error. Verify it anyway. Otherwise you can fix the hostname correctly and immediately run into a second problem caused by an outdated port.

Read the FileZilla message log before changing anything else

The FileZilla message log tells you whether the client is still trying to resolve a name or has already started contacting an address. Wording varies between versions, so treat the following as representative sequences rather than strings that every FileZilla build must print exactly.

A hostname-resolution failure can look conceptually like this:

Status: Resolving address of server.example.com
Error: ssh_init: host does not exist

No connection attempt to an IP appears. Stay on the Host and DNS branch.

A later network failure looks different:

Status: Connecting to 203.0.113.20...
Error: Connection timed out

The presence of a destination IP changes the diagnosis. FileZilla got past name resolution and is now failing while trying to reach the service.

If the log reaches the SSH server and then reports an authentication problem, DNS is already behind you:

Status: Connected to server.example.com
Error: Authentication failed

Do not obsess over the exact English phrase in these examples. Look for the transition from hostname resolution to a concrete IP or connection attempt. That boundary tells you which section of this guide matters next.

After correcting the FileZilla profile, reconnect with the message log visible. If ssh_init: host does not exist disappears, read the new failure on its own terms rather than continuing to change DNS automatically.

Does the SSH hostname resolve outside FileZilla?

Test the exact hostname outside FileZilla. If the operating system cannot obtain an address for that name, FileZilla has no normal direct destination to contact and authentication troubleshooting should wait.

Test DNS on Windows

In PowerShell or Command Prompt, replace the example name with the literal value configured in FileZilla:

nslookup server.example.com

PowerShell also provides:

Resolve-DnsName server.example.com

A successful query should return at least one address record or a DNS chain that ultimately reaches one. For example:

Name:    server.example.com
Address: 203.0.113.20

The address above is documentation data, not a real SSH server. On a live system, compare the returned address with the endpoint documented by the hosting provider or server administrator.

If the resolver returns NXDOMAIN or another non-existent-domain response, recheck the hostname before doing anything else. If the response is a timeout, the resolver did not answer. Those failures may look similar in FileZilla, but they do not mean the same thing.

ping can provide one extra clue. If ping server.example.com prints an IP address and then reports timeouts, the hostname was already translated to an address for that test. ICMP echo may simply be blocked. That does not prove SSH is reachable, but it means the next useful test is the SSH port rather than another password reset.

Test DNS on Linux or macOS

Direct DNS queries can be made with:

dig server.example.com
nslookup server.example.com

On Linux, getent adds another useful perspective because it goes through the system's configured name-service stack:

getent hosts server.example.com

That distinction matters when /etc/hosts, NSS configuration, local resolver services, or corporate name sources are involved. If dig returns a public DNS answer but getent hosts returns a different address, the application may not be seeing the same result as your standalone DNS query.

A typical troubleshooting scene is simple: dig shows the new VPS address, but getent hosts still reports an old address. That is a reason to investigate the system resolver path or local overrides, not a reason to change the SSH key.

Distinguish NXDOMAIN, timeout, and SERVFAIL

The DNS response decides the next test. Calling every resolver problem "propagation" throws away useful information.

SERVFAIL does not identify one specific cause. DNSSEC trouble, an authoritative-server problem, or another failure in the resolution path can produce it. A failure from one resolver also does not prove that every resolver sees the same problem.

Check whether the SSH hostname is a CNAME

An SSH hostname does not have to point directly to an A or AAAA record. It may be an alias that eventually resolves through a CNAME. When you control the DNS zone, inspect the chain rather than looking only for an A record under the original name.

dig server.example.com
dig CNAME server.example.com

Suppose server.example.com is a CNAME for node17.example.net. The original name can be syntactically correct while the target name is missing or points at an old server. The practical question is still where the chain ends and which IP FileZilla ultimately receives.

Does connecting to the server IP work, and what does that prove?

Testing the documented server IP bypasses hostname lookup and gives you a controlled comparison. If FileZilla works when only the Host value changes from the failing hostname to the correct server IP, the fault is probably in the name-resolution path rather than in the password or private key.

Use an address obtained from a trusted source such as the hosting panel, Linux VPS configuration, or server administrator. Do not pick an IP from an unrelated record and assume that it is the SSH endpoint.

You can make the same comparison with OpenSSH:

ssh user@203.0.113.20 -p 2222

If the documented IP connects while server.example.com returns NXDOMAIN, stop rotating SSH keys. The same username, port, and authentication settings already work when DNS is removed from the path.

If neither the hostname nor IP works, do not force a single explanation. The hostname may still be wrong, while the IP test may reveal another issue such as an unreachable port or an outdated address. Two failed tests can indicate two different failed stages.

Do not turn the diagnostic IP into a permanent workaround automatically. Providers can move services between addresses, a hostname may be the supported endpoint, and clustered systems may not be intended for direct access by every backend IP.

Use the IP as a diagnostic bypass, not as duct tape.

Are DNS cache, the hosts file, VPN, or a proxy changing the destination?

If the SSH hostname works from another computer or network but fails on one machine, inspect the local resolver path. At that point the server account becomes a weaker suspect because the same server can already be reached elsewhere.

Check the local hosts file

A hosts-file entry can override normal name resolution. This often survives server migrations, temporary testing, or manual troubleshooting long after everyone has forgotten why the override was created.

On Windows, inspect:

C:\Windows\System32\drivers\etc\hosts

On Linux and macOS:

/etc/hosts

Search for the exact SSH hostname. If it is pinned to an old address, applications using the system resolver may continue to contact that address even though public DNS now points elsewhere.

Do not add another hosts entry simply to hide a public DNS fault. That replaces one problem with a local override that may fail again during the next migration. Remove or correct an entry only when you know what the intended destination should be.

Clear DNS cache only when the evidence fits

Resolver-cache flushing is useful after a recent DNS change, not as a universal SSH fix. It cannot manufacture a missing DNS record.

On Windows:

ipconfig /flushdns

On Linux systems using systemd-resolved:

resolvectl flush-caches

Repeat the same lookup after clearing the relevant cache. If NXDOMAIN remains, another flush will not help. Verify whether the hostname actually exists in the authoritative DNS data or whether you were given the wrong host.

Compare VPN, corporate DNS, and another network

Some SSH hostnames exist only inside a private network. Others return different addresses through corporate DNS, a VPN, or split-DNS configuration. FileZilla may therefore work in the office and fail at home, or the hostname may appear only after a VPN is connected.

Record the current resolver result first. Where policy permits, compare the same lookup with and without the VPN or from another network:

nslookup server.example.com

If the VPN returns a private address such as 10.x.x.x while the public connection returns NXDOMAIN, the server may intentionally depend on internal DNS. The fix is not to invent a public hostname. Use the network and resolver path required for that service.

Check whether a short hostname depends on a DNS search suffix

A terminal command such as ssh server1 can work on a corporate machine even when there is no public DNS record named server1. The operating system may append a configured DNS search suffix and actually resolve something like server1.corp.example.

This differs from an OpenSSH Host alias: the expansion happens in the resolver environment rather than in ssh_config. It also explains why a short name can work on one workstation but fail in FileZilla on another computer or outside the VPN.

When a short hostname works only in one network context, obtain the intended fully qualified hostname from the administrator instead of assuming that the short label is globally resolvable.

Check FileZilla proxy settings when only FileZilla fails

If ssh user@server.example.com works from the same computer with the same literal hostname and port while FileZilla still reports a hostname-related failure, stop changing system DNS. The next suspects are the saved FileZilla profile and client-specific network or proxy settings.

Keep the comparison strict: same machine, same network, same hostname, same port. Otherwise a successful terminal test may be using a VPN, SSH alias, ProxyJump, or another route that FileZilla does not share.

Do not blindly disable security software, remove corporate proxies, or replace the machine's DNS configuration. First prove that FileZilla is the only path that fails.

Does OpenSSH resolve the same destination that FileZilla is trying to use?

CLI works. Before blaming FileZilla, confirm what CLI is actually connecting to. A command such as ssh myserver can succeed even when myserver has no DNS record because OpenSSH may rewrite the destination through ssh_config.

Check whether the working SSH name is only an ssh_config alias

Consider this configuration:

Host myserver
    HostName ssh.example.com
    User deploy
    Port 2222

The user types:

ssh myserver

but OpenSSH actually contacts ssh.example.com. The string myserver does not need to exist in DNS.

Print the effective OpenSSH configuration:

ssh -G myserver

Look for values such as:

hostname ssh.example.com
user deploy
port 2222

A common troubleshooting trap now becomes obvious. ssh production works, so production is copied into FileZilla. FileZilla fails immediately. ssh -G production then reveals hostname ssh.example.com. The terminal was never connecting to a DNS host literally named production.

On Linux and macOS, user SSH configuration is commonly stored in:

~/.ssh/config

On Windows OpenSSH, user configuration is commonly found under:

%USERPROFILE%\.ssh\config

Use verbose SSH output to locate the failure stage

Run OpenSSH against the literal hostname and the actual port:

ssh -vvv user@server.example.com -p 2222

You do not need to interpret every debug line. Find the last stage that clearly succeeded.

A name-resolution failure may end with a message similar to:

ssh: Could not resolve hostname server.example.com: Name or service not known

The wording differs by platform, but there is no destination IP and no TCP connection. Stay with the hostname and resolver.

When resolution succeeds, verbose output typically shows a connection attempt containing a concrete address:

debug1: Connecting to server.example.com [203.0.113.20] port 2222.

At this point the hostname has already done its job. If the session stalls or times out after this line, investigate TCP reachability rather than DNS.

Once OpenSSH reports a connection:

debug1: Connection established.

both hostname resolution and the TCP connection have succeeded. Later output may move into host-key exchange and authentication. If you eventually see a permission or public-key failure, debug the account and authentication method instead of returning to the DNS settings.

New error, new layer.

Check ProxyJump, ProxyCommand, or special SSH routing

OpenSSH may also reach the server through a path that FileZilla is not using. A working CLI profile can include ProxyJump, ProxyCommand, a rewritten HostName, or other SSH configuration.

If ssh myserver works but direct resolution of myserver fails, inspect the effective SSH configuration before treating that result as proof against FileZilla. The two clients are comparable only when they use the same actual destination and route.

ssh -G is useful here because it shows the effective OpenSSH settings without requiring a full bastion-host investigation. Compare the resulting hostname, port, and relevant routing directives with what FileZilla is configured to use.

What if DNS works but the SSH port cannot be reached?

The name resolves. That does not mean the SSH port is open. Once DNS returns the expected address, test the actual service port and treat timeout or refusal as a separate network or server-side problem.

On Windows PowerShell:

Test-NetConnection server.example.com -Port 22

For a custom SSH port:

Test-NetConnection server.example.com -Port 2222

The key field in the result is:

TcpTestSucceeded : True

If it is True, a TCP connection to that destination and port succeeded. SSH can now proceed to handshake and authentication. If it is False, the test has not proved why the port is unreachable, only that the expected TCP connection did not succeed.

On Linux or macOS, when nc is available:

nc -vz server.example.com 22

or for a custom port:

nc -vz server.example.com 2222

A timeout can be caused by filtering, routing, an unreachable server, the wrong address, or another network-path problem. A refusal generally means a destination responded but no service accepted the connection on that port, or the connection was actively rejected. Neither message proves a specific firewall rule by itself.

If you control the VPS, check whether SSH is actually listening

Client-side tests tell you that a port cannot be reached. Root access to the VPS lets you check the other end of the connection.

On a Linux server, inspect listening TCP sockets:

ss -lntp | grep ':22'

For a custom port such as 2222:

ss -lntp | grep ':2222'

If SSH is listening, the output should show a LISTEN socket associated with the configured address and port. Depending on permissions, process details may require root access. Also pay attention to the bind address: a daemon listening only on 127.0.0.1 is not equivalent to one listening on an external interface.

No matching socket is a strong reason to inspect the SSH service rather than FileZilla.

Check the SSH service and effective port

The systemd service name differs between distributions. Common commands are:

systemctl status ssh

or:

systemctl status sshd

A running service does not automatically prove that it listens on the port FileZilla uses. With administrative access, the effective OpenSSH server configuration can also be inspected:

sshd -T | grep '^port '

If sshd -T reports port 2222 while FileZilla is testing 22, you have found a concrete mismatch. If the daemon listens correctly but remote clients still time out, move outward to host firewall rules, provider firewall or security-group rules, NAT, and routing as appropriate for the server environment.

DNS is done once the expected address resolves. If the TCP port is the first failed step, troubleshoot the path and listening service. If TCP works and ssh -vvv reaches authentication, move on again.

Could IPv4, IPv6, or stale DNS records explain inconsistent SSH results?

A hostname can resolve successfully and still send different clients toward different destinations. Inspect the actual A and AAAA records when SSH works from one network or address family but fails from another.

Compare A and AAAA records

On systems with dig:

dig A server.example.com
dig AAAA server.example.com

On Windows:

Resolve-DnsName server.example.com

Compare every returned address with the current server configuration. An A record can point to the new VPS while an old AAAA record still references another system. The presence of IPv6 itself is not a fault. The question is whether the returned IPv6 address belongs to the intended SSH service and is reachable.

Compare SSH over IPv4 and IPv6

OpenSSH can force the address family for a diagnostic comparison:

ssh -4 user@server.example.com
ssh -6 user@server.example.com

If IPv4 works and IPv6 fails, investigate the IPv6 DNS record, route, firewall, and SSH listener for that address family. Do not disable IPv6 across the machine merely to hide one stale AAAA record.

If IPv6 works and IPv4 fails, investigate the IPv4 path instead. The comparison is valuable because both tests use the same logical hostname and account while changing the network family.

Check multiple A or AAAA records separately

Some hostnames legitimately return more than one address. That becomes a troubleshooting issue when one backend or route works and another does not. A single successful lookup can therefore hide an inconsistent destination set.

On a system with dig, a compact view is:

dig +short A server.example.com
dig +short AAAA server.example.com

If several addresses are returned, compare them with the intended infrastructure. With authorization and a clear understanding of the service topology, test the relevant addresses individually. Do not delete extra DNS records merely because there is more than one result; load-balanced and redundant services may depend on them.

The useful symptom here is inconsistency: one connection attempt works, the next one does not, while the hostname and credentials remain unchanged. Multiple address records are one possible explanation worth checking.

Look for an old IP after a migration

A server migration can leave a mixed state: the hosting panel shows the new endpoint while one DNS record, local override, or resolver cache still returns the old address. Do not label that automatically as "DNS propagation" and wait without checking.

Compare three pieces of evidence:

• the address returned by the affected machine now;
• the current SSH endpoint shown by the hosting provider or server administrator;
• the active DNS record and its TTL if you control the zone.

The lifetime of a cached answer depends on the TTL, resolver behavior, and when the record changed. A fixed "wait 24 or 48 hours" rule ignores the data already available to you.

Seeing an IP in DNS is only half the check. Make sure it is an IP you actually expect.

How can you tell whether the problem is FileZilla, DNS, the network, or the SSH server?

Compare DNS resolution, the documented IP, the SSH port, OpenSSH, and FileZilla from the same machine. The matrix narrows the search area; it does not prove every cause by itself.

Keep comparisons controlled. "OpenSSH works" is meaningful against FileZilla only if OpenSSH uses the same literal destination, port, network, and route. A command that succeeds through ProxyJump or an SSH alias does not prove that FileZilla can connect directly to the text you typed into its Host field.

A useful diagnosis sounds specific: "The hostname resolves to the expected IPv4 address, TCP/2222 is reachable, and OpenSSH reaches authentication from the same PC, but FileZilla with the same literal hostname and port fails before login." The search area is now small.

10-minute checklist for ssh_init: host does not exist

Stop at the first failed stage. Fix it, repeat the test, and then continue. Otherwise one hostname problem can quickly become a pile of unrelated configuration changes.

What should you send to hosting support if the hostname still does not work?

If the hostname still fails after these checks, send support the resolution and connectivity evidence rather than passwords or private keys. A useful ticket should show where the connection stops, not merely state that FileZilla cannot connect.

Include the exact hostname and SSH/SFTP port, the relevant FileZilla log lines, the DNS result, returned addresses, the TCP-port result, and the OpenSSH test. Also mention whether the provider-supplied IP works and whether the behavior changes with a VPN or another network.

Host:
Port:
Protocol: SFTP

FileZilla error:
Relevant FileZilla log lines:
Time of test:

DNS result:
Resolved IPv4:
Resolved IPv6:

Connection using documented server IP:
TCP port test:
OpenSSH test:

VPN / other network result:
Recent server or DNS migration, if known:

Do not include the account password, private-key contents, secret tokens, or an unreviewed verbose SSH log. If you attach ssh -vvv output, remove information that should not be shared outside the intended support channel.

Turn "FileZilla does not work" into a reproducible report

A weak ticket gives support almost no boundary to work with:

FileZilla does not connect.
Please check the server.

A useful report can be only a few lines longer:

Host: server.example.com
Port: 2222

server.example.com returns NXDOMAIN from two tested networks.
The documented IP 203.0.113.20 accepts TCP/2222.
OpenSSH to that IP reaches authentication.
FileZilla fails when the hostname is used.

That report already separates the SSH endpoint from the broken hostname path. Support does not need to start by resetting credentials or asking whether port 22 is open; the user has supplied evidence that port 2222 on the documented IP is reachable.

A different report might say that DNS returns the expected address but Test-NetConnection reports TcpTestSucceeded : False. That sends the investigation toward network reachability, firewall policy, or the SSH listener instead.

Once you can state the failing stage this precisely, ssh_init: host does not exist is no longer a vague FileZilla problem. Either the client cannot obtain the correct destination, or that problem has been fixed and the connection is now failing somewhere later in the SSH path.