Impossible de se connecter à la machine distante à l'aide du script shell dans Crontab


11

Voici le script que j'essaie d'exécuter, qui s'exécute sans aucun problème

for i in `seq 200 2100`
do
  usr=(`ssh -t -t -o ConnectTimeout=60 machine$1 finger | tail -1 | awk '{print$1}'`) 
  echo $usr
done

Mais une fois que je l'ajoute à crontab, il ne me donne pas l'utilisateur.

22  12  *  *  *  sh /home/subrahmanyam/Scripts/who.sh

Veuillez donner votre avis .....

peut-être que cron demon est en cours d'exécution, nous devons donc inclure des binaires ...?


1
Autorisation refusée (publickey, gssapi-keyex, gssapi-with-mic, mot de passe). Autorisation refusée (publickey, gssapi-keyex, gssapi-with-mic, mot de passe). Autorisation refusée (publickey, gssapi-keyex, gssapi-with-mic, mot de passe).

Quelles sont vos intentions avec cela? Qu'essayez-vous d'accomplir. Juste pour que vous sachiez que nous ne pouvons pas aider sur toute activité malveillante si telle est votre intention
Timothy Frew

Réponses:


14

Vous pouvez établir des connexions ssh dans une session cron. Ce dont vous avez besoin est de configurer une authentification par clé publique pour avoir un accès sans mot de passe. Pour que cela fonctionne, vous devez avoir PubkeyAuthentication yesdans chaque serveur distant sshd_config.

Vous pouvez créer une paire de clés privée / publique avec ou sans phrase secrète. Si vous utilisez une phrase secrète (recommentée), vous devez également démarrer ssh-agent. Sans phrase secrète, il vous suffit d'ajouter le paramètre -i your_identity_fileà la sshligne de commande. sshutilisera $HOME/.ssh/id_rsapar défaut.

J'ai reproduit votre exemple en utilisant une paire de clés avec une phrase secrète. Voici comment je l'ai fait.

1) Création de la paire de clés avec phrase secrète. Enregistré la clé privée sous ~/.ssh/id_rsa_test, qui devrait avoir les autorisations correctes par défaut. Nous pouvons saisir une phrase secrète vide pour ne pas en utiliser une.

john@coffee:~$ ssh-keygen -N "somephrase" -f .ssh/id_rsa_test
Generating public/private rsa key pair.
Your identification has been saved in .ssh/id_rsa_test.
Your public key has been saved in .ssh/id_rsa_test.pub.
[snip]

2) Envoyé la clé publique aux serveurs, fait de même pour chacun d'eux. N'oubliez pas qu'ils doivent avoir PubkeyAuthenticationactivé.

john@coffee:~$ ssh-copy-id -i .ssh/id_rsa_test server1
The authenticity of host 'server1 (11.22.33.1)' can't be established.
RSA key fingerprint is 79:e8:0d:f5:a3:33:1c:ae:f5:24:55:86:82:31:b2:76.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,11.22.33.1' (RSA) to the list of known hosts.
john@server1's password: 
Now try logging into the machine, with "ssh 'server1'", and check in:

  .ssh/authorized_keys

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

3) Exécutez ssh-agent en tant que service avec -s. Cela ne le tuera pas si vous vous déconnectez. Sa sortie est un script shell valide, définissant l'environnement pour que le client ssh sache comment s'y connecter. Nous l'enregistrons dans un fichier (seule la première ligne est vraiment nécessaire).

john@coffee:~$ ssh-agent -s | head -n 1 > ssh-agent.cf 
john@coffee:~$ cat ssh-agent.cf 
SSH_AUTH_SOCK=/tmp/ssh-VhyKL22691/agent.22691; export SSH_AUTH_SOCK;

4) Chargé ce qui précède dans notre environnement actuel afin que nous puissions utiliser ssh-addpour ajouter notre clé privée à ssh-agent. la phrase secrète d'en haut.

john@coffee:~$ source ssh-agent.cf 
john@coffee:~$ ssh-add  .ssh/id_rsa_test
Enter passphrase for .ssh/id_rsa_test: 
Identity added: .ssh/id_rsa_test (.ssh/id_rsa_test)

5) Vérifié, il est ajouté.

john@coffee:~$ ssh-add -l
2048 96:58:94:67:da:67:c0:5f:b9:0c:40:9b:52:62:55:6a .ssh/id_rsa_test (RSA)

6) Le script que j'ai utilisé, légèrement modifié que le vôtre. Notez que je n'ai pas mis la commande ssh entre parenthèses et que je n'utilise pas plutôt des astuces $(), ce qui est une meilleure alternative pour la substitution de commandes (c'est bashcompatible, vous n'avez pas mentionné le shell que vous utilisez). J'ai utilisé exactement la même commande ssh que la vôtre.

john@coffee:~$ cat foo.sh 
#!/bin/bash

