Not quite sure what you're looking for, but in thinking about some things that might cause confusion to someone just getting started I can think of the following grossly oversimplified comments:
FTP is an protocol for transferring files between two computers; it's plagued with problems in modern networks with firewalls, none of the protocol is encrypted (aka your username, password, and all data is sent over the network in plain old readable forms). There are millions of copies of the client code to support this protocol pretty much built-in to every meaningful system connected to the internet (similar to how http/s (web browsing) is built-in). More recently, mostly due to its inherent insecurity, but also due to the aggravation FTP causes firewalls, people are starting to actively refuse FTP, or are at least strongly encouraging people use better and more secure file transfer methods.
I'd say there are two primary leaders for the replacement, FTPS and SFTP.
First, FTPS (note the position of the 'S' in that identifier), is FTP with the Secure Sockets Layer (SSL) bolted on to it; it's the equivalent of HTTPS to HTTP. FTPS takes FTP and just wraps it an encrypted channel, that's it; encrypted FTP (just like HTTPS is simply encrypted HTTP). FTPS in my opinion, is simply more aggravating. It makes everything more complicated and harder to fix and by design prevents some of the "man-in-the-middle" NAT techniques that firewalls use to make FTP continue to work in the first place (an explanation of active mode versus passive mode FTP is beyond the scope of this comment. :))
The other is SFTP, a special case of implementing a protocol similar to FTP on top of the more general SSH protocol.
SSH (and it's children SFTP, SCP, et al.) under the hood is a different protocol from FTP entirely (though they can both support copying files).
See http://en.wikipedia.org/wiki/Secure_Shell
When dealing with SSH it's mainly happening on port 22, the server will first provide the connecting client a host-key (which can be used to validate that the server is actually the intended server; but this mechanism is not very well automated and usually just resorts to "ask the user if this 128bit hexadecimal string looks right"); then the client provides either username/password or private key based authentication credentials (or other mechanism if the client/server both support and choose it). SSH is extensible so that it can support many different types of encryption and authentication methods over time.
SSH's primary/original use was for opening a terminal prompt on the remote computer. It's main advantages were:
1) it was encrypted, authenticated, and supported various and extensible protocols
2) authentication could use either a username/password or a special private key file that the user had on their local (i.e. the initiating) computer
3) it additionally provided a basic means for authenticating that the server being connected to was actually the server intended (aka there was little chance there was a man-in-the-middle capturing the conversation/data stream).
In other words, it gave you an encrypted and more trustworthy way to "log in" to a text terminal on a remote computer very much like a direct VPN would.
Before long, people were using SSH to do specific tasks beyond just a text terminal, such as private VPNs between machines, file transfers, encrypted NAT/PORT redirection, remotely automated and secured jobs that didn't require some plaintext password be retrieved from a file somewhere (passwords that would get changed and the scripts have to be updated), and all manner of other nifty data transfer and automation tricks.
SSH has basically become an authenticated and encrypted swiss army knife of both TCP/IP and command level protocols depending on which one you need; and that doesn't necessarily require typing in a username and password every time it gets used to remotely connect. It also has some basic failsafes that prevent connection if any of the automated key mechanisms don't seem 100% kosher. So it is great for both automated, unattended tasks and for interactive log ins.
SSH's only main downside is that it is directly supported by pretty much every operating system/platform vendor on the planet except for Microsoft and that's what makes this SSH.Net project/library such a kick-ass and important piece of code and God bless all the people who are making it possible.
In fancy speak, create a connection to a remote server (an SshNet.SftpClient), using the connection information (SshNet.ConnectionInfo), giving it an Authentication Method (most likely a SshNet.PasswordAuthenticationMetod that takes a username and password). Or, if you want to be lazy about it and treat it just like FTP, use the SshNet.SftpClient constructor that takes the hostname, username, and password directly.
Once the SftpClient object has been instantiated with the appropriate ConnectionInfo; call its Connect() method.
Once the SftpClient is Connected, you can do lots of FTP like things; while SshNet supports lots of awesome Asynchronous callback methods which are great for GUIs (and tricky to implement properly so God bless them again!); it also supports several synchronous methods of interest like: DownloadFile("fileName", localFileStream), UploadFile(localFileStream, "fileName"), Get("fileName") (which gets detailed information about a file), and ListDirectory("path") which returns a List(Of SftpFile) object with all the files in "path" on the remote server.
Once you're done, call the SftpClient.Disconnect() method and Dispose() of the object (code with the "using" clause can skip these (especially dispose)).
Here's a brain dead example of synchronously downloading a file:
Hope that helps get you started.
Cheers!
Mike
FTP is an protocol for transferring files between two computers; it's plagued with problems in modern networks with firewalls, none of the protocol is encrypted (aka your username, password, and all data is sent over the network in plain old readable forms). There are millions of copies of the client code to support this protocol pretty much built-in to every meaningful system connected to the internet (similar to how http/s (web browsing) is built-in). More recently, mostly due to its inherent insecurity, but also due to the aggravation FTP causes firewalls, people are starting to actively refuse FTP, or are at least strongly encouraging people use better and more secure file transfer methods.
I'd say there are two primary leaders for the replacement, FTPS and SFTP.
First, FTPS (note the position of the 'S' in that identifier), is FTP with the Secure Sockets Layer (SSL) bolted on to it; it's the equivalent of HTTPS to HTTP. FTPS takes FTP and just wraps it an encrypted channel, that's it; encrypted FTP (just like HTTPS is simply encrypted HTTP). FTPS in my opinion, is simply more aggravating. It makes everything more complicated and harder to fix and by design prevents some of the "man-in-the-middle" NAT techniques that firewalls use to make FTP continue to work in the first place (an explanation of active mode versus passive mode FTP is beyond the scope of this comment. :))
The other is SFTP, a special case of implementing a protocol similar to FTP on top of the more general SSH protocol.
SSH (and it's children SFTP, SCP, et al.) under the hood is a different protocol from FTP entirely (though they can both support copying files).
See http://en.wikipedia.org/wiki/Secure_Shell
When dealing with SSH it's mainly happening on port 22, the server will first provide the connecting client a host-key (which can be used to validate that the server is actually the intended server; but this mechanism is not very well automated and usually just resorts to "ask the user if this 128bit hexadecimal string looks right"); then the client provides either username/password or private key based authentication credentials (or other mechanism if the client/server both support and choose it). SSH is extensible so that it can support many different types of encryption and authentication methods over time.
SSH's primary/original use was for opening a terminal prompt on the remote computer. It's main advantages were:
1) it was encrypted, authenticated, and supported various and extensible protocols
2) authentication could use either a username/password or a special private key file that the user had on their local (i.e. the initiating) computer
3) it additionally provided a basic means for authenticating that the server being connected to was actually the server intended (aka there was little chance there was a man-in-the-middle capturing the conversation/data stream).
In other words, it gave you an encrypted and more trustworthy way to "log in" to a text terminal on a remote computer very much like a direct VPN would.
Before long, people were using SSH to do specific tasks beyond just a text terminal, such as private VPNs between machines, file transfers, encrypted NAT/PORT redirection, remotely automated and secured jobs that didn't require some plaintext password be retrieved from a file somewhere (passwords that would get changed and the scripts have to be updated), and all manner of other nifty data transfer and automation tricks.
SSH has basically become an authenticated and encrypted swiss army knife of both TCP/IP and command level protocols depending on which one you need; and that doesn't necessarily require typing in a username and password every time it gets used to remotely connect. It also has some basic failsafes that prevent connection if any of the automated key mechanisms don't seem 100% kosher. So it is great for both automated, unattended tasks and for interactive log ins.
SSH's only main downside is that it is directly supported by pretty much every operating system/platform vendor on the planet except for Microsoft and that's what makes this SSH.Net project/library such a kick-ass and important piece of code and God bless all the people who are making it possible.
In fancy speak, create a connection to a remote server (an SshNet.SftpClient), using the connection information (SshNet.ConnectionInfo), giving it an Authentication Method (most likely a SshNet.PasswordAuthenticationMetod that takes a username and password). Or, if you want to be lazy about it and treat it just like FTP, use the SshNet.SftpClient constructor that takes the hostname, username, and password directly.
Once the SftpClient object has been instantiated with the appropriate ConnectionInfo; call its Connect() method.
Once the SftpClient is Connected, you can do lots of FTP like things; while SshNet supports lots of awesome Asynchronous callback methods which are great for GUIs (and tricky to implement properly so God bless them again!); it also supports several synchronous methods of interest like: DownloadFile("fileName", localFileStream), UploadFile(localFileStream, "fileName"), Get("fileName") (which gets detailed information about a file), and ListDirectory("path") which returns a List(Of SftpFile) object with all the files in "path" on the remote server.
Once you're done, call the SftpClient.Disconnect() method and Dispose() of the object (code with the "using" clause can skip these (especially dispose)).
Here's a brain dead example of synchronously downloading a file:
public void Sftp_Download_File()
{
using (var sftp = new SftpClient(Resources.HOST, Resources.USERNAME, Resources.PASSWORD))
{
sftp.Connect();
using (var fs = File.Create(@"C:\Temp\somefile.txt"))
{
sftp.DownloadFile("/somefile.txt", fs);
}
sftp.Disconnect();
}
}
Hope that helps get you started.
Cheers!
Mike