lumnik. / scenarios All scenarios · Français

The carrier's SFTP drop read every night with nothing taken on trust

Goal Read the carrier's file every night, file it away, and refuse a server whose key changed.

A carrier drops livraisons.csv on its SFTP every night, always under the same name.

manifests/10-carrier.yaml
apiVersion: connectors.lumnik.io/v1kind: Connectormetadata:  name: scenario-carrier-a  connector_type: csv-file  scopes: [transport]spec:  transport:    kind: sftp    host: host.docker.internal    port: 2223    user: carrier    path: /out/*.csv    password_env: SCENARIO_CARRIER_A_SFTP    # The fingerprint the carrier's server presents, read out of band (ssh-keyscan | ssh-keygen -lf -).    host_key_fingerprint: "SHA256:FINGERPRINT_READ_AT_REPLAY"  parser:    has_header: true  after_process: archive  archive_path: /archive/
livraisons-night1.csv
shipment,status,city
S-1001,TRA,Lyon
S-1002,TRA,Vienne
S-1003,LIV,Givors
S-1004,TRA,Lyon
S-1005,RET,Bron
S-1006,TRA,Lyon
livraisons-night2.csv
shipment,status,city
S-1001,LIV,Lyon
S-1002,LIV,Vienne
S-1003,LIV,Givors
S-1004,TRA,Lyon
S-1005,RET,Bron
S-1006,LIV,Lyon
livraisons-night3.csv
shipment,status,city
S-1004,LIV,Lyon
S-1007,TRA,Vénissieux
$ lm connector run scenario-carrier-d
run scheduled: bc7df8c4-f546-41a8-9ab5-4ce1eba4c618

$ lm run get bc7df8c4-f546-41a8-9ab5-4ce1eba4c618
ID        CONNECTOR           ENDPOINT  STATUS  IN  OUT  SKIPPED  DEAD-LETTERS  STARTED           ENDED             EVALUATED
bc7df8c4  scenario-carrier-d  default   Failed  0   0    0        0             2026-10-22 20:44  2026-10-22 20:44  no
✖ run failed: SFTP host key refused for host.docker.internal:2223 — the server presented SHA256:z0s2KEWB7fEsBsd/JTIbxr5YwdTbZLCJNtG9UWmafe8, and it does not match the declared SHA256:FZMB2WwJKm87XB3fpEhOPieZ3XZW5VAolwo6+MX+iHg. Confirm that fingerprint out of band (ssh-keyscan -p 2223 host.docker.internal | ssh-keygen -lf -), then set host_key_fingerprint: "SHA256:z0s2KEWB7fEsBsd/JTIbxr5YwdTbZLCJNtG9UWmafe8" in the transport block. Setting strict_host_key: false connects without checking at all — which accepts an impostor as readily as the real server. — Server key did not validate
livraisons-night4.csv
shipment,status,city
S-1007,LIV,Vénissieux

Limits

  • The check before a move is not atomic with it: a file dropped in the milliseconds between them is still moved.
  • A carrier that writes under another name and renames it in is never caught in that window.
  • Simulated SFTP server; synthetic data.

Transport · SFTP

The carrier drops a file every night.

Always under the same name.

Four nights, simulated server

The problem

Same name, same size.

  • One night can look like the last.
  • One archive can overwrite another.

What is not changed

The carrier's server stays as it is.

  • Its drop folder.
  • Its SFTP account.

The trap

Talking to the wrong server.

  • The server is reinstalled.
  • Its key is no longer the same.

What had to be written

host_key_fingerprint: "SHA256:…"

One line.

  • The hub only talks to the known server.
  • Each night archived under its time.
  • A 20-line scenario, one manifest.

A refusal

The key changed: refused.

  • Both fingerprints named.
  • Confirm with the carrier, then pin.

The limit

A drop during the move.

  • A few non-atomic milliseconds.

Try it

The scenario replays locally.

Every step is published with its output.

This scenario runs on lumnik Open, free and open source.

Try lumnik Open →