ssh, ssh-copy-id değerine rağmen parola ister

Uzaktaki bir sunucuda genel anahtar kimlik doğrulamasını bir süredir uzak kabuk kullanımı için ve sshfs bağları için kullanıyorum. Benim sshfs dizininin bir miktarını zorladıktan sonra, ssh'nin beni bir şifre sormaya başladığını fark ettim. Herhangi bir yerel makineden uzaktaki .ssh / yetkili_ anahtarlarını temizlemeyi denedim ve yerel makineyi uzaktaki makineye yapılan referanslardan temizledim. Daha sonra ssh-copy-id numaramı tekrar ettim, bu şifre sormamı istedi ve normal şekilde geri döndü. Ama bakalım, uzaktaki sunucuya ssh gönderdiğimde hala bir şifre soruluyor. Sorunun ne olabileceği, herhangi bir önerim konusunda biraz kafam karıştı.

sshd, $ HOME, $ HOME / .ssh (her iki dizin) ve $ HOME / .ssh / onaylı_keys üzerindeki izinler konusunda garipleşir.

Linux kutularmdan biri $ HOME dizininde drwxrwxrwx izinlerine sahipti. Arch linux kutusu, $ HOME dizinindeki diğer grup için 'w' iznini silene kadar kesinlikle ortak anahtarlar kullanarak giriş yapmaz.

$ HOME ve $ HOME / .ssh yapmayı deneyin / grup ve diğerleri için daha kısıtlayıcı izinlere sahip olun. Bakalım bu sshd'nin işini yapmasına izin vermiyor mu?

Aşağıdaki izinler gerekli:

• .sshklasör:700 (drwx------)
• Genel anahtar: 644 (-rw-r--r--)
• Özel anahtar: 600 (-rw-------)

Son zamanlarda bu sorunu da yaşadım.

$HOMEDizinin izinleri değiştirilerek düzeltildi . Ancak, basitçe çalışan chmod g-w ~/sorunu düzeltmedi. Buna ek olarak , dizinde çalıştırılan dizinin chmod g-w ~/izinlerini değiştirmem gerekiyordu.others$HOMEchmod o-wx ~/

Birlikte:

chmod g-w ~/
chmod o-wx ~/

Gerekir mi emin değilim o-x, sadece önlem olarak koştum unutmayın.

~ / .Ssh klasörü için izinlerin değiştirilmesi, Süper Kullanıcı SE'deki bu yayına göre sorunumu çözdü .

Sorun, paralel oturum açmalarda da mı ortaya çıkıyor, yani açık bir ssh oturumu yaparken sshfs'i bağlamaya çalışırsanız? Olmazsa, o zaman ana dizininizin şifrelenmiş olduğunu tahmin ediyorum. Bu durumda $HOME/.ssh/authorized_keys, uzak makinede yalnızca ilk girişinizden sonra (şifrenizi kullanarak) kullanılabilir.

Check out https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Troubleshooting bir açıklama ve gereken geçici çözüm için.

Bunu bir yorum olarak gönderirdim, ama muhtemelen çok uzun olurdu. Ben sadece eklemek istediğim ssh-copy-id, ortak anahtarı klasörünüzün /.sshiçindeki konumdan göndermeye çalışmak $HOME.

Eğer sshbir ortak anahtarla kök olarak çalışıyorsanız (güvenlikle ilgili yorumları kaydedin), değişkeniniz başka bir şeye ayarlanmışsa (normal kullanıcının ana klasörüne ayarlanmış gibi) ssh-copy-idyanlış ortak anahtarla giriş yapmaya çalışıyor olabilirsiniz. bu nedenle, kök kullanıcının ortak anahtarı uzaktaki sistemde yüklü olmadığı için kök kullanıcıdan istenir.$HOME/root

Tam ortak anahtarı belirtmek için aşağıdaki tek astarı kullanabilirsiniz:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

Bu senaryo ile birkaç kez (bu sabah da dahil olmak üzere) vahşi doğada karşılaştım ve birinin kendisini aynı durumda bulması ihtimaline karşı 2 sentimi kullanmaya çalışacağımı düşündüm.

Bahsedilen diğer katkıda bulunanlar gibi, bu muhtemelen bir izin sorunudur.

Bunu teşhis etmenin en iyi yolu uzak sunucudaki SSH arka planını, genellikle "-d" seçeneği olan hata ayıklama seçeneğiyle yeniden başlatmaktır. OpenSSH daemon mesajı çok açık. Örneğin, aşağıdaki gibi mesajları göreceksiniz:

Authentication refused: bad ownership or modes for directory /some/path

Genel anahtarın yeniden başlatma sonrası hayatta kalmamasının nedeni, sunucumun ana dizininin şifrelenmiş olmasıdır. (bunu sunucuyu kurarken yaparsınız)

Başka bir olası sorun da sunucunun anahtar algoritmanızı desteklememesidir. Benim durumumda, sshdgünlüklerimde şu mesajları buldum ( /var/log/auth.logbenim durumumda):

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

Bu durumda, sshdyapılandırmanızda bu algoritma desteğini etkinleştirmeniz (daha yeni bir sshdsürüm için güncelleme gerektirebilecek ) veya anahtarınızı sshdbağlanmaya çalıştığınız tarafından desteklenen bir algoritmaya geçirmeniz gerekir. .

Bu davranış, bu davranışa googling yaparken ilk arama sonuçları arasında göründüğü için, çözümümü de ekleyeceğim:

Benim durumumda izinlerle ilgili hiçbir şey yoktu. Herhangi bir nedenden ötürü (hızlı bir düzeltme bulduğum için aslında hangi sebepten dolayı olduğumu bulmak için kendimi rahatsız etmedim) ssh komutunu çalıştırırken program doğru kimlik dosyasını aramamış. Çözümlerden biri, uzaktaki sunucuya, SSH programının kullanmaya çalıştığı bir SSH anahtarı el ile eklemekti. Komutu çalıştırırken SSH programının ne yaptığını gözlemleyebilirsiniz: -v ekleyerek:

ssh -v username@your-host-ip-or-domain 

Ardından, yerel makinenizde, SSH programının bir Mac'te bir kimlik dosyası / özel anahtar bulmaya çalıştığı herhangi bir genel anahtarı alırsınız, örneğin:

cat ~/.ssh/id_rsa.pub

... ve kumandanın yetkili_keys dosyasına ekleyin:

~/.ssh/authorized_keys

Başka bir, benim durumumda daha iyi bir çözüm yerel ssh config dosyama özel bir ana bilgisayar eklemek oldu. Mac'imde:

/Users/my-user-name/.ssh/config

Burada örneğin şunun gibi bir şey ekleyebilirsiniz:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

O zaman uygulamanız yeterlidir:

ssh mynewserver

... ve Voilà