What happened to FTP over SSH?

[Jeff]

Hi,

I've been a long-time user of SecureFX, and I regularly use FTP over SSH. But it appears that this feature is gone from the latest BETA release of SecureFX!

Our company has a corporate gateway SSH server, and then a number of servers on the "inside" that only run FTP. So I've used FTP over SSH, and it works great!

Now that the feature is removed, what's the alternate mechanism to do this? FTP uses various ports, so it's difficult to know what to set up, up front.

Advice appreciated, thanks ...

[It's strange to see a new version that REMOVES a certain feature ...]

-- Jeff

[Maureen]

Jeff,

Thanks for your post. There are a couple of reasons why we dropped support for FTP over SSH2. One is that the way it was implemented made it harder for us to add IPv6 support. The other reason is that it was implemented, SFTP wasn't a standard yet, so it was a way to support secure file transfers until the SFTP draft was finalized.

FTP over SSH2 was dropped because our assessment was that not many of our customers were still using it. We will continue to support SecureFX 2.2 for at least another year. Depending on demand, we may add the equivalent functionality back, but so far, we've only had a handful of requests.

SecureCRT 5.0 (and Entunnel 1.2 - not yet out) support dynamic forwarding which allows you to proxy FTP over SSH2. Would this be possible work around for you?

Here is a link to a forum thread with a discussion about FTP over SSH2 that took place about a year ago, if you're interested.

http://forums.vandyke.com/showthread.php?t=137

Maureen

[scaturan]

why can't VanDyke release a slimdown version of SecureFX that supports only FTP over SSH2?

i'm responsible for http://negimaki.com/ and i have about 250+ users and increasing by the month which i have recommend SecureFX everytime a user signs up because it works with my setup. the SFTP protocol, which is an option and is widely used by competing OSS products like FileZilla doesn't work well.

i hope you will reconsider releasing such version.

thanks,

[jpv]

Originally Posted by scaturan

why can't VanDyke release a slimdown version of SecureFX that supports only FTP over SSH2?

i'm responsible for http://negimaki.com/ and i have about 250+ users and increasing by the month which i have recommend SecureFX everytime a user signs up because it works with my setup. the SFTP protocol, which is an option and is widely used by competing OSS products like FileZilla doesn't work well.

i hope you will reconsider releasing such version.

thanks,

Can you elaborate on what you're looking for?

SecueFX 2.2 is available and has FTP over SSH2 support. We will continue to support this version for at least the next 12 months.

Is directing your users to SecureFX 2.2 an option?

--Jeff

[scaturan]

Originally Posted by jpv

Can you elaborate on what you're looking for?

SecueFX 2.2 is available and has FTP over SSH2 support. We will continue to support this version for at least the next 12 months.

Is directing your users to SecureFX 2.2 an option?

--Jeff

thanks for the reply, Jeff.

basically, this is the default message i send to new account sign-ups for my portal.

"if you need to transfer files using FTP, you must install a client that supports "ftp over ssh2" protocol like SecureFX - download an evaluation copy at http://vandyke.com/download/securefx/index.html. sorry, my SFTP setup at this time is buggy so you can only login via "ftp over SSH2" to perform (secure) file transfers.

i hope SFX 2.2 be available in the coming years, or at least a slimdown version that supports "ftp over ssh2" - on my server, i've disabled direct FTP (port 21) due to random dictionary attacks so the only way for my users to get in is to use client like SecureFX which uses local port forwarding with "ftp over ssh2". sounds like anarchy, but i have to do it. my platform is FreeBSD 4.11 and by default, users "without" a valid login (eg. /sbin/nologin) will render SFTP with a million errors. 99.9% of my users have custom "/usr/local/bin/ftponly" shell. but FTP over SSH2 works great, no problems at all since "inetd" opens port 21 by default so port forwarding isn't a problem.

afaik, no existing OSS projects offer this functionality. only Tectia and SecureFX support it. it works for me and for a lot of my users. i've been thinking of buying multi-site licenses for my users but at this time, it'd be an overkill for my purposes and services.

i have a few dozen users who use Mac OS X and currently don't have an alternative. i think it's a platform you guys should get into because its gaining momentum. i'd recommend SecureFX to them if it worked for Mac OS X but for now, it looks like they're stuck.

[jad]

I recommend you solve this problem on the system side. From the sound of it, you need to investigate usage of one of the various sftp/scp "only" shells that are available.

There is rssh, chressh, as well as a couple of others (including my sftpsh.c, which is not presently on the web, but which I will gladly send to you).

This "problem" as you've described it sounds like an ideal candidate for one of these restricted access shells. At which point you could support scp/sftp, if the reasons you've given thus far are the only reasons preventing you.


Cheers,
Jason

[Jeff]

FTP over SSH2 was dropped because our assessment was that not many of our customers were still using it. We will continue to support SecureFX 2.2 for at least another year. Depending on demand, we may add the equivalent functionality back, but so far, we've only had a handful of requests.

In the published link, there were others that chimed in asking for FTP over SSH2. Add me to the list: the sole reason I originally purchased SecureFX is because of this feature. SFTP is available as freeware, and there are other free alternatives. FTP over SSH2 was the 'killer feature' that was ONLY available in SecureFX (and nothing else that I could find at the time).

SecureCRT 5.0 (and Entunnel 1.2 - not yet out) support dynamic forwarding which allows you to proxy FTP over SSH2. Would this be possible work around for you?

I'm desperate. I'll do anything that works, including dynamic forwarding. However, last time I looked at this (with VanDyke support), we were unable to make dynamic port forwarding work properly on v3.0 (build 842). There appears to be no way to specify the remote host to forward to (it gets grayed out).

So, I'm willing to look at dynamic forwarding if it works. Today, near as I can tell, it does not.

[jcj]

I'm desperate. I'll do anything that works, including dynamic forwarding. However, last time I looked at this (with VanDyke support), we were unable to make dynamic port forwarding work properly on v3.0 (build 842). There appears to be no way to specify the remote host to forward to (it gets grayed out).

Jeff -

If I understand what you're saying correctly, this behavior is by design.

You shouldn't need to directly specify the remote host when using the dynamic forwarding option.

Let's say you have machines A, B & C. Machine A runs SecureCRT 5.0 and SecureFX 3.0 . Machine B runs a SSH2 server, but not an FTP server, and does not have SFTP enabled. Machine C runs an FTP server. The goal is to set-up dynamic forwarding so that Machine A can use SecureFX and FTP to get to Machine C, by essentially using the SSH2 server on Machine B as a proxy.

On Machine A, you'll want to have two sessions open - one SecureCRT SSH2 session (Entunnel 1.2 would work as well), and one SecureFX FTP session. In addition, you'll want to create a new Firewall in Global Options/Firewall .

In SecureCRT (on Machine A), you should have a session configured with the following:

protocol: SSH2
hostname: MachineB.mycompany.com
Port Forward:
name: Local SOCKS5 (this can be any name you like)
port: 9999 (this can be any port as long as it's not in use already)
check: "Dynamic forwarding ..."

Now, in Global Options/Firewall (on Machine A), create your new firewall:

name: SOCKS on localhost (this can be any name you like)
type: SOCKS version 5 (no authentication)
hostname or IP: 127.0.0.1
port: 9999

Finally, in SecureFX (on Machine A), create a session configured with the following:

protocol: FTP
hostname: MachineC.mycompany.com
port: 21 (or whatever port the FTP server runs on on Machine C)
firewall: SOCKS on localhost

So, now, assuming you're connected with the SecureCRT session, and you then attempt to connect with the SecureFX session, you should ultimately land on the FTP server on Machine C.

Here's what the traffic might look like (assuming you have Trace Options enabled in SecureCRT):

SecureCRT:

[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT.
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = "SSH-2.0-VShell_2_4_0_15 VShell"
[LOCAL] : CAP  : Remote can re-key
[LOCAL] : CAP  : Remote sends language in password change requests
[LOCAL] : CAP  : Remote sends algorithm name in PK_OK packets
[LOCAL] : CAP  : Remote sends algorithm name in public key packets
[LOCAL] : CAP  : Remote sends algorithm name in signatures
[LOCAL] : CAP  : Remote sends error text in open failure packets
[LOCAL] : CAP  : Remote sends name in service accept packets
[LOCAL] : CAP  : Remote includes port number in x11 open packets
[LOCAL] : CAP  : Remote uses 160 bit keys for SHA1 MAC
[LOCAL] : CAP  : Remote supports new diffie-hellman group exchange messages
[LOCAL] : CAP  : Remote correctly handles unknown SFTP extensions
[LOCAL] : CAP  : Remote correctly sends UTF8 where UTF8 is specified
[LOCAL] : CAP  : Remote correctly encodes OID for gssapi
[LOCAL] : CAP  : Remote correctly uses connected addresses in forwarded-tcpip requests
[LOCAL] : CAP  : Remote is IETF-DRAFT compliant
[LOCAL] : CAP  : Remote VShell can do SFTP version 4
[LOCAL] : SEND : KEXINIT
[LOCAL] : RECV : Read kexinit
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE.
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
[LOCAL] : Selected Kex Method = diffie-hellman-group-exchange-sha1
[LOCAL] : Available Remote Host Key Algos = ssh-dss
[LOCAL] : Selected Host Key Algo = ssh-dss
[LOCAL] : Available Remote Send Ciphers = aes256-cbc,aes192-cbc,aes128-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour
[LOCAL] : Selected Send Cipher = aes128-cbc
[LOCAL] : Available Remote Recv Ciphers = aes256-cbc,aes192-cbc,aes128-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour
[LOCAL] : Selected Recv Cipher = aes128-cbc
[LOCAL] : Available Remote Send Macs = hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
[LOCAL] : Selected Send Mac = hmac-sha1
[LOCAL] : Available Remote Recv Macs = hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
[LOCAL] : Selected Recv Mac = hmac-sha1
[LOCAL] : Available Remote Compressors = none,zlib
[LOCAL] : Selected Compressor = zlib
[LOCAL] : Available Remote Decompressors = none,zlib
[LOCAL] : Selected Decompressor = zlib
[LOCAL] : SEND : KEXDH_GEX_REQUEST
[LOCAL] : RECV : KEXDH_GEX_GROUP
[LOCAL] : RECV : DH Prime is 2047 bits
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : RECV : KEXDH_REPLY
[LOCAL] : SEND : NEWKEYS
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_EXPECT_NEWKEYS.
[LOCAL] : RECV : NEWKEYS
[LOCAL] : Changing state from STATE_EXPECT_NEWKEYS to STATE_CONNECTION.
[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth]
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : SENT : USERAUTH_REQUEST [none]
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [keyboard-interactive,password,publickey]
[LOCAL] : SENT : USERAUTH_REQUEST [password]
[LOCAL] : RECV : AUTH_SUCCESS
[LOCAL] : SEND: Pty Request (row: 40, col: 132)
[LOCAL] : RECV: pty request succeeded
[LOCAL] : SEND: x11 forwarding request
[LOCAL] : RECV: x11 request succeeded
[LOCAL] : SEND: agent forwarding request
[LOCAL] : RECV: agent request succeeded
[LOCAL] : SEND: shell request
[LOCAL] : RECV: shell request succeeded
06/01 [1] MachineB:~ > [LOCAL] : Starting port forward from 127.0.0.1 on local 127.0.0.1:9999 to remote MachineC.mycompany.com:21. 
[LOCAL] : Starting port forward from 127.0.0.1 on local 127.0.0.1:9999 to remote MachineC.mycompany.com:8919. 
[LOCAL] : Starting port forward from 127.0.0.1 on local 127.0.0.1:9999 to remote MachineC.mycompany.com:8923. 
[LOCAL] : Starting port forward from 127.0.0.1 on local 127.0.0.1:9999 to remote MachineC.mycompany.com:8927.

SecureFX:

i Session 00002 established for session ftp_over_socks_test (1)
i SecureFX version 3.0.0.858 (Beta Release - June 2, 2005)
i Initializing Firewall[SOCKSv5]: 127.0.0.1:9999
i Control connection successfully established.
< 220 MachineC.mycompany.com FTP server (Version wu-2.4.2-academ[BETA-16](1) Thu May 7 23:18:05 EDT 1998) ready.
i Time zone of server could not be determined.
> USER username
< 331 Password required for username.
> PASS <password>
< 230 User username logged in.
> SYST
< 215 UNIX Type: L8
i Remote operating system type is UNIX.
> PWD
< 257 "/home/username" is current directory.
> TYPE A
< 200 Type set to A.
> PASV
< 227 Entering Passive Mode (192,168,0,x,34,185)

i Data connection 71AB3B91 connected.
> LIST
< 150 Opening ASCII mode data connection for /bin/ls.
< total 331
< drwxr-xr-x  18 username      users        2048 Apr 13 17:14 .
< drwxr-xr-x  35 root     root         1024 Apr  6  2001 ..
< -rw-------   1 username      users         404 Apr 13 17:12 .Xauthority
< -rw-r--r--   1 username      users         775 May 21  2001 .bash_history
< -rw-r--r--   1 username      users          26 Sep 22  2000 .login
< -rw-r--r--   1 username      users          42 Feb 14  2001 .rhosts
< drwxr-xr-x   2 username      users        1024 Sep  4  2002 .ssh
< -rw-r--r--   1 username      users         272 Sep 22  2000 .tcshrc
< -rwxr-xr-x   1 username      users          65 Sep 22  2000 .vimrc
< drwxr-xr-x   2 username      users        1024 Mar 23  2001 bin
< drwx------   2 username      users        1024 Jan 11  2000 mail
< drwxr-xr-x   2 username      users        1024 Feb  2  2001 public_html
< drwxr-xr-x   2 username      users        1024 Sep 22  2000 public_keys
< drwxr-xr-x   2 username      users        1024 Apr  9  2004 tmp
i Data connection 71AB3B91 closed normally.
< 226 Transfer complete.
> CWD /home/username/public_html
< 250 CWD command successful.
> TYPE A
< 200 Type set to A.
> PASV
< 227 Entering Passive Mode (192,168,0,x,34,198)
i Data connection 71AB3B91 connected.
> LIST
< 150 Opening ASCII mode data connection for /bin/ls.
< total 5
< drwxr-xr-x   2 username      users        1024 Feb  2  2001 .
< drwxr-xr-x  18 username      users        2048 Apr 13 17:14 ..
< -rwxr-xr-x   1 username      users          29 Jun 29  1999 index.html
< -rwxr-xr-x   1 username      users         757 Feb  2  2001 test.sh
i Data connection 71AB3B91 closed normally.
< 226 Transfer complete.
> Transfer(00BD0678): PASV
< Transfer(00BD0678): 227 Entering Passive Mode (192,168,0,x,34,200)
i Transfer(00BD0678): Data connection 71AB3B91 connected.
> Transfer(00BD0678): LIST test.sh
< Transfer(00BD0678): 150 Opening ASCII mode data connection for /bin/ls.
< Transfer(00BD0678): -rwxr-xr-x   1 username      users         757 Feb  2  2001 test.sh
i Transfer(00BD0678): Data connection 71AB3B91 closed normally.
< Transfer(00BD0678): 226 Transfer complete.
i Transfer(00BD0678): Opening file 'test.sh' for download as 'test.sh'.
> Transfer(00BD0678): PASV
< Transfer(00BD0678): 227 Entering Passive Mode (192,168,0,x,34,201)
i Transfer(00BD0678): Data connection 71AB3B91 connected.
> Transfer(00BD0678): RETR test.sh
< Transfer(00BD0678): 150 Opening ASCII mode data connection for test.sh (757 bytes).
i Transfer(00BD0678): Data connection 71AB3B91 closed normally.
< Transfer(00BD0678): 226 Transfer complete.
i Transfer(00BD0678): 788 bytes (of 757 bytes) transferred in 0.03 seconds (25.61 KB/s).
< 421 Timeout (900 seconds): closing control connection.
i Control connection closed normally.

Does this help ?

Please keep us informed.

Thanks~

~JcJ