How to use command line (!) ftp WITH TLS resp SSH encryption?
Matthew Lincoln
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?
Matthew
Robert Heller
man sftp
>
> Matthew
>
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Nico Kadel-Garcia
> At 03 May 2008 11:36:19 GMT kmlinc...@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.
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.
Robert Heller
>
> Robert Heller wrote:
> > At 03 May 2008 11:36:19 GMT kmlinc...@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.
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).
>
> 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.
>
--
Nico Kadel-Garcia
> At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia <nka...@gmail.com> wrote:
>
>> Robert Heller wrote:
>>> At 03 May 2008 11:36:19 GMT kmlinc...@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.
Dan Stromberg
ftp vs sftp - the choice is not 100% good and 100% bad, one consistently
preferable over the other. You need to be aware of the tradeoffs and
choose accordingly.
However, a program like http://sublimation.org/scponly/wiki/index.php/
Main_Page can help sftp considerably.
PS: There are actually SSL-capable ftp implementations, but they require
SSL support in both the client and server to be effective at encrypting.
Nico Kadel-Garcia
A chrooted restricted shell? Interesting! I hadn't seen that one. It basically
does what that that previous hook I mentioned to a manually built chroot cage
does, but with a restricted shell. It could be pretty nasty trying to put in
the various scriptable 'tar' or 'dd' operations mentioned by other folks in
some other recent threads.
> PS: There are actually SSL-capable ftp implementations, but they require
> SSL support in both the client and server to be effective at encrypting.
Yes, there's also WebDAV over HTTPS (which I believe I already mentioned).
Plenty of Java GUI clients clients, it's built into lftp, built into Windows
under the Network Neighborhood tools, and it's got manageable chroot cage
built behavior built right in. Quite useful.
Nico Kadel-Garcia
> (Followup-To set)
>
> On 2008-05-03, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>> 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.
>
> a process has authority derived almost entirely from who it runs as
> instead of from a definition of what it is supposed to be doing.
>
> Ivan's excellent foreword addresses this:
> http://wiki.laptop.org/go/OLPC_Bitfrost#Foreword
>
> Other relevant links from David Wagner:
> http://www.youtube.com/watch?v=EGX2I31OhBE
> http://www.cs.berkeley.edu/~daw/talks/TRUST07.pdf
>
> I could rustle up a few more links but the implication
> for ssh/sftp and most other software is that you have to work
> a great deal harder than you should to get reasonable security
> and even then it's usually not all that solid.
>
> There's a mailing list about this problem and the potential
> of capability-based designs to deal with it at:
> http://www.eros-os.com/pipermail/cap-talk/
Good followup-to set, thanks. And the links you provide do describe the issue
rather well, from somewhat different perspectives.