Possibili ragioni per il timeout durante il tentativo di accedere all'istanza EC2

Non riesco ad accedere tramite SSH alla mia istanza - Operazione scaduta. Quali potrebbero essere i motivi e cosa posso fare per risolverlo? Il riavvio normalmente richiede molto tempo per avere effetto e potrebbe solo peggiorare le cose

AGGIORNAMENTO: Non si tratta di autorizzazioni: posso accedere normalmente senza problemi. Ho il sospetto che potrebbe essere a causa di problemi di memoria

Hai impostato un gruppo di sicurezza appropriato per l'istanza? Cioè uno che consente l'accesso dalla tua rete alla porta 22 sull'istanza. (Per impostazione predefinita, tutto il traffico non è consentito.)

Aggiornamento: Ok, non è un problema del gruppo di sicurezza. Ma il problema persiste se avvii un'altra istanza dalla stessa AMI e provi ad accedervi? Forse questa particolare istanza EC2 è fallita casualmente in qualche modo: è solo questione di tempo che qualcosa del genere accada. (Letture consigliate: Architecting for the Cloud: Best Practices (PDF), un documento di Jinesh Varia che è un evangelista dei servizi web in Amazon. Vedi in particolare la sezione intitolata "Design for failure and nothing will fail".)

Ho avuto lo stesso problema e la soluzione è stata l'aggiunta dell'IP della mia macchina locale all'elenco delle regole in entrata nel gruppo di sicurezza attivo. Nella finestra di dialogo in entrata di seguito, inserisci 22 nell'intervallo di porte, il tuo IP / 32 locale nel campo di origine e lascia "regola tcp personalizzata" nel menu a discesa.

Distruggi e crea di nuovo

Avevo una zona di disponibilità dove potevo connettermi e un'altra dove non potevo. Dopo alcune ore mi sono sentito così frustrato che ho cancellato tutto in quella zona di disponibilità.

Ricostruendo tutto dovevo assicurarmi di creare TUTTO. Questo includeva:

• Crea VPC
  • CIDR: 10.0.0.0/24
• Crea gateway Internet
• Collega Internet Gateway a VPC
• Crea tabella di instradamento
• Aggiungi percorso alla tabella di instradamento
  • Destination: 0.0.0.0/0
  • Target: <Internet Gateway from earlier>
• Crea sottorete
  • CIDR: 10.0.0.0/24
  • Routing Table: <Routing Table from earlier

Mi ci è voluto un SACCO di armeggiare per ottenere tutto questo. Ho ordinato i passaggi nel modo che penso potrebbe essere più efficiente, ma potrebbe essere necessario modificarli per rendere disponibile un elemento per il successivo.

Suggerimento

Non sto suggerendo di passare al termo nucleare come ho fatto io. Ti sto offrendo tutte queste informazioni in modo che tu possa controllare queste associazioni per assicurarti che le tue siano appropriate.

Questa risposta è per le persone stupide (come me). Il DNS pubblico del tuo EC2 potrebbe (cambierà) quando verrà riavviato. Se non te ne rendi conto e tenti di accedere a SSH nel tuo vecchio DNS pubblico, la connessione si bloccherà e andrà in timeout. Questo potrebbe farti presumere che qualcosa non va con il tuo EC2 o gruppo di sicurezza o ... No, solo SSH nel nuovo DNS. E aggiorna il tuo ~/.ssh/configfile se devi!

Per connetterti usa ssh in questo modo:

ssh -i keyname.pem username@xxx.xx.xxx.xx

Dov'è keyname.pemil nome della tua chiave privata, usernameè il nome utente corretto per la distribuzione del tuo sistema operativo ed xxx.xx.xxx.xxè l'indirizzo IP pubblico.

Quando scade o non riesce, controlla quanto segue:

Gruppo di sicurezza

Assicurati di avere una regola in entrata per la porta tcp 22 e tutti gli IP o il tuo IP. Puoi trovare il gruppo di sicurezza tramite il menu ec2, nelle opzioni dell'istanza.

Tabella di instradamento

Per una nuova sottorete in un vpc, è necessario passare a una tabella di routing che punti 0.0.0.0/0 alla destinazione del gateway Internet . Quando crei la sottorete nel tuo vpc, per impostazione predefinita assegna la tabella di routing predefinita, che probabilmente non accetta il traffico in entrata da Internet. È possibile modificare le opzioni della tabella di routing nel menu vpc e quindi nelle sottoreti.

IP elastico

Per un'istanza in un vpc, devi assegnare un indirizzo IP elastico pubblico e associarlo all'istanza. L'indirizzo IP privato non è accessibile dall'esterno. Puoi ottenere un IP elastico nel menu ec2 (non nel menu istanza).

Nome utente

Assicurati di utilizzare il nome utente corretto . Dovrebbe essere uno di ec2-usero rooto ubuntu. Provali tutti se necessario.

Chiave privata

