On 04/24/2012 01:38 PM, David C. Rankin wrote:
> I'm looking too. I'm reading the ssh man pages. I'm guessing that there is a
> separate call to ssh somewhere that causes ssh to return the port number for
> the host or that there is a way that this information is read 'on-the-fly'
> when 'ssh hostname' is given.

AARGH!!!

   We have been thinking about this thing 'bass-ackwards'. All sftp has to do 
is read what 'ssh' spits out upon connection. You don't care about reading any 
config files prior to calling 'ssh', 'ssh' takes care of that for you 
automagically!

   Think about it:

13:43 providence:~/tde/tmp/patch/tdebase/kioslave/sftp> ssh -v phoenix
OpenSSH_5.9p1, OpenSSL 1.0.1a 19 Apr 2012
debug1: Reading configuration data /home/david/.ssh/config
debug1: /home/david/.ssh/config line 36: Applying options for phoenix
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to phoenix [192.168.7.15] port 6630.
debug1: Connection established.

   When ssh is called, it reads BOTH /etc/ssh/ssh_config and ~/.ssh/config and 
acts accordingly. This means the only reason sftp://hostname fails when ssh is 
on a non-standard port is that the sftp:// code is NOT interpreting the ssh 
response correctly and is erroneously closing a perfectly good connection that 
ssh has established. Basically -- the sftp code just gets stuck waiting on 
some response that has changed in the new openssh -- doesn't know what to do 
with the response it gets -- and just sits there until it times out with an error.

   You will have to be the wizard that figures out where this happens, but is 
suspect it is in ksshprocess with the version tables that are set up at the 
top of the file :)

-- 
David C. Rankin, J.D.,P.E.