É possível ssh ou rsync em um sistema cujo sistema de arquivos tenha se montado novamente como somente leitura?

Question

Eu preciso fazer login em um sistema que entrou em um estado somente leitura. Eu posso pingar muito bem, mas eu não posso mais ssh. Existe algum sinalizador / parâmetro de linha de comando especial que eu possa passar ssh que me permite entrar em um sistema que entrou em modo somente leitura?

Esqueceu de adicionar o erro de conexão exato:

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.4 [192.168.0.4] port 22.
debug1: Connection established.
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
ssh_exchange_identification: Connection closed by remote host

Devo acrescentar que o ping é bastante robusto para essa caixa:

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

    

Answer 1

Você poderia fazer login invocando uma sessão de shell sem login. Por exemplo, você pode passar um comando para ssh após autenticar com sucesso:

ssh user@host bash --noprofile --norc

Claro, isso usa bash como o shell. Shells diferentes exigirão parâmetros apropriados para não acionar um wtmp / utmp update, bem como não tentar fazer coisas que poderiam falhar e efetuar logoff antecipadamente ( ie, antes do shell termina suas tarefas habituais quando normalmente abre uma sessão de login).

Uma nota de aviso: o shell será bastante ( muito! ) limitado, geralmente sem avisos e outras fantasias. Mas é o suficiente para você entrar na máquina e verificar o que está errado.

Editado para adicionar: dependendo das circunstâncias do seu host, pode ser necessário especificar um caminho completo, por exemplo, /bin/bash como o comando para executar com sucesso na autenticação.

    

Answer 2

a resposta curta é que seu servidor SSH provavelmente não é funcional devido aos problemas do sistema que você descreveu. Eu não acho que há algo diferente que o cliente possa fazer.

Vou dividir seu rastreio de depuração:

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

O cliente fez uma conexão com esse endereço e porta. Isso implica que o processo sshd no servidor ainda está em execução.

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

Seu cliente ssh local procurou por esses arquivos-chave e não os encontrou. Esses são todos os nomes de arquivos de chaves padrão que normalmente seriam procurados. Isso é apenas um problema se você espera que um desses arquivos esteja presente. Eles também não são realmente relevantes aqui, porque o cliente nunca teve a chance de autenticar.

ssh_exchange_identification: Connection closed by remote host

O servidor remoto fechou a conexão TCP. Esta mensagem específica significa que o servidor fez um fechamento "normal" na conexão. Se o servidor travasse, você veria uma mensagem diferente dizendo "conexão redefinida pelo par".

Normalmente, a primeira coisa que um servidor SSH fará é enviar sua string de versão de software. Se isso tivesse acontecido aqui, você veria isso no rastreamento de depuração:

...
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*

O servidor não está chegando tão longe antes de fechar a conexão.

Se o servidor fosse saudável, a explicação usual para o que você está vendo seria que o servidor está rejeitando o cliente devido a TCP wrappers . Mas no seu caso, algo sobre o estado do sistema provavelmente está impedindo que sshd funcione corretamente. Por exemplo, imediatamente após aceitar uma conexão, o servidor chamará [fork()][2] para criar um processo filho. O processo filho manipula a conexão enquanto o pai continua ouvindo outras conexões. Se a bifurcação falhar, o servidor fechará a conexão sem enviar nada ao cliente.