On 04/24/2012 12:51 PM, Timothy Pearson wrote:
I am not convinced that kio_sftp (or kio_fish) reads ANYTHING from ~/.ssh/config, rather I suspect it relies on implicit ssh behavior when ssh is invoked in the background. Something probably changed there; I will look into the problem shortly.
Tim
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.
When I'm in a directory in the code line tdebase/kioslave/sftp -- is there some c++ 'tool' I can run that will scan the code and give me a representation of how the files and functions are called? Kind of like a process diagram? Something that says 'this file is executed first, second, etc..' That would really help me find my way around.
Especially with things like bool KSshProcess::setOptions(const SshOptList& opts) -- what the heck is SshOptList and where is it filled? That's the type question that really hangs me up. I can grep it, but that doesn't help 90% of the time.
ksshprocess seems to talk the most about setting up the connection. eg:
ksshprocess.h
* To setup a SSH connection first create a list of options to use and tell * KSshProcess about your options. Then start the ssh connection. Once the * connection is setup use the stdin, stdout, stderr, and pty file descriptors * to communicate with ssh. For a detailed example of how to use, see * ksshprocesstest.cpp.
ksshprocess.cpp
* To start ssh we take the arguments the user gave us * in the SshOptList and build the ssh command arguments based on the version * of ssh we are using. This command and its arguments are passed to * PTYProcess for execution. Once ssh is started we scan each line of input * from stdin, stderr, and the pty for recognizable strings. The recognizable * strings are taken from several string tables. Each table contains a string * for each specific version of ssh we support and a string for a generic * version of OpenSSH and commercial SSH incase we don't recognized the * specific ssh version strings (as when a new SSH version is released after * a release of KSshProcess). There are tables for ssh version strings, * password prompts, new host key errors, different host key errors, * messages than indicate a successful connect, authentication errors, etc. * If we find user interaction is necessary, for instance to provide a * password or passphrase, we return a err code to the user who can send * a message to KSshProcess, using one of several methods, to correct * the error.
I have no doubt you will find the key to unlock the chest far before I do...