openssh unix dev - Jul 2000 - Problems with Port Forwarding and Password auth

Secure FTP through SecureFX 1.8B3: issues  (Using OpenSSH 2.1.1p2)

I downloaded the latest SecureFX because it now claims support for OpenSSH. 
I'm
like cool, now I'll finally be able to secure my ftp on my gateway.

First off, I really like the new configure.  Everything went ok, I could ssh
into
the box just fine.  Unfortunately ftp didn't work work through SecureFX.   I
would
get this error back from OpenSSH "Opening channel administratively
prohibited bla
bla".  

The SecureFX people thought it meant I didn't have my ftp server working
right, but
that clearly wasn't true.  So I decided it was time to dig out the source. 
(I love
that about open source).  Anyways, after a few moments of checking, I was able
to
trace the problem down to this line in input_direct_tcpip()
...
 if (! no_port_forwarding_flag)
...

Basically the no_port_forwarding_flag was set to 0.  Which seemed odd because I
set
the GatewayPorts to yes, in the sshd_config.  So I look further, and it seems
that
the no_port_forwarding_flag only is set in one place inside sshd.  That is in
auth_parse_options().

Unfortunately auth_parse_options() is only called by user_dsa_key_allowed()
which is
in turn only called by ssh2_auth_pubkey() which due to this if statement in
input_userauth_request()

 if (pw && strcmp(service, "ssh-connection")==0) {
  if (strcmp(method, "none") == 0) {
   authenticated = ssh2_auth_none(pw);
  } else if (strcmp(method, "password") == 0) {
   authenticated = ssh2_auth_password(pw);
  } else if (strcmp(method, "publickey") == 0) {
   authenticated = ssh2_auth_pubkey(pw, service);
  }
 }

never gets called because it is authenticated by ssh2_auth_password() first.  So
in
effect, it is never possible for the no_port_forwarding_flag to be ==1.  

So, for a long story made short, setting the default value of
no_port_forwarding_flag=1 fixes my problem for SecureFX. But it seems to me that
the
problem goes deeper in that port forwarding does not seem to work under any
circumstance for password authentication.  Only authentication through public
keys
seems to allow it.

As a side question, that this process got me thinking about.  For password
authentication is the username/password pair encrypted using an RSA session key
through SSH v1 and v2?  Or is it encrypted through some other form?

Andy

Andy Hanson <hanson at phat.shugashack.com> writes:
> So, for a long story made short, setting the default value of
> no_port_forwarding_flag=1 fixes my problem for SecureFX. But it seems
> to me that the problem goes deeper in that port forwarding does not
> seem to work under any circumstance for password authentication.  Only
> authentication through public keys seems to allow it.
Yes, that's right.  We have customized OpenSSH 1.2.x for our own use
so that we have more control over port forwarding.  (Users do not have
shell accounts on the tunneling endpoint, so they cannot set up
tunnels on their own.)  While the patch primarily aims at fine-grained
control regarding to which hosts and ports can be tunneled, port
forwarding can be disabled on a per-user base as a side effect (and
not only on a per-RSA-key base, as with standard OpenSSH).

We can donate the patch to the OpenSSH team if there is any interest
(if some legal details with the univeristy administration can be
worked out, that is...)  The patch was developed on Linux, and has yet
to be tested in an IPv6 environment, though.

-- 
Florian Weimer 	                  Florian.Weimer at RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5