Re: [PLUG] rsync: worked once now perms error [RESOLVED]

2018-11-13 Thread Rich Shepard

On Tue, 13 Nov 2018, David wrote:


Is it possible that your old system overwrote the keys from old system
during the first sync? If so, that would explain a lot, and you would have
the same happen again after this run completes.


dafr,

  I suppose anything's possible, but this has never before been an issue
when I've used rsync to transfer files between the old desktop and
portables, or between the desktop and external backup drive (dirvish uses
rsync).

Regards,

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error [RESOLVED]

2018-11-13 Thread David

On 11/13/18 2:03 PM, Rich Shepard wrote:

On Sun, 11 Nov 2018, Rich Shepard wrote:


Yesterday rsync copied ~/ from the current desktop (salmo) to the new
desktop (baetis) using this command from ~/ on the new desktop: rsync -av
salmo: .


   I gave up trying to find a reason for this behavior and re-ran 
ssh-keygen,
ssh-agent, and ssh-add. Now rsync is transferring files from the old 
desktop

to the new one. Perhaps this will stick.


Is it possible that your old system overwrote the keys from old system 
during the first sync? If so, that would explain a lot, and you would 
have the same happen again after this run completes.


dafr
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error [RESOLVED]

2018-11-13 Thread Rich Shepard

On Sun, 11 Nov 2018, Rich Shepard wrote:


Yesterday rsync copied ~/ from the current desktop (salmo) to the new
desktop (baetis) using this command from ~/ on the new desktop: rsync -av
salmo: .


  I gave up trying to find a reason for this behavior and re-ran ssh-keygen,
ssh-agent, and ssh-add. Now rsync is transferring files from the old desktop
to the new one. Perhaps this will stick.

  There are still wierd things going on, such as root being the only user
allowed to mount a usb flash drive that authorizes 'users' in fstab. Will
work on this as time permits.

Thanks everyone,

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-13 Thread wes
On Tue, Nov 13, 2018 at 8:56 AM Rich Shepard 
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


Re: [PLUG] rsync: worked once now perms error

2018-11-13 Thread Rich Shepard

On Tue, 13 Nov 2018, Smith, Cathy wrote:


I apologize for intruding.


Cathy,

  Apologies not necessary.


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.


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.

Regards,

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-13 Thread Smith, Cathy
I apologize for intruding.  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? 

Have you tried to run the rsync without the use of keys? 

Are you aware that rsync can be resumed?

If you haven't checked, the perms on the .ssh directory should be 700.



Cathy
-- 
Cathy L. Smith
IT Engineer

Pacific Northwest National Laboratory
Operated by Battelle for the 
U.S. Department of Energy

Phone: 509.375.2687
Fax:       509.375.4399
Email: cathy.sm...@pnnl.gov


-Original Message-
From: plug-boun...@pdxlinux.org [mailto:plug-boun...@pdxlinux.org] On Behalf Of 
Rich Shepard
Sent: Tuesday, November 13, 2018 5:54 AM
To: Portland Linux/Unix Group 
Subject: Re: [PLUG] rsync: worked once now perms error

On Mon, 12 Nov 2018, wes wrote:

> You said "rather than ssh" - did you test ssh again after you started 
> getting this error? What command and parameters do you use to make the 
> ssh connection?

wes,

   When rsync failed to connect Sunday I used 'ssh -vv ...' to test since 
adding the verbose switches to rsync did not provide useful output.

   Yesterday I tried rsync again; same failure.

   Today I will re-generate the public/private key pair (same pass phrase), 
copy the new public key to the old desktop's authorized_keys and expect that to 
resolve the issue.

   Perhaps there is no way to determine why rsync failed after spending a lot 
of time moving 89G across the cat5 cable. If a new key pair works perhaps it 
will keep working.

Regards,

Rich

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-13 Thread Rich Shepard

On Mon, 12 Nov 2018, wes wrote:


You said "rather than ssh" - did you test ssh again after you started
getting this error? What command and parameters do you use to make the ssh
connection?


