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

This is a discussion on How to use command line (!) ftp WITH TLS resp SSH encryption? - SSH ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

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

  1. 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

  2. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    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
    >


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


  3. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    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.

    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.

  4. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia 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.

    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
    heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk


  5. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    Robert Heller wrote:
    > At Sat, 03 May 2008 15:04:16 +0100 Nico Kadel-Garcia 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.
    >>

    >


  6. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    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
    >> 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.
    >>>
    >>>


    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.

  7. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    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
    >>> 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.
    >>>>
    >>>>

    >
    > 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.

  8. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    (Followup-To set)

    On 2008-05-03, Nico Kadel-Garcia 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/

  9. Re: How to use command line (!) ftp WITH TLS resp SSH encryption?

    all mail refused wrote:
    > (Followup-To set)
    >
    > On 2008-05-03, Nico Kadel-Garcia 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/


    Good followup-to set, thanks. And the links you provide do describe the issue
    rather well, from somewhat different perspectives.

+ Reply to Thread