Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

SFTP and SSH authentication patterns

28 Jan 2022 🔖 architecture integration
💬 EN

Table of Contents

When you automate business processes into “Extract, Transform, Load” (ETL) jobs, there’s a good chance that you’ll need to use one of these two major internet-based communications protocols:

  1. SFTP (for making your server upload or download files to/from a 3rd party’s server)
  2. SSH (for making your server execute commands on a 3rd party’s server)

There are two common ways of proving your identity in these kinds of inter-server communications.

Client = you, Server = them

Typically, when you schedule automations between your company and “the cloud,” your server will be the “client” and the 3rd-party server will be the “server” in the relationship.

That is, you say, “Don’t call us; we’ll call you.”

Your company’s server will be the computer that initiates a connection to the 3rd party’s server, not the other way around.

Linux commands

Software capable of knocking on 3rd-party servers’ doors over these two protocols comes standard in Linux, which is the operating system running on many corporate servers – probably including yours.

In fact, the commands to run such software – sftp and ssh – are literally named after the protocols they communicate over.

Authentication protocols

When the 3rd-party server comes to the door, it can identify that your server is friendly and genuinely belongs to you with one of two approaches:

1: Key-based authentication

  1. Your server knocks on the door saying:

    “Hey, it’s me, coolestserver.example.com / 101.101.101.3, public key ‘xyzzy’ … remember me? Can I come in?”

  2. The 3rd-party server sees that indeed, it has xyzzy on file as a cryptographic public key already known to belong to your server (e.g. because you LiquidFiles’ed it to them when you first set up a contract with them)
  3. The 3rd-party server uses the public key xyzzy to cryptographically encrypt a message and send it to your server. The message says something like:

    “Who’s there? If you can read this, write me back ‘purple monkey’, being sure to append the current date and time after a double hyphen, and sign it with your private key.”

  4. Your server uses its private key to decrypt the message, which wouldn’t be mathematically possible if your server’s private key didn’t cryptographically match the public key on file with the 3rd party.
  5. Your server cryptographically signs the message “purple monkey 2022-01-28--04:02:42.120AM-PST” and sends it back.
  6. The 3rd-party server uses the public key xyzzy to cryptographically encrypt a message and send it back. The message says:

    “Nice to see you! Let’s switch over now to encrypting our messages with this key I just made up, ‘abc123456xyz.’

  7. Your server uses its private key one last time, to decrypt the welcome message and read it.
  8. Your server proceeds with initiating whatever business it wanted to do over SFTP or SSH, but now using abc123456xyz to cryptographically encrypt communications. In fact, both servers now encrypt all communications with the key “abc123456xyz” until all business has been done and your server goes away.

Server key changes

If at any point you need to change your server’s private key, your old public key of xyzzy will become useless.

You’ll need to open a ticket with tech support with every single 3rd party who’s ever put your public key on file and ask them to update it to your newest public key.

2: Username and password authentication

  1. Your server knocks on the door saying, “Hey, it’s me, coolestserver.example.com / 101.101.101.3. Let me in, please.”
  2. The 3rd-party server writes back:

    “Hi there! What’s your username and password? When you answer, please be sure to cryptographically encrypt your reply with the public key ‘jkl765’.”

  3. Your server mutters to itself:

    “Okay, yup, I remember ‘jkl765’ being the correct public key for this 3rd-party server. That’s good.”

  4. Your server cryptographically encrypts a reply with the 3rd-party public key “jkl765” and sends it back. The reply says something like:

    “my_username / my_password – by the way, I have a little public key for you, too – it’s ‘xyzzy’.”

  5. The 3rd-party server uses the private key associated with the public key “jkl765” to decrypt the username and password that you just sent, and checks whether it has such a username and password on file.
  6. The 3rd-party server uses the public key “xyzzy” to cryptographically encrypt a message, and sends it. The message says:

    “Nice to see you! Let’s switch over to encrypting our messages with this key I just made up, ‘abc123456xyz.”

  7. Your server uses the private key cryptographically associated with the public key xyzzy to decrypt the welcome message.
  8. Your server proceeds with initiating whatever business it wanted to do over SFTP or SSH, but now using abc123456xyz to cryptographically encrypt communications. In fact, both servers now encrypt all communications with the key “abc123456xyz” until all business has been done and your server goes away.

Additional authentication

Either type of authentication can potentially also have a validation step early in the process where the 3rd-party server says:

“What are you doing with a luggage tag on your suitcase that says you came here from Kazakhstan?

“You’re supposed to be coming here straight from 101.101.101.3.

“Go away – you’re an impostor.”

Server moves

If you move “where on the internet” your server lives, you might have to open a ticket with tech support at your 3rd-party provider to let them know your new address.

Notes

--- ---