È ansible ssh o rsync in un sistema il cui file-system è rimontato in sola lettura?

Devo accedere a un sistema che è entrato in uno stato di sola lettura. Posso ping solo bene, ma non posso ssh in più. C'è qualche speciale flag di command / parametro che posso passare ssh che mi permette di accedere a un sistema che è passato in modalità di sola lettura?

Hai dimenticato di aggiungere l'errore esatto di connessione:

 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 feb 2013
 debug1: Lettura dei dati di configuration / etc / ssh / ssh_config
 debug1: Applicare opzioni per *
 debug2: ssh_connect: needpriv 0
 debug1: Connessione a 192.168.0.4 [192.168.0.4] port 22.
 debug1: Connessione stabilita.
 debug1: file di identity framework; /home/username/.ssh/identity type -1
 debug1: file di identity framework; /home/username/.ssh/identity-cert type -1
 debug1: file di identity framework; /home/username/.ssh/id_rsa tipo -1
 debug1: file di identity framework; /home/username/.ssh/id_rsa-cert tipo -1
 debug1: file di identity framework; /home/username/.ssh/id_dsa tipo -1
 debug1: file di identity framework; /home/username/.ssh/id_dsa-cert tipo -1
 ssh_exchange_identification: connessione chiusa da host remoto

Dovrei aggiungere che il ping è abbastanza robusto a quella casella:

 ping 192.168.0.4
 PING 192.168.0.4 (192.168.0.4) 56 (84) byte di dati.
 64 byte da 192.168.0.4: icmp_seq = 1 ttl = 64 tempo = 0.662 ms
 64 byte da 192.168.0.4: icmp_seq = 2 ttl = 64 tempo = 0.088 ms
 64 byte da 192.168.0.4: icmp_seq = 3 ttl = 64 tempo = 0.089 ms

2 Solutions collect form web for “È ansible ssh o rsync in un sistema il cui file-system è rimontato in sola lettura?”

Potresti accedere invocando una session di shell senza login. Ad esempio, è ansible passare un command a ssh dopo aver eseguito l'authentication:

 ssh user@host bash --noprofile --norc 

Ovviamente, questo usa bash come shell. Le conchiglie differenti richiederanno parametri appropriati per non triggersre un aggiornamento wtmp / utmp e non cercare di fare cose che potrebbero non riuscire e di disconnettersi anticipatamente (ad esempio, prima che la shell finisca le attività usuali quando apre normalmente un login session).

Una nota di avvertimento: il guscio sarà piuttosto ( molto! ) Limitato, di solito senza prompt e altra fanciness. Ma è sufficiente per entrare nella macchina e verificare che cosa è sbagliato.

Modificato per aggiungere: a seconda delle circostanze dell'host, potrebbe essere necessario specificare un path completo, ad esempio /bin/bash come command da eseguire dopo aver eseguito l'authentication.

la breve risposta è che il server SSH è probabilmente non funzionante a causa dei problemi di sistema che hai descritto. Non credo che esista qualcosa che il cliente possa fare.

Troverò la tua traccia di debug:

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

Il cliente ha fatto una connessione a tale indirizzo e alla port. Ciò implica che il process sshd sul server sia ancora in esecuzione.

 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 

Il tuo client locale ssh ha cercato quei file chiave e non li ha trovati. Questi sono tutti i nomi di file predefiniti di default che normalmente cercheranno. Questo è solo un problema se si prevede che uno di questi file sia presente. Anche qui non sono pertinenti, perché il cliente non ha mai avuto la possibilità di autenticare.

 ssh_exchange_identification: Connection closed by remote host 

Il server remoto chiuse la connessione TCP. Questo messaggio specifico significa che il server ha effettuato una chiusura "normale" della connessione. Se il server si è schiantato, vednetworking un altro messaggio che dice "la connessione resettata da peer".

Normalmente, la prima cosa che un server SSH farà è quello di submit la sua string di versione software. Se questo fosse accaduto qui, lo vedrai nella traccia di debug:

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

Il server non è nemless arrivato prima di chiudere la connessione.

Se il server era sano, la solita spiegazione di ciò che stai vedendo sarebbe che il server sta rifiutando il client a causa di wrapper TCP . Ma nel tuo caso, qualcosa sullo stato del sistema probabilmente impedisce al sshd di funzionare correttamente. Ad esempio, subito dopo aver accettato una connessione, il server chiamerà [fork()][2] per creare un process figlio. Il process figlio gestisce la connessione mentre il genitore continua ad ascoltare per ulteriori connessioni. Se la fork non riesce, il server chiude la connessione senza submit nulla al client.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.