SSH ortak anahtarı sunucuya gönderilmiyor

Birkaç saat boyunca bununla mücadele ediyorum, bu yüzden herhangi bir yardım çok takdir ediliyor ...

Her ikisi de sshOSX’in ortak anahtarlarıyla yapabileceğim 2x sunucum var , sorun yok, bu yüzden her şeyin yolunda olduğundan eminim sshd_config.

rsyncİki sunucuyu eşitlemek için bir cron işi yapılandırmaya çalışıyorum ve B (yedek) sshsunucusunu bir genel anahtar kullanarak sunucu A'ya ihtiyaç duymaya çalışıyorum .

Hayatım boyunca neden açık anahtarımı bulamadığını çözemiyorum - bunlar ~/.ssh/içeride (yani. /root/.ssh) Ve tüm dosya izinleri A & B'de doğru.

Bu çıktı:

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Ayrıca, var olmayan özel anahtarları aradığını da unutmayın ...

drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root  403 May 25 01:37 authorized_keys
-rw-------. 1 root root    0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root  405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root  395 May 25 02:36 known_hosts

Ssh man sayfasına bir göz atın:

   -i identity_file
          Selects a file from which the identity (private key) for public
          key authentication is read.  The default is ~/.ssh/identity for
          protocol   version   1,   and  ~/.ssh/id_dsa,  ~/.ssh/id_ecdsa,
          ~/.ssh/id_ed25519 and ~/.ssh/id_rsa  for  protocol  version  2.
          Identity files may also be specified on a per-host basis in the
          configuration file.  It is possible to have multiple -i options
          (and  multiple  identities  specified  in configuration files).

veya ssh_config man sayfası:

   IdentityFile
          Specifies a file from which the user's DSA, ECDSA,  ED25519  or
          RSA   authentication   identity   is   read.   The  default  is
          ~/.ssh/identity for  protocol  version  1,  and  ~/.ssh/id_dsa,
          ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
          col version 2.  Additionally, any identities represented by the
          authentication  agent  will  be  used for authentication unless
          IdentitiesOnly is set.

Görüyorsunuz, bir anahtar belirtmezseniz, denenen birkaç özel dosya adı vardır. Bunlar, log çıktınızda gördüğünüz dosyalardır.

Farklı adda bir dosyada bir anahtar kullanmak için üç seçeneğiniz vardır:

• Yukarıdaki -iseçeneği kullanarak dosyayı açıkça belirtin .
• Yukarıdaki IdentityFileseçeneği kullanarak istemcinizdeki dosyayı yapılandırabilirsiniz .
• anahtarı kullanarak aracınıza ekleyin ssh-add.

Etkileşimli oturumlar için aracı en esnek olanıdır. Cron mesleğiniz için -iseçenek muhtemelen en kolay olanı.

Hedef ana bilgisayardaki hatalı biçimlendirilmiş bir yetkili_ anahtar dosyası, ssh'ın "bir paket göndermedik" iletisini çıkarıp pubkey auth kullanmak yerine bir parola istemesinin başka bir nedenidir: -

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method

Bu özel durumdaki sorun .ssh/authorized_keys, hedef konağa yapıştırılmış olan açık anahtar verilerinin ilk karakterinin eksik olmasıydı:

sh-rsa AAAA...

Çözüm basit "eksik" eklemek oldu.

ssh-rsa AAAA...

Ve bu yüzden:-

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).

Sorudaki bu tam hata mesajı dizisi , yerel taraftaki eşleşmeyen bir özel / ortak anahtar çifti durumunda da ortaya çıkabilir . Hayır, bu hiç mantıklı gelmiyor ama ben sadece neler olduğunu anlamaya çalışırken uzun zamandır saçlarımı yırttım.

• Uzak sistem A .ssh/mykey.pubkopyalandı .ssh/authorized_keys.
• Yerel sistem B, .ssh/mykeysistem A'nın genel anahtarıyla eşleşecek doğru özel anahtara sahip ancak aynı zamanda bir .ssh/mykey.pubeşleşmeyen, muhtemelen değiştirilmiş bir anahtarın önceki bir sürümü olan bir dosyaya sahip.

B'den A'ya SSH ( ssh -i mykey A), söz konusu iletilerde başarısız olur, özellikle -vvde ssh istemcisinden açarsanız şunu görürsünüz:

Özel anahtar deneniyor: .ssh / mykey
bir paket göndermedik, yöntemi devre dışı bırakın

Bu bir yalan çünkü gerçek anahtar denenmedi, görünüşe göre yerel ortak anahtar dosyasını, eşleşen bir olasılıkla işe yarayıp yaramadığını anlamak için kullandı ve daha sonra bir uyuşmazlık olduğunda hiçbir şey yapmadı. Her iki taraftaki hata ayıklama bilgilerinden hiçbiri sorunu gerçekten önemsemez.

Ssh'nin aradığı varsayılan dosya isimleri id_rsave id_rsa.pub.

Başka dosya adları kullanmak istiyorsanız, bunları ssh_config( IdentityFileayarı kullanarak ) veya ssh komut satırı parametresi ile belirtmeniz gerekir -i.

RedHat'ta da aynı sorunu yaşadım; kayıtları kontrol etti ve ana dizinin yanlış kullanıcı hakları olduğunu tespit etti.

sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user

Ev direktörü haklarının düzeltilmesi bunu çözdü.

Debian / Ubuntu'da hata ayıklamanın basit bir yolu şudur: Parola ile bağlan ve günlüğü kaydet

tail -f /var/log/auth.log

Başka bir terminalden bağlanmayı deneyin ve hatayı göreceksiniz ...

Benim durumumda / root dizini 770 idi ve 700 değildi, bu da varsayılan değerdi. Hata: "Kimlik doğrulama reddedildi: kötü sahiplik veya dizin / kök için modlar" idi.

Bunu düzelt ve bittin.

Deneyin

/sbin/restorecon -r /root/.ssh

Bağlam satış ile ilgili olası bir sorun

Koşudan sonra

ssh-copy-id user@remote-host

normalde çalışması gerekir. Ancak başarısız olursa, şunu deneyin: İleride oturum açmak ve çalıştırmak istediğiniz kullanıcı olarak uzak ana bilgisayara giriş yapın:

ssh-keygen

Bana yardımcı oldu.

Bu yüzden benim için olan şey, yerel makinemden erişmek için 2 VM'm olduğu (2 anahtar id_rsa.pub ve id_rsa2.pub). Ssh bağlantımın varsayılan olarak herhangi bir ssh user@xx.xx.xx.xx bağlantısı için id_rsa.pub kullandığını fark ettim. Bir config dosyası ekleyerek sorunumu çözdüm ve her ana bilgisayar için kullanılacak kimliği aşağıdaki gibi belirledim:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2

müşteri:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart