Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.networking > #4186 > unrolled thread

Need help with iptables and ftp

Started byT <T@invalid.invalid>
First post2018-08-24 15:39 -0700
Last post2018-08-31 12:30 +0000
Articles 16 on this page of 56 — 12 participants

Back to article view | Back to comp.os.linux.networking


Contents

  Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-24 15:39 -0700
    Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-24 16:11 -0700
    Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-25 07:23 +0000
      Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-25 23:13 -0700
        Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-08-26 11:35 +0200
          Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 14:05 -0700
            Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 00:02 +0000
              Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 17:11 -0700
                Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 02:00 +0000
                  Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 19:37 -0700
                  Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-26 22:59 -0400
                    Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 20:42 -0700
                      Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-27 00:29 -0400
                        Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 22:06 -0700
                          Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 09:47 +0000
                            Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-03 20:47 +0200
                    Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-27 09:44 +0000
                      Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-27 06:17 -0400
                      Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-27 12:21 -0700
                        Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-03 20:55 +0200
                    Re: Need help with iptables and ftp Scott Hemphill <hemphill@hemphills.net> - 2018-08-27 11:22 -0400
                    Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-27 12:18 -0700
            Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 17:44 -0700
        Re: Need help with iptables and ftp T <T@invalid.invalid> - 2018-08-26 17:43 -0700
    Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-28 11:28 +0000
      Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-29 05:38 +0000
        Re: Need help with iptables and ftp Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-08-29 10:13 +0300
        Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-29 09:52 +0000
          Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-29 12:13 +0000
            Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-29 12:27 +0000
              Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-29 11:14 -0400
                Re: Need help with iptables and ftp Aragorn <thorongil@telenet.be> - 2018-08-29 23:15 +0200
                Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-30 10:35 +0200
                  Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-30 13:16 +0000
                    Re: Need help with iptables and ftp Richard Kettlewell <invalid@invalid.invalid> - 2018-08-30 16:15 +0100
                    Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-30 18:42 +0200
                      Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-31 00:31 +0000
                        Re: Need help with iptables and ftp Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-08-31 05:49 +0000
                        Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-31 12:48 +0200
                          Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-31 22:11 +0000
                            Re: Need help with iptables and ftp Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-09-01 09:56 +0300
                              Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-01 16:14 +0200
                                Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-04 18:00 +0200
                                  Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-04 20:36 +0200
                                    Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-05 10:25 +0200
                                      Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-05 20:30 +0200
                                        Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-06 00:03 +0200
                      Re: Need help with iptables and ftp Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-01 15:56 +0200
                        Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-09-01 19:18 +0000
                          Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-09-04 18:01 +0200
                  Re: Need help with iptables and ftp William Unruh <unruh@invalid.ca> - 2018-08-31 00:25 +0000
                    Re: Need help with iptables and ftp "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-08-30 20:34 -0400
                    Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-31 09:25 +0000
                      Re: Need help with iptables and ftp Wouter Verhelst <w@uter.be> - 2018-08-31 12:50 +0200
                        Re: Need help with iptables and ftp Dan Purgert <dan@djph.net> - 2018-08-31 11:13 +0000
                      Re: Need help with iptables and ftp Allodoxaphobia <knock_yourself_out@example.net> - 2018-08-31 12:30 +0000

Page 3 of 3 — ← Prev page 1 2 [3]


#4240

FromTauno Voipio <tauno.voipio@notused.fi.invalid>
Date2018-09-01 09:56 +0300
Message-ID<pmdd7f$ajm$1@dont-email.me>
In reply to#4239
On 1.9.18 01:11, William Unruh wrote:
> On 2018-08-31, Wouter Verhelst <w@uter.be> wrote:
> :
>> FTP says "please open a new TCP connection on <addr:port> and dump your
>> data there". This is awful.
> 
> Why is this awful?

The address and port are inside the TCP message,
not only in the IP header. This makes it awful
to firewall and/or NAT.

-- 

-TV

[toc] | [prev] | [next] | [standalone]


#4242

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2018-09-01 16:14 +0200
Message-ID<5b8a9ece$0$21585$426a74cc@news.free.fr>
In reply to#4240
Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
> On 1.9.18 01:11, William Unruh wrote:
>> On 2018-08-31, Wouter Verhelst <w@uter.be> wrote:
>> :
>>> FTP says "please open a new TCP connection on <addr:port> and dump your
>>> data there". This is awful.
>>
>> Why is this awful?
> 
> The address and port are inside the TCP message,
> not only in the IP header. This makes it awful
> to firewall and/or NAT.