wes,

  When rsync failed to connect Sunday I used 'ssh -vv ...' to test since
adding the verbose switches to rsync did not provide useful output.

  Yesterday I tried rsync again; same failure.

  Today I will re-generate the public/private key pair (same pass phrase),
copy the new public key to the old desktop's authorized_keys and expect that
to resolve the issue.

  Perhaps there is no way to determine why rsync failed after spending a lot
of time moving 89G across the cat5 cable. If a new key pair works perhaps it
will keep working.

Regards,

Rich

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-12 Thread wes
On Mon, Nov 12, 2018 at 11:09 AM Rich Shepard 
wrote:

> On Sun, 11 Nov 2018, Rich Shepard wrote:
>
> > Yesterday rsync copied ~/ from the current desktop (salmo) to the new
> > desktop (baetis) using this command from ~/ on the new desktop: rsync -av
> > salmo: .
>
>Today I tried using rsync again rather than ssh. I don't know where to
> look to see the error:
>

You said "rather than ssh" - did you test ssh again after you started
getting this error? What command and parameters do you use to make the ssh
connection?

-wes
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-12 Thread Rich Shepard

On Sun, 11 Nov 2018, Rich Shepard wrote:


Yesterday rsync copied ~/ from the current desktop (salmo) to the new
desktop (baetis) using this command from ~/ on the new desktop: rsync -av
salmo: .


  Today I tried using rsync again rather than ssh. I don't know where to
look to see the error:

$ rsync -av salmo:/opt/ .
Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.3]

  The rsync version installed on salmo (the receiver, I presume) is version
3.1.3. How would an issue with source code affect the compiled binary
(again, which worked last Saturday)?

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-11 Thread Tomas Kuchta
I would not think that you want to really set any directory in /opt as 777.

So that anything could write or delete stuff there.

-T

On Mon, Nov 12, 2018, 2:17 AM david  On 11/11/18 7:49 AM, Rich Shepard wrote:
> >Yesterday rsync copied ~/ from the current desktop (salmo) to the new
> > desktop (baetis) using this command from ~/ on the new desktop: rsync -av
> > salmo: .
> >
> >/opt on both hosts have perms 777.
> >
> >However, when I try to copy the /opt partition from salmo to baetis I
> > get
> > a permission denied (publickey) error. Running 'ssh -vv salmo' from the
> new
> > desktop shows sending and receiving packets with no issues until this:
> >
> > debug2: service_accept: ssh-userauth
> > debug1: SSH2_MSG_SERVICE_ACCEPT received
> > debug1: Authentications that can continue: publickey
> > debug1: Next authentication method: publickey
> > debug1: Offering ED25519 public key: /home/rshepard/.ssh/id_ed25519
> > debug2: we sent a publickey packet, wait for reply
> > debug1: Authentications that can continue: publickey
> > debug2: we did not send a packet, disable method
> > debug1: No more authentication methods to try.
> > Permission denied (publickey).
> >
> >Line 5 looks to be trying to send the private key rather than the
> public
> > key.
> >
> >Here's what I checked:
> >
> >1. Perms for both hosts' .ssh/ are 644 except for the private keys for
> >  which it is 600.
> >2. Both hosts have the other host's public key in
> > ~/.ssh/authorized_keys.
> >3. Both hosts have the other host recognized in ~/.ssh/known_hosts.
> >4. From salmo I can successfully connect to baetis,
> >
> >Since rsync worked on baetis yesterday to copy my home directory from
> > salmo I'm not seeing why today it will not copy /opt. And web searches
> > (almost all from ubuntu and github users) offered nothing different from
> > what I checked.
> >
> >A clue stick will help.
>
>
> A series of thoughts, but nothing specifically to help, sorry.
>
> Are you able to connect to salmo using the password, and is it
> configured to accept the ED25519 key format?
>
> Are both machines set up with the UID/GID values for the username in
> question? You can try specifying the username on the rsync call to be a
> bit more specific, too. (I don't expect this to be a problem, but worth
> looking at.)
>
> Also, even if /opt is set for 777, directories below that may not be,
> and that may be a cascading problem after the key issue is resolved.
>
> dafr
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-11 Thread Rich Shepard

