How to use command line (!) ftp WITH TLS resp SSH encryption?

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?

Matthew

At 03 May 2008 11:36:19 GMT (E-Mail Removed) (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
>

--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
(E-Mail Removed) -- Contract Programming: C/C++, Tcl/Tk

Robert Heller wrote:
> At 03 May 2008 11:36:19 GMT (E-Mail Removed) (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.

At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia <(E-Mail Removed)> wrote:

>
> Robert Heller wrote:
> > At 03 May 2008 11:36:19 GMT (E-Mail Removed) (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.
>

--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
(E-Mail Removed) -- Contract Programming: C/C++, Tcl/Tk

Robert Heller wrote:
> At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia <(E-Mail Removed)> wrote:
>
>> Robert Heller wrote:
>>> At 03 May 2008 11:36:19 GMT (E-Mail Removed) (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.
>>
>

On Sat, 03 May 2008 22:58:25 +0100, Nico Kadel-Garcia wrote:

> Robert Heller wrote:
>> At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia <(E-Mail Removed)>
>> wrote:
>>
>>> Robert Heller wrote:
>>>> At 03 May 2008 11:36:19 GMT (E-Mail Removed) (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.
>>>
>>>

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.

Dan Stromberg wrote:
> On Sat, 03 May 2008 22:58:25 +0100, Nico Kadel-Garcia wrote:
>
>> Robert Heller wrote:
>>> At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia <(E-Mail Removed)>
>>> wrote:
>>>
>>>> Robert Heller wrote:
>>>>> At 03 May 2008 11:36:19 GMT (E-Mail Removed) (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.
>>>>
>>>>
>
> 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.

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.

On 2008-05-03, Matthew Lincoln <(E-Mail Removed)> 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?

You'd have to use an SSH tunnel, which gets fairly complicated (and requires
you to have root on the server).

> How do I tell ftp to encrypt/decrypt the stream?

You don't. ftp doesn't support SSL/TLS.
>
> Is there an option like "-ssh" which does the job?

Nope.

However, SSH itself supports sftp, which is not in fact related to ftp,
but sports a similar interface.

>
> Matthew


--
Christopher Mattern

NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities

(Followup-To set)

On 2008-05-03, Nico Kadel-Garcia <(E-Mail Removed)> 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.

Perhaps the strategic equivalent of the above tactical error is that
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/

--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/