Indeed. It is a violation of the network layers separation.
Other protocols such as SIP (VoIP) do the same. Should it die too ?

Note that setting up separate control and data connections has 
advantages. It allows to do direct transfers between two FTP servers 
(FXP) controlled by a client. It allows SIP to set up direct media 
streams between the two peers.

[toc] | [prev] | [next] | [standalone]


#4254

FromWouter Verhelst <w@uter.be>
Date2018-09-04 18:00 +0200
Message-ID<1pm26f-c9n.ln1@gangtai.home.grep.be>
In reply to#4242
On 9/1/18 4:14 PM, Pascal Hambourg wrote:
> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>> On 1.9.18 01:11, William Unruh wrote:
>>> On 2018-08-31, Wouter Verhelst <w@uter.be> wrote:
>>> :
>>>> FTP says "please open a new TCP connection on <addr:port> and dump your
>>>> data there". This is awful.
>>>
>>> Why is this awful?
>>
>> The address and port are inside the TCP message,
>> not only in the IP header. This makes it awful
>> to firewall and/or NAT.
> 
> Indeed. It is a violation of the network layers separation.
> Other protocols such as SIP (VoIP) do the same. Should it die too ?

I'm well aware that SIP does that too. It has an excuse, in that for SIP
latency is everything, so I'm willing to cut it some slack there; but
for FTP, who gives a **** about latency?

> Note that setting up separate control and data connections has
> advantages. It allows to do direct transfers between two FTP servers
> (FXP) controlled by a client.

How many clients support that reliably?
How many FTP server configurations won't go coocoo when you try?
How often have you done this?

> It allows SIP to set up direct media
> streams between the two peers.

Yes, and there, because it reduces latency, it's a good idea. It causes
headache and annoyances, but the alternative is worse, so I'm willing to
ignore the annoyances.

Not so for FTP, though.

[toc] | [prev] | [next] | [standalone]


#4255

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2018-09-04 20:36 +0200
Message-ID<pmmjas$j4n$1@saria.nerim.net>
In reply to#4254
Le 04/09/2018 à 18:00, Wouter Verhelst a écrit :
> On 9/1/18 4:14 PM, Pascal Hambourg wrote:
>> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>>>
>>> The address and port are inside the TCP message,
>>> not only in the IP header. This makes it awful
>>> to firewall and/or NAT.
>>
>> Indeed. It is a violation of the network layers separation.
>> Other protocols such as SIP (VoIP) do the same. Should it die too ?
> 
> I'm well aware that SIP does that too. It has an excuse, in that for SIP
> latency is everything, so I'm willing to cut it some slack there; but
> for FTP, who gives a **** about latency?

What does latency have to do here ?

>> Note that setting up separate control and data connections has
>> advantages. It allows to do direct transfers between two FTP servers
>> (FXP) controlled by a client.
> 
> How many clients support that reliably?
> How many FTP server configurations won't go coocoo when you try?
> How often have you done this?

I do not remember ever trying it. This is probably not possible any more 
in the current state of the internet full of NATs and firewalls. I admit 
FXP is not a essential feature of FTP, merely a side effect. If you want 
to transfer files directly between two servers, just ssh into one and 
start the transfer from there.

[toc] | [prev] | [next] | [standalone]


#4256

FromWouter Verhelst <w@uter.be>
Date2018-09-05 10:25 +0200
Message-ID<4hg46f-ja7.ln1@gangtai.home.grep.be>
In reply to#4255
On 9/4/18 8:36 PM, Pascal Hambourg wrote:
> Le 04/09/2018 à 18:00, Wouter Verhelst a écrit :
>> On 9/1/18 4:14 PM, Pascal Hambourg wrote:
>>> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>>>>
>>>> The address and port are inside the TCP message,
>>>> not only in the IP header. This makes it awful
>>>> to firewall and/or NAT.
>>>
>>> Indeed. It is a violation of the network layers separation.
>>> Other protocols such as SIP (VoIP) do the same. Should it die too ?
>>
>> I'm well aware that SIP does that too. It has an excuse, in that for SIP
>> latency is everything, so I'm willing to cut it some slack there; but
>> for FTP, who gives a **** about latency?
> 
> What does latency have to do here ?

