Amazon EC2 - Yeniden Başlatma Sonrası SSH Yok, Bağlantı Reddedildi

Bunu iki ya da üç kez kopyaladım, bu yüzden yaptığımla ilgili bir sorun var sanırım.

İşte adımlarım:

1. EC2 Yönetim konsolu üzerinden aşağıdakileri kullanarak yeni örneği başlatın: Ubuntu Server 13.10 - ami-ace67f9c (64-bit)
2. Varsayılanlarla başlat (mevcut anahtar çiftimi kullanarak)
3. Örnek başlar. Putty veya Mac terminalini kullanarak SSH yapabilirim. Başarı!
4. Örneği yeniden başlatırım

5. 10 dakika sonra, örneğin yedeklenmesi ve çalışması gerektiğinde, terminal bağlantım şunları gösterir:

   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$
   

İyi, genel IP adresinin değişebileceğini anlıyorum, bu yüzden EC2 yönetim konsolunu kontrol ederek, aynı olduğunu doğruladım. Tuhaf. Sadece eğlence için, genel DNS ana bilgisayar adı ile bağlanmayı deniyorum: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Zar yok, aynı sonuç.

EC2 konsolunda yerleşik Java SSH üzerinden Bağlan istemcisini kullanarak bile, Bağlantı Reddedildi.

Güvenlik gruplarını kontrol ettim. Bu örnek grup başlatma sihirbazı-4'te bulunur. Bu grup için gelen yapılandırmaya bakıldığında, Port 22'ye 0.0.0.0/0 tarihinden itibaren izin verilir, bu yüzden herhangi bir yerde olmalıdır. Örneğime vurduğumu biliyorum ve bu doğru güvenlik grubu, çünkü örneğe ping atamıyorum. Bu güvenlik grubu için ICMP'yi etkinleştirirsem, aniden pinglerim geçer.

İnternette benzer hata mesajlarına sahip birkaç yayın daha buldum, ancak çoğu güvenlik duvarı ayarlarını değiştirerek kolayca çözülebilir gibi görünüyor. Bunlardan birkaçını şanssız denedim.

Sanırım eksik olduğum basit bir EC2 adımı var. Verebileceğiniz herhangi bir yardım için teşekkürler ve daha fazla bilgi vermekten veya daha fazla test etmekten mutluluk duyuyorum!

Güncelleme - İşte Amazon EC2 konsolundan sistem günlüklerim: http://pastebin.com/4M5pwGRt

Bugün ec2 örneğimde benzer bir davranış vardı ve bunu izledi: Ne zaman ben sudo reboot now makineyi askıda kaldım ve bunu yaptığımda ne zaman aws yönetim konsolundan manuel olarak yeniden başlatmak zorundayım sudo reboot . Görünüşe göre "şimdi" burada belirtildiği gibi yeniden başlatma için geçerli bir seçenek değil /ubuntu/397502/reboot-a-server-from-command-line

düşünceler?

Gönderen Bu konu hakkında AWS Geliştirici Forumu yazı :

Bozuk örneği durdurmayı, EBS birimini ayırmayı ve başka bir örneğe ikincil birim olarak eklemeyi deneyin. Bozuk birimi diğer örnekte bir yere monte ettikten sonra, / etc / sshd_config dosyasını (altına yakın) kontrol edin. Yum'un sözdizimi hataları nedeniyle başlangıçta sshd'nin başarısız olmasına neden olan alt satırlara yinelenen satırlar ekleyerek sshd_config scrogged birkaç RHEL örnekleri vardı.

Düzelttikten sonra, ses seviyesini çıkarın, ayırın, diğer örneğinize yeniden takın ve tekrar çalıştırın.

AWS belgelerine bağlantılar vererek bunu yıkalım:

1. Bozuk örneği durdurun ve EC2 Yönetim Konsolu'na giderek "Elastik Blok Deposu"> "Birimler" i tıklatarak EBS (kök) birimini ayırın, durdurduğunuz örnekle ilişkili birimi sağ tıklatın.
2. Yeni bir örneği başlatın aynı bölgede ve kırık örneğiyle aynı OS sonra yeni örneğine ikincil hacim olarak orijinal EBS kök hacmini takmak . Aşağıdaki 4. adımdaki komutlar, birimi "veri" adlı bir klasöre bağladığınızı varsayar.
3. Bozuk birimi diğer örnekte bir yere monte ettikten sonra ,
4. şu komutları vererek "/ etc / sshd_config" dosyasını yinelenen girişler için denetleyin:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v Dosyanın altına ulaşmak için birkaç kez
   • ctrl-k "Parola olmadan PermitRootLogin" ve "UseDNS no" ifadelerini içeren tüm satırlar
   • ctrl-xve Ydüzenlenen dosyayı kaydedip çıkmak için