source /home/john/ssh-agent.cf
for server in server1 server2; do
    usr=$(ssh -t -t -o ConnectTimeout=60 $server finger | tail -1 | awk '{print $1}')
    date=$(ssh -o ConnectTimeout=60 $server date)
    echo "$server - $date - $usr" >> /home/john/foo.log
done

7) Mon crontab (notez que mon shest en fait bash)

john@coffee:~$ crontab -l
# m h  dom mon dow   command
*/1  *  *  *  *  sh /home/john/foo.sh

8) La sortie

john@coffee:~$ tail -n 4 foo.log
server1 - Wed Mar 23 14:12:03 EET 2011 - john
server2 - Wed Mar 23 14:12:04 EET 2011 - john
server1 - Wed Mar 23 14:13:03 EET 2011 - john
server2 - Wed Mar 23 14:13:04 EET 2011 - john

Le seul problème avec l'utilisation d'une phrase secrète est que vous devez la saisir manuellement au moins une fois. Ainsi, ce qui précède ne fonctionnera pas automatiquement après un redémarrage.


Merveilleux - merci. Je peux vivre avec le redémarrage automatique sans redémarrage pour l'instant, au moins.
Peter Mounce

Utilisez ssh-cron pour configurer des connexions SSH planifiées pour sécuriser les serveurs sans exposer vos clés SSH, mais en utilisant l'agent SSH. unix.stackexchange.com/questions/8903/…
Luchostein

4

Qui tape le mot de passe? Le travail cron ne peut pas atteindre votre agent ssh, donc la clé publique ne fonctionnera pas.

Vous devez fournir sshun fichier de clé explicitement (voir l' -ioption), car il ne peut pas interroger un agent; et cette clé doit avoir une phrase de passe vide.


Essayé en passant aussi le nom d'utilisateur et le mot de passe - ssh -t -t -o ConnectTimeout = 60 utilisateur @ machine $ 1 doigt | queue -1 | awk '{print $ 1}' </ home / user / passwd ---- je veux dire que le répertoire personnel est sur NFS, donc il se monte sur everymachine

Si ssh a un sens, il utilise /dev/ttypour lire le mot de passe au lieu de stdin; cela ne fonctionnera pas depuis cron.
geekosaur

J'ai essayé de donner l'option -i mais pas de chance! ---- ssh -o ConnectTimeout = 60 -i /home/subrahmanyam/.ssh/known_hosts machine $ 1 doigt | queue -1 | awk '{print $ 1}' ------ AVERTISSEMENT: FICHIER DE CLÉ PRIVÉE NON PROTÉGÉ! Les autorisations 0640 pour '/home/user/.ssh/known_hosts' sont trop ouvertes. Il est recommandé que vos fichiers de clés privées ne soient PAS accessibles aux autres. Cette clé privée sera ignorée. mauvaises autorisations: ignorer la clé:

Pourquoi se plaint-il known_hosts? Mais oui, vous devez faire attention aux autorisations - le fichier de clé privée doit être le mode 0600 ou même 0400, qui vous appartient. Si vous avez besoin d'un autre utilisateur pour pouvoir également l'utiliser, vous devrez vous pencher sur les ACL POSIX ou similaire.
geekosaur

À bien y penser, j'ai vu GSSAPI être offert là-bas, donc une autre possibilité est d'obtenir un keytab et de l'utiliser pour l' kinitintérieur du travail cron. Cela dit, les keytabs nécessitent également le même soin dans les autorisations; mais sshau moins ne s'en plaindra pas.
geekosaur

1

Plutôt que de stocker un fichier temporaire comme forcefsck, je préfère utiliser findpour rechercher sur l'agent actif.

Au sujet d'un script qui a besoin de ssh-agent, j'utilise:

export SSH_AUTH_SOCK=$(find /run/user/$(id -u)/ -mindepth 2 -maxdepth 2 -path '*keyring-*' -name 'ssh' -print -quit 2>/dev/null)

Il recherche le ssh-agentsocket et retourne le premier. Il est limité à l'utilisateur actuel, vous n'essaierez donc pas accidentellement d'utiliser un autre utilisateur et d'obtenir une erreur d'autorisation refusée. Vous devrez également être déjà connecté avec un actif ssh-agent. (Ubuntu démarre un agent au démarrage de l'interface graphique).

Si vous mettez cela dans un autre script, vous devrez l'appeler avec sourceou .parce qu'il doit définir la SSH_AUTH_SOCKvariable.


0

Utilisez ssh-cron pour configurer des connexions SSH planifiées pour sécuriser les serveurs sans exposer vos clés SSH, mais en utilisant l'agent SSH.


0

Vous pouvez exécuter votre script ou commande dans crontab comme:

0 * * * * bash -c -l "/home/user/sshscript.sh"

ou

0 * * * * bash -c -l "ssh root@yourhost 'echo $HOSTNAME'"
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.