February 16, 2017

User's crontab

Per crontab man page:

Each user can have their own crontab, and though these are files in /var/spool/cron/crontabs, they are not intended to be edited directly.

Files under /var/spool are considered temporary/working and it's always a good practice to back up your cron entries or keep them in a file in your home directory.

I assume you're using crontab -e to create crontab files on the fly. If so, you can get a "copy" of your crontab file by doing crontab -l. Pipe that to a file to get a "backup":

crontab -l > my-crontab

Then you can edit that my-crontab file to add or modify entries, and then "install" it by giving it to crontab:

crontab my-crontab

This does the same syntax checking as crontab -e.

To list all cron jobs from all users in your system:

for user in $(cut -f1 -d: /etc/passwd)
do
  echo $user
  crontab -u $user -l
done

or

for user in $(cut -f1 -d: /etc/passwd)
do
  echo $user
  crontab -l $user 

done

February 15, 2017

Why am I still getting a password prompt with ssh with public key authentication

Following this tutorial : http://www.linuxproblem.org/art_9.html

Why am I still getting a password prompt with ssh with public key authentication?

Make sure the permissions on the ~/.ssh directory and its contents are proper. Create .ssh folder if it's not there yet. Same goes to authorized_keys file.

Your home directory ~, your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you:
rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good.
700 or 755, not 775

If ~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked.

Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400) but you probably need it to be also writable (600) if you will add any more keys to it.

Your private key file (on the local machine) must be readable and writable only by you: rw-------, i.e. 600.

Also, if SELinux is set to enforcing, you may need to run restorecon -R -v ~/.ssh (see e.g. Ubuntu bug 965663 and Debian bug report #658675; this is patched in CentOS 6).