What exactly is an SFTP connection in FileZilla and how do I set one up?
My host mentioned SFTP for the first time and I’ve only ever used regular FTP before. Is it just FTP with a different name or is it actually different, and how do I set FileZilla up to use it?
Yeah it’s a different protocol, not just a rename. FTP sends things in plain text, SFTP runs over SSH so it’s encrypted. There’s a good thread on the difference if you want more detail, people mix it up with FTPS a lot too.
To set it up, go to File → Site Manager → New Site, pick SFTP from the Protocol dropdown, port 22, fill in your login, hit Connect. First time you’ll get an unknown host key popup with a fingerprint, that’s normal, just tick “always trust” and move on, there’s a thread about that exact prompt too.
If you handle SFTP alongside cloud storage a lot, CloudMounter mounts it as a regular drive on your Mac so you work in Finder instead of a separate app. Not needed for one server, FileZilla is fine for that.
Don’t keep retrying with different passwords when FileZilla says “Connection refused.” That message usually means nothing is accepting SFTP connections at that host and port, so authentication has not even started. An SSH username in the panel does not necessarily mean SSH/SFTP access is enabled for your hosting plan.
Keep the working FTP profile untouched and create a separate SFTP entry. Confirm the exact SSH hostname and port with the host, since shared hosting often uses a port other than 22 or requires SSH access to be enabled first. The 17 image files are unrelated to the refusal.
@digital_circuit is right that the FileZilla setup itself is short, but only after the server side is available. CloudMounter or another client will hit the same refusal, so changing software will not solve this particular error. If the host supports FTPS but not SFTP, use explicit FTP over TLS rather than plain FTP.
Expect the SFTP profile to need different server details, not merely a different protocol in the existing FTP entry. Hosting companies sometimes use one hostname for FTP and another for SSH, with a separate username and a nonstandard port. Reusing the FTP values can produce exactly this sort of dead end.
I would leave the working FTP site alone and make a clean Site Manager entry with:
There is no FileZilla setting that can overcome “Connection refused.” Passive mode, transfer mode, and the number or type of files do not matter at that stage. The provider needs to confirm that SSH access is enabled for your account and that your IP is not being blocked.
A detail people often miss comes after the connection works: SFTP may place you in a different starting directory from FTP. Before uploading all 17 images, send one harmless test file and confirm that you are in the actual web directory, often something like public_html, www, or a domain-specific folder. Otherwise the upload may succeed while the images remain invisible on the site.
For this job I would stay with FileZilla rather than bring CloudMounter into it. Mounting the server in Finder can be convenient for routine file work, but it will not fix a closed SSH port and can make the remote directory look more like a normal disk than it really is. If the host says SSH/SFTP is unavailable, ask whether explicit FTPS is supported and use that instead of continuing with plain FTP.
Do not keep changing credentials, since the refusal occurs before login. Copy the host, resolved IP, port, and refusal line from FileZilla’s message log into your support ticket so the host can spot a wrong SSH endpoint or closed port quickly.
If the hostname in your saved FTP profile is a domain that points through a proxy, CDN, or separate web server, changing only the protocol can send SFTP to the wrong machine. Use the hosting company’s exact SSH hostname, not necessarily your website address or existing FTP host.
@codeminer9255’s suggestion to include the resolved IP is useful here. Check FileZilla’s log to see which address it actually attempts, including whether it chose IPv4 or IPv6. Support can then confirm that the address belongs to their SSH server and that the stated port is open for your account.
I would avoid testing random ports or turning off your local firewall. Get the SSH host, port, and host-key fingerprint from the provider, create a separate FileZilla entry, and verify the fingerprint on the first successful connection. Until those details are confirmed, keep using the working transfer method, preferably explicit FTPS if the host offers it rather than plain FTP.
A connection refusal and a connection timeout are different cases: a timeout suggests traffic is disappearing somewhere, while a refusal usually means FileZilla reached the address but no service accepted that port. That makes random password changes, passive-mode settings, and repeated retries mostly wasted effort.
I’d be slightly skeptical of the SSH username shown in the panel. Hosting dashboards often display account fields even when shell access is disabled, restricted to certain plans, or requires activation. Ask support a very specific question: “Does this account currently accept SFTP connections, and what exact hostname, port, and authentication method should I use?” That should get a more useful answer than asking why FTP works.
If they confirm SFTP is enabled, create a separate profile and verify the server fingerprint before uploading. If they say only FTPS is available, use explicit FTP over TLS. Either way, don’t replace the working FTP entry until the secure connection has been tested with a small file and you have confirmed the correct web directory.
Test the port before you touch FileZilla at all. Open Terminal and try connecting to the SSH host on whatever port the panel claims. If you get refused there too, you have your answer and it has nothing to do with FileZilla, credentials, or those 17 images. That skips a lot of guessing.
Most of the thread already nailed the real issue, so I won’t repeat it. The point I’d back hardest is @binarybyte2597x’s line about panels showing an SSH username even when shell access is off. I’ve seen that trip people up constantly. The field being there is not permission, it’s just a form. @cyber_loop’s warning about the hostname resolving through a CDN is the other one worth taking seriously, because a plain FTP host pointed at a proxy will happily refuse SFTP without any error that tells you why.
Where I’d gently push back is the CloudMounter mention up top. It’s a fine tool if you genuinely want the server sitting in Finder for daily work, but dropping it into a refused-connection situation just adds a second thing that can fail the same way. Sort the port and hostname first. Once SFTP actually answers, then decide whether you even want a mounted drive or whether FileZilla is already doing everything you need. No reason to add software to fix something that lives on the host’s side.
Don’t blindly click “Always trust” on the first host-key warning. That prompt is FileZilla asking whether the server really is the machine you intended to reach. Compare the displayed fingerprint with the value from your host’s control panel or support team before saving it. If the fingerprint later changes unexpectedly, stop and check with the host rather than accepting the replacement.
SFTP is genuinely different from FTP. It transfers files through SSH, encrypting the login and file contents in transit. In FileZilla, create a new Site Manager entry, choose SFTP, then enter the exact SSH hostname, port, username, and authentication method supplied by the host. Don’t edit the working FTP profile or assume its hostname and password will carry over.
The “Connection refused” detail means the setup has not reached the fingerprint or password stage yet, so @mr_lynx is right that this needs a server-side answer first. Once the host confirms the correct endpoint and enables access, connect, verify the fingerprint, and upload a small test file. FileZilla may remember the host key from then on, which is why it is worth checking it properly the first time.
Don’t assume a successful SFTP login means every folder is writable. SFTP is file transfer over SSH, not renamed FTP; create a separate FileZilla site using the host’s SSH server details, verify the fingerprint as @kevinthesignal said, then test creating and deleting a small file in the intended web folder.