Problema con Agentes en 1.3

[vdelburgo]

¿Qué tal?

Tengo un problema con los Agentes en la versión 1.3, tanto en Windows como en Linux. Los tengo creados en los equipos clientes y ejecutándose (también he hecho la prueba de conectividad y funcionan) pero no se reflejan en la consola, no hay cambios ni se ven los monitores ni nada.

¿Alguien sabe como solucionar esto?

Un saludo y gracias,


VÍCTOR

[Sancho Lerena]

¿Qué tal?

Tengo un problema con los Agentes en la versión 1.3, tanto en Windows como en Linux. Los tengo creados en los equipos clientes y ejecutándose (también he hecho la prueba de conectividad y funcionan) pero no se reflejan en la consola, no hay cambios ni se ven los monitores ni nada.

¿Alguien sabe como solucionar esto?

Un saludo y gracias,


VÍCTOR

Has creado los agentes (con el mismo nombre) primero en la consola ?, ¿les has activado la opcion "Autolearn" ?. ¿Tienes corriendo el servidor de datos?.

[raul]

Revisa también los logs de los servidores y de los agentes. Si no ves nada extraño, intenta lanzar uno de los agentes en modo debug (editando el fichero de configuración).

Raúl desde Bs As

[vdelburgo]

Al final he reinstalado el Servidor desde cero, porque en la parte de la gestión de agentes, no me aparecía la opción de 'Crear Agente', estaba tirando de los agentes instalados de la versión 1.2, aunque en los equipos clientes había subido a la 1.3. Ahora, con el Servidor y la Consola en la versión 1.3 me aparece todo (está la base de datos limpia) pero cuando en el equipo cliente me creo las claves id_dsa (con la opción de exportar) y id_dsa.pub (copiando la clave en el .txt) e intento ejecutar el test de conectividad me aparece ésto:

D:\Archivos de programa\Pandora_Agent>PandoraAgent.exe --test-ssh
Public key file D:\Archivos de programa\Pandora_Agent\key\id_dsa.pub exists.
Private key file: D:\Archivos de programa\Pandora_Agent\key\id_dsa exists.
Connecting with 10.200.100.254.
Authentication Failed when connecting to 10.200.100.254
Check the remote host configuration and the public/private key files.

Es como si reconociera que están los archivos, pero como si no aceptara la conexión. El contenido del id_dsa.pub lo he copiado en /home/pandora/.ssh/authorized_keys pero parece que no lo pilla. En el log me sale lo siguiente:

11-22-07 08:47:59: Pandora agent started
11-22-07 08:48:05: Pandora Agent: Failed when copying to 10.200.100.254 (couldn't connect to server)
11-22-07 08:48:06: Pandora agent stopped

La IP en el pandora_agent.conf concuerda con la IP del servidor y el directorio del servidor /var/spool/pandora/data_in que está indicado también en el pandora_agent.conf tiene los permisos a 777 con propietario al usuario 'pandora'

Ya no se qué más puedo probar ¿alguna idea sobre esto?

Un saludo y gracias,


VICTOR

[Manuel Arostegui]

Hola,

Bueno, parece claramente un tema de llaves de ssh.
Prueba desde un terminal de ms-dos la opción PandoraAgent.exe --test-ssh y seguramente verás que falle.

El problema de generar las llaves en Windows y copiarlas a los ficheros de linux es que casi siempre se dejan retornos de carro o cosas similares.
Asegurate de que no los hay, asegurate de que está toda la llave generada en una sola linea (abre la llave de windows con un notepad y comprueba si está en una linea)

Saludos.

[raul]

y que no hay ningún retorno de carro al final del fichero. SHH es muy quisquilloso para eso.

[vdelburgo]

Me falla tanto desde un cliente Windows en el que tengo instalado el agente como desde el propio servidor Pandora, que también tengo otro agente... pero en este me pide continuamente un password:

pandora@10.200.100.254's password:

¿Acaso tengo que poner un password nulo para el usuario 'pandora'? Porque si cuando me lo solicita pongo el por defecto me entra...

Un saludo,


VICTOR

[raul]

Desde el servidor Pandora: Necesitas que el usuario desde el que haces la conexión tenga la clave en el /home/pandora/.ssh/authorized_keys.

Para la creación de la clave en windows, ¿has seguido el "howto", paso por paso, importando la clave en formato OpenSSH: http://www.openideas.info/wiki/index.php?title=Pandora_1.3:Documentation_en:Install_Agent#Creating_SSH_keys_with_Windows_Agents?

El password no debería estar en blanco para el usuario pandora, una vez configurado correctamente SSH, utilizarás la clave para entrar sin contraseña.

Por otro lado, si tienes una copia del agente anterior y el authorized_keys anterior, debe funcionar, no sería necesario generar de nuevo las claves.

Otra opción en la versión 1.3 es utilizar FTP en lugar de SSH.

Puedes también utilizar ssh con debug [code:1]ssh -vv pandora@IP[/code] para ver qué está pasando.

Un saludo,

Raúl

Me falla tanto desde un cliente Windows en el que tengo instalado el agente como desde el propio servidor Pandora, que también tengo otro agente... pero en este me pide continuamente un password:

pandora@10.200.100.254's password:

¿Acaso tengo que poner un password nulo para el usuario 'pandora'? Porque si cuando me lo solicita pongo el por defecto me entra...

Un saludo,


VICTOR

[Manuel Arostegui]

Hola victor,
Te recomiendo que uses scponly en el servidor de pandora y para el usuario pandora, como medida de seguridad...

http://www.openideas.info/wiki/index.php?title=Pandora_1.3:Documentation_en:Advanced_Setup

[vdelburgo]

Sí, he utilizado el 'howto' tal y como viene en la documentación... he probado el debug y me sale esto:

[root@localhost ~]# ssh -vv pandora@10.200.100.254
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.200.100.254 [10.200.100.254] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 127/256
debug2: bits set: 490/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.200.100.254' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 526/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa ((nil))
debug2: key: /root/.ssh/id_dsa (0x8da8d28)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Offering public key: /root/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

He comprobado el directorio /var/spool/pandora/data_in y el fichero ssh.test no se ha tocado, y eso que tiene permisos 777 y el propietario y grupo son 'pandora' con lo que debería de haberlo modificado, pero nada...

He probado a poner el modo en FTP pero ¿cómo podría hacer la prueba a ver si así lo coge bien?

Un saludo y gracias,


VICTOR

[Manuel Arostegui]

Has probado el --test-ssh que te dije?

[vdelburgo]

Sí, lo he probado desde el cliente windows y me saca ésto:

D:\Archivos de programa\Pandora_Agent>PandoraAgent.exe --test-ssh
Public key file D:\Archivos de programa\Pandora_Agent\key\id_dsa.pub exists.
Private key file: D:\Archivos de programa\Pandora_Agent\key\id_dsa exists.
Connecting with 10.200.100.254.
Authentication Failed when connecting to 10.200.100.254
Check the remote host configuration and the public/private key files.

[vdelburgo]

También he probado a poner, en el Servidor, el cliente con la configuración 'transfer_mode local' y tampoco me recolecta datos... esto es muy raro...

[Manuel Arostegui]

Vale, viendo que falla el test de ssh, está claro que has generado o copiado mal las llaves de ssh.
Hazlo de nuevo

En segundo lugar, lo de local si que es raro, está la IP correcta? Está en modo debug?

[vdelburgo]

Las llaves SSH las he creado bastantes veces y todas las veces que las creo las anexo a /home/pandora/.ssh/authorized_keys... la IP es la correcta, porque por el navegador accedo mediante IP...