For FTP? Nothing. I'm willing to cut *SIP* some slack because it needs
to do those things for latency reasons, but that doesn't apply to FTP
(hence my "who cares" statement).

>>> Note that setting up separate control and data connections has
>>> advantages. It allows to do direct transfers between two FTP servers
>>> (FXP) controlled by a client.
>>
>> How many clients support that reliably?
>> How many FTP server configurations won't go coocoo when you try?
>> How often have you done this?
> 
> I do not remember ever trying it. This is probably not possible any more
> in the current state of the internet full of NATs and firewalls. I admit
> FXP is not a essential feature of FTP, merely a side effect. If you want
> to transfer files directly between two servers, just ssh into one and
> start the transfer from there.

Exactly, that's my point.

[toc] | [prev] | [next] | [standalone]


#4257

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2018-09-05 20:30 +0200
Message-ID<pmp7c8$1bc8$1@saria.nerim.net>
In reply to#4256
Le 05/09/2018 à 10:25, Wouter Verhelst a écrit :
> On 9/4/18 8:36 PM, Pascal Hambourg wrote:
>> Le 04/09/2018 à 18:00, Wouter Verhelst a écrit :
>>> On 9/1/18 4:14 PM, Pascal Hambourg wrote:
>>>> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>>>>>
>>>>> The address and port are inside the TCP message,
>>>>> not only in the IP header. This makes it awful
>>>>> to firewall and/or NAT.
>>>>
>>>> Indeed. It is a violation of the network layers separation.
>>>> Other protocols such as SIP (VoIP) do the same. Should it die too ?
>>>
>>> I'm well aware that SIP does that too. It has an excuse, in that for SIP
>>> latency is everything, so I'm willing to cut it some slack there; but
>>> for FTP, who gives a **** about latency?
>>
>> What does latency have to do here ?
> 
> For FTP? Nothing. I'm willing to cut *SIP* some slack because it needs
> to do those things for latency reasons, but that doesn't apply to FTP
> (hence my "who cares" statement).

Sorry for not being clear enough. I was wondering what passing address 
and port information over the control channel had to do with latency ?

[toc] | [prev] | [next] | [standalone]


#4258

FromWouter Verhelst <w@uter.be>
Date2018-09-06 00:03 +0200
Message-ID<he066f-531.ln1@gangtai.home.grep.be>
In reply to#4257
On 9/5/18 8:30 PM, Pascal Hambourg wrote:
> Le 05/09/2018 à 10:25, Wouter Verhelst a écrit :
>> On 9/4/18 8:36 PM, Pascal Hambourg wrote:
>>> Le 04/09/2018 à 18:00, Wouter Verhelst a écrit :
>>>> On 9/1/18 4:14 PM, Pascal Hambourg wrote:
>>>>> Le 01/09/2018 à 08:56, Tauno Voipio a écrit :
>>>>>>
>>>>>> The address and port are inside the TCP message,
>>>>>> not only in the IP header. This makes it awful
>>>>>> to firewall and/or NAT.
>>>>>
>>>>> Indeed. It is a violation of the network layers separation.
>>>>> Other protocols such as SIP (VoIP) do the same. Should it die too ?
>>>>
>>>> I'm well aware that SIP does that too. It has an excuse, in that for
>>>> SIP
>>>> latency is everything, so I'm willing to cut it some slack there; but
>>>> for FTP, who gives a **** about latency?
>>>
>>> What does latency have to do here ?
>>
>> For FTP? Nothing. I'm willing to cut *SIP* some slack because it needs
>> to do those things for latency reasons, but that doesn't apply to FTP
>> (hence my "who cares" statement).
> 
> Sorry for not being clear enough. I was wondering what passing address
> and port information over the control channel had to do with latency ?

Ah, yes. Sorry; I wasn't clear enough in explaining that, either :-)

That in and of itself doesn't. But the ability to make the media streams
go peer-to-peer, rather than have them be routed through whatever SIP
registry you're using, does; it means you don't need a round-trip to the
registry server and then another round-trip to the party you're having a
SIP communication with, but can instead have things go directly to the
other end of the communication; and that does cut latency.

[toc] | [prev] | [next] | [standalone]


