SSH

RFC 4253 is the transport: the handshake, the server host key, and the record protection. RFC 4254 is the connection layer: channels for a shell, for port forwarding, and for a named subsystem. File transfer is one subsystem. SSH itself is not a file protocol.

That split is why SFTP and legacy SCP both "use SSH" and still differ. Both ride a channel on an SSH connection, almost always TCP port 22. SFTP is the subsystem named `sftp`. Legacy SCP is a remote command on an exec channel. The login, the host-key check, and the encryption are SSH. The messages that name a path and carry bytes are the file protocol on top. A firewall rule that allows 22 does not tell you which of those is enabled. A server can allow a shell and refuse the sftp subsystem.

A partner asks for key-based SSH to `sftp.partner.example`. The job presents a private key, the server accepts it, and the client requests the sftp subsystem. The host key matches the one pinned last quarter. The file lands. A second job uses the same key and the same port, then runs `scp -O`, which needs the legacy copy command. The server allows SFTP and blocks remote commands. The key worked. The copy failed. Rotating the host key without updating the pin fails earlier: the client stops before authentication, which is the check RFC 4253 is for.

SSH is not TLS, and it is not FTPS. TLS is the channel under HTTPS. SSH is the channel under SFTP. Both are encryption in transit. Neither encrypts the file after the session ends. People who say "SSH the file" usually mean SFTP or the scp command. Ask which channel the server will accept before you write the job.