We will begin by downloading a file from the SFTP server and
exploring the resulting debug messages.
This slide is for reference only.
Given that SFTP is encrypted and hard to see via packet capture,
I am displaying the relevant SFTP message codes.
Feel free to pause the video, take a screenshot,
or reference the URL if you'd like to read the technical history.
We will see these codes in our client debugging where I'll add more context.
There are many more codes that I am not listing here.
Let's examine the script first.
The first line is setting debug to 9, which prints out everything.
We need to turn up the debug intensity to see the low-level SFTP signaling,
since Wireshark won't reveal it.
I then set the SFTP auto-confirm option,
which is really an SSH-related option to store any
public SSH keys from the SFTP server.
This prevents SFTP transfers from failing due to the client not having
the server's public key and its known host's file.
If the server's public key is already trusted, this option is not necessary.
Next, I use the open command except with different syntax.
I specify that SFTP is the protocol using the same
username and password from earlier.
I also include the IP address following the at symbol.
After that, I change into the FTP directory,
a step that was unnecessary for regular FTP.
With vsftpd,
we adjusted the user local root by automatically dropping
users into their FTP subdirectory at login.
Because SFTP is a subsystem of SSH, our vsftpd configuration is irrelevant now.
Issuing the ls and get commands is nothing new, so I won't discuss those again.
Let's run the script and see what happens.
I won't be detailing every line, as the focus is on the five major steps.
The client sends the INIT message, which has a type of 1 and a request ID of 0.
The server responds with the version message,
which is type 2,
and also has a request ID of 0 that identifies it as the
reply to the client's INIT message.
I'm not going to detail all the auxiliary SFTP command exchanges that follow.
To summarize,
the client issues commands to change the directory
and list the directory's contents,
then the server replies with the appropriate acknowledgements and information.
The request ID keeps incrementing and a variety of minor messages are used.
I want to jump down to the ninth request ID,
which begins when the client sends a type 3 open message.
This starts the file download process.
The server replies with a handle message, which is type 102.
The file handle is eight 0s, and the maximum length of this string is 256 bytes.
Such a huge handle might be present on a very bust SFTP
server with many concurrent files operations.
Jump down to the type 5 read message with request ID 11.
This is the next step in the download process.
With the file open and a valid handle at the ready,
the client begins downloading the file's contents.
Data is transferred from server to client using the type 103 data message.
This isn't actually one data packet, just a representation of data transfer.
If you transfer large files requiring multiple packets,
there will still only be one data line in the LFTP debug output.
The fifth and final step includes the client sending a type 4 close
message and supplying the file handle back to the server. This completes the file download transaction.