Credentials Between Servers: Who Holds What

Every server-to-server flow, whatever its shape, plants a secret somewhere. One machine must prove its identity to another at two in the morning with no human present. That means a credential — a password or a private key — sits on a disk, readable by a scheduled job, waiting. Multiply by every flow in the estate and you have dozens of standing secrets, each one a key to some other system. They are distributed across machines by decisions nobody wrote down.

The design question is not whether these secrets exist — unattended transfer requires them — but who holds what. Which machine stores each secret, and which machine hosts the matching account? What does each unlock, and who is on the hook when one must change? Estates that can answer those questions rotate credentials calmly and shrug off a compromised box. Estates that cannot, postpone rotation for years because nobody knows what will break.

This article — part of our Server-to-Server Exchange Patterns series — maps credential placement across the exchange patterns. It covers the rule that decides where secrets live, per-flow accounts, and key placement done properly. It offers a who-holds-what matrix you can copy. It covers the discipline of inventorying and rotating secrets when the two ends belong to different teams.

Why Machine Credentials Are Different

A service account is an account that exists for software rather than for a person. It breaks most of the intuitions we carry over from human logins. Nobody types its password, so the password can be — and should be — long, random, and unmemorable. Nobody is present when it authenticates, so there is no one to answer a second-factor prompt, notice a warning, or hesitate at something odd. And it works at machine rhythm: the same credential, used every night for years, from the same address, at the same minute.

Those properties cut both ways. The regularity makes abuse conspicuous. A login from a new address, or at an unusual hour, is a louder signal for a service account than for any human account. But failures are harsher too: an expired password that a human would reset in a minute becomes a silent batch failure at 02:00. A leaked machine credential keeps working indefinitely precisely because nobody is watching it get used. The care and feeding of these accounts — naming, ownership, documentation, monitoring — is the subject of service account hygiene. This article takes the next step: deciding where the accounts and their secrets should live across an estate of flows.

The Placement Rule: Secrets Follow the Initiator

Every credential in a transfer flow has two halves, and they live on opposite machines. The account — the identity, its folder scope, its permissions — lives on the passive side, the machine that runs the transfer server and accepts the connection. The secret — the password or private key that proves the identity — lives on the initiating side, the machine that runs the client. Since the initiator is chosen when you choose push or pull, direction decides placement. The whole argument is laid out in choosing direction between systems, and this is its credential consequence.

The asymmetry between the two halves is the useful part. The account's owner can constrain and revoke: jail the account to one folder and strip its permissions to the minimum. The owner can pin it to one source address and disable it the moment something looks wrong. The secret's holder can only store and use: protect the thing at rest, keep it out of scripts and repositories, and use it from the one job that needs it. Constraint power sits on the passive side; custody duty sits on the initiating side. A well-designed estate exploits both — every account maximally constrained by its owner, every secret minimally exposed by its holder. A badly designed one does neither, which is how a leaked password for "the transfer user" turns into free run of a server.

One Account Per Flow, Per Direction

The unit of credential design is the flow, not the machine pair and certainly not the estate. The working rule: every flow gets its own account, scoped to its own folder, in its one direction. When the warehouse system pushes shipments and pulls stock levels, that is two flows and two accounts, even though the same two machines are involved.

Shared accounts are the tempting shortcut, and each temptation has a specific bill attached. Share one account across two flows and you can no longer tell from the logs which flow did what — attribution dies. Rotate that shared secret and both flows break together — rotation couples. Compromise it and both flows' folders are exposed — blast radius doubles. The general principle that one account's reach should be as small as its job is explored in the blast radius of one account. For transfer flows the practical shape is:

• A name that says what it is: svc-wms-shipments-push tells the next administrator the holder, the flow, and the direction before they open a single document.
• Folder scope of one: the account sees the flow's folder and nothing else. A push account writes into its intake folder; a pull account reads from its outbox; neither can list, read, or touch anything beyond it.
• Address pinning: the account accepts logins only from the machine that legitimately initiates the flow. On a Windows endpoint running Sysax Multi Server, this stacks naturally. Each account is isolated to its own folder tree, and the server's IP allow and block lists refuse that account from any unexpected address. So a stolen secret is useless from an attacker's machine.
• A recorded owner: a team name attached to the account, because an account nobody owns is an account nobody will ever dare delete.