#4241

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2018-09-01 15:56 +0200
Message-ID<5b8a9a89$0$11048$426a74cc@news.free.fr>
In reply to#4227
Le 30/08/2018 à 18:42, Wouter Verhelst a écrit :
> 
> but then sftp also isn't really FTP

SFTP is not FTP at all.
TFTP is not FTP either.
Any file transfer protocol is not FTP.

[toc] | [prev] | [next] | [standalone]


#4243

FromWilliam Unruh <unruh@invalid.ca>
Date2018-09-01 19:18 +0000
Message-ID<pmeomo$ph8$1@dont-email.me>
In reply to#4241
On 2018-09-01, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Le 30/08/2018 à 18:42, Wouter Verhelst a écrit :
>> 
>> but then sftp also isn't really FTP
>
> SFTP is not FTP at all.
> TFTP is not FTP either.
> Any file transfer protocol is not FTP.

Its name begs to differ.

[toc] | [prev] | [next] | [standalone]


#4253

FromWouter Verhelst <w@uter.be>
Date2018-09-04 18:01 +0200
Message-ID<erm26f-c9n.ln1@gangtai.home.grep.be>
In reply to#4243
On 9/1/18 9:18 PM, William Unruh wrote:
> On 2018-09-01, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>> Le 30/08/2018 à 18:42, Wouter Verhelst a écrit :
>>>
>>> but then sftp also isn't really FTP
>>
>> SFTP is not FTP at all.
>> TFTP is not FTP either.
>> Any file transfer protocol is not FTP.
> 
> Its name begs to differ.

Yes, but its implementation doesn't. The FTP over-the-wire protocol is
not even remotely similar to the one of SFTP or TFTP.

[toc] | [prev] | [next] | [standalone]


#4230

FromWilliam Unruh <unruh@invalid.ca>
Date2018-08-31 00:25 +0000
Message-ID<pma1t7$eo5$1@dont-email.me>
In reply to#4224
On 2018-08-30, Wouter Verhelst <w@uter.be> wrote:
> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>> As to the questions of why use ftp instead
>> of something secure, there are many times where publicly shared files
>> have no need for security, so ftp is the lowest overhead option for
>> those transfers.
>
> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
> all middle boxes for no particularly good reason.
>
> FTP must die.

Not before something equivalent replaces it. From when I have used http,
I have not beeen impressed.

But it is not clear to me what this "high overhead" is. Why is it any
higher than  one port? The packets have to be routed in any case, and
only the two end machines have to keep track of how the traffic on the
two routes relates to each other.

[toc] | [prev] | [next] | [standalone]


#4232

From"David W. Hodgins" <dwhodgins@nomail.afraid.org>
Date2018-08-30 20:34 -0400
Message-ID<op.zok47mi8a3w0dxdave@hodgins.homeip.net>
In reply to#4230
On Thu, 30 Aug 2018 20:25:11 -0400, William Unruh <unruh@invalid.ca> wrote:

> But it is not clear to me what this "high overhead" is. Why is it any
> higher than  one port? The packets have to be routed in any case, and
> only the two end machines have to keep track of how the traffic on the
> two routes relates to each other.

I find stream mode ftp transfers go much faster than http transfers.
https://en.wikipedia.org/wiki/File_Transfer_Protocol#Communication_and_data_transfer

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]


#4234

FromDan Purgert <dan@djph.net>
Date2018-08-31 09:25 +0000
Message-ID<slrnpoi2c6.u91.dan@xps-linux.djph.net>
In reply to#4230
William Unruh wrote:
> On 2018-08-30, Wouter Verhelst <w@uter.be> wrote:
>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>> As to the questions of why use ftp instead
>>> of something secure, there are many times where publicly shared files
>>> have no need for security, so ftp is the lowest overhead option for
>>> those transfers.
>>
>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>> all middle boxes for no particularly good reason.
>>
>> FTP must die.
>
> Not before something equivalent replaces it. From when I have used http,
> I have not beeen impressed.

Well, there is SFTP.  Other than using ssh transport, and "exit" rather
than "bye", it's pretty much identical.  Need to use an sftp-capable
client though (not 100% sure if web-browsers will play well with it,
though I've never tried).

>
> But it is not clear to me what this "high overhead" is. Why is it any
> higher than  one port? The packets have to be routed in any case, and
> only the two end machines have to keep track of how the traffic on the
> two routes relates to each other.

Spartknotes / pre-coffee version of the story is that you have two
sessions in conntrack (port 21 for the control session, and related-port
"whatever" for the data session).  It's mainly the two endpoints
(assuming the FTP server is behind NAT) that're getting this overhead
more than "everything" in the middle though.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]


