Posted: 6/4/2009 12:36:29 PM EDT
|
My company needs to setup an sftp server and I have a few questions I hope someone (Subnet) can answer... o Can the sftp software be installed on an existing ftp server with the *option* to use it? As in you can configure a website to not require SSL when its installed. o What sftp software would you recommend for a Windows 2003 Server? o What sftp software would you recommend for a free/linux setup (including linux distro)? o What sftp software would you recommend period, and if relevant, what O/S? |
|
First one thing needs to be clarified with this. Are you talking about FTP over SSH or FTP over SSL?
For a server on Windows I really like FileZilla Server, but Cygwin is also a possibility. Doing FTP over SSH on Linux is very easy. The only thing that you need to keep in mind is setting up a jail so that the users cannot SSH to the server if you only want them to be able to do file transfers. For server side, I really recommend doing this on Linux with the native capabilities. For client side, go with FileZilla's Client. Very nice and easy to use. -Mike |
|
Quoted: ... Are you talking about FTP over SSH or FTP over SSL? ... -Mike Why does it matter (as in I obviously don't understand the difference, I just need an ftp site with encrypted transmission)? Extra Info: We already have an ftp server for our clients to ul/dl files. We have some potential new clients that insist we use sftp. I'm trying to figure out if we can... o Use our existing server (Win2k3 w/ MS FTP) *without* forcing our current clients to use an sftp client. o Get a dedicated sftp server to support both client bases. o Force all customers to sftp. |
|
Quoted:
Quoted:
... Are you talking about FTP over SSH or FTP over SSL? ... -Mike Why does it matter (as in I obviously don't understand the difference, I just need an ftp site with encrypted transmission)? Extra Info: We already have an ftp server for our clients to ul/dl files. We have some potential new clients that insist we use sftp. I'm trying to figure out if we can... o Use our existing server (Win2k3 w/ MS FTP) *without* forcing our current clients to use an sftp client. o Get a dedicated sftp server to support both client bases. o Force all customers to sftp. FTP over SSL and FTP over SSH are different ways of doing secure FTP. The vast majority of people use FTP over SSH so we'll go with that. If you are currently a Windows Shop I would look at installing Cygwin on your server. This will allow you to have customers use FTP over SSH with very little work and no cost. Also, it will not require that they use the new FTP over SSH connection. They can still use clear text FTP if they want. If you want to have a dedicated server doing this you can do that easily enough with CentOS. If you want you could look into something like SliceHost where you can get a small CentOS box with a very fast internet connection so that you customers don't have to wait on whatever you have at your office. |
|
Quoted: This will allow you to have customers use FTP over SSH with very little work and no cost. Also, it will not require that they use the new FTP over SSH connection. They can still use clear text FTP if they want. OK, this sounds like exactly what I'm looking for. So to be clear (for me)... o Clear text clients would upload via ftp.yadayadayada.com o Secure text clients would upload (to the same physical server) via sftp.yadayadayada.com Is this correct? |
|
Quoted: FTP over SSL and FTP over SSH are different ways of doing secure FTP. It really should be thought of as FTP with SSL and FTP thru SSH. Semantics, I know. Or you could deploy IPv6 everywhere and use IPSec at the network layer.  Quoted: OK, this sounds like exactly what I'm looking for. So to be clear (for me)... o Clear text clients would upload via ftp.yadayadayada.com o Secure text clients would upload (to the same physical server) via sftp.yadayadayada.com Is this correct? They would still use the same FQDN for either: ftp.example.com What would be different is the port numbers. Really, read this http://en.wikipedia.org/wiki/File_Transfer_Protocol secure ftp section. There are 4 ways to do this, you don't need to know all 4, but you do need to know 1.  Gezz I come across as a dick.Fuck, even I'm confused now. |
|
Quoted:
Quoted:
This will allow you to have customers use FTP over SSH with very little work and no cost. Also, it will not require that they use the new FTP over SSH connection. They can still use clear text FTP if they want. OK, this sounds like exactly what I'm looking for. So to be clear (for me)... o Clear text clients would upload via ftp.yadayadayada.com o Secure text clients would upload (to the same physical server) via sftp.yadayadayada.com Is this correct? That isn't even necessary. The secure server would be listening on port 22 and the cleartext server would be on port 21 by default. The type of connection that the customer initiates would dictate whether they got a secure connection or not. |
|
Quoted:
Quoted:
FTP over SSL and FTP over SSH are different ways of doing secure FTP. It really should be thought of as FTP with SSL and FTP thru SSH. Semantics, I know. Or you could deploy IPv6 everywhere and use IPSec at the network layer.
Very true on all points. |
|
Just to add to the confusion, because I've had this requirement come up before (damn .gov customers...):
While you CAN have both FTP and SFTP on the same FQDN, using only the Port Number to separate them, you MAY have them on separate FQDNs also, just both will point to the same IP address. This allows people to feel good about not having both secure and insecure on the same FQDN, for whatever that is worth. They are still on the same server, served by the same IPv4 address, just listening on different ports. But having the separate DNS names ticks a box on someone's security checklist. It DOES also allow for a painless move of one or the other in the future if you find that you need to physically separate the secure and insecure FTP functions for some reason. I'm thinking future security requirements might dictate it at some point. Actually, in general, I am in favor of multiple FQDNs to support all functions at a site, even if they all currently point to the same box. It makes migration efforts MUCH less stressful in the future. Good Luck! FluxPrism |
|
Why would you give any user the option to use non-secure file transfer? If you have *any* non-secure protocol on that server, and standard ftp uses cleartext passwords, then there is very little point to offering secure services at all.
You are either secure, or you aren't. Given the option here, and if I were stuck on Windows, I'd run the ftp service on a VM server so you can re-provision the OS quickly. On linux, still running secure and non-secure services, I'd at least put the non-secure service on a loopback mount, or a FreeBSD jail. Finally, on any service accessed from outside the LAN (eg: The InterTubes...), don't run *any* service on privileged ports. Have all access to the server through NAT/PAT. See iptables. m |