Keys, Passwords, and What Goes Where

For SFTP flows — the common case between servers — the strong default is key authentication. A key pair is two matched halves: the private key, which proves identity and must be protected, and the public key. The public half verifies that proof and can be shared freely. Placement follows the rule above: the private key lives on the initiating machine, readable only by the account the transfer job runs as. The public key is registered against the service account on the passive side. Getting the public half onto the right server, correctly and verifiably, is its own small craft — see distributing authorized keys.

Keys beat passwords for machine flows on three counts. The secret half never crosses the network during login. A well-made key cannot be guessed the way a password can. And — decisive for rotation, as we will see — a service account can hold two authorized public keys at once. This allows a new key to be introduced while the old one still works.

There is a second identity check in every flow, and it points the other way: the initiator must verify the server it is connecting to. SSH does this with host keys — the server's own identity key, which the client checks against a stored copy (the known-hosts list) on every connection. A transfer job that blindly accepts whatever host key it is offered will happily deliver your invoice file to an impostor. Pin host keys deliberately, and treat an unexpected host-key change as an incident, not a prompt to click through. The full story is in host keys and known hosts.

Where keys are not available — FTPS endpoints, legacy servers, partner constraints — passwords carry the flow, and storage discipline does the work keys would have done. The one unbreakable rule: no plaintext passwords inside scripts, where they get copied, committed, and emailed. Put the secret in the scheduling tool's protected store or the platform's credential facility, and let the job reference it. The options are compared in job credentials storage. Purpose-built automation helps here by consolidating. In Sysax FTP Automation, a scheduled task created through the wizard carries its connection details with the task definition. So the credential lives in one managed place per flow instead of being hardcoded into whichever script mentions the hostname.

The Who-Holds-What Matrix

Placement generalizes across the exchange patterns in this series. The matrix below is the one-page answer — for each pattern, where the accounts and secrets sit, and what one compromised machine can reach:

Two readings are worth pausing on. In the staged and hub patterns, no production system ever holds a secret for another production system. Every secret unlocks only the neutral middle, which is a machine built and monitored for exactly that exposure. That containment is a large share of why staging areas and hubs get built at all. And in the hub pattern, rotation stops being an n-squared negotiation. Every rotation is a two-party affair between one spoke team and the hub's owner, on a standard runbook.

Secret Sprawl and the Credential Inventory

Secret sprawl is what happens to credential placement by default: every new flow adds a secret on some machine. Every migration copies secrets to new homes without deleting the old ones. After a few years, keys and passwords are scattered across the estate in locations no list has ever captured. Sprawl's cost is not hypothetical. Sprawl is the reason credential rotation feels dangerous ("what else uses this password?") and the reason decommissioning drags ("what will break if we delete this account?"). It is the first thing an attacker on a compromised box goes shopping for.

The countermeasure is dull and powerful: a credential inventory, one line per machine credential, kept where the flow documentation lives:

CREDENTIAL INVENTORY — machine credentials only
id    secret held on        type      unlocks account        on host              flow   owner      last rotated
C01   billing-02            ssh key   svc-billing-push       stage-01.example.com F03    finance    Mar (this yr)
C02   erp-01                ssh key   svc-erp-pull           stage-01.example.com F03    erp team   Mar (this yr)
C03   wms-01                password  svc-wms-shipments      erp-01.example.com   F01    logistics  unknown
C04   bi-02                 ssh key   svc-bi-pull            erp-01.example.com   F02    data team  never
Findings: C03 predates the inventory - rotate and record; C04 never rotated.

The inventory earns its keep the first time you answer "this server was compromised — what could the attacker log into?" by reading instead of guessing. Filter the secret held on column by the fallen host and you have the complete revocation list. Keep it honest by making it part of every flow's setup and teardown checklist, and audit it against reality on a schedule. For SSH keys specifically, key rotation and inventory walks the audit method. Note what the inventory deliberately excludes: the secrets themselves. It records locations and relationships, never values.

