how ssh puts the S in ftp ;)
While we’re on the topic of logging-in to remote servers…
All of these articles are meant to serve as notes or reminders to my future self. When I write them, I’m trying to stay relatively platform agnostic. We live in a world that has a proliferation of diverse stacks, and that’s not a bad thing! It’s the price of cutting-edge technology. It doesn’t really matter which collection of software you happen to have in place, it’s guaranteed to change. If it doesn’t then look out because it’s fast becoming obsolete. The structure of the stack itself is constantly changing, and as a web developer it’s your job to get these stacks to share data in a secure, standardized way. That’s the problem at the heart of this particular article, and it’s a pretty common one: how do you get a Windows machine to share data securely with a Linux server? Yes, we’re all supposed to be moving towards event-driven, api-oriented architecture but how do we manage in the mean-time? Using ssh and sftp is one solution, and I do believe that my future self will appreciate my efforts.
If you're a server admin then you may not have to read any further because there’s a good chance that setting up ssh & sftp is your bread and butter. On the other hand, if you're but a humble developer like myself this is the kind of thing that you have to set up every once in a while. When you've got it working, the details of how you got it to work immediately start to fade away. At least, that's how my brain operates with regards to this particular task.
If you want to know more about the reasoning behind the use of ssh, and you don't want to bother your friendly neighbourhood server admin, here's a really handy article (from SSH Academy) that describes why ssh is more secure than password authentication alone:
What is SSH?
As the SSH Academy will tell you, Secure SHell (a.k.a. ssh) is a protocol that "uses encryption to secure the connection between a client and a server." If you’re interested in the cryptography behind this protocol, you might want to listen to the Sept. 28, 2022 episode of the Vox podcast Unexplainable called “The math problem that could break the internet”. Here’s the transcript. Don’t freak out, math isn’t going to actually break the internet. At least, not any time soon… The title is a little dramatic, but so is the story behind the development of this protocol!
OpenSSH is the most popular implementation of the ssh protocol. It's based on the original version of ssh (invented by Tatu Ylonen). If both the client and the host are Linux-based then OpenSSH will probably be your go-to implementation, as recommended by the SSH Academy. Digital Ocean also has pretty thorough documentation regarding how to set up ssh.
If there's a Windows machine involved, well things might get a little more complicated but that’s why we’re here! Because Windows doesn’t have ssh built-in to their OS you’ll have to determine the best fit for both the client and the host. Fortunately MicroSoft actually recommends using OpenSSH.
ANYWAY, the ssh protocol ensures that all data transmitted between the client and server is encrypted. When you use a Secure SHell client to open up the connection to a host, you can be fairly certain that the data you're sharing with that host will be protected. How does the establishment of such a secure connection work? Typically the user generates a public-private key pair. The public key sits on the host machine to verify its authenticity, and the private key sits on the client’s machine to provide it with unique identification. How can you generate your own magical public-private key pair? Whoa there, you’re gonna need to ask yourself a few questions…
BEFORE YOU GENERATE THE KEY PAIR
1) You need to know what implementation is being used on both the client and host in question. For example, if your key pair is going to be consumed by a Windows server and a Linux server then you’ll probably be using OpenSSH but verify this first!
2) Are there any further requirements for the process? As an added layer of security, some ssh implementations require a passphrase to be used alongside the private key when the client initiates the process. This affects how you'll generate the private key, as well as the command that you use to access it.
3) Choose your client carefully, with all the above considered. Wikipedia even has an extensive list of ssh clients prepared just for you. Having said that, there’s a reason why PuTTY is the most popular Windows ssh client: it plays nicely with both Windows and Linux systems (though not necessarily with Oracle cloud VMs, more on that here).
If you’re convinced that PuTTY is the ssh client for you, well you’re in luck because Simon Tatham continues to publish the latest versions of PuTTY on his personal website here. The SSH Academy is also giving you a helping hand with installation instructions specifically for Windows, as well as instructions for generating the key pair.
REMEMBER
When a key pair is generated with PuTTY, the private key is given a .ppk file extension (PuTTY Private Key), and format, by default. This helps you to keep track of which key is private and public. Though there’s no formal naming convention for key pairs, often “.pub” or “.pubk” is used as the extension for the public key. Following this convention is helpful for the server admin who likely has a whole whack of private and public keys to maintain. If you use the “.pub” extension, a Windows machine will usually interpret it as a Publisher file (which doesn’t really affect much other than human users reading the file names). Keep your file names both Windows and Linux friendly if they’re meant to be used on either system. Generally it’s best to store the keys in a hidden directory, as they are meant to be a secret after all. Make sure that you have the correct path to where the private key is being stored on the client side. You’re gonna need it!
GET TO THE SFTP, ALREADY!
Because SSH is the protocol that secures the connection for file transfers, now that you've got your key pair in place (public key on the host, private key on the client) you too are ready to put the S into the FTP.
You’ll have to make sure that your ssh-client has sftp capacity. (Here’s a list, just in case!) We’re going to keep using PuTTY because it’s got a pretty handy sftp commandline utility. Keep in mind the working directory when you're opening a terminal, as this is the default for where files will be downloaded-to and uploaded-from during your session.
If you want to test things out with the command line, you’ll start by entering
psftp -i C:\Private_Keys\id_rsa.ppk username@domain.ca
In this command we’re opening up a connection to a particular domain or host, with our own username.
The “-i” switch specifies the identity of the private key we’re using, and the parameter entered is the (secret!) path to that key.
If this is the first time connecting to a certain host, then you’ll be prompted to add the host’s public key to your own known_hosts file. This is to verify the host's identity so that you’re not sharing data with an unknown entity.
Whenever you run this command, you should be prompted for the passphrase that you set for this private key. A key and its corresponding passphrase can be automatically loaded on start-up but that’s another story for another day… This article is already far too long(and I haven’t even addressed the host side of things)!
Once you’ve established a connection to the host, you should be able to run other commands like “get” to download a file, and “put” to upload a file. If you want to see a list of all the commands you can run simply enter “help”. When you’re done transferring files you can enter “bye” to finish your Secure File Transfer Protocol session.
BYE!