This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Problems with ssh and tunnelling with cygwin 1.5.12

> -----Original Message-----
> From: cygwin-owner On Behalf Of Nick Wisniewski
> Sent: 15 November 2004 19:58

> > Is this really sh.exe?  Can you check whether this sh.exe process is
> > running before you start ssh (e.g., compare the outputs of 
> "ps -ef" before
> > and after "ssh -X")?
> before
> bash-2.05b$ ps -ef
>      Nick    2888       1 con  13:34:32 /usr/bin/bash
>      Nick    4052       1 con  13:37:33 /usr/bin/bash
>      Nick     236    4052 con  13:39:22 /usr/bin/ps
> after
> bash-2.05b$ ps -ef
>      Nick    2888       1 con  13:34:32 /usr/bin/bash
>      Nick    4052       1 con  13:37:33 /usr/bin/bash
>      Nick    3936    2888 con  13:40:16 /usr/bin/ssh
>      Nick    4012    3936 con  13:40:25 /usr/bin/sh
>      Nick     936    4052 con  13:40:29 /usr/bin/ps

> As I mentioned before, if I kill sh.exe from the task manager, 
> everything works fine (i.e. it finishes logging in and I can display 
> things from the remote machine).

  It has to be ssh trying to execute some system(..) call prior to opening the
connection, and the problem is with the command in question; that's hanging up,
openssh is waiting for it to complete.... boom!  Although I'm not familiar with
the source code and haven't studied it (and 'grep' is _not_ a source analysis
tool!), nonetheless a quick grep lends at least some support to this hypothesis:

dk@mace /usr/src/openssh-3.9p1-2> grep -w sh *.[ch]
auth.c:  * legal, and means /bin/sh.
defines.h:# define _PATH_BSHELL "/bin/sh"
pathnames.h: * /bin/sh before starting the shell or command if they exist.  They
 will be
session.c:       * legal, and means /bin/sh.
sshconnect.c:    * Use "exec" to avoid "sh -c" processes on some platforms
dk@mace /usr/src/openssh-3.9p1-2>

  That comment in sshconnect.c looks highly significant to me!

  You could probably strace openssh, then find out what parameters sh.exe is
being called with, and see if sh.exe shows the same behaviour when you try the
same command from a prompt.  I think the problem that needs tracking down will
turn out to be with the commands that openssh is relying on sh to execute,
rather than anything intrinsic to openssh itself.

  Actually strace probably isn't necessary.  I see lines like this

	debug("Executing proxy command: %.500s", command_string);

and oh look!  like this!

 * Run $HOME/.ssh/rc, /etc/ssh/sshrc, or xauth (whichever is found
 * first in this order).
static void
do_rc_files(Session *s, const char *shell)
	FILE *f = NULL;
	char cmd[1024];
	int do_xauth;
	struct stat st;

	do_xauth =
	    s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL;

	/* ignore _PATH_SSH_USER_RC for subsystems */
	if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st) >= 0)) {
		snprintf(cmd, sizeof cmd, "%s -c '%s %s'",
		    shell, _PATH_BSHELL, _PATH_SSH_USER_RC);
		if (debug_flag)
			fprintf(stderr, "Running %s\n", cmd);
		f = popen(cmd, "w");

which make me think you ought to just be able to run ssh with some debug options
on the command line, and that ought to give you enough information to find out
what's wrong.  Try "ssh -v -v -v <rest of options>" and see what that tells you.

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]