On Tue, Nov 13, 2018 at 8:56 AM Rich Shepard <rshep...@appl-ecosys.com> wrote:
> On Tue, 13 Nov 2018, Smith, Cathy wrote: > > > I apologize for intruding. > > Cathy, > > Apologies not necessary. > +1 to this: we just jump in whenever we feel we can be helpful. Occasionally this leads to confusion and chaos, but it's at least entertaining. > > I've been following this conversation and now I'm confused. Is the issue > > the use of keys to lock down access, or the use of rsync in general? > > The issue is that I set up ssh on the new desktop Saturday and it worked > to copy ~/ from the old desktop. Sunday, it failed to copy /opt/ from the > old desktop to the new one because of a permissions error (publickey). > > Also, I cannot ssh from the new desktop to the old one, but can the > other > direction. > > > Have you tried to run the rsync without the use of keys? > > No. I didn't know I could do this. > This is accomplished by re-configuring SSH to allow passwords instead of requiring only keys. > > Are you aware that rsync can be resumed? > > If you mean resuming a partial transfer, yes. If you mean resumeing > working at all, that's what I'm trying to do. > > > If you haven't checked, the perms on the .ssh directory should be 700. > > Yes, ~/.ssh has perms of 700. > Not only that, but the private key file must be mode 600 or ssh will refuse to read it. This is logged, though. -wes _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
