Using darcs 1.0.8.

I apologize in advance if this report is cryptic. I am not quite sure what's
causing the problem.

I am experiencing the following problem with my university host. I have no
troubles with other hosts:

When pushing to the repository over ssh, darcs prompts me if I want to push the
patch, and when I confirm, it immediately returns to prompt without any
success/error messages.

Further more, "darcs get" over ssh creates an empty dir with a basic initialized
repository - no files in it.

The symptoms described seem similar to issue155, but I have no problem using
both scp and sftp to access the remote machine.


To diagnose the problem, I executed the following tests:
1) Executed "push" with --disable-ssh-cm - Exactly the same behavior as before.
2) This works just fine:
$ darcs send -o bundle http://www.server.com/~user/my_repos
$ cat bundle | ssh user@server.com darcs apply --all --repodir 'my_repos'
3) I modified the ssh call to be more verbose:
{
hunk ./External.hs 666
-    return (ssh, "-q" : ssh_args ++ cm_args)
+    return (ssh, "-v" : "-v" : "-v" : ssh_args ++ cm_args)
}

The output of darcs push now was:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug2: Received EOF from master

Where a healthy server should print:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
Finished applying...
debug2: Received exit status from master 0
debug2: Received EOF from master

Hi,

Are you on Windows/Cygwin by any chance?

If so, http://bugs.darcs.net/issue218 might be relevant, although your
symptoms look quite different.

> $ darcs send -o bundle http://www.server.com/~user/my_repos
> $ cat bundle | ssh user@server.com darcs apply --all --repodir 'my_repos'

On Fri, Aug 11, 2006 at 01:47:46PM +0300, Ori Avtalion wrote:
> Does darcs transfer the patch bundle via ssh? If it does, I think I need
> to disable pseudo-tty allocation. I tried replacing "-t" with "-T" but
> it still gave the same "(scp) failed to fetch" error.

Yes, darcs does transfer the patch bundle using ssh.
-- 
David Roundy

> Are you on Windows/Cygwin by any chance?

I'm on Linux, and the server runs SunOS.
I compiled darcs myself locally, and the server is using the
statically-linked binary from
http://darcs.net/DarcsWiki/CategoryBinaries#head-6bb7f3e3e3428a27d7d37884bf66beb0d5fac5cb

Here's another test I did:

"ssh user@server.com darcs help" runs darcs successfully, but two lines
of "stty: : Invalid argument" are printed.

I read that to disable those the flag "-t" forces pseudo-tty allocation.
Modifying the SSH call to use "-t" has no effect. (In my previous try I
accidentally added "-t" to the scp command, which has no such flag - hence the
scp failure)

The ssh manpage says:
"If no pseudo-tty has been allocated, the session is transparent and can
be used to reliably transfer binary data."

According to that, the correct flag to use would be "-T", which disables stty
allocation. It also had no effect.

The problem was caused due to --disable-ssh-cm being broken. see issue239.

Actually, the two of us have been poking around.  It's a bit more complicated
than that.

1) --disable-ssh-cm wasn't working, which is why it didn't make a difference

2) when ControlMaster is enabled - the server side randomly closes the
connection -- darcs does _seem_ to relaunch the ControlMaster, probably because
the first one it launches exits cleanly

3) darcs does not seem to be catching scp/sftp errors completely

4) Even without control master (we commented out the CM bits of the code), sftp
has trouble connecting.  Not sure why.  Ori thinks it's something to do with
keyboard authentication.

There is also a bug I had introduced into unstable, namely that I try to pass -q
to all ssh commands, which is clearly bad because sftp does _not_ accept -q as a
flag.  So, any darcs command which uses sftp fails.

Apparently, the server I'm using starts acting weird when using ControlMaster.
After establishing a connection with:
$ ssh user@server.com -S /tmp/darcs-ssh/user@server.com -N -f -M
it will let one or two ssh-based commands to run with that ControlPath before
closing the connection.
Darcs identifies the closed connection and tries to set up the ControlMaster
again again... but only on the next command. It does not run the failed command
again.

This caused scp to fail getting the inventory file. It actually does do
something - it creates an empty file, which led to sftp running just the "cd
my_repos/_darcs/patches" command and succeeding in it.

darcs should do some sanity tests to see if the inventory file is not empty, and
maybe catch the disconnection problem (although it could be caused by an out of
date version on the server).

The problem was located by using a set of wrapper scripts for ssh, scp, and
sftp, and setting DARCS_S(CP|FTP|SH) accordingly.
I am attaching them here.

When I disabled the ControlMaster parameters by modifying the source, I had no
problem pushing patches into the remote repository. pushing uses scp to get the
inventory file, and ssh to run darcs apply. (I had to input my password for each
of these commands.)

Getting over the ssh connection failed.

The get over ssh sequence:
 * scp, to get the motd file
 * scp, to get the inventory file
 * sftp, to get all the patches listed in the inventory

The scp commands are interactive, and prompt for a password.
On the other hand, the sftp command is run using the -b flag and file with
commands. In that case, it prefers a non-interactive authentication method, such
as publickey.

When I run "darcs get user@server.com:my_repos" I get the error:
darcs failed:  (sftp) failed to fetch files.
source directory: my_repos/_darcs/patches
source files:
20060810230301-37f1f-e934b5619b4280bcf586700b64902490f1ccf294.gz
20060809223736-37f1f-d4fdd74d63d19350fc1bbb2bf4d6a1959624d827.gz
20060804225717-37f1f-afc10a07094744a38916873b499160c6b14a1f6d.gz
20060804181307-37f1f-5a98744731e7dcda065414bdae72c81f4b11a2bc.gz
20060801193729-37f1f-5e03b85d732f27d2b1ad09f59d96f7c4a85abff4.gz
and 42 more
sftp output:
Permission denied (publickey,password).
Couldn't read packet: Connection reset by peer

The authentication method that failed here was "publickey" (that's expected. I
didn't setup it). Even though it failed, sftp did not go on to try the
"password" method, that was used in the previous scp calls.

The sftp manpage vaguely hints that sftp *cannot* work interactively. I checked
the openSSH sources and it indeed blocks interactive prompting (even if
specifically stated using -oPasswordAuthentication=yes or
-oPreferredAuthentications=password).
I will email the openssh mailing list about it - It's a nice-to-have in darcs.

Attachments

• chatty_ssh_wrappers.tar.gz

I just discovered that sftp can be used interactively by passing the commands
file via stdin instead of the -b flag. Perhaps darcs' sftp handling could be
changed to that?

fixed in 1.0.9