L'istanza di EC2 in esecuzione rifiuta improvvisamente la connessione SSH

Question

Ho impostato il paio di istanze EC2 giorni fa e persino ieri sera sono riuscito a collegarlo a SSH senza problemi. Oggi mattina, non posso ssh ad esso. La porta 22 è già aperta nel gruppo di sicurezza e non ho cambiato nulla dalla scorsa notte.

Errore:

ssh: connect to host [ip address] port 22: Connection refused 

ho avuto problema simile di recente e io non riuscivo a capire perché stava accadendo, così ho dovuto creare una nuova istanza, impostare di nuovo, e collegare e configurare tutto EBS depositi a quello nuovo. Mi ci sono voluti un paio d'ore ... e ora sta succedendo di nuovo. Nel precedente, ho installato denyhost, che potrebbe bloccarmi, ma in quello corrente, ci sono solo apache2 e mysql in esecuzione.

L'istanza corrente è rimasta attiva per 16 ore, quindi non penso sia perché non ha terminato l'avvio ... Inoltre, la porta 22 è aperta a tutte le fonti (0.0.0.0/0) ed è usando il protocollo TCP.

Qualche idea?

Grazie.

Answer 1

Con l'aiuto di @ abhi.gupta200297, siamo stati in grado di risolverlo.

Il problema era l'errore in /etc/fstab e sshd doveva essere avviato dopo che fstab ha avuto esito positivo. Ma non lo era, quindi, la sshd non sarebbe iniziata ed è per questo che stava rifiutando la connessione. La soluzione era creare un'istanza temporanea, montare l'EBS di root dall'istanza originale e commentare le cose da fstab e voilà, mi permette di connettermi di nuovo. E per il futuro, ho smesso di usare fstab e ho creato numerosi comandi shell per montare i volumi EBS in directory e li ho aggiunti nel file /etc/init.d/ebs-init-mount e quindi eseguire update-rc.d ebs-init-mount defaults per inizializzare il file e non ho più problemi con ssh bloccato.

UPDATE 4/23/2015

squadra Amazon ha creato un video tutorial di problema simile e mostrare come eseguire il debug con questo metodo: https://www.youtube.com/watch?v=_P29ZHu_feU

Answer 2

Accedere alla console di gestione AWS> selezionare l'istanza> fare clic con il pulsante destro del mouse e selezionare "Ottieni registri di sistema" Ciò elencherà ciò che è andato storto.

Answer 3

Sembra che sshd si sia fermato per qualche motivo. L'istanza EBS è supportata? se questo è il caso, prova a spegnerlo e riavviarlo. Questo dovrebbe risolvere il problema.

Inoltre, si è in grado di ssh dalla console Web di AWS? Hanno un plugin java lì per ssh nell'istanza.

Answer 4

Questo è successo a me su un'istanza EC2 Red Hat perché queste due linee venivano automaticamente aggiunti alla fine del file/etc/ssh/sshd_config ogni volta che ho lanciato il mio esempio:

PermitRootLogin senza password-
UseDNS non

Una di queste operazioni accodare è stato fatto senza un'interruzione di linea, in modo che la coda del file sshd_config sembrava:

PermitRootLogin senza password-
UseDNS noPermitRootLogin senza password-
UseDNS senza

che ha causato sshd a non riescono a partire al prossimo avvio. Penso che questo sia stato causato dal bug riportato qui: https://bugzilla.redhat.com/show_bug.cgi?id=956531 La soluzione era rimuovere tutte le voci duplicate nella parte inferiore del file sshd_config e aggiungere ulteriori interruzioni di riga alla fine.

Answer 5

Per quelli di voi che sono imbattuto in questo post, perché non si riesce a SSH nella vostra istanza EC2 dopo un riavvio, this is cross-posted-a similar question at serverfault:

Da the AWS Developer Forum post on this topic:

Try stopping the broken instance, detaching the EBS volume, and attaching it as a secondary volume to another instance. Once you've mounted the broken volume somewhere on the other instance, check the /etc/sshd_config file (near the bottom). I had a few RHEL instances where Yum scrogged the sshd_config inserting duplicate lines at the bottom that caused sshd to fail on startup because of syntax errors.

Once you've fixed it, just unmount the volume, detach, reattach to your other instance and fire it back up again.

Rompiamo questo giù, con collegamenti alla documentazione AWS:

1. Stop the broken instance e scollegare il volume EBS (root) entrando in EC2 Gestione Contro Oppure, facendo clic su "Elastic Block Store"> "Volumes", fai clic con il pulsante destro del mouse sul volume associato all'istanza che hai interrotto.
2. Avviare una nuova istanza nella stessa regione e dello stesso SO dell'istanza danneggiata quindi attach the original EBS root volume as a secondary volume to your new instance. I comandi del passaggio 4 in basso presumono che il volume venga montato su una cartella denominata "dati".
3. Una volta che hai mounted the broken volume somewhere on the other instance,
4. controllo il file "/ etc/sshd_config" per le voci duplicate mediante l'emissione di questi comandi:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v un mucchio di volte per ottenere in fondo al file
   • ctrl-k tutte le righe in basso che menzionano "PermitRootLogin without-password" e "UseDNS no"
   • ctrl-x e Y per salvare e uscire il file modificato
5. @Telegardpoints out (in his comment) che abbiamo risolto solo il sintomo. Possiamo correggere causa commentando le 3 righe correlate nel file "/etc/rc.local".Quindi:
   • cd /etc
   • sudo nano rc.local
   • look per le linee "PermitRootLogin ..." e cancellare i loro
   • ctrl-x e Y per salvare e chiudere il file modificato
6. Una volta' l'ho riparato, solo unmount the volume,
7. staccare andando nella console di gestione EC2, facendo clic su "Elastic Block Sto re"> 'Volumi', il tasto destro del mouse sul volume associato con l'istanza è stata interrotta,
8. reattach to your other instance e
9. fire it back up again.

Answer 6

mi sono simili ssh chiusa fuori dal distacco di un EBS ma ho dimenticato di modificare il file/etc/fstab