vostorga.org

Encontrando fingerprint de una llave pública

Posted by vostorga - 04/10/10 at 11:10:13 am

ssh-keygen -lv -f /ruta/a/la/llave.publica

Para todos los que han ocupado ssh, el fingerprint es aquella cadena de texto que se presenta la primera vez que nos conectamos a un usuario@servidor desde ssh:

$ ssh host.tld
The authenticity of host ‘host.tld (aa.bb.xx.yy)’ can’t be established.
RSA key fingerprint is D7:8e:76:10:2c:63:d4:87:71:d1:03:aa:c6:51:01:tr.
Are you sure you want to continue connecting (yes/no)?

Obtener el fingerprint de una llave ayuda a asegurarnos de manera previa si el host es realmente el que esperamos que sea.

Quick and dirty: Copiando archivos de un servidor a otro preservando links simbólicos

Posted by vostorga - 17/08/09 at 04:08:57 pm

Recientemente me vi en la necesidad de pasar un par de GB entre dos servidores, pero preservando los vínculos simbólicos, cosa que el scp no puede hacer ya que los sigue o en otras palabras reemplaza el vínculo por el archivo al cual apunta.

Además de no contar con rsync ya que era un live cd , ejecutar el siguiente comando en la máquina origen solvento la situación:

tar -cpf – /ruta/origen | ssh host.name tar -xpf – -C /destino

Fácil cierto?

OpenSSH y configuración de DNS

Posted by vostorga - 25/03/09 at 09:03:37 pm

Recientemente me fijé que un Linux Box tardaba demasiado tiempo (unos 6 segundos) para pedirme la contraseña una vez ingresado el comando ssh user@ip

Haciendo una depuración del lado del cliente, se mostraba lo siguiente:

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: /home/vostorga/.ssh/id_rsa
debug2: key: /home/vostorga/.ssh/id_dsa

<una pausa de 6 segundos>

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/vostorga/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/vostorga/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
root@192.168.x.x’s password:

Al principio pensé que había algún problema con los tipos de autenticación disponibles en el servidor, pero viendo un problema parecido del joven jmaslibre con su DNS, me puse a revisar la configuración de dns del servidor OpenSSH, en otras palabras /etc/hosts y /etc/resolv.conf y resultó que la IP especificada en /etc/resolv.conf no  estaba ofreciendo DNS.

Lo curioso es que si no se especificaba servidor DNS o se agregaba otro, funcionaba correctamente, a pesar de estar trabajando en una LAN.

El servidor OpenSSH quería hacer una resolución inversa y esos segundos de pausa era el intento fallido de realizar dicha operación, por lo que las soluciones pueden incluir:

• Verificar /etc/hosts
• Verificar que /etc/resolv.conf no contengan servidores inválidos
• Deshabilitar en el archivo sshd_config la resolución inversa con el parámetro UseDNS no

Utilizando túnel ssh para acceder a X

Posted by vostorga - 18/01/08 at 08:01:44 pm

Como administrador de servidores el 99% de las tareas puede ser hecha desde una consola, pero en ese 1% restante podemos necesitar de una interfaz gráfica. Para acceder al X de un servidor remoto podemos utilizar VNC, XDMCP, entre otros pero enfrentaremos un problema si solamente tenemos acceso a ese equipo a través del puerto de SSH (regularmente el 22), situación que me sucedió y explico como hacerle frente. El primer requisito es que el servidor al cual queremos acceder gráficamente tenga instalado x11vnc el cual no es más que un servidor VNC para X, instalarlo es tán fácil como:

Debian: apt-get install x11vnc

Gentoo: emerge x11-misc/x11vnc

Luego hacemos un tunel a la conexión vnc ejecutando: ssh -t -L 5901:localhost:5900 usuario@servidor

Ya logueados en el server ejecutamos: x11vnc

Por último ejecutamos en la máquina local un visor VNC, por ejemplo: vncviewer localhost:1

Listo! Ya tenemos acceso gráfico al servidor remoto, es de notar que al momento de ejecutar x11vnc este se ejecuta sin contraseña asi que hay que tomar las precauciones del caso; el propio x11vnc en su salida muestra como utilizar contraseñas.

Search