#4236

FromWouter Verhelst <w@uter.be>
Date2018-08-31 12:50 +0200
Message-ID<45jn5f-vbr.ln1@gangtai.home.grep.be>
In reply to#4234
On 8/31/18 11:25 AM, Dan Purgert wrote:
> William Unruh wrote:
>> On 2018-08-30, Wouter Verhelst <w@uter.be> wrote:
>>> On 8/29/18 5:14 PM, David W. Hodgins wrote:
>>>> As to the questions of why use ftp instead
>>>> of something secure, there are many times where publicly shared files
>>>> have no need for security, so ftp is the lowest overhead option for
>>>> those transfers.
>>>
>>> No, HTTP is. FTP, with is two ports, incurs a high amount of overhead on
>>> all middle boxes for no particularly good reason.
>>>
>>> FTP must die.
>>
>> Not before something equivalent replaces it. From when I have used http,
>> I have not beeen impressed.
> 
> Well, there is SFTP.  Other than using ssh transport, and "exit" rather
> than "bye", it's pretty much identical.

Well, yes, the command line is. The on-the-wire protocol isn't, not even
remotely.

> Need to use an sftp-capable
> client though (not 100% sure if web-browsers will play well with it,
> though I've never tried).
> 
>>
>> But it is not clear to me what this "high overhead" is. Why is it any
>> higher than  one port? The packets have to be routed in any case, and
>> only the two end machines have to keep track of how the traffic on the
>> two routes relates to each other.
> 
> Spartknotes / pre-coffee version of the story is that you have two
> sessions in conntrack (port 21 for the control session, and related-port
> "whatever" for the data session).  It's mainly the two endpoints
> (assuming the FTP server is behind NAT) that're getting this overhead
> more than "everything" in the middle though.

Everything in the middle which needs to keep state needs to have the
overhead. It's useless and painful.

[toc] | [prev] | [next] | [standalone]


#4237

FromDan Purgert <dan@djph.net>
Date2018-08-31 11:13 +0000
Message-ID<slrnpoi8ni.u91.dan@xps-linux.djph.net>
In reply to#4236
Wouter Verhelst wrote:
> On 8/31/18 11:25 AM, Dan Purgert wrote:
>> William Unruh wrote:
>>> On 2018-08-30, Wouter Verhelst <w@uter.be> wrote:
>>>> No, HTTP is. FTP, with is two ports, incurs a high amount of
>>>> overhead on all middle boxes for no particularly good reason.
>>>>
>>>> FTP must die.
>>>
>>> Not before something equivalent replaces it. From when I have used http,
>>> I have not beeen impressed.
>> 
>> Well, there is SFTP.  Other than using ssh transport, and "exit" rather
>> than "bye", it's pretty much identical.
>
> Well, yes, the command line is. The on-the-wire protocol isn't, not even
> remotely.

Of course, but then I took William's "equivalency" need in terms of
usability / features rather than on-the-wire implementation :)


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]


#4238

FromAllodoxaphobia <knock_yourself_out@example.net>
Date2018-08-31 12:30 +0000
Message-ID<slrnpoid6f.u2a.knock_yourself_out@vps.jonz.net>
In reply to#4234
On Fri, 31 Aug 2018 09:25:26 -0000 (UTC), Dan Purgert wrote:
>
> Well, there is SFTP.  Other than using ssh transport, and "exit" rather
> than "bye", it's pretty much identical.  Need to use an sftp-capable
> client though (not 100% sure if web-browsers will play well with it,
> though I've never tried).

konqueror :  sftp://username:passwd@example.com/home/username

(The password is removed in the location bar after connect.)

Makes a GREAT inter-host file manager.

Jonesy -- Ubuntu + Trinity
-- 
  Marvin L Jones    | Marvin      | W3DHJ.net  | linux
   38.238N 104.547W |  @ jonz.net | Jonesy     |  FreeBSD
    * Killfiling google & XXXXbanter.com: jonz.net/ng.htm

[toc] | [prev] | [standalone]


Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.os.linux.networking


csiph-web