Amazon EC2 - Nessun SSH dopo il riavvio, connessione rifiutata

L'ho replicato due o tre volte, quindi immagino che ci sia qualcosa di sbagliato in quello che sto facendo.

Ecco i miei passi:

1. Avviare una nuova istanza tramite la console di gestione EC2 utilizzando: Ubuntu Server 13.10 - ami-ace67f9c (64-bit)
2. Avvia con i valori predefiniti (usando la mia coppia di chiavi esistente)
3. L'istanza inizia. Posso SSH ad esso usando Putty o il terminale Mac. Successo!
4. Riavvio l'istanza

5. 10 minuti dopo, quando l'istanza dovrebbe essere di nuovo in esecuzione, la mia connessione al terminale mostra:

   stead:~ stead$ ssh -v -i Dropbox/SteadCloud3.pem ubuntu@54.201.200.208
   OpenSSH_5.6p1, Op`enSSL 0.9.8y 5 Feb 2013
   debug1: Reading configuration data /etc/ssh_config
   debug1: Applying options for *
   debug1: Connecting to 54.201.200.208 [54.201.200.208] port 22.
   debug1: connect to address 54.201.200.208 port 22: Connection refused
   ssh: connect to host 54.201.200.208 port 22: Connection refused
   stead:~ stead$
   

Bene, capisco che l'indirizzo IP pubblico può cambiare, quindi controllando la console di gestione EC2, riconosco che è lo stesso. Strano. Solo per divertimento, provo a connettermi con il nome host DNS pubblico: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Nessun dado, stesso risultato.

Anche usando il client Connect via Java SSH integrato nella console EC2, ottengo il rifiuto della connessione.

Ho controllato i gruppi di sicurezza. Questa istanza è nel gruppo launch-wizard-4. Osservando la configurazione in entrata per questo gruppo, la porta 22 è consentita da 0.0.0.0/0, quindi dovrebbe essere ovunque. So che sto colpendo la mia istanza e questo è il giusto gruppo di sicurezza, perché non riesco a eseguire il ping dell'istanza. Se abilito ICMP per questo gruppo di sicurezza, all'improvviso i miei ping passano.

Ho trovato alcuni altri post su Internet con messaggi di errore simili, ma la maggior parte sembra essere facilmente risolta modificando le impostazioni del firewall. Ho provato alcuni di questi, senza fortuna.

Immagino che manchi un semplice passaggio EC2. Grazie per l'aiuto che puoi dare, e sono felice di fornire ulteriori informazioni o testare ulteriormente!

Aggiornamento: ecco i miei registri di sistema dalla console Amazon EC2: http://pastebin.com/4M5pwGRt

Ho avuto un comportamento simile oggi sulla mia istanza ec2 e ho rintracciato la cosa in questo modo: quando faccio sudo reboot now il computer si blocca e devo riavviarlo manualmente dalla console di gestione di aws quando lo faccio sudo reboot si riavvia bene. Apparentemente "ora" non è un'opzione valida per il riavvio, come indicato qui /ubuntu/397502/reboot-a-server-from-command-line

pensieri?

Dal post del forum per sviluppatori AWS su questo argomento :

Prova a interrompere l'istanza interrotta, staccare il volume EBS e collegarlo come volume secondario a un'altra istanza. Dopo aver montato il volume rotto da qualche parte sull'altra istanza, controlla il file / etc / sshd_config (nella parte inferiore). Ho avuto alcune istanze di RHEL in cui Yum ha scroccato il file sshd_config inserendo righe duplicate in fondo che causavano il fallimento di sshd all'avvio a causa di errori di sintassi.

Una volta risolto il problema, basta smontare il volume, staccarlo, ricollegarlo all'altra istanza e riaccenderlo.

Analizziamo questo, con collegamenti alla documentazione di AWS:

1. Arresta l'istanza interrotta e scollega il volume EBS (root) accedendo alla console di gestione EC2, facendo clic su "Elastic Block Store"> "Volumes", facendo clic con il pulsante destro del mouse sul volume associato all'istanza che hai interrotto.
2. Avviare una nuova istanza nella stessa area e dello stesso sistema operativo dell'istanza interrotta, quindi collegare il volume radice EBS originale come volume secondario alla nuova istanza . I comandi nel passaggio 4 di seguito presuppongono che si monti il ​​volume in una cartella denominata "dati".
3. Dopo aver montato il volume rotto da qualche parte sull'altra istanza ,
4. controlla il file "/ etc / sshd_config" per le voci duplicate emettendo questi comandi:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v un sacco di volte per arrivare in fondo al file
   • ctrl-k tutte le righe in basso che menzionano "PermitRootLogin senza password" e "UseDNS no"
   • ctrl-xe Yper salvare ed uscire dal file modificato
5. @Telegard sottolinea (nel suo commento) che abbiamo risolto solo il sintomo. Possiamo risolvere la causa commentando le 3 righe correlate nel file "/etc/rc.local". Così:
   • cd /etc
   • sudo nano rc.local
   • cercare le righe "PermitRootLogin ..." ed eliminarle
   • ctrl-xe Yper salvare ed uscire dal file modificato
6. Una volta risolto, basta smontare il volume ,
7. staccare andando nella console di gestione EC2, facendo clic su "Elastic Block Store"> "Volumes", facendo clic con il tasto destro del mouse sul volume associato all'istanza che hai interrotto,
8. ricollegare all'altra istanza e
9. esegui nuovamente il backup .

Potrebbe non aiutare la situazione, ma ho visto alcuni casi in cui un riavvio su EC2 si blocca. Se si esegue un "ripristino" sulla macchina virtuale e quindi si ripristinano i registri di sistema, è possibile che il comportamento venga modificato. Assicurarsi che i registri provengano dal secondo avvio e non dal primo: tendono ad essere ritardati sugli aggiornamenti.

Un'altra cosa da verificare è assicurarsi che l'istanza stia rispondendo sull'IP. Sembra che tu abbia rifiutato una connessione sopra, che suona come un'istanza attiva, ma SSH non è in esecuzione o è protetto da firewall, ma assicurati che l'istanza sia stata riavviata completamente.

Puoi anche provare ad aprire tutte le porte da un sistema di test e vedere cosa ti mostra 'nmap': stanno rispondendo altri servizi sull'istanza.

Fare clic destro sul nome dell'istanza e fare clic su "Cambia gruppi di sicurezza". Assicurarsi che il gruppo di sicurezza creato che consente a chiunque da qualsiasi luogo alla porta 22 sia verificato e applicato a questa istanza.

Ho riscontrato questo problema dopo aver effettuato sudo reboot nowtramite SSH sul mio server EC2 con Ubuntu 14.04. Ha funzionato bene dopo il riavvio utilizzando la console di gestione EC2.

Nel mio caso, avrei creato un gruppo di sicurezza per consentire le connessioni alla porta 22 solo dal mio IP. Alcuni giorni dopo il mio ISP ha cambiato il mio indirizzo IP, quindi il gruppo di sicurezza deve essere aggiornato.

Ho avuto un problema simile, la mia istanza di Amazon Linux EC2 non era più raggiungibile dopo aver eseguito il riavvio di sudo .

Nessun accesso SSH, comandi di arresto / avvio / riavvio dalla console di amministrazione di Amazon non mi hanno dato alcun risultato.

Sono stato finalmente in grado di riavviare la mia istanza creando un'immagine tramite la console di Amazon. Il processo di creazione dell'immagine sembra correggere lo stato dell'istanza.

Spero che sia d'aiuto ;)

Ho avuto lo stesso problema dopo aver eseguito un sudo rebootcomando vanilla . Ho scoperto di essere stato in grado di risolvere il problema arrestando completamente (non riavviando) il mio AMI utilizzando la console AWS e quindi avviandolo nuovamente.

Per qualsiasi motivo, il riavvio dell'AMI dalla console AWS, come nel fare clic sull'azione di riavvio anziché arrestare e quindi avviare l'istanza, non ha risolto il problema.

Come accennato, probabilmente hai sbagliato con / etc / fstab /

Ho avuto questo problema Per prima cosa devi aggiungere nuovamente il volume in / dev / sda1 come dice il messaggio di avviso.

Quindi non ho potuto ssh. Mi sono reso conto che dovevo aggiungere l'altro volume che avevo creato e che risolveva il problema ssh.

Quindi è possibile accedere e ripristinare fstab sull'originale.