24 Apr
2012
24 Apr
'12
11:48 a.m.
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.