Rotating When Two Teams Hold the Halves

Rotation is where placement pays or punishes. The account's owner and the secret's holder are different teams — that is the normal case, not the awkward one. So rotation is a coordinated handoff, and it needs a runbook both sides have agreed to before the day comes:

CROSS-TEAM ROTATION RUNBOOK (key-based flow)
1. Announce      Secret holder proposes the window; account owner confirms.
                 Nothing changes yet.
2. Add alongside Initiating team generates the new key pair; account owner
                 authorizes the NEW public key next to the old one.
                 Both keys now work - nothing has broken.
3. Switch        Initiating team points the transfer job at the new private key.
4. Verify        Both sides watch the next scheduled runs succeed:
                 initiator sees successful transfers, account owner sees
                 logins in the server log using the new key.
5. Revoke        After an agreed number of clean runs (e.g. three nights),
                 account owner removes the OLD public key.
6. Record        Update the credential inventory: new key, rotation date.

The overlap in step 2 is the whole trick, and it is why keys are the rotation-friendly choice. Both credentials are valid during the switch, so no scheduled run ever finds the door locked. Password rotation lacks that grace on most servers — one password per account means the change and the switch must land together. Two workarounds keep it calm. Schedule the swap inside a window when no runs fire, with both teams on the call. Or create a parallel account (svc-wms-shipments-b), migrate the job to it, and retire the original. That is the key overlap pattern rebuilt from accounts. With external partners the dance is the same but slower and more formal; the partner credential lifecycle covers the etiquette.

Rotation's forgotten sibling is retirement. When a flow is decommissioned, both halves must die. The account owner disables and then deletes the account, and the secret holder deletes the key or password from the initiating machine. Then both update the inventory. Estates that only ever do the first half accumulate orphaned secrets pointing at dead accounts. Estates that only do the second accumulate live accounts nobody uses. Both are findings on the next audit, and the second is a standing gift to attackers.

Containment: Assume One Box Falls

The final test of a credential design is a tabletop exercise, run before the incident instead of during it. Pick any machine in the estate and ask: if an attacker owns this box tonight, what do its stored secrets unlock, and how quickly would we know and revoke?

1. Enumerate — filter the credential inventory by that host. The list should be short: only the secrets that machine's own flows genuinely need. If secrets for long-dead flows or "just in case" copies show up, fix that today.
2. Bound the reach — for each secret, name what the matching account can actually do. If every account is folder-jailed and address-pinned, the honest answer is "write into two intake folders, read one outbox" — an incident, not a catastrophe.
3. Check the tripwires — a stolen secret used from the attacker's own machine should fail on the address pinning. Used from the compromised box, it produces logins that the account's activity log records with times and addresses. Someone, or something, should be reading those logs for the off-schedule and off-address oddities. The monitoring habits from monitoring authentication attacks apply to trusted accounts too.
4. Time the revocation — from decision to done: disable the accounts the fallen box's secrets unlock, rotate what its flows need to resume, and measure the wall-clock time honestly. If the answer is a scramble of days, the inventory and the runbook are the missing tools, not more heroics.

Run the exercise for the middle boxes especially. A staging server or hub concentrates accounts, so its fall looks alarming — but notice what it does not hold. The middle stores no secrets for the spokes. So owning it lets an attacker receive what producers deliver and serve what consumers collect, yet log into nothing else. The damage is real but bounded and visible in one activity log. That bounded shape is the credential argument for the patterns this series recommends, and you will see it running through the reference designs.

The Estate Answer

Who holds what, then. The passive side holds accounts — one per flow and direction, folder-jailed, address-pinned, owned by name. The initiating side holds secrets — private keys by preference, stored in a protected credential store, never in scripts. The middle boxes hold accounts for everyone and secrets for almost no one, which is precisely why they make good middles. And the estate holds two documents that make all of it operable. They are a credential inventory that says where every secret sits, and a rotation runbook both teams have rehearsed.

If you arrived here from the direction decision, push or pull is the companion piece. If the matrix has you considering a neutral middle, hub-and-spoke vs point-to-point weighs that estate shape honestly.

Frequently Asked Questions