rsync/cron/ssh
 

Hi, I have a cron job which runs every night and rsyncs the contents of one area on disk to a similar area on another computer:

It stopped working last week and I get a mail message:
This computer is running Centos 6. The computer from which the files are being dragged runs Fedora 19. The key mentioned id_rsa was generated back in June using ssh-keygen when I installed F19. Is it relevant that the key was generated on Jun 7 which is approx 100 days before the problems started (Most days there is nothing to copy so no suggestion it did not work)? A quick search suggests keys generated by ssh-keygen has no expiry.

If I try to run the rsync job from the command line it works but asks for the password of 10.1.1.51. So it looks like there is a problem with the key?

I run an automatic yum update every night but I can't see any updates on either end to ssh.

Any other ideas why a key just stops working?

Thanks

Have you tried to run the script manually?

Are you facing same permission denied error when you run the script on terminal without getting your desired result?

I think you should try to generate authorized_keys on the server once again so when you will try to be inside of server, it will not ask password. If your public key(the client system) is changed somehow, the server will not let you in with saved authorized_keys file.

authorized_keys is a file which contains public key of your system (the client from where you are trying log-into server)

this smells of a permissions issue on either the backup computer (your CentOS box if i follow you correctly) and your host computer, the F19 box.

follow the links in my sig for detailed information on ssh keys and permissions required for all the files involved as well as the directories including the /home directory. if the permissions are wrong keyless access will FAIL.

a few other things to consider is to create a rolling log file that self cleans every 30-45 days or so.

so add a few lines like so:

note my variables are different then yours so please feel free to edit them as required. also note that I enclose all of my called variables inside {} this helps to prevent bad interpretation of the data I am trying to call.

my script cleans the log file up every 16 days, you could set yours to much long time for cleanup due to the limited size your rsync log will be. mine are rather large so i clean mine up more often then you might need require.

My thoughts exactly. Look at your destination computer. Make sure you $HOME directory is not writeable by anyone but yourself. Make sure the same is true for your .ssh subdirectory. And make sure your authorized_keys file is not writeable by others as well. It is unlikely that /home itself would be writeable by others unless root made a typo in some chmod command, but if so, that will cause ssh pubkey authentication errors as well.

Test by running ssh from your source computer to your destination computer with the -v (verbose) option. Look at your log fil on your destination computer (might be something like /var/log/auth.log, but depends on your distro). Note that file/directory permission issues like lleb mentioned do NOT give you helpful error messages in either the destination log files or in the output of ssh -v on the source end. Things just fail, and you're left wondering why. When that happens (no helpful log mesages), it is almost always a file/directory permissions issue on the destination computer.

Are you sure the IP address still points to the same computer?

thanks for the hints guys. I am no further forward but I now have something to work on. I have 2 connections where I use a public key. Let's say 61->51 does not work but 51->93 does work.

I thought of privileges but not in the .ssh directory. So I compared the contents of the .ssh directory on all these computers and the privileges look the same. Ditto the protection on .ssh in the home directory.

The "-v" switch on ssh gives me something to dig into. This throws up:

which again suggests something dodgy with the id_rsa file.

Like I say, I'll keep digging when I get a spare moment. There must be something obvious I can't see at the moment.

Cheers

Hi,

I think you should be looking at the log from sshd on the remote host. On centos this would be /var/log/secure. If you don't have permission to read this file, then you can start up your ownd sshd in debug mode on a higher numbered port and look at its output when you try to connect to it.

So in one terminal on the remote host:
If you get a /etc/ssh/sshd_config permission denied error, try with:
Then in another terminal on the localhost
and look at the output from sshd in the first terminal.

Evo2.

Hmmm, I have never used /var/log/secure before but that helps me solve this. I checked the log and got

I didn't check my home directory before as I really didn't think this would be the problem. /home/tim was set to 775 so I chmodded this to 770 and the key works now.

I can't work out how /home/tim got into that state and how long it has been like that. And why? I guess that is my problem to solve.

Anyway. SOLVED

Well, I was half right:
... and half wrong:
Looks like more recent versions of SSHD are indeed logging the permissions problems into their log files. SSHD didn't used to do this. At least not on Solaris, even recent versions of it, but I didn't checked on a recent Linux system for this lack of logging and I just "assumed". I know, I know - never assume anything!

You must have a typo there. If 775 didn't work, then 770 shouldn't have either. ??? 775 doesn't give "others" write permission to a directory any more than 770 does. 755 is a typical $HOME directory permission, or 700 if you are paranoid. 770 would be for "half paranoid" people.

typo I changed to 700

Hi,

I don't know what implementation of sshd is used on Solaris but most linux distros use openssh from openbsd. As far as I know it has always logged this stuff. IMHO, checking the sever logs when there are ssh problems is always the first thing to do. There are any number of things that can cause authentication problems, and it's no fun compiling a list of possible causes and then checking each one individually.

Cheers,

Evo2.

yup glad you found it. its exactly what i suspected.

http://wiki.linuxquestions.org/wiki/...reate_ssh_keys

see that link for permissions and proper settings on the keyless entry for ssh.

Thanks lieb. I plan to upgrade to F20 alpha shortly so these "how tos" are appreciated

keep in mind if you are using full disk encryption, there is a known bug with fedup that will cause you to fail the upgrade process. At least there was when F19 went live a few months back. I have not read/heard that it has been resolved yet.

There are work-a-arounds for partitions that are encrypted, but none that ive seen for full disk encryption.

if you are running full disk encryption, and why would you not, then you will need to backup up all of your /home or other personal files/folders/customization/etc... and perform a full fresh install.

As much as Id love to move to F20, im going to wait as all three of my laptops running F19 are currently running full disk encryption. Im not looking forward to those 3 full installs, so im hoping the Fedora devs can figure out how to get around the full disk encryption failures for fedup.