> -----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
> UID PID PPID TTY STIME COMMAND
> 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
> UID PID PPID TTY STIME COMMAND
> 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:
[EMAIL PROTECTED] /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
[EMAIL PROTECTED] /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.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
