it-swarm-tr.com

Yerel Ubuntu'dan Amazon EC2 sunucusuna SSH'ye çalışırken neden "İzin reddedildi (publickey)" alıyorum?

Amazon EC2 örneğinde bulutta çalışan bir uygulamanın örneğim var ve bunu yerel Ubuntu'mdan bağlamam gerekiyor. Yerel ubuntu ve ayrıca dizüstü bilgisayarda iyi çalışıyor. Başka bir yerel Ubuntu üzerinde EC2 SSH'ye erişmeye çalışırken "İzin reddedildi (publickey)" mesajı aldım. Benim için çok garip.

Bir örnek veya sertifikaya sınırlı IP erişimi olan Amazon EC2'deki güvenlik ayarlarıyla ilgili bir takım sorunların yeniden oluşturulması gerekebilir.

Bir çözüm bilen var mı?

217
Vorleak Chy

Bu durumda yapılacak ilk şey -v seçeneği ssh seçeneğiyle, hangi kimlik doğrulama türlerinin denendiğini ve sonucun ne olduğunu görebilirsiniz. Bu durumun aydınlanmasına yardımcı olur mu?

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

143
Greg Hewgill

Açıkça belirtilmediğinden, sshd varsayılan olarak authorized_keys Dosyalarının izinleri konusunda çok katıdır. Bu nedenle, authorized_keys Kullanıcı dışında herhangi biri için yazılabilir ise veya yazılabilir hale getirilebilir kullanıcı dışındaki herhangi biri tarafından onaylanırsa, kimlik doğrulamasını ( sshd StrictModes no ile yapılandırılmadığı sürece)

"Yazılabilir yapılabilir" ile kastettiğim, ana dizinlerden herhangi biri kullanıcı dışında herhangi biri için yazılabilirse, bu dizinleri değiştirmesine izin verilen kullanıcıların izinleri değiştirilebilecek/değiştirilecek şekilde izinleri değiştirmeye başlayabilmesidir.

Ayrıca, /home/username/.ssh Dizini kullanıcıya ait değilse ve bu nedenle kullanıcının anahtarı okuma izni yoksa, sorunlarla 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 .ssh Dosyasına sahip olmadığını unutmayın. Bunu şu yolla düzeltin:

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

