Prev: Difference between VNC and Screen Sharing
Next: Major problems with browsers and asda finance
From: Paul Sture on 29 Jun 2010 13:24
Before I start pointing fingers I thought I'd ask here.

Yesterday I found that scp and rsync to my website don't work anymore. I
do have ssh access to the website, but it's hosted elsewhere.

Specifically:

scp -p MySshAccount:backups/* .

and

scp x.txt MySshAccount:somedir

both fail, chucking me back to the help for scp

rsync to back up my website contents to my local system gives me some
more useful info:

all the help rubbish, then:

rsync error: syntax or usage error (code 1) at main.c(1408)
[client=3.0.4]
rsync: connection unexpectedly closed (0 bytes received so far)
[receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(600)
[receiver=3.0.6]

However an ssh login in "don't need to supply the password mode) to my
web host still works.

I haven't changed anything on my PowerBook. To cut to the chase, how do
I determine whether my ISP or my web hosting provider have caused a
problem?

I should probably add that I have been using the same script files to
execute my scp and rsync commands on a ner daily basis for several months
now, without problems.

--
Paul Sture
From: Richard Maine on 29 Jun 2010 14:16
Paul Sture <paul.nospam(a)sture.ch> wrote:

> Yesterday I found that scp and rsync to my website don't work anymore. I
> do have ssh access to the website, but it's hosted elsewhere.
....
> rsync error: syntax or usage error (code 1) at main.c(1408)
> [client=3.0.4]
> rsync: connection unexpectedly closed (0 bytes received so far)
> [receiver]
> rsync error: error in rsync protocol data stream (code 12) at io.c(600)
> [receiver=3.0.6]
>
> However an ssh login in "don't need to supply the password mode) to my
> web host still works.

A bit of a shot in the dark, but I vagely recall that some problems of
this general type can happen if the remote shell startup outputs
messages. It is "normal" to get messages of various kinds during an
interactive login, but for a non-interactive one, the shell startup
ought to be "silent". If people put message-producing commands
unconditionally in inappropriate places in the shell startup scripts,
you can get errors like this. Interactive logins work fine and you just
see the messages, as you are presumably meant to. Non-interactive things
get messed up though by seeing the messages that are intended for humans
instead of for whatever protocol is involved.

Yes, the symptoms can show up after apparently working fine for a long
time. For example, an account that doesn't normally get mail can get a
piece and trigger a "You have mail" login message that causes the
problem.

I've no idea whether this is actually your problem. But the symptoms at
least sound vaguely familliar (from old non-Mac Unix experiences of
mine, but they would apply).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Geoffrey S. Mendelson on 29 Jun 2010 14:24
Paul Sture wrote:

>
> scp -p MySshAccount:backups/* .

Without looking too deeply, isn't it scp -p MySshAccount(a)hostname:backups/* .

or even better if you have a directory backups, it should be in quotes or your
shell will substitute the local file names if you have a file or directory
called MySshAccount or MySshaccount:hostname, which scp has a bad habit
of creating.

BTW, you don't need the user name, in ~/.ssh/config you can specify it there,
as in:

Host somehost
User MySshAccount
(other options)

Then you can just do scp hostname:files and it will get the user name
correctly.

You can also abbreviate it if you want by:

Host x
User MySshAccount
Hostname actual.hostname

Then you can scp x:files .

Geoff.


--
Geoffrey S. Mendelson, Jerusalem, Israel gsm(a)mendelson.com N3OWJ/4X1GM
I do multitasking. If that bothers you, file a complaint and I will start
ignoring it immediately.
From: Jolly Roger on 29 Jun 2010 16:07
In article <1jkuhgb.12dhw71spf4giN%nospam(a)see.signature>,
nospam(a)see.signature (Richard Maine) wrote:

> Paul Sture <paul.nospam(a)sture.ch> wrote:
>
> > Yesterday I found that scp and rsync to my website don't work anymore. I
> > do have ssh access to the website, but it's hosted elsewhere.
> ...
> > rsync error: syntax or usage error (code 1) at main.c(1408)
> > [client=3.0.4]
> > rsync: connection unexpectedly closed (0 bytes received so far)
> > [receiver]
> > rsync error: error in rsync protocol data stream (code 12) at io.c(600)
> > [receiver=3.0.6]
> >
> > However an ssh login in "don't need to supply the password mode) to my
> > web host still works.
>
> A bit of a shot in the dark, but I vagely recall that some problems of
> this general type can happen if the remote shell startup outputs
> messages.

That's precisely what I was about to suggest. I've seen login messages
on the remote side cause scp and other utilities like it to fail time
and again over the years.

--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR
From: Warren Oates on 29 Jun 2010 16:13
In article <jollyroger-4BF064.15073729062010(a)news.individual.net>,
Jolly Roger <jollyroger(a)pobox.com> wrote:

> That's precisely what I was about to suggest. I've seen login messages
> on the remote side cause scp and other utilities like it to fail time
> and again over the years.

This is from the rsync FAQ:

The "is your shell clean" message and the "protocol mismatch" message
are usually caused by having some sort of program in your .cshrc,
..profile, .bashrc or equivalent file that writes a message every time
you connect using a remote-shell program (such as ssh or rsh). Data
written in this way corrupts the rsync data stream. rsync detects this
at startup and produces those error messages. However, if you are using
rsync-daemon syntax (host::path or rsync://) without using a
remote-shell program (no --rsh or -e option), there is not remote-shell
program involved, and the problem is probably caused by an error on the
daemon side (so check the daemon logs).

A good way to test if your remote-shell connection is clean is to try
something like this (use ssh or rsh, as appropriate):

ssh remotesystem /bin/true > test.dat
That should create a file called test.dat with nothing in it. If
test.dat is not of zero length then your shell is not clean. Look at the
contents of test.dat to see what was sent. Look at all the startup files
on remotesystem to try and find the problem.
--
Very old woody beets will never cook tender.
-- Fannie Farmer
 |  Next  |  Last
Pages: 1 2
Prev: Difference between VNC and Screen Sharing
Next: Major problems with browsers and asda finance