Can I tell Rsync to wait longer for a password when connecting to a remote system?

[Doug S]

It seemed to work for me. I did it just as a test, but otherwise agree with the comments from the others.
Anyway, I changed the sshd_config file as so:

doug@s19:~/config/etc/ssh$ diff -u sshd_config.24.04.original sshd_config
--- sshd_config.24.04.original  2024-09-02 10:58:17.367097735 -0700
+++ sshd_config 2024-09-03 20:11:45.040473573 -0700
@@ -29,7 +29,7 @@

 # Authentication:

-#LoginGraceTime 2m
+LoginGraceTime 1440m
 #PermitRootLogin prohibit-password
 #StrictModes yes
 #MaxAuthTries 6
doug@s19:~/config/etc/ssh$

And the connection status while the client rsync waits for the password:

doug@s19:/media/backup/backup/rpi3$ ss -o -t
State   Recv-Q   Send-Q Local Address:Port     Peer Address:Port           Process
ESTAB 0           52         192.168.111.136:ssh 192.168.111.122:54934 timer:(on,232ms,0)
ESTAB 0             0         192.168.111.136:ssh 192.168.111.122:63092 timer:(keepalive,119min,0)  <<< It is this one
ESTAB 0             0         192.168.111.136:ssh 192.168.111.122:50446 timer:(keepalive,87min,0)
doug@s19:/media/backup/backup/rpi3$

I'll edit this later with more entries, but it should wait for a day. I tested shorter timeouts already.

EDIT: The above was about 11 hours ago. I entered the password for the waiting rsync command just now and it worked fine.

[goemonburo]

Well, this is turning into quite the mess. I've configured passwordless login, for user A and user B on the remote machine, but when I try to run my rsync, it won't allow me to connect as root anymore...and if I can't connect as root, I don't have permissions to sync the files that I need to.

I think the issue is that a connection is fine if it's from my local machine as a normal user, but not as root. Do I repeat the passwordless login process AS ROOT as well? (For example, if I "sudo ssh-keygen" instead of just "ssh-keygen"?!)

Thank you!

[TheFu]

ssh-keygen just creates the keys. It has nothing to do with properly placing the key on the remote system, in the correct account. That's what ssh-copy-id does.

If you'd show your work, then we could have corrected the issue already.

Most people would create a different userid and allow that user to run sudo commands necessary for their backups without any password. But you should do it your way, until you get to that point and understand the risks of allowing any remote root access. I was careful with my wording above. I didn't say to use root for remote connections. I said

Normally, backups need to be performed as root

Perhaps I was too subtle in my wording. Sorry.

BTW, it would be a good idea NOT to use RSA ssh-keys. Use one of the others that are supported, then specifically push those non-RSA public keys to the correct account on the remote system.

[goemonburo]

Thank you for the additional suggestions. I don't know what "show my work" means, I did do the ssh-keygen and the ssh-copy-id, is there a command to run to show that?

Anyway, it's a step in the right direction. Thank you! I appreciate the help.

[TheFu]

I don't know what "show my work" means

Remember in math class when you'd just write the answer, "42" and you'd get 50% credit because you didn't show your work? Same thing.
If you don't show the EXACT commands
AND
the exact output, then you didn't show your work and we don't know what you did wrong or the hard way.

Saying it didn't work, but not showing your work means everyone has to guess. We are volunteers. Please don't make helping you so hard. Helping others is fun for us, but only when it isn't like digging a 30ft hole with a rake would do just as well.

[goemonburo]

Okay, then this is what I did:

ssh-keygen -f keyname

ssh-copy-id -i ~/.ssh/keyname user1@remote.ip.add.here
ssh-copy-id -i ~/.ssh/keyname user2@remote.ip.add.here

I can now successfully ssh without authenticating with a password to both user1 and user2.

But I cannot do that when I'm using "sudo ssh user1@remote.ip.add.here" I need to do this rsync as sudo so that it correctly accesses the folders and files. If I run it as a regular user, I get lots of permission errors.

Now when I try to run the program that used to work fine with "sudo" and prompt me for passwords, it instead says "Permission denied (publickey)."

Sounds like 1) you'd suggest not having run ssh-keygen as above but instead with one of the other options, and two, to create a separate user with sudo permissions (on the local? or remote? machine).

But ideally, I'm guessing that I need to somehow add another key or add the same key to a different place (root? sudo?) so that I can get passwordless authentication while in "sudo." I might be most of the way there (assuming I stick with RSA).

Thank you as always for help; I'm certainly not trying to make things difficult for anyone.

[TheFu]

Looks like you are missing the idea that sudo runs programs as a different userid.

sudo ls will first change to the root userid, change the HOME environment variable to whatever /etc/passwd says that the root userid should use for HOME, then run the 'ls' command. It doesn't run root's startup scripts. It doesn't change the directory. So, in your example, using sudo ssh user1@remote.ip.add.here, the keys used are pulled from $HOME/.ssh/id_rsa (the default) which is in /root/.ssh/id_rsa ... which isn't what you intended, I'm guessing.

On the remote machine, you are connecting with user1 ... so it looks in ~user1/.ssh/id_rsa.pub for the matching public key there. Was that what you wanted? Really?

BTW, most ssh-based tools will support the "verbosity" option. To see what is actually being used, just add -v and add more v's to get more verbose debug information. Normally, -vv is sufficient to understand what isn't working as expected, but -vvv will get enough details that it is usually too much.

I don't see why you'd want to use sudo on the local side, but not on the remote side too? Call me confused.

[goemonburo]

Thank you for the additional info.

I'm using "sudo" on the local server because when I do that, I don't get floods of error messages about files not being accessible. I believe that's because the user1 and user2 are different users than user1 on the local machine...but I don't know if that's true. But that's why I have been doing that.

It sounds like you're saying that sudo isn't working because it isn't getting a proper key pair. Could you explain what I need to do to set it up? Do I need to copy my local user1 key to root on remote system? Or do I create a root local key and copy it to the root remote?

[TheFu]

sudo used to start the command only impacts the local machine. It has no baring on the remote machine file/directory access.

You really should switch to doing system-level backups, not 1 user at a time. If you want to do 1-user at a time backups, then you need to setup those users on the local system too and use user1@local ---> user1@remote for those files only. Seems harder to me than using a real backup tool and running it with the needed privileges on both sides of the connection, but that's your choice.

[goemonburo]

All fine to suggest and any suggestions considered, but can we back up to answering the question: "How do I fix the Permission denied (publickey)"? That's really what I need.

I feel like I've come into a shop asking "How do I fix my scooter?" and am getting told "The best way is to buy this Lamborghini." Not trying to say that a Lamborghini won't fix the issues and might indeed be better than a scooter, but it's not what I'm trying to do and it's not what my question was. What was working was working great before, with the ONE issue that it required me to sit there and wait for it to chug through so I could supply the passwords...which I thought might be fixed by extending that timeout window.

Instead, I've gone through the process to make passwordless-ssh-authentication, but did that fix things? No. It created a different issue. And I'd ideally just like to fix the "Permission denied" error. I think if I can do that, then I'll be all set. My system for backups has been fine, it's been a stable, solid way to back up what I need to.

I don't really want to embark on a long road of replacing something that was working fine with a complicated system-level backup that I'll have to learn and which could easily have vastly MORE bugs and issues that I'll have to beg for help for.

Anyway, thanks again to all on this thread. It is probably frustrating to offer advice that isn't appreciated. But does anyone out there know what I need to do to fix a "Permission denied" error?
Alternatively, does anyone know how I can extend the ssh login time to something like...two hours? Either of those will easily answer my question.