From: Bob Harris on
In article <paul.nospam-75B656.19241729062010(a)pbook.sture.ch>,
Paul Sture <paul.nospam(a)sture.ch> wrote:

> 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.

Can you ssh into your remote account?

If you do not have ssh access, then try

scp -v -v -v ...the.rest.of.your.command...

The tripple -v's will provide tons of ssh debug output.

Do the same thing to a working system.

Compare the results and see where the failed system takes a
radical left turn.
From: Paul Sture on
In article
<nospam.News.Bob-084533.21585429062010(a)62-183-169-81.bb.dnainternet.fi>,
Bob Harris <nospam.News.Bob(a)remove.Smith-Harris.us> wrote:

> Can you ssh into your remote account?

Yes I can.

> If you do not have ssh access, then try
>
> scp -v -v -v ...the.rest.of.your.command...
>
> The tripple -v's will provide tons of ssh debug output.
>
> Do the same thing to a working system.
>
> Compare the results and see where the failed system takes a
> radical left turn.

Thanks.

Well waddyaknow! I was just about to try that, fished an scp command out
of my command history and it worked.

Someone somewhere has obviously fixed the problem.

--
Paul Sture
From: Paul Sture on
In article <slrni2keea.49h.gsm(a)cable.mendelson.com>,
"Geoffrey S. Mendelson" <gsm(a)cable.mendelson.com> wrote:

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

You are correct of course.

> 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.

Fortunately I don't have directories with those names, but I'll modify
my scripts to put the relevant bits in quotes.

> 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 .
>

Excellent tips. Thanks.

--
Paul Sture
From: Paul Sture on
In article <1jkuhgb.12dhw71spf4giN%nospam(a)see.signature>,
nospam(a)see.signature (Richard Maine) wrote:

> 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).

Interesting. I scrolled back to see if there is anything unusual the ssh
session I did yesterday. I did see this (it's a FreeBSD system at the
other end):

$ ssh me(a)hostname
UID must be less than 65536
Last login: Mon Jun 28 19:44:23 2010 from ...

but I also see that UID message today, and scp and rsync are working
fine.

It's certainly something to add to a troubleshooting checklist.

--
Paul Sture
From: Paul Sture on
In article <4c2a53f9$0$16659$c3e8da3(a)news.astraweb.com>,
Warren Oates <warren.oates(a)gmail.com> wrote:

> 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.

I've just tried that and it's clean now.

I can't wind time back on this to see if it was causing yesterday's
problem, of course.

Filed for future use, thanks.

--
Paul Sture