On Sun, 11 Nov 2018, david wrote:


Are you able to connect to salmo using the password, and is it configured
to accept the ED25519 key format?


David,

  I use a passphrase and added it to ssh-agent yesterday. Both before and
after I was able to use rsync and scp to move files over from one to the
other.


Are both machines set up with the UID/GID values for the username in
question?


  Yep. Both have the same Slackware default numbers. And neither changed
overnight.


You can try specifying the username on the rsync call to be a bit more
specific, too. (I don't expect this to be a problem, but worth looking
at.)


  Nope. No differece.


Also, even if /opt is set for 777, directories below that may not be, and
that may be a cascading problem after the key issue is resolved.


  Tain't nuttin' there yet. That's why I want rsync to copy the contents
from the old desktop to the new desktop.

Thanks,

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


Re: [PLUG] rsync: worked once now perms error

2018-11-11 Thread david

On 11/11/18 7:49 AM, Rich Shepard wrote:

   Yesterday rsync copied ~/ from the current desktop (salmo) to the new
desktop (baetis) using this command from ~/ on the new desktop: rsync -av
salmo: .

   /opt on both hosts have perms 777.

   However, when I try to copy the /opt partition from salmo to baetis I 
get

a permission denied (publickey) error. Running 'ssh -vv salmo' from the new
desktop shows sending and receiving packets with no issues until this:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: /home/rshepard/.ssh/id_ed25519
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

   Line 5 looks to be trying to send the private key rather than the public
key.

   Here's what I checked:

   1. Perms for both hosts' .ssh/ are 644 except for the private keys for
 which it is 600.
   2. Both hosts have the other host's public key in 
~/.ssh/authorized_keys.

   3. Both hosts have the other host recognized in ~/.ssh/known_hosts.
   4. From salmo I can successfully connect to baetis,

   Since rsync worked on baetis yesterday to copy my home directory from
salmo I'm not seeing why today it will not copy /opt. And web searches
(almost all from ubuntu and github users) offered nothing different from
what I checked.

   A clue stick will help.



A series of thoughts, but nothing specifically to help, sorry.

Are you able to connect to salmo using the password, and is it 
configured to accept the ED25519 key format?


Are both machines set up with the UID/GID values for the username in 
question? You can try specifying the username on the rsync call to be a 
bit more specific, too. (I don't expect this to be a problem, but worth 
looking at.)


Also, even if /opt is set for 777, directories below that may not be, 
and that may be a cascading problem after the key issue is resolved.


dafr
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug


[PLUG] rsync: worked once now perms error

2018-11-11 Thread Rich Shepard

  Yesterday rsync copied ~/ from the current desktop (salmo) to the new
desktop (baetis) using this command from ~/ on the new desktop: rsync -av
salmo: .

  /opt on both hosts have perms 777.

  However, when I try to copy the /opt partition from salmo to baetis I get
a permission denied (publickey) error. Running 'ssh -vv salmo' from the new
desktop shows sending and receiving packets with no issues until this:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: /home/rshepard/.ssh/id_ed25519
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

  Line 5 looks to be trying to send the private key rather than the public
key.

  Here's what I checked:

  1. Perms for both hosts' .ssh/ are 644 except for the private keys for
which it is 600.
  2. Both hosts have the other host's public key in ~/.ssh/authorized_keys.
  3. Both hosts have the other host recognized in ~/.ssh/known_hosts.
  4. From salmo I can successfully connect to baetis,

  Since rsync worked on baetis yesterday to copy my home directory from
salmo I'm not seeing why today it will not copy /opt. And web searches
(almost all from ubuntu and github users) offered nothing different from
what I checked.

  A clue stick will help.

TIA,

Rich
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug