Par mesure de sécurité il est fortement conseillé d’exécuter ces crons sous un autre utilisateur que root. Dans le cas où vous faites de la maintenance sur des serveurs ne vous appartenant pas, cela devient vite un casse tête de trouver quel utilisateur exécute ces tâches ?

A titre de rappel, la commande pour lister les cron job de l’utilisateur courant :

# crontab -l

Pour lister les cron job d’un autre utilisateur que l’utilisateur courant :

# crontab -u nom_utilisateur -l

A condition toutefois d’avoir les droits de lecture sur le fichier, ce qui peut ne pas être le cas pour tous les utilisateurs.

Je vous propose de lister les tâches de tous les utilisateurs (listés dans /etc/passwd). Définissons un alias depuis l’utilisateur root :

# alias cronall='for user in $(cut -f1 -d: /etc/passwd); do echo -e "\n\n==> $user:" && crontab -u $user -l; done'

Il vous suffit ensuite de faire appel à cronall :

# cronall

==> root:
# m h  dom mon dow   command
30 23 * * * df >> test_blogmotion.fr

==> daemon:
no crontab for daemon

==> bin:
no crontab for bin

==> sys:
no crontab for sys

==> sync:
no crontab for sync

==> mail:
no crontab for mail

==> www-data:
no crontab for www-data

==> backup:
no crontab for backup

Les tâches sont listées par utilisateur, plutôt pratique. Dans mon cas, seul l’utilisateur root possédait un cron job.

Attention : ce script ne fonctionne pas sur les crons périodiques (cron.daily, cron.weekly, etc.) qui sont dans des répertoires distincts et non liés à un utilisateur mais au système. Pour lister ces crons une commande simple suffira pour trouver ce que vous cherchez :

