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

Discussion in 'Linux Networking' started by Matthew Lincoln, May 3, 2008.

  1. 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 Lincoln, May 3, 2008
    1. Advertisements

  2. man sftp
    Robert Heller, May 3, 2008
    1. Advertisements

  3. 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.
    Nico Kadel-Garcia, May 3, 2008
  4. 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

    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).
    Robert Heller, May 3, 2008
  5. 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.
    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.
    Nico Kadel-Garcia, May 3, 2008
  6. 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
    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, May 4, 2008
  7. 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.
    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, May 4, 2008
  8. You'd have to use an SSH tunnel, which gets fairly complicated (and requires
    you to have root on the server).
    You don't. ftp doesn't support SSL/TLS.

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

    Christopher Mattern

    Thank you for noticing this new notice
    Your noticing it has been noted
    And will be reported to the authorities
    Chris Mattern, May 4, 2008
  9. (Followup-To set)

    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:

    Other relevant links from David Wagner:

    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:
    all mail refused, May 4, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.