Problems with Port Forwarding and Password auth

Andy Hanson hanson at
Wed Jul 12 18:11:29 EST 2000

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

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

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

 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?


More information about the openssh-unix-dev mailing list