cat /etc/cron.d/* | grep "votre recherche"

De même que pour lister tous les scripts (sans le contenu) :

ls -al /etc/cron.*

Source d’inspiration du premier script

Article original écrit par Mr Xhark publié sur Blogmotion le 13/11/2009 | 5 commentaires |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Principe

Il peut-être utile d’automatiser des transferts de fichiers de façon sécurisée entre deux machines fonctionnant sous une distribution Linux.

Vous pouvez par exemple créer des CRONS qui se chargeront d’effectuer un transfert via rsync, généralement utilisé pour créer des sauvegardes entre deux serveurs distincts.

Le principe reste le même : on établit une connexion SSH dans laquelle vont circuler les données (via rsync, scp ou sftp).

Une connexion SSH s’établit avec un nom d’utilisateur autorisé à se connecter en SSH sur la machine (voir sshd_config), ainsi qu’un mot de passe associé à ce compte. Un échange de clé publique s’effectue ensuite pour créer une connexion SSH sécurisée, plus d’infos chez Wikipedia.

Pour que la machine distante accepte une connexion sans mot de passe, il faut que le serveur distant possède la clé publique du serveur local (dans la liste des clés publiques autorisées à effectuer une connexion sans mot de passe).

Nota : toutes les commandes de ce guide ont été effectuées sous Debian Etch (4.0), mais elle restent valables sur de nombreuses distributions : Debian toutes versions, Red Hat, CentOS, etc.

Etape 1 : générer la clé publique (machine locale)

Connectez-vous en root sur la machine locale, puis générer la clé :

ssh-keygen -t dsa -b 1024

serveurlocal:# ssh-keygen -t dsa -b 1024
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): [TOUCHE ENTREE]
Enter passphrase (empty for no passphrase):[TOUCHE ENTREE]
Enter same passphrase again:[TOUCHE ENTREE]
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
44:f8:69:4b:ad:9f:bd:42:dd:3d:17:04:0d:f0:b9:81 root@serveurlocal
The key's randomart image is:
+--[ DSA 1024]----+
|       ..  ..o+  |
|      ..    o .o |
|       ..o E +.  |
|       .= .   o. |
|       oSo . o ..|
|        o . . ..o|
|         o o    o|
|          + .    |
|           ...   |
+-----------------+
serveurlocal:#

Attention : n’entrez aucun passphrase, validez par entrée. Si vous entrez un passphrase il devra être entré à chaque demande de connexion, nous perdons le bénéfice de l’automatisation

Cela va générer deux fichiers dans le répertoire /root/.ssh/ :

• id_dsa : la clé privée (à ne pas diffuser), appelée identification pour identité
• id_dsa.pub : la clé publique

Note : n’utilisez que des clés de 1024 bits maximum, vous pourrez sinon avoir le message d’erreur : « DSA keys must be 1024 bits ».

Etape 2 : transférer la clé publique dans le serveur distant

Plusieurs méthodes s’offrent à vous pour transférer la clé publique vers la machine distante, nous allons toutes les voir en détail.

Méthode A : Transfert via ssh-copy-id

La commande ssh-copy-id permet d’installer votre clé publique sur une machine distante :

serveurlocal:~# ssh-copy-id -i /root/.ssh/id_dsa.pub root@serveurdistant
root@serveurdistant's password:
Now try logging into the machine, with "ssh 'root@serveurdistant'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

serveurlocal:~#

L’intérêt de cette commande est double puisqu’elle place la clé directement dans le serveur distant et elle applique également les bons droits (chmod) sur le répertoire ~/.ssh ainsi que sur le fichier authorized_keys.

Liens utiles : QTH (pour ssh-copy-id)

Méthode B : Transfert via SCP

Pré-requis : connectez-vous en SSH sur le serveur distant, puis vérifiez que le répertoire ~/.ssh existe ainsi que le fichier authorized_keys Si ce n’est pas le cas, les créer  et appliquer les bons droits :

serveurdistant:# mkdir ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh

Vous pouvez ensuite envoyer la clé publique du serveur local en utilisant le de transfert SeCure coPy (SCP) :

scp ~/.ssh/id_dsa.pub root@serveurdistant:/root/clelocale.pub

serveurlocal:~# scp ~/.ssh/id_dsa.pub root@serveurdistant:/root/clelocale.pub
The authenticity of host 'serveurdistant (82.0.1.2)' can't be established.
RSA key fingerprint is 17:5d:99:24:b5:e1:b0:3a:98:e9:90:59:0d:1e:c6:9c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'serveurdistant,82.0.1.2' (RSA) to the list of known hosts.
root@serveurdistant's password:
id_dsa.pub                                                                     100%  608     0.6KB/s   00:00
serveurlocal:~#

A la question « Are you sure you want to continue connecting » bien répondre yes (en toutes lettres).

Ajoutons ensuite la clé dans le fichier ~/.ssh/authorized_keys :

cat /root/clelocale.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm -f /root/clelocale.pub

Liens : Joël Brogniart, NotMyIdea (Alexis Métaireau)

Méthode C : Transfert via SSH + commande (manuel)

Réservée aux geeks ultimes, cette technique permet en une ligne de commande de faire tout le boulot, elle ressemble un peu à la commande ssh-copy-id puisqu’elle permet d’écrire dans la valeur de la clé stockée localement dans le serveur distant

ssh root@serveurdistant "echo $(cat ~/.ssh/id_dsa.pub) >> .ssh/authorized_keys"

Pensez également à faire un coup de chmod par mesure de sécurité :

cat /root/clelocale.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm -f /root/clelocale.pub

Liens : Hostingrails, Ubuntu (ssh), Yoann’s Blog

Exemple de transfert via Rsync

Voici un exemple de transfert de fichier entre les deux machines grâce à Rsync, il ne faut pas oublier de préciser la clé publique dans la commande :

rsync -avz -e "ssh -i /root/.ssh/id_dsa" root@serveurdistant:/chemin/distant /chemin/local

Lien : Jdmz

Aspect sécurité

Je vous déconseille fortement d’utiliser ce genre de transfert directement avec l’utilisateur root, vous comprendrez que si la clé publique vous est dérobée (par un quelconque piratage de votre site/serveur) vous offrez une connexion à un second serveur en SSH sans mot de passe…

Je vous invite plutôt à créer un second utilisateur unix qui ne sera pas super-utilisateur, quitte à lui donner différents droits d’exécution via le fichiers sudoers. C’est aussi pour cela que j’ai assez insisté sur le chmod, qui ne rendra visible la clé publique que à l’utilisateur concerné : il serait impossible, en exploitant une quelconque faille d’un mauvais script PHP, de récupérer cette clé publique car l’utilisateur  exécutant sera celui d’apache (www-data ou httpd) et n’aura aucun droit dessus.

Je partagerai prochainement l’un de mes scripts à base de rsync qui exploite ces échanges SSH sans mot de passe

Note : le fichier ~/.ssh/authorized_keys ne doit contenir aucun retour chariot pour une même clé, mais uniquement pour séparer les différentes clés autorisée.

Article original écrit par Mr Xhark publié sur Blogmotion le 10/05/2009 | 32 commentaires |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

De cette façon vous pouvez programmer l’exécution d’une tâche via un script PHP par exemple (backup de votre base de donnée par exemple, envoie d’un mail à vos membres, etc).

Depuis le mois d’octobre, Webcron évolue vers des offres payantes. Les tarfis ne sont certes pas exhorbitants, mais vous ne souhaitez peut-être pas payer pour ce type de services.

Je vous propose deux alternatives : Hiwit et Cronjobs. Tous deux gratuits mais assez limité car ils proposent également une version payante…

Si vous cherchez une idée à développer, lancer vous dans les webcron

Article original écrit par Mr Xhark publié sur Blogmotion le 02/10/2008 | 3 commentaires |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons