Yerel Ubuntu’dan bir Amazon EC2 sunucusuna SSH’ye girmeye çalışırken neden “İzin verilmedi” (publickey) alıyorum?

Amazon EC2 örneğindeki bulutta çalışan bir uygulamanın bir örneğim var ve onu yerel Ubuntu'mdan bağlamam gerekiyor. Yerel ubuntu birinde ve ayrıca dizüstü bilgisayarda iyi çalışıyor. Başka bir yerel Ubuntu'da SSH’ye EC2’ye erişmeye çalışırken "İzin engellendi (publickey)" mesajı alıyorum. Bu benim için çok garip.

Amazon EC2'de, bir örneğe veya sertifikaya sınırlı IP erişimi olan güvenlik ayarlarıyla ilgili bazı sorunların yeniden oluşturulması gerekebileceğini düşünüyorum.

Bir çözüm bilen var mı?

Bu durumda yapılacak ilk şey, -vseçeneğinin kullanılmasıdır; sshböylece hangi kimlik doğrulama türlerinin denendiğini ve sonucun ne olduğunu görebilirsiniz. Bu durumun aydınlanmasına yardımcı oluyor mu?

Sorunuzla ilgili güncellemenizde "başka bir yerel Ubuntu'dan" bahsediyorsunuz. Ssh özel anahtarını diğer makineye kopyaladınız mı?

Açıkça ifade edilmemiştir gibi, sshd için üzerinde izinlere çok sıkı varsayılan olarak authorized_keysdosyaları. Yani, eğer authorized_keysolduğunu yazılabilir kullanıcı dışında veya bir başkası için yazılabilir yapılabilir (sshd ile yapılandırılmış sürece kullanıcı dışında kimse tarafından, bu kimlik doğrulaması reddedebilir edeceğiz StrictModes no)

"Yazılabilir hale getirilebilir" ile kastettiğim, üst dizinlerden herhangi birinin kullanıcı dışındaki herhangi biri için yazılabilir olması durumunda, bu dizinleri değiştirmesine izin verilen kullanıcıların izinleri değiştirebilecek / değiştirebilecek şekilde değiştirmeye başlayabilmeleridir.

Ayrıca, /home/username/.sshdizin kullanıcıya ait değilse ve dolayısıyla kullanıcının anahtarı okuma iznine sahip değilse, sorunla karşılaşabilirsiniz:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Jane'in .sshdosyaya ait olmadığını unutmayın . Bu ile düzelt

chown -R jane:jane /home/jane/.ssh

Bu tür dosya sistemi izin sorunları ortaya ssh -vçıkmaz ve günlük düzeyini DEBUG olarak belirleyene kadar sshd günlüklerinde (!) Görünmezler.

