Connecting your own server (SSH/SFTP)

Add a machine on the Credentials page, under Servers, and it can be three things:

• •a drive — its folders open alongside your buckets, and you browse, upload, download, rename and delete exactly as you would in a bucket. Business plan.
• •a migration source — copy what is on it into a bucket, on a schedule, incrementally.
• •a migration or restore destination — pull a bucket down onto it. Business plan.

Adding and testing a server isn't plan-gated; using one as a drive or as a job endpoint is.

Linux and Windows are both supported, and BucketPilot works out which it's talking to rather than asking you — see How the platform is detected.

One address to allow through your firewall. Every connection BucketPilot makes — tests, jobs, browsing — comes from 3.111.107.194, so you can allow that single address on your SSH port instead of opening it to the internet.

The host key is pinned on first connect. If it ever changes, jobs stop and show you both fingerprints instead of connecting anyway — that's what an impersonated server looks like. Re-trust it from the Credentials page if the change was expected, such as a rebuild.

This is the step that catches almost everyone, because nothing about the symptom points at it: OpenSSH Server is an optional feature on Windows. A perfectly healthy machine that has never had it installed looks exactly like one that's switched off — the connection simply gets no answer.

In PowerShell as Administrator, on the Windows machine:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service sshd -StartupType Automatic
New-NetFirewallRule -Name sshd -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Then check it's listening — Get-Service sshd should say Running.

If a connection test times out, this is the first thing to rule out. If it says the port refused the connection, the machine is reachable and it's the service that's missing or stopped — same fix.

⚠️ An administrator's key does not go in that account's .ssh folder. OpenSSH on Windows reads one shared file for every account in the Administrators group, and silently ignores C:\Users\<name>\.ssh\authorized_keys for them. A key in the wrong file produces no error anywhere — it just never authenticates, which is indistinguishable from a wrong key.

For an administrator account the key belongs in C:\ProgramData\ssh\administrators_authorized_keys, and that file's permissions must grant only Administrators and SYSTEM:

$f = "C:\ProgramData\ssh\administrators_authorized_keys"
Add-Content $f (Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub") -Encoding ascii
icacls $f /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F"

Run that as written — it copies the key out of your .pub file, so there's nothing to paste and nothing to edit. Then confirm with Get-Content $f: you should see a line beginning ssh-ed25519 AAAAC3… and ending with your comment.

Two ways this goes wrong, both of which look like a rejected key:

• •The file holds a placeholder instead of your key. If Get-Content $f shows AAAA..., something copied an example rather than the real thing. Delete that line and re-run the command above.
• •The file is UTF-16. Written with > or Out-File instead of the -Encoding ascii above, Windows PowerShell saves it in a form sshd can't read, and not one key in it works.

For a standard (non-administrator) account the ordinary path is right: C:\Users\<name>\.ssh\authorized_keys.

Or use a password. On Windows that's often genuinely simpler — no shared file and no ACL to get right. Passwords are encrypted at rest and never returned by any API. The username is the account name for a local account (Administrator), or DOMAIN\user / [email protected] for a domain account.

There's no operating-system dropdown, and there shouldn't be one: a wrong pick would silently apply the wrong path rules to your server. On the first successful connection BucketPilot asks the machine to resolve its own working directory. Windows answers with something like /C:/Users/Administrator; Linux answers /home/ubuntu. That answer is stored, and it decides how every path on that server is separated, compared and contained.

Two things follow:

• •A server that has never connected successfully hasn't been detected yet, and is treated as Linux until it has. Press Test Connection — a Windows machine then shows a Windows badge, and the test result says so.
• •Windows paths are written /C:/like/this throughout BucketPilot. That's the form Windows' own SSH server prints and accepts. You can type C:\like\this and it will be stored in the canonical form — so a path shown back to you with forward slashes is correct, not a display bug.

A key in a bucket can be almost any text. A Windows filename can't — and the interesting part isn't what Windows refuses, it's what Windows accepts and then does something else with. BucketPilot checks every name before writing it, per file, and keeps the rest of the run going.

Accepted, and worse for it:

• •A colon. report:final.txt is accepted, and the colon opens an NTFS *alternate data stream* — the bytes end up hidden inside a file called report, and a naive copy reports success for something that exists nowhere you'll look. Refused before writing, with the reason.
• •Capitalisation. Report.pdf and report.pdf are two objects in a bucket and one file on Windows. Copying both would silently overwrite one and report two successes. The second is refused, and it names the first.
• •Reserved device names. aux.txt, con.txt, nul, com1 and friends are accepted on current Windows and refused by older versions and plenty of applications. Reported as a warning, not an error — refusing what your server accepts would be us overruling your machine.

Refused, but with a misleading message if you ask Windows directly: the characters " * < > ? |, names ending in a dot or a space (Windows strips both, so the file would arrive under a different name), and paths over the length limit. Windows reports all of these as "No such file", which reads as the *source* having gone missing.

Path length. The limit is 260 characters unless long paths have been deliberately enabled. Note that a job allows 246, not 260: it writes to a temporary name and renames it into place, so a failure can never leave a half-written file — and that temporary name is 14 characters longer. A name the file browser accepts and a job refuses is that difference, not an inconsistency.

Check before you run. On a migration into a Windows server, Check names on the job page lists everything that wouldn't arrive as itself — unwritable names, case collisions and reserved names — before the run starts, while there's still time to rename them at the source.

A drive opened on a Windows server browses like any other. Two differences are worth knowing before you set one up.

Don't root a drive at a whole drive. C:\ isn't a folder — it's Windows itself, every installed program, and every other user's files. BucketPilot will browse it, but it won't index it, so there's no search, no file-type or size breakdown, and no size alerts on it. The switch is shown and disabled, with the reason next to it. Root the drive at the folder you actually care about — /C:/inetpub/wwwroot, /D:/shares — and index that. The same applies to /, which on Windows means every drive at once.

Re-scans only look at what changed. A Windows drive is walked by a single PowerShell process on the server rather than by thousands of round trips, and a re-run asks only for files written or created since the last scan — so a re-scan of a large, mostly-unchanged drive finishes in seconds. A full walk still runs periodically, because only a full pass can notice that something was *deleted*.

The first scan of a drive is always a full one, and hourly auto-sync is safe on Windows for the same reason it is on Linux.

The test uses the same connection path a job does, so a test that passes means a job will connect too.

The failure stays on the server's card while you work through it, rather than disappearing after a few seconds.