lunes, 6 de julio de 2015

Acceso SSH denegado: ¿Qué ha pasado?

Como ya sabréis, tengo una raspberry con un port de FreePBX para procesadores arm. Pues resulta que recientemente he tenido problemas para acceder por consola ssh. Hacía una temporada que no intentaba acceder por ahí, y desde hace una semana y pico que llevo intentándolo, pero nada.

¿Qué he hecho? Varios intentos, bastante infructuosos, la verdad.

El primero de todo, ha sido extraer la tarjeta del dispositivo, ponerla en mi flamante equipo nuevo, tirar de la herramienta FTK (Forensics ToolKit) desde Windows, y extraer algunos ficheros que podían ser de interes:
  • /var/log/ entero. Quería tener todos los logs posibles. En la búsqueda que hice de los que me parecían más importantes no encontré nada.
  • .bashrc_history de mis usuarios. Tampoco había nada que me ayudase.
  • Fichero de configuración del servicio de ssh: por si alguna cosa había cambiado. Nada.
Y yo como loco buscando qué había podido pasar. Intenté hacer varios cambios editando algunos ficheros de confirguación del ssh, pero no hubo éxito. Por lo tanto, ya me puse a hacer un backup a través de la consola de administración de la centralita y después, con Kali, hacer una imagen de la tarjeta. Incluso, con la imagen ya hecha, me atreví a hacer cambios en la configuración del servicio: permitir a root acceso directo, entre otros. 

También eliminé las claves que te guarda el putty al acceder al ssh. Y, aún ofreciendo guardarlas de nuevo, no hubo manera. 

Como no se me ocurría qué más hacer, me he puesto a buscar, y he encontrado una idea muy interesante: intentar acceder por sftp. Y, en efecto, así sí que accedo perfectamente. Por lo tanto, queda mirar qué está sucediendo. 

Haciendo memoria, y con alguna búsqueda más, me he dado cuenta de que una de las últimas veces que entré por ssh hice una actualización (una pena que el bashrc_history no te diga cuándo se ha producido cada línea). Voy a hacer un intento: "eliminar" las claves de ssh (renombrándolas, claro), pondré un fichero en la carpeta /etc/cron.d/ para que ejecute un script:






Todo esto, a ciegas. A ver qué resultado da. Después, a la vuelta, os cuento.

Algunos de estos consejos los he seguido a través de los siguientes enlaces:
Después de conseguir hacerlo funcionar (cuidado: asegúrate de que los ficheros contienen los datos, que me encontré con que uno de ellos se me había quedado vacío). Ahora, me está dando problemas incluso para que me ofrezca el usuario y la contraseña. Mensajes como "connection refused" o "Software caused connection abort" son algunos de ellos, dependiendo de qué cliente usase. 

Por lo tanto, volveré a cargar la tarjeta en el ordenador y haré una lectura, a ver qué más datos puedo sacar. 

Mirando los logs de /var/log/auth.log he podido encontrar comensajes  como:

sshd[13400]: error: Could not load host key: /etc/ssh/ssh_host_rsa_key
sshd[13400]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
sshd[13400]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
sshd[13400]: fatal: No supported key exchange algorithms [preauth]


Por lo que buscaré dos cosas: si hay algo que se haya hecho o pasado a la hora de lanzar cron y qué claves hay en la carpeta del servicio ssh.


Lo primero que me encuentro es que el fichero /var/log/dpkg.log está vacío desde marzo. 

---

La mala pata de que todo lo de arriba no me funcionase, hizo que me tocase buscarme un televisor o monitor para poder ver qué me mostraba. Tuve que terminar haciendo dos cosas:

  • Eliminar el hash de mi usuario root y el mortal: aún con el usuario root, no me permitía cambiar la contraseña del mortal sin ejecutar la siguiente opción.
  • Resetar las claves de ssh: no sé por qué, pero me tocó volver a generar las claves.
Una vez se ah conseguido que la contraseña de root funcionase, ya están las decisiones a gusto del consumidor:
  1. Cambiar directamente la contraseña del usuario mortal.
  2. Cambiar la configuración de ssh para que te permitiese que root accediese y después de realizar los cambios de contraseñas de tus usuarios mortales, acordarse de volver a impedir que root pudiera acceder desde una conexión remota. 
Es más,  me tocó comprarme un teclado inalámbrico para poder escribir mientras lo miraba en el televisor. Incluso un lío más: como no tengo uno con HDMI, me tocó llevarme la rasp a casa de mis padres. Y la compra del teclado tampoco es una molestia teniendo en cuenta que para otro proyecto que tengo en mente me iba a hacer falta. 
Siento mucho que este post sea uno de esos tan caóticos. Pero que al menos, le pueda ayudar a alguien que le haya pasado lo mismo. 

2 comentarios:

  1. Bueno, he tenido más de algún entronazo con 'ssh', con ese tipo de mensajes, me ha ocurrido con Ubunty y con Fedora/RedHat/Centos.
    Algunas veces, después de restaurar no se restauran adecuadamente los permisos, eso es fundamental desgraciadamente los 'logs' no ayudan.
    Resumiendo:
    - El directorio '.ssh', sino lo tienes ejecuta 'ssh-keygen' debe de tener permisos 700 y el usuario actual debe de ser el propietario.
    - Las claves públicas aquellas que tiene extensión '.pub' debe tener los permisos 644 y el propietario usuario actual.
    - Las claves privadas id_rsa o id_dsa los permisos 600 (Esto es importante)
    - Los ficheros know_host y authorized_keys los permisos 600

    En caso que falle fijarse el los permisos dentro del directorio /etc/sshd

    ResponderEliminar
    Respuestas
    1. Muchas gracias por tu aportación. Viene muy, muy bien toda esta información. Se agradece muchisimo.

      Eliminar