Re: Port-forwarding FTP
From: Dirk Munk (munk_at_home.nl)
Date: 10/17/03
- Next message: John Smith: "Re: OpenVMS in an HP advertisment"
- Previous message: Alan Adams: "Re: Latest VMS Critical Upgrade"
- In reply to: Michael T. Davis: "Re: Port-forwarding FTP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 17 Oct 2003 00:15:53 +0200
Michael T. Davis wrote:
The FTP client would be configured to
>>>establish passive transfer with the server and the SSH client would be
>>>invoked with something like this:
>>>
>>> ssh -L 21:<server-IP>:21 <server-IP>
>>
>>
>>The command is a bit wrong. It should be something like this:
>>
>>ssh -L2222:localhost:21 <server-IP>
>>
>>Localhost is IP number 127.0.0.1 as you will know, and 2222 is 'just' a port
>>number you can choose.
>
>
> If your concern is over the intervening space between "-L" and
> "21:...", it has not proved to be a problem (at least under CYGWIN). What's
> more, there's no reason for me to use a different local port number, since
> the client side doesn't have a FTP server and I'm running under an account
> with administrative access. Finally, localhost doesn't typically work as
> the target of the "-L" option when you're trying to port-forward passive FTP;
> you have to use the remote system's IP address or host name.
I don't understand this. The -L command should tell the local SSH client to
listen to port 2222 (in my example), then connect to the remote SSH server, and
tell this remote server to deliver the data to port 21 on its localhost.
> (At least, that was necessary under TCP/IP Services v5.1.) Regardless, no specification
> of "localhost", remote server IP (or host name), or even client IP (or host
> name) seems to help matters, now.
>
>
>>>From the client you have to start your ftp session like this:
>>
>>ftp localhost 2222
>
>
> ...Or, in my case, "ftp localhost 21."
>
> It seems that the engineers have addressed a security concern in
> TCP/IP Services for VMS v5.3 that was left open under v5.1. I have seen
> reference to this problem under other operating systems and FTP servers
> as I was researching this issue via Google. In some cases, the FTP server
> can be coerced to override the source check on the data stream, but as
> far as I can tell, the FTP server under TCP/IP Services can't.
>
>
>>By the way, TCP/IP V5.4 will have SSH as a standard part of the
>>distribution.
>>I'm trying the file test version right now.
>
>
> That sounds interesting. Does it support SSH levels 1 (1.5) and 2?
> (As you may know, Dave Jones' server only support level 1 [1.5].) Does
> it include a SSH client?
It is a SSH V2 server & client, based on the 'real' SSH from a Finish company.
>
>
>>>Now, the command connection still manages to connect, but my FTP client
>>>(WS_FTP) now reports the following problem after I connect, in response to a
>>>directory listing (LIST) request:
>>>
>>>425 Disallowing data connection for <client-IP>,4523
>>>
>>>(4523 is the randomly assigned client-side data port.) A direct connection
>>
>>to
>>
>>>our FTP server is completely successful, as always.
Perhaps you have to look at the -R command, and make the connection from the
server side ?
>>>
>>> Researching port-forwarding FTP in general, I discovered that newer
>>>FTP servers may not allow the above scenario to work. In particular, the
>>>FTP server checks to see what the source of the control connection is, and
>>>if it's different from the address specified as the client's data
>>
>>connection,
>>
>>>the server denies the request. This would seem to describe the behavior I'm
>>>seeing. In particular, since the control connection is forwarded via the
>>>server's IP address ("<server-IP>"), this is the address that the FTP server
>>>sees as the control connection source address, not "<client-IP>". As such,
>>>the FTP server denies the data request. If this is what's happening, is
>>>there any way to work around this restriction, apart from using either
>>>"direct FTP" or SCP/SFTP?
SCP and SFTP do only binary transfers. The SHH kit in TCP/IP V5.4 can only read
and write Stream_LF files (not the tradional 512 byte block binary files).
Furthermore SCP and SFTP do not run the login command file, which is a problem
in my view. It contradicts VMS standards (FTP in Unix does not execute login
command files either, but VMS does), and for me it makes it impossible to setup
the proper logicals for the destination of the data. In a future release their
may be an option to change this behaviour we have been told.
So I'm going to try the FTP tunneling. I hope to be able to report back sometime
next week about my progress.
>>>[...]
>
>
> Regards,
> Mike
> --
> Michael T. Davis | Systems Specialist: ChE,MSE
> E-mail: davism@er6.eng.ohio-state.edu | Departmental Networking/Computing
> -or- DAVISM+@osu.edu | The Ohio State University
> http://www.er6.eng.ohio-state.edu/~davism/ | 197 Watts, (614) 292-6928
- Next message: John Smith: "Re: OpenVMS in an HP advertisment"
- Previous message: Alan Adams: "Re: Latest VMS Critical Upgrade"
- In reply to: Michael T. Davis: "Re: Port-forwarding FTP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
