4 votos

¿Es posible ssh o rsync en un sistema cuyo sistema de archivos ha vuelto a montar sí mismo sólo lectura?

Necesito acceder a un sistema que entró en un estado de sólo lectura. Puedo hacer ping bien pero no puedo ssh en más. Hay algunos especiales de la línea de comandos indicador/parámetro puedo pasar ssh que me permite iniciar sesión en un sistema que ha entrado en modo de sólo lectura?

Se olvidó de agregar la conexión exacta de error:

OpenSSH_5.3p1, OpenSSL 1.0.1 e-fips 11 de Febrero de 2013
debug1: la Lectura de los datos de configuración /etc/ssh/ssh_config
debug1: la Aplicación de opciones para *
debug2: ssh_connect: needpriv 0
debug1: Conexión a 192.168.0.4 [192.168.0.4] el puerto 22.
debug1: Conexión establecida.
debug1: identidad archivo /home/username/.ssh/identity tipo de -1
debug1: identidad archivo /home/username/.ssh/identity-cert tipo de -1
debug1: identidad archivo /home/username/.ssh/id_rsa tipo de -1
debug1: identidad archivo /home/username/.ssh/id_rsa-cert tipo de -1
debug1: identidad archivo /home/username/.ssh/id_dsa tipo de -1
debug1: identidad archivo /home/username/.ssh/id_dsa-cert tipo de -1
ssh_exchange_identification: Conexión cerrada por el host remoto

Debo añadir que el ping es bastante robusto a la caja:

ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
64 bytes from 192.168.0.4: icmp_seq=1 ttl=64 time=0.662 ms
64 bytes from 192.168.0.4: icmp_seq=2 ttl=64 time=0.088 ms
64 bytes from 192.168.0.4: icmp_seq=3 ttl=64 time=0.089 ms

1voto

rnsanchez Puntos 9

Usted podría inicio de sesión mediante la invocación de un no-intérprete de comandos de inicio de sesión. Por ejemplo, usted puede pasar un comando a ssh tras el éxito de la autenticación:

ssh user@host bash --noprofile --norc

Por supuesto, este utiliza bash como la cáscara. Diferentes conchas se requieren parámetros adecuados a fin de no provocar un wtmp/utmp actualización, así como no tratando de hacer cosas que pueden fallar y registro de corta edad (es decir, antes de que el shell termina sus tareas habituales cuando normalmente la apertura de una sesión de inicio de sesión).

Una nota de advertencia: el shell va a ser bastante (muy!) limitado, por lo general sin instrucciones y otros fanciness. Pero es suficiente para que usted pueda entrar en la máquina y comprobar lo que está mal.

Editado para añadir: dependiendo de las circunstancias de su anfitrión, podría ser necesario especificar la ruta completa, por ejemplo /bin/bash como el comando a ejecutar con éxito la autenticación.

1voto

Kenster Puntos 1070

la respuesta corta es que su servidor SSH es, probablemente, no funcional debido a los problemas del sistema que usted ha descrito. No creo que hay algo diferente que el cliente podía hacer.

Voy a romper su traza de depuración:

debug1: Connecting to 192.168.0.4 [192.168.0.4] port 22.
debug1: Connection established.

El cliente hizo una conexión a ese puerto y dirección. Esto implica que el sshd proceso en el servidor se está ejecutando.

debug1: identity file /home/username/.ssh/identity type -1
debug1: identity file /home/username/.ssh/identity-cert type -1
debug1: identity file /home/username/.ssh/id_rsa type -1
debug1: identity file /home/username/.ssh/id_rsa-cert type -1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: identity file /home/username/.ssh/id_dsa-cert type -1

Su local del cliente ssh miró para los archivos de claves y no encontrarlas. Estos son todos los predeterminada del archivo de claves de nombres que normalmente busca. Esto solo es un problema si usted espera que uno de esos archivos. No son muy relevantes aquí, porque el cliente nunca tiene una oportunidad para autenticar.

ssh_exchange_identification: Connection closed by remote host

El servidor remoto cierra la conexión TCP. Este mensaje significa que el servidor hizo un "normal" cerrar la conexión. Si el servidor se había estrellado, había un mensaje diferente diciendo: "connection reset by peer".

Normalmente, la primera cosa que un servidor SSH va a hacer es enviar su cadena de versión de software. Si eso hubiera sucedido aquí, tendría que ver esto en la traza de depuración:

...
debug1: identity file /home/foo/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*

El servidor no está siquiera a llegar lejos antes de cerrar la conexión.

Si el servidor estuviera sano, la explicación habitual para lo que estamos viendo podría ser que el servidor rechaza el cliente debido a TCP wrappers. Pero en tu caso, algo sobre el estado del sistema es, probablemente, la prevención de la sshd de funcionar correctamente. Por ejemplo, inmediatamente después de aceptar una conexión al servidor llamará [fork()][2] a crear un proceso hijo. El proceso hijo se encarga de la conexión, mientras que el padre sigue escuchando para futuras conexiones. Si el tenedor de falla, el servidor cierra la conexión sin enviar nada al cliente.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: