Problema con Agentes en 1.3

[Sancho]

Like it

Up

0

Down

Drop it

::

¿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]

Like it

Up

0

Down

Drop it

::

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]

Like it

Up

0

Down

Drop it

::

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 programaPandora_Agent>PandoraAgent.exe –test-ssh
Public key file D:Archivos de programaPandora_Agentkeyid_dsa.pub exists.
Private key file: D:Archivos de programaPandora_Agentkeyid_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

[manu]

Like it

Up

0

Down

Drop it

::

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]

Like it

Up

0

Down

Drop it

::

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

[vdelburgo]

Like it

Up

0

Down

Drop it

::

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:

[email protected]‘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]

Like it

Up

0

Down

Drop it

::

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 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:

[email protected]‘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

[manu]

Like it

Up

0

Down

Drop it

::

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]

Like it

Up

0

Down

Drop it

::

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 [email protected]
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,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],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,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],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

[manu]

Like it

Up

0

Down

Drop it

::

Has probado el –test-ssh que te dije?

[vdelburgo]

Like it

Up

0

Down

Drop it

::

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

D:Archivos de programaPandora_Agent>PandoraAgent.exe –test-ssh
Public key file D:Archivos de programaPandora_Agentkeyid_dsa.pub exists.
Private key file: D:Archivos de programaPandora_Agentkeyid_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]

Like it

Up

0

Down

Drop it

::

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…

[manu]

Like it

Up

0

Down

Drop it

::

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]

Like it

Up

0

Down

Drop it

::

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…

[raul]

Like it

Up

0

Down

Drop it

::

Si no has generado y metido la clave pública ssh del usuario root en el /home/pandora/.ssh/authorized_keys, no entrarás in autenticarte desde localhost y usuario root…

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…

Envía a mi correo raulofpandora arroba gmail punto com el authkeys y el id_dsa.pub que has generado en windows. Elimina los datos que consideres sensibles (IPs…)

Raúl

[manu]

Like it

Up

0

Down

Drop it

::

Los permisos de .ssh/ y authorized_keys son los correctos?

[vdelburgo]

Like it

Up

0

Down

Drop it

::

Los permisos de .ssh/ y authorized_keys son los correctos?

Los permisos en .ssh son 777 y en el authorized_keys también (con el usuario propietario ‘pandora’)

¿?

[manu]

Like it

Up

0

Down

Drop it

::

Eso está mal, .ssh tiene que tener 700 y authorized_keys tiene que tener 600
Por eso no conectaba.

[vdelburgo]

Like it

Up

0

Down

Drop it

::

El problema era ese con los agentes de Windows… ¿no se supone que con permisos 777 están incluído todo, es decir, los 700 y los 600?

Ahora el problema persiste en los servidores Linux…

Por cierto, en la ‘Vista táctica del servidor’ me aparecen el servidor ‘Net’ y el ‘Data’, pero no me aparecen ni el ‘Recon’ ni el ‘Snmp’, pero los demonios en el servidor Pandora están arrancados…

[rnovoa]

Like it

Up

0

Down

Drop it

::

Hola vdelburgo,

La restricción en cuanto a permisos es simplemente una cuestión de seguridad. Sería bastante peligroso que cualquier usuario tuviese acceso a tu clave privada, o pudiese añadir claves públicas que le permitiesen autenticarse como si fuese tu usuario.