This module focuses on SSH FTP,
not to be confused with FTP Secure from the previous module.
SSH FTP, also called SFTP and occasionally Secure FTP,
is another option to protect our FTP traffic.
I'll follow a consistent pattern in this module, as I did for the last three.
FTPS utilized digital certificates,
which I briefly explained in the previous module.
SFTP introduces Secure Shell, or SSH,
and I'll provide a high-level summary of how it works.
Next,
we need to understand how SFTP works and how it differs from more
traditional FTP variants for downloading and uploading files.
Like FTPS, there are some changes required on the server,
so I'll cover those briefly.
To test it, we will execute some SFTP file transfers with debugging enabled.
This is followed by examining the resultant packet captures.
Unlike FTPS, SFTP changes the TCP ports used for file transfer,
indicating that our firewall policies must be revisited.
I'll say up front that SFTP is a tricky topic to deep dive for a few reasons.
IETF drafts written between 2001 and 2007 have since expired,
yet the protocol lives on.
Many in the community believe that SFTP isn't really a protocol,
just a file transfer application nested inside of SSH,
which has many RFCs associated with it.
Because there is no formal specification,
your mileage may vary when deploying SFTP.
Perhaps this is obvious, but SFTP relies upon SSH for its transport.
SSH uses TCP port 22 by default,
as opposed to the well-known FTP-related ports of 20 and
21 observed in the previous modules.
All communications are therefore encrypted.
At the time of this recording, Wireshark does not offer SSH decryption support.
The secret keys used for SSH encryption are temporary and session specific.
That is to say, they do not exist in the file system of either Linux box,
making it challenging to decrypt the traffic,
even if Wireshark supported it.
Because SFTP has these characteristics,
we can't easily deep dive the protocol operation via a packet capture.
To compensate,
I'll explain the high-level operations per the IETF drafts and rely on
LFTP client debugging during the demonstrations.
This isn't a cryptography class, but if you are going to deploy SFTP,
you need to be conversant in SSH operations.
Somewhat like the creation of digital certificates, SSH relies on key pairs.
I will provide a rather imprecise sequence of events in the interest of brevity,
as my goal is to illustrate the main actions that occur.
Each entity, such as a person or a machine,
has a public key that is freely shared and is used to
encrypt traffic sent to that entity.
Exchanging public keys is how two hosts communicate
using a method known as Diffie Hellman.
Each entity also has a private key used to decrypt
any incoming encrypted traffic.
In the context of SSH,
these key pairs are used to create a secure
communications channel on TCP port 22.
Contrary to popular belief,
this asymmetric encryption technique is not used for general SSH encryption.
Both SSH speakers independently compute a
session-specific key that is used for encryption.
This also relies on Diffie Hellman and introduces large prime numbers.
Authentication is similar to FTPS in that the username/password pairs
or public key-based methods are both acceptable.
We'll stick to the username/password pair for simplicity,
but in either case, there is only one TCP session for both signaling and data,
unlike classic FTP.
To learn more, you can watch Pluralsight's SSH Protocol Deep Dive course.
How does SFTP fit into the picture?
In our network, SFTP is built into the OpenSSH server,
which ships with many modern Linux distributions.
We don't need vsftpd installed to support SFTP because,
again, classic FTP and SFTP are completely different protocols.
I know what some of you are thinking, can't we just use Secure Copy Protocol,
or SCP, if we wanted to transfer files via SSH?
It's true that SCP is a file transfer mechanism built on SSH.
As such, its profile on the network would look almost identical to that of SFTP.
Both would look like regular TCP port 22 SSH traffic.
Operationally, SCP is much less capable than SFTP.
SCP only allows for the downloading and uploading of files.
SFTP can do many of the things classic FTP can,
such as create and browse folders, delete files and folders,
change file permissions, and more.
As a result, it's a better use of our time to focus on SFTP,
the more capable protocol,
as it will likely be the better choice for general purpose secure file transfers.