• Düzen /etc/ssh/sshd_config. LogLevel DEBUGOrada bir yerde okuyan bir çizgi istiyorsun . Dağıtım tarafından sağlanan mekanizmayı kullanarak SSH sunucusunu yeniden yükleyin. ( service sshd reloadRHEL / CentOS / Scientific'te.) Zarif bir yeniden yükleme mevcut oturumları bırakmayacaktır.
• Kimlik doğrulamayı tekrar deneyin.
• Kimlik doğrulama tesisinizin kayıtlarının nereye gittiğini ve bunları okuduğunu öğrenin. (IIRC, /var/log/auth.logDebian merkezli dağıtımlarda; /var/log/secureRHEL / CentOS / Scientific'te).

Dosya sistemi izin hatalarını içeren hata ayıklama çıktısında neyin yanlış gittiğini hesaplamak çok daha kolay. Değişikliği /etc/ssh/sshd_configne zaman yaptığınıza geri döndürmeyi unutmayın !

-lSeçenek eklemeyi unuttuğum için bu hatayı aldım . Yerel kullanıcı adım uzak sistemdeki ile aynı değildi.

Bu, sorunuzu cevaplamıyor, ancak sorunumu cevaplamak için buraya geldim.

Bu mesajı Ubuntu AMI'yi temel alan yeni bir örnek aldım. PEM'yi sağlamak için -i seçeneğini kullanıyordum ama yine de "İzin reddedildi (publickey)" gösteriyordu.

Benim sorunum doğru kullanıcıyı kullanmamamdı. Ssh ubuntu @ ec2 ile çalıştırılarak ... normal şekilde çalıştı.

Okumaktan daha kolay bir şey ssh -v(elbette bence) tail -f /var/log/auth.log. Bağlanmaya çalışırken, bağlanmaya çalıştığınız sunucuda çalıştırılmalıdır. Düz metinde hatalar gösterecektir.

Bu, sorunumu çözmeme yardımcı oldu:

Kullanıcı grubunun hiçbiri AllowGroups'da listelenmediğinden xx.yy.com kullanıcısının [kullanıcı adı] kullanımına izin verilmiyor

/ Etc / ssh / sshd_config dosyanızı kontrol edin . İşte, söyleyen çizgiyi bul.

PasswordAuthentication no

Bu çizginin hayır yerine evet demek için değiştirilmesi gerekiyor. Ayrıca, sshd sunucusunu daha sonra yeniden başlatın.

sudo /etc/init.d/ssh restart

Belki de mevcut posterle alakalı olmayabilir, ancak benzer durumlara cevap ararken bunu bulan başkalarına yardımcı olabilir. Amazon’un ssh keypair’i oluşturmasına izin vermek yerine, kendi standart, varsayılan public ssh anahtarınızı Amazon’a yüklemenizi ve bir EC2 örneği çalıştırdığınızda bunu belirtmenizi öneririm.

Bu, "-i" tipi sözdizimini ssh'ye bırakmanıza, rsync'i standart seçeneklerle kullanmanıza ve aynı ssh anahtarını tüm EC2 bölgelerinde kullanmanıza izin verir.

Bu süreç hakkında burada bir makale yazdım:

Kişisel ssh Anahtarlarını Amazon EC2’ye Yükleme
http://alestic.com/2010/10/ec2-ssh-keys

Garip bir şekilde benim sorunum, sunucunun yeniden başlatıldığı ve yeni bir DNS adı verildiği ortaya çıktı. Eski DNS adını kullanıyordum. Kulağa aptalca geldiğini biliyorum ama bunu anlamak biraz zaman aldı.

Dropbear'ın çalıştığı bir CyanogenMod telefona bağlanmaya çalışıyorsanız, her şeyin izin verildiğinden emin olmak için aşağıdaki satırları çalıştırmalısınız:

chmod 600 /data/dropbear/.ssh/authorized_keys

veya

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

ve

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Bu benim için düzeltti, aksi halde hiçbir şey bağlanamaz.

Eğer CentOS 5 kullanıyorsanız, size ayarlamak isteyebilirsiniz StrictModes noiçinde /etc/ssh/sshd_config. NIS / NFS kullanarak / home dizinini paylaşıyorum ve tüm izinleri doğru bir şekilde ayarlıyorum, ancak her zaman parolayı sordu. Ayarladıktan sonra StrictModes nosorun ortadan kalktı!

Greg'in cevabı nasıl daha iyi çekebileceğini açıklıyor, ancak asıl sorun, parola tabanlı kimlik doğrulaması yerine genel anahtar kimlik doğrulaması yapmaya çalışan işlemin (müşteri) bir tarafında ayarlanmış bir ssh anahtarına sahip olmanız. EC2 örneğinde ilgili ortak anahtara sahip olmadığınız için bu işe yaramaz.

Aynı problemi yaşadım ve çalışamayan tonlarca çözümü denedikten sonra yönlendiricimin güvenlik duvarındaki SSH portunu açtım (yönlendiricimin güvenlik duvarı kontrol paneli bir karmaşa, bu yüzden ne olduğunu söylemek zor). Neyse, bu düzeltti :)

Aldığınız hatanın sinirini bozan süper kanlı izin reddedildi, bu da bir tür bağlantı yapıldığını ima ederek grr.

Ben de dahil olmak üzere tüm adımları sözde olsa bile aynı sorunu yaşıyordum

$ ec2-authorize default -p 22

Ancak, örneğimi ABD-Batı-1 bölgesinde başlatmıştım. Bu yüzden yukarıdaki komut da bunu belirtmelidir.

$ ec2-authorize default -p 22 --region us-west-1

Bu komuttan sonra örneğe girebildim. Sorunu fark etmeden önce biraz zaman harcadım ve bu yazının başkalarına yardımcı olmasını umuyorum.

Bu nadir bir durumdur, ancak selinux'u etkinleştirdiyseniz ve onaylanmış nkeylerle dizinde nfs kullanıyorsanız (örn. Paylaşılan ev dizinleri), selinux'u devre dışı bırakmanız gerekir (güvenlik nedeniyle önerilmez), ancak geçici olarak devre dışı bırakabilirsiniz. bunun soruna neden olup olmadığını görmek için) veya selinux'un nfs ana dizinini kullanmasına izin verin. Detaylar konusunda net değilim, ama bu benim için çalıştı. setsebool -P use_nfs_home_dirs 1

Aynı sorunu, yanlışlıkla istemcilerin kullanıcılar giriş dizinine grup yazma izinleri ekledikten sonra yaşadım.

tail -f /var/log/secureMakinede çalışan ve hatayı görerek nedeni olduğunu keşfettim Authentication refused: bad ownership or modes for directory /home/<username>.