5. @Telegard (yorumunda) sadece semptomu düzelttiğimize dikkat çekiyor . "/Etc/rc.local" dosyasındaki ilgili 3 satıra yorum yaparak nedeni düzeltebiliriz . Yani:
   • cd /etc
   • sudo nano rc.local
   • "PermitRootLogin ..." satırlarını bulun ve silin
   • ctrl-xve Ydüzenlenen dosyayı kaydedip çıkmak için
6. Düzelttikten sonra, ses seviyesini çıkarın ,
7. EC2 Yönetim Konsolu'na giderek, "Elastik Blok Deposu"> "Birimler" i tıklayarak, durduğunuz örnekle ilişkili birime sağ tıklayarak,
8. diğer örneğinize yeniden ekleyin ve
9. tekrar ateşle .

Bu duruma hiç yardımcı olmayabilir, ancak EC2'de yeniden başlatmanın 'takılıp kaldığı' bazı durumlar gördüm. Sanal makinede bir 'sıfırlama' yapar ve ardından sistem günlüklerini yeniden denerseniz, davranışı değiştirebilir. Günlüklerin ilk önyüklemeden değil, ikinci önyüklemeden olduğundan emin olun - güncelleştirmelerde gecikme eğilimi gösterirler.

Kontrol edilmesi gereken bir diğer şey de örneğin IP'ye yanıt verdiğinden emin olmaktır. Yukarıda reddedilmiş bir bağlantı alıyor gibi görünüyorsunuz, bu örnek çalışıyor gibi görünüyor, ancak SSH çalışmıyor veya güvenlik duvarı çalışıyor, ancak örneğin tamamen yeniden başlatıldığından emin olun.

Ayrıca, bir test sistemindeki tüm bağlantı noktalarını açmayı deneyebilir ve 'nmap'in size gösterdiklerini görebilirsiniz - örneğin yanıt veren diğer hizmetler.

Örnek adını sağ tıklayın ve "Güvenlik Gruplarını Değiştir" i tıklayın. Oluşturduğunuz Güvenlik bağlantı noktasının herhangi bir yerden Bağlantı Noktası 22'ye izin veren Güvenlik grubunun işaretlendiğinden ve bu örneğe uygulandığından emin olun.

sudo reboot nowUbuntu 14.04 çalıştıran EC2 sunucumda SSH üzerinden yaptıktan sonra bu sorunu aldım . EC2 Yönetim Konsolu'nu kullanarak yeniden başlattıktan sonra iyi çalıştı.

Benim durumumda, yalnızca IP adresimden bağlantı noktası 22 bağlantılarına izin vermek için bir güvenlik grubu ayarladım. Birkaç gün sonra İSS'm IP adresimi değiştirdi, bu nedenle güvenlik grubunun güncellenmesi gerekiyor.

Benzer bir sorun yaşadım, EC2 Amazon Linux örneğime sudo yeniden başlatmayı çalıştırdıktan sonra erişilemedi .

Amazon yönetici konsolundan SSH erişimi, durdur / başlat / yeniden başlat komutları da bana sonuç vermedi.

Sonunda Amazon konsolu üzerinden bir görüntü oluşturarak örneğimi yeniden başlatabildim. Görüntü oluşturma işlemi örnek durumunu düzeltiyor gibi görünüyor.

Umarım yardımcı olur ;)

Vanilya sudo rebootkomutunu çalıştırdıktan sonra da aynı sorunu yaşadım . AWS konsolunu kullanarak AMI'mi tamamen durdurarak (yeniden başlatmama) ve ardından yeniden başlatarak sorunu çözebildiğimi buldum.

Durdurma ve sonra örneğinin başlatılmasını aksine yeniden başlatma eylemi tıklayarak olduğu gibi, AWS konsolundan AMI yeniden başlatmayı Sebebi ne olursa olsun, için, did not sorunu çözmek.

Belirtildiği gibi, muhtemelen / etc / fstab /

Bu sorunu yaşadım. Öncelikle, uyarı mesajının söylediği gibi / dev / sda1'deki birimi yeniden eklemeniz gerekir.

Sonra ssh yapamadım. Oluşturduğum diğer hacmi eklemem gerektiğini fark ettim ve bu ssh problemini çözdü.

Daha sonra giriş yapabilir ve fstab'ı orijinaline geri düzeltebilirsiniz.