Bu tür dosya sistemi izin sorunları ssh -v İle görünmez ve günlük düzeyini DEBUG olarak ayarlayana kadar sshd günlüklerinde (!) Görünmez.

  • /etc/ssh/sshd_config Düzenleyin. Orada bir yerde LogLevel DEBUG Yazan bir satır istiyorsunuz. Dağıtım tarafından sağlanan mekanizmayı kullanarak SSH sunucusunu yeniden yükleyin. (service sshd reload RHEL/CentOS/Scientific'te.) Zarif bir yeniden yükleme mevcut oturumları düşürmez.
  • Kimlik doğrulamayı tekrar deneyin.
  • Kimlik doğrulama tesisinizin günlüklerinin nereye gittiğini öğrenin ve okuyun. (IIRC, Debian tabanlı dağıtımlarda /var/log/auth.log; RHEL/CentOS/Scientific'te /var/log/secure.)

Dosya sistemi izin hataları içeren hata ayıklama çıktısında neyin yanlış gittiğini bulmak çok daha kolay. İşiniz bittiğinde /etc/ssh/sshd_config Değişikliğini geri almayı unutmayın!

76

Bu hatayı aldım, çünkü -l seçeneği. Yerel kullanıcı adım uzaktaki sistemle aynı değildi.

Bu, sorunuza cevap vermiyor, ama buraya sorunuma bir cevap arıyorum.

37
pkmk

Bu mesajı Ubuntu AMI tabanlı yeni bir örnekte aldım. PEM sağlamak için -i seçeneğini kullanıyordum ama yine de "İzin reddedildi (publickey)" gösteriliyordu.

Benim sorunum doğru kullanıcıyı kullanmıyordu. Ssh'ı ubuntu @ ec2 ile çalıştırarak ... normal gibi çalıştı.

19
user60587

ssh -v 'Dan (elbette bana göre) okunması daha kolay bir şey tail -f /var/log/auth.log. Bağlanmaya çalıştığınızda, bağlanmaya çalıştığınız sunucuda çalıştırılmalıdır. Hataları düz metin olarak gösterir.

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

Kullanıcı gruplarının hiçbiri AllowGroups'da listelenmediği için xx.yy.com sitesinden [kullanıcı adı] kullanıcısına izin verilmiyor

16
Znarkus

/ etc/ssh/sshd_config dosyanızı kontrol edin. Orada, şu satırı bulun:

PasswordAuthentication no

Bu satır, hayır yerine evet diyecek şekilde değiştirilmelidir. Ayrıca, daha sonra sshd sunucusunu yeniden başlatın.

Sudo /etc/init.d/ssh restart
10

Belki şu anki posterle alakalı değildir, ancak benzer durumlara cevap ararken bunu bulanlara yardımcı olabilir. Amazon'un ssh anahtar çiftini oluşturmasına izin vermek yerine, Amazon'a kendi, standart, varsayılan genel ssh anahtarınızı yüklemenizi ve bir EC2 örneği çalıştırdığınızda bunu belirtmenizi öneririm.

Bu, "-i" türü sözdizimini ssh'a bırakmanıza, rsync'i standart seçeneklerle kullanmanıza ve aynı ssh anahtarını tüm EC2 bölgelerinde kullanmanızı sağlar.

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

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

6
Eric Hammond

Garip bir şekilde, sorunum sunucunun yeniden başlatılmış olması ve yeni bir DNS adı verilmiş olmasıydı. Eski DNS adını kullanıyordum. Bunun kulağa aptalca geldiğini biliyorum ama bunu çözmem biraz zaman aldı.

5
Patrick Collins

Dropbear çalıştıran bir CyanogenMod telefonuna 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üzeltildi, aksi takdirde hiçbir şey bağlanamaz.

2
Naftuli Kay

CentOS 5 kullanıyorsanız, StrictModes no içinde /etc/ssh/sshd_config. NIS/NFS kullanarak/home dizinini paylaşıyorum ve tüm izinleri doğru bir şekilde ayarladım, ancak her zaman parola ile bana soruldu. StrictModes no, sorun kayboldu!

2
uichin

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

$ ec2-authorize default -p 22

Ancak, örneğime biz-batı-1 bölgesinde başlamıştım. Dolayısıyla yukarıdaki komut da bunu belirtmelidir.

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

Bu komuttan sonra örneği ssh edebildim. Sorunu fark etmeden önce biraz zaman geçirdim ve bu yazının başkalarına yardımcı olacağını umuyorum.

1
Ajit Verma

Greg'in cevabı, nasıl daha iyi çekim yapılacağını açıklıyor, ancak asıl sorun, parola tabanlı kimlik doğrulaması yerine ortak anahtar kimlik doğrulaması yapmaya çalışan işlemin (istemcinin) bir tarafında bir ssh anahtarı ayarlamanızdır. EC2 örneğinde ilgili ortak anahtara sahip olmadığınız için, bu işe yaramaz.

1
Cian

Aynı sorunu yaşadım ve işe yaramayan tonlarca çözümü denedikten sonra yönlendiricimin güvenlik duvarındaki SSH bağlantı noktasını açtım (yönlendiricimin güvenlik duvarı kontrol paneli bir karışıklık, bu yüzden neler olduğunu söylemek zor). Her neyse, bu düzeltildi :)

Süper Aldığınız hatanın İzin Verilmediği kanlı can sıkıcı, bir çeşit bağlantının olduğunu ima ediyor, grr.

1
chichilatte

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

Bunun [tail -f /var/log/secure makinede ve Authentication refused: bad ownership or modes for directory /home/<username>.

0
Jacob Tomlinson

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

0
Reese