No se puede ingresar a la máquina remota mediante el script de shell en Crontab

11

A continuación se muestra el script que estoy tratando de ejecutar, que se ejecuta sin ningún problema.

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

Pero una vez que lo agrego a crontab, no me da el usuario.

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

Por favor, da tus pensamientos .....

puede que se esté ejecutando cron demon, por lo que debemos incluir algunos archivos binarios ...

Gilles 'SO- deja de ser malvado'
fuente
1
Permiso denegado (publickey, gssapi-keyex, gssapi-with-mic, contraseña). Permiso denegado (publickey, gssapi-keyex, gssapi-with-mic, contraseña). Permiso denegado (publickey, gssapi-keyex, gssapi-with-mic, contraseña).
¿Cuáles son tus intenciones con esto? Qué estás intentando lograr. Solo para que sepa que no podemos ayudarlo en ninguna actividad maliciosa si esa es su intención
Timothy Frew

Respuestas:

14

Puede hacer conexiones ssh dentro de una sesión cron. Lo que necesita es configurar una autenticación de clave pública para tener acceso sin contraseña. Para que esto funcione, debe tener PubkeyAuthentication yesen cada servidor remoto sshd_config.

Puede crear un par de claves privadas / públicas con o sin frase de contraseña. Si usa una frase de contraseña (recomendada), también debe iniciar ssh-agent. Sin una frase de contraseña, solo necesita agregar el parámetro -i your_identity_filea la sshlínea de comando. sshse usará $HOME/.ssh/id_rsapor defecto.

Repliqué tu ejemplo usando un par de claves con una frase de contraseña. Así es como lo hice.

1) Creó el par de claves con frase de contraseña. Guardado la clave privada como ~/.ssh/id_rsa_test, que debería tener los permisos correctos por defecto. Podemos ingresar una frase de contraseña vacía para no usar una.

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) Envió la clave pública a los servidores, hizo lo mismo para todos ellos. Recuerde que necesitan tener PubkeyAuthenticationhabilitado.

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) Ejecute ssh-agent como servicio con -s. Esto no lo matará si cierra sesión. Su salida es un script de shell válido, que configura el entorno para que el cliente ssh sepa cómo conectarse a él. Lo guardamos en un archivo (solo se necesita la primera línea).

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) Cargué lo anterior en nuestro entorno actual para que podamos usarlo ssh-addpara agregar nuestra clave privada ssh-agent. la frase de contraseña de arriba.

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) Verificado se agrega.

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) El script que utilicé, ligeramente modificado que el tuyo. Tenga en cuenta que no incluí el comando ssh entre paréntesis y no utilicé backticks $(), que es una mejor alternativa para la sustitución de comandos (esto es bashcompatible, no mencionó qué shell está usando). Usé exactamente el mismo comando ssh que el tuyo.

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) Mi crontab (tenga en cuenta que mi shes realmente bash)

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

8) La salida

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

El único problema con el uso de una frase de contraseña es que debe ingresarla manualmente al menos una vez. Por lo tanto, lo anterior no funcionará automáticamente después de un reinicio.

forcefsck
fuente
Maravilloso, gracias. Puedo vivir sin reinicio automático después de reiniciar por ahora, al menos.
Peter Mounce
Use ssh-cron para configurar conexiones SSH programadas para proteger los servidores sin exponer sus claves SSH, pero usando el agente SSH. unix.stackexchange.com/questions/8903/…
Luchostein
4

¿Quién escribe la contraseña? El trabajo cron no puede llegar a su agente ssh, por lo que la clave pública no funcionará.

Debe proporcionar sshun archivo de clave explícitamente (consulte la -iopción), ya que no puede consultar a un agente; y esa clave debe tener una frase de contraseña vacía.

geekosaur
fuente
Intentó pasar el nombre de usuario y la contraseña también - ssh -t -t -o ConnectTimeout = 60 usuario @ máquina $ 1 dedo | cola -1 | awk '{print $ 1}' </ home / user / passwd ---- me refiero a que el directorio de inicio está en NFS, por lo que se monta en todos los equipos
Si ssh tiene algún sentido, se usa /dev/ttypara leer la contraseña en lugar de stdin; eso no funcionará desde cron.
geekosaur
Intenté dar -i opción pero no suerte! ---- ssh -o ConnectTimeout = 60 -i /home/subrahmanyam/.ssh/known_hosts machine $ 1 dedo | cola -1 | awk '{print $ 1}' ------ ADVERTENCIA: ¡ARCHIVO DE CLAVE PRIVADA SIN PROTECCIÓN! Los permisos 0640 para '/home/user/.ssh/known_hosts' están demasiado abiertos. Se recomienda que otras personas no puedan acceder a sus archivos de clave privada. Esta clave privada será ignorada. malos permisos: ignorar clave:
¿Por qué se queja known_hosts? Pero sí, debe tener cuidado con los permisos: el archivo de clave privada debe ser el modo 0600 o incluso 0400, de su propiedad. Si necesita otro usuario para poder usarlo también, tendrá que buscar en ACL POSIX o similar.
geekosaur
Ahora que lo pienso, vi que se ofrecía GSSAPI allí, así que otra posibilidad es obtener una pestaña y usarla kinitdentro del trabajo cron. Dicho esto, las pestañas también requieren el mismo cuidado en los permisos; pero sshal menos no se quejarán de ellos.
geekosaur
1

En lugar de almacenar un archivo temporal como forcefsck lo hizo, prefiero usar findpara buscar en el agente activo.

En el tema de un script que necesita ssh-agent, utilizo:

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

Busca el ssh-agentzócalo y devuelve el primero. Está restringido solo al usuario actual, por lo tanto, no intentará accidentalmente utilizar a otros usuarios y obtendrá un error de permiso denegado. También deberías haber iniciado sesión con un activo ssh-agent. (Ubuntu inicia un agente cuando se inicia la GUI).

Si coloca esto en otro script, deberá llamarlo con sourceo .porque necesita establecer la SSH_AUTH_SOCKvariable.

reaver277
fuente
0

Use ssh-cron para configurar conexiones SSH programadas para proteger los servidores sin exponer sus claves SSH, pero usando el agente SSH.

Luchostein
fuente
0

Puede ejecutar su script o comando en crontab como:

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

o

0 * * * * bash -c -l "ssh root@yourhost 'echo $HOSTNAME'"
pawan
fuente