Assicurati di utilizzare la chiave privata corretta (quella che scarichi o scegli quando avvii l'istanza). Sembra ovvio, ma copia incolla mi ha fatto due volte.

Hai esaminato l'output della console dall'istanza? Puoi farlo tramite la console AWS (Istanze -> Fai clic con il pulsante destro del mouse sull'istanza -> Ottieni registro di sistema). Ho avuto occasioni in cui i servizi di rete su un'istanza EC2 non si avviavano correttamente, provocando connessioni SSH scadute; riavviare l'istanza di solito risolveva le cose.

DOPO 2 ORE HO TROVATO QUESTO

Nota che ssh ip 120.138.105.251/32

• NON È L'INDIRIZZO IP dell'istanza aws

• Non è il tuo IP locale 127.0.0.1

• Non è il tuo IP locale localhost

MA MA MA

È il tuo indirizzo IP pubblico del tuo personal computer da cui stai tentando di accedere all'istanza di aws

1. Vai su https://www.whatismyip.com/ qualunque indirizzo IP inserito in ssh

SE VUOI APRIRE COMPLETAMENTE SSH A TUTTI GLI INDIRIZZI IP

ECCO COME SEMBRANO LE VOCI COMPLETAMENTE ACCESSIBILI - BASE RACCOMANDATO

QUESTO È QUELLO CHE STO USANDO NELLA PRODUZIONE

I seguenti sono possibili problemi:

• La più probabile è che il gruppo di sicurezza non sia configurato correttamente per fornire l'accesso SSH sulla porta 22 al tuo ip La modifica delle impostazioni di sicurezza non richiede il riavvio del server perché sia ​​efficace, ma è necessario attendere alcuni minuti affinché sia applicabile.

• La configurazione del firewall locale non consente l'accesso SSH al server. (puoi provare una connessione Internet diversa, il tuo telefono / dongle per provarlo)

• Il server non è avviato correttamente (quindi i controlli di accesso falliranno anche sulla console di Amazon), nel qual caso sarà necessario arrestare e avviare il server.

Consulta questa pagina della guida sui documenti AWS:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectionTimeout Probabilmente troverai la tua soluzione lì. per me questa parte ha fatto la correzione:

[EC2-VPC] Controlla la tabella di route per la sottorete. È necessaria una route che invii tutto il traffico destinato al di fuori del VPC al gateway Internet per il VPC.

• Apri la console Amazon VPC su https://console.aws.amazon.com/vpc/ .

• Nel riquadro di navigazione, scegli Internet Gateway. Verifica che al tuo VPC sia collegato un gateway Internet. Altrimenti, scegli Crea gateway Internet e segui le istruzioni per creare un gateway Internet, seleziona il gateway Internet, quindi scegli Collega a VPC e segui le istruzioni per collegarlo al VPC.

• Nel riquadro di navigazione, scegli Subnet e quindi seleziona la tua subnet.

• Nella scheda Route Table, verifica che sia presente una route con 0.0.0.0/0 come destinazione e il gateway Internet per il tuo VPC come destinazione. Altrimenti, scegli l'ID della tabella delle rotte (rtb-xxxxxxxx) per navigare nella scheda Rotte per la tabella delle rotte, scegli Modifica, Aggiungi un'altra rotta, inserisci 0.0.0.0/0 in Destinazione, seleziona il tuo gateway Internet da Destinazione, quindi scegli Salva.

Ma ti suggerisco di controllare tutte le opzioni che il link sopra copre, potresti trovare lì uno o più problemi che hai.

Il mio problema: avevo la porta 22 aperta per "Il mio IP" e ho cambiato la connessione Internet e il cambio di indirizzo IP causato. Quindi ho dovuto cambiarlo di nuovo.

Partendo dalla @ted.straussrisposta di, puoi selezionare SSHe MyIPdal menu a discesa invece di navigare in un sito di terze parti.

Riavvia semplicemente l'istanza Ec2 dopo aver applicato le regole

Consenti ssh e la porta 22 da ufw, quindi abilitalo e controlla con il comando status

sudo ufw allow ssh
sudo ufw allow 22
sudo ufw enable
sudo ufw status

Un'altra possibilità. I gruppi di sicurezza AWS sono configurati per funzionare solo con indirizzi IP in entrata specifici. Se il tuo gruppo di sicurezza è configurato in questo modo, tu (o il titolare dell'account) dovrai aggiungere il tuo indirizzo IP al gruppo di sicurezza. Per farlo, apri la dashboard AWS, seleziona i gruppi di sicurezza, seleziona un gruppo di sicurezza e fai clic sulla scheda in entrata. Quindi aggiungi il tuo IP come appropriato.

Ho riscontrato lo stesso problema e la soluzione è stata consentire l'accesso da qualsiasi luogo all'elenco delle regole in entrata nel gruppo di sicurezza attivo. Nella finestra di dialogo in entrata, inserisci 22 nell'intervallo di porte, ovunque nel campo di origine, e seleziona "ssh" nel menu a discesa.

PS: questa potrebbe non essere la soluzione consigliata in quanto significa che questa istanza può essere ssh'ed da qualsiasi macchina, ma non sono riuscito a farlo funzionare con il mio IP locale.

Ho avuto un problema simile, quando stavo usando il Wifi pubblico, che non aveva la password. Il passaggio dalla connessione Internet a una connessione sicura ha risolto il problema.

Se l'accesso SSH non funziona per la tua istanza EC2, devi controllare:

• Il gruppo di sicurezza della tua istanza consente l' accesso SSH in entrata (verifica: visualizza le regole ).

Se utilizzi un'istanza VPC (hai l' ID VPC e l' ID sottorete collegati all'istanza), controlla:

