​
Understand the connection direction

In the standard setup, the client hosts the SFTP server and GetBill initiates the connection:
  • the client’s IT team creates the SFTP user and agreed folders;
  • GetBill connects from the fixed source IP address 13.36.197.47;
  • GetBill reads the inbound folder;
  • when exports are enabled, GetBill also writes to the outbound folder.
If the server filters connections, allow 13.36.197.47 on the agreed port, usually 22. Restrict the user to required operations: inbound-folder reads and outbound-folder writes when exports are enabled.
On request, GetBill can host and operate the SFTP server. This is a bespoke service billed monthly, and requires separate commercial and technical scoping. GetBill then provides applicable network settings, credentials, paths, and responsibilities in a dedicated onboarding sheet.

​
Authenticate GetBill with an SSH key

A dedicated SSH key is recommended. GetBill generates a 4096-bit RSA key pair:
  1. GetBill retains the private key in its secure environment.
  2. GetBill sends only the public key to the client’s IT team.
  3. The IT team installs that key in authorized_keys for the agreed user.
  4. GetBill uses the matching private key to authenticate.
The private key must never be sent to the client, emailed, or added to a ticket. The public key is not secret. Password authentication remains available when agreed, but the secret must be transferred only through the secure onboarding channel.

​
Pin the server host key

Two different keys take part:
  • the GetBill public key lets the client server authenticate GetBill;
  • the client SFTP server host key lets GetBill authenticate the server.
To detect an unexpected server identity, the IT team supplies the host-key fingerprint in OpenSSH SHA256:... format, preferably through a separate channel. GetBill compares it with the key presented on every connection before continuing with file operations. If the fingerprint differs, GetBill refuses the connection. A legitimate rotation must be announced and validated before it goes live. Pinning is strongly recommended before production activation. Any exception must be explicitly accepted as a risk during onboarding; dedicated SSH-key authentication remains preferred in that case.

​
Divide the onboarding information

Do not put client identifiers, environment fingerprints, or secrets in public documentation.

​
Validate access

  1. GetBill provides its IP and, when used, its public key.
  2. The IT team allows the IP, creates the user, and installs the key with least privilege.
  3. The IT team provides host, port, username, paths, and, unless an exception is accepted, the host-key fingerprint.
  4. GetBill configures pinning when selected, then tests the connection and read access.
  5. If exports are enabled, GetBill tests outbound-folder write access.
  6. Both parties validate key rotation and the incident procedure.

Prepare inbound files

Next configure naming, formats, and the row contract.