Robert Heller wrote:
> At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia <nkadel@gmail.com> wrote:
>
>> Robert Heller wrote:
>>> At 03 May 2008 11:36:19 GMT kmlincoln100@hotmail.com (Matthew Lincoln) wrote:
>>>
>>>> Ok, normally I can perform some (unencrypted) ftp operations by simply typing
>>>>
>>>> ftp .....
>>>>
>>>> But what if I want to do the same over an TLS/SSH encrypted ftp connection?
>>>> How do I tell ftp to encrypt/decrypt the stream?
>>>>
>>>> Is there an option like "-ssh" which does the job?
>>> man sftp
>>>
>>>> Matthew
>>>>
>> sftp *is not FTP*. It is functionally scp with a very limited FTP-like user
>> interface. It does not, and cannot, understand symlinks properly, which makes
>> it quite dangerous if you're not careful. sftp, at least on OpenSSH, has no
>> chroot cages available, which makes security a separate adventure.
>
> OTOH, sftp for most common uses (such as uploading HTML pages), sftp is
> secure. A properly secured site would not be allowing root to login
> (via ssh or otherwise). With correct file system permissions, there is
> generally no need for a chroot cage -- secure ftp uses a chroot cage
> because ftp is an inherently insecure protocol. I suspect that the OP
> should be able to do what he needs to do with sftp and/or scp and/or
> ssh.

This is the philosophy of some programmers. It is a major tactical error. I
cannot overstate this. By granting a user non-chrooted shell access, they can
do severe and random destrunction to the target system: The partitions
containing /tmp, /usr/tmp, and /var/tmp can be overflowed and cause damage
that is very difficult to control. They can poke around in any system file
that is not secured from non-root access, such as /etc/passwd, for the
grabbing of login names and charactistics. They can poke around in any
user-accessible shared files. If you run autofs, they can poke karound in
*other* system's SSH shared repositories.

sftp is fine for protecting the passwords of the user, but it is a nightmare
about providing undesirable access to the rest of hte operating system. I've
been harsh about this for years.

> The main problem with ftp outside of anonymous downloading, is the fact
> that the username and password are sent in clear text.

> symlinks can be handled using tar and ssh (gnu tar understands about
> symlinks and will preserve them).

Great, you've just eliminated the possibility of using a restricted shell for
your scp or sftp clients. That's.... how can I put this? It's leaving a shell
account, on your server, for anyone who wants to poke around. Relying on a
'properly secured server' in such circumstances is an amazingly bad idea in
this world of script kiddies and random crackers as opposed to hackers.

>
>> FTP has problems with the data and command streams being on different ports:
>> this makes encryption a bit of an adventure. If you need a reasonably safe,
>> encrypted, FTP or HTTP like access, I suggest using WebDAV over HTTPS,
>> supported by Apache, compatible with lots of GUI's, and compatible with lftp.
>>
>