From: Bob Harris on 29 Jun 2010 21:58 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 30 Jun 2010 07:07 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 30 Jun 2010 08:53 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 30 Jun 2010 09:00 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 30 Jun 2010 09:07 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
First
|
Prev
|
Pages: 1 2 Prev: Difference between VNC and Screen Sharing Next: Major problems with browsers and asda finance |