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

Reply via email to