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.