1. In VPC Dashboard, trova l'ID sottorete utilizzato che è collegato al tuo VPC.
2. Controlla la sua tabella di instradamento allegata che dovrebbe avere 0.0.0.0/0come destinazione e il tuo gateway Internet come destinazione.

Su Linux, puoi anche controllare le informazioni sul percorso nel registro di sistema in Rete dell'istanza, ad esempio:

++++++++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++++++++
+--------+------+------------------------------+---------------+-------+-------------------+
| Device |  Up  |           Address            |      Mask     | Scope |     Hw-Address    |
+--------+------+------------------------------+---------------+-------+-------------------+
|   lo   | True |          127.0.0.1           |   255.0.0.0   |   .   |         .         |
|  eth0  | True |         172.30.2.226         | 255.255.255.0 |   .   | 0a:70:f3:2f:82:23 |
+--------+------+------------------------------+---------------+-------+-------------------+
++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++
+-------+-------------+------------+---------------+-----------+-------+
| Route | Destination |  Gateway   |    Genmask    | Interface | Flags |
+-------+-------------+------------+---------------+-----------+-------+
|   0   |   0.0.0.0   | 172.30.2.1 |    0.0.0.0    |    eth0   |   UG  |
|   1   |   10.0.3.0  |  0.0.0.0   | 255.255.255.0 |   lxcbr0  |   U   |
|   2   |  172.30.2.0 |  0.0.0.0   | 255.255.255.0 |    eth0   |   U   |
+-------+-------------+------------+---------------+-----------+-------+

dove i UGflag che mostrano il tuo gateway Internet.

Per maggiori dettagli, consulta: Risoluzione dei problemi di connessione all'istanza su Amazon docs.

Per abilitare l'accesso SSH da Internet per le istanze in una sottorete VPC, procedi come segue:

• Collega un gateway Internet al tuo VPC.
• Assicurati che la tabella di route della tua subnet punti al gateway Internet.
• Assicurati che le istanze nella tua sottorete abbiano un indirizzo IP univoco globale (indirizzo IPv4 pubblico, indirizzo IP elastico o indirizzo IPv6).
• Assicurati che il controllo dell'accesso alla rete (a livello VPC) e le regole del gruppo di sicurezza (a livello ec2) consentano il flusso del traffico pertinente da e verso la tua istanza. Assicurati che il tuo indirizzo IP pubblico di rete sia abilitato per entrambi. Per impostazione predefinita, Network AcL consente tutto il traffico in entrata e in uscita tranne che diversamente configurato in modo esplicito

Per me era il server Apache ospitato su un'istanza EC2 linux t2.micro, non l'istanza EC2 stessa.

L'ho risolto facendo:

sudo su

service httpd restart

Ho avuto lo stesso problema e l'ho risolto aggiungendo una regola ai gruppi di sicurezza

SSH in entrata 0.0.0.0/0

Oppure puoi aggiungere solo il tuo indirizzo IP

Per me, era che avevo cancellato tutto dal volume di avvio. E non è più possibile connettersi all'istanza.

Stavo lavorando sull'istanza ed è andato tutto bene, il giorno successivo, quando ho provato ad accedere a SSH nella mia istanza, è stato visualizzato il messaggio - Timeout connessione.

Ho provato a leggere questo post ma non ha funzionato. Così ho fatto -

Nella Edit inbound rulescolonna from source scegli MY IPe popolerà automaticamente il tuo indirizzo IP pubblico in formato CIDR ( XXX.XXX.XXX.XX/32).

Ho provato con la risposta @ ted.strauss fornendo l'IP locale, ma nel mio caso non è stato d'aiuto. Quindi ho scelto il MIO IP e ha funzionato.

Spero che questo aiuti qualcuno!

eseguire prima il ping al DNS. Se fallisce, configura le tue regole in entrata / uscita nella procedura guidata di avvio. configurare TUTTO il traffico e TUTTO il protocollo e salvare con le opzioni predefinite. Ping di nuovo con il tuo sistema locale e poi dovrebbe funzionare

Se hai appena creato una nuova istanza e non riesci a connetterti ad essa, sono stato in grado di risolvere il problema terminando quella e creandone una nuova. Ovviamente funzionerà solo se si tratta di una nuova istanza e non hai più lavorato su di essa.