SSH: “böyle bir kimlik yok”

5

SSH'nin Linux kutumda çalışmasını sağlama konusunda kendine özgü bir sorun yaşıyorum. Bir OpenSSH anahtarı ile tanımlanmış bir şifresiz git kullanıcısı var. Bunu, ağdaki aynı veya farklı bir Linux VM'den ssh yapmaya çalışırsam, başarısız olur (tam hata ayıklama bilgisi için aşağıya bakın).

Ama şimdi, işte tuhaf kısım: Windows 7 kutumdan tam aynı anahtarları kullanarak ssh yapabiliyorum ! Bu bana müşteri tarafında bir probleme baktığımızı gösteriyor. Sunucudaki anahtarlar bir şekilde toplanmışsa, hiçbir yerden bağlanamam.

Tekerleklerimi bu günlerde çamurda taşlıyorum. Konuyla ilgili tonlarca konu var, ancak çözümlerin hiçbiri işe yaramadı ya da uygulanmadı.

Zaten denedim ortak çözümler:

  1. ~ / .Ssh izinlerinin tümü hem istemci hem de sunucu üzerinde doğru şekilde ayarlandı.

    Spesifik olarak, ~ / .ssh / * 600 olarak ayarlandı (bir iş parçacığı yetkili_keys (sunucu) 644 olarak değiştirilmesini tavsiye etti, ancak bunun bir etkisi olmadı).

    ~ / .Ssh dizininin kendisi 700 olarak ayarlandı.

    ~ İçindeki her şey, adını taşıyan kullanıcı / gruba aittir.

    Müşteri (/home/kris/.ssh):

    drwx------  2 kris kris 4096 Apr 11 01:17 .
drwx------ 38 kris kris 4096 Apr 11 01:29 ..
-rw-------  1 kris kris  458 Apr 11 16:22 config
-rw-------  1 kris kris 1675 Apr 10 22:29 id_rsa_kriscraig_git
-rw-------  1 kris kris 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw-------  1 kris kris  400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw-------  1 kris kris 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw-------  1 kris kris  400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw-------  1 kris kris  951 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris
-rw-------  1 kris kris  214 Apr 10 22:29 id_rsa_kriscraig_gitolite_Kris.pub
-rw-------  1 kris kris  381 Apr 10 22:29 id_rsa_kriscraig_git.pub
-rw-------  1 kris kris 1626 Apr 11 17:50 known_hosts

    Sunucu (/home/git/.ssh; şu anda yaptığım tüm deneme / hata nedeniyle biraz karışık):

    drwx------ 2 git git 4096 Apr 11 01:36 .
drwx------ 8 git git 4096 Apr  9 17:55 ..
-rw-r--r-- 1 git git 2174 Apr 11 01:40 authorized_keys
-rw------- 1 git git  904 Aug  4  2012 authorized_keys_bak
-rw------- 1 git git  354 Aug  4  2012 authorized_keys_bak2
-rw------- 1 git git 2174 Apr 11 01:13 authorized_keys_bak3
-rw------- 1 git git  160 Apr 10 00:32 config
-rw------- 1 git git 1675 Aug  3  2012 id_rsa
-rw------- 1 git git 1675 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX
-rw------- 1 git git  400 Apr 11 01:08 id_rsa_kriscraig_git_CRAIGCOM-LINUX.pub
-rw------- 1 git git 1675 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3
-rw------- 1 git git  400 Apr 11 01:09 id_rsa_kriscraig_git_CRAIGCOM-UT3.pub
-rw------- 1 git git  951 Apr 10 00:32 id_rsa_kriscraig_gitolite_Kris
-rw------- 1 git git  214 Apr 10 00:33 id_rsa_kriscraig_gitolite_Kris.pub
-rw------- 1 git git  381 Aug  3  2012 id_rsa.pub
-rw------- 1 git git  414 Aug  4  2012 known_hosts

  2. Bu muhtemelen açık olmasına rağmen, aslında, config dosyasındaki dosya yollarının doğru olduğunu onayladım.

  3. Yeni anahtarlar üretmeyi / dağıtmayı birçok kez denedim.

    Herhangi bir kodlama sorunu (CRLF / LF, vb.) İle uğraşmadığımızdan emin olmak için dos2unix kullanmaya devam eden bile olsa, Windows'ta da çalışanları kopyalamayı / yapıştırmayı denedim.

    Anahtarları standart yaklaşımı kullanarak oluşturdum:

    ssh-keygen -t rsa

  4. Ana dizinin izinleriyle boşuna uğraşmayı denedim.

  5. Yerel yapılandırmalarla ve / etc / ssh / * _ config ile birlikte çalıştım.

    Ve evet, her seferinde sshd'yi yeniden başlattım. Sadece durumda bile sunucuyu rastgele aralıklarla yeniden başlattım.

  6. Eminim en azından birkaç şeyi özlüyorum. Son zamanlarda pek uyuyamadım ....

    Bu noktada herhangi bir öneride bulunacağım. Zaten denediğim ortaya çıkarsa, sizi oy kullanmaz. =)

Temel İstemci / Sunucu Bilgisi

Sunucu

  • CentOS 5.9 64 bit (VirtualBox)
  • 4 GB RAM
  • 200 GB HDD (dinamik ayırma)
  • 4 işlemci
  • Köprülü ağ iletişimi (hepsi aynı yönlendiriciye bağlanır)
  • Testler: Yok

Linux İstemcisi # 1

  • CentOS 5.9 64 bit (VirtualBox)
  • 1 GB RAM
  • 15 GB HDD (dinamik ayırma)
  • 1 işlemci
  • Köprülü ağ iletişimi
  • Testler: FAIL

Linux İstemcisi # 2

  • Sunucunun kendisi. Birkaç olasılıktan kurtulmak için iyi bir yol gibi göründü.
  • Testler: FAIL

Windows İstemcisi

  • Windows 7 Ultimate 64-bit (VirtualBox için ana bilgisayar)
  • 32 GB RAM
  • 200 GB HDD
  • 731 GB HDD
  • 232 GB HDD
  • 465 GB HDD
  • 2.72 TB HDD
  • 16 işlemci
  • Testler: BAŞARI

Hata Ayıklama Bilgisi (hassas veriler yeniden düzenlendi)

Sunucu

/ Var / log / secure'deki iki başarısız ssh girişiminin sonuç girdileri:

    Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14738]: Connection from (WAN IP) port 35326
    Apr 11 22:21:45 CRAIGCOM-LINUX sshd[14739]: Connection closed by (WAN IP)
    Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14741]: Connection from (WAN IP) port 35328
    Apr 11 22:21:52 CRAIGCOM-LINUX sshd[14742]: Connection closed by (WAN IP)

Linux İstemcileri (her ikisi için de aynıdır)

    [kris@CRAIGCOM-LINUX .ssh]$ ssh git@CRAIGCOM-LINUX -vvv
    OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
    debug1: Reading configuration data /home/kris/.ssh/config
    debug1: Applying options for CRAIGCOM-LINUX
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Applying options for *
    debug2: ssh_connect: needpriv 0
    debug1: Connecting to (SERVER HOST) [(SERVER IP)] port 22.
    debug1: Connection established.
    debug1: identity file "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" type -1
    debug1: loaded 1 keys
    debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
    debug1: match: OpenSSH_4.3 pat OpenSSH*
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_4.3
    debug2: fd 3 setting O_NONBLOCK
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: first_kex_follows 0 
    debug2: kex_parse_kexinit: reserved 0 
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: 
    debug2: kex_parse_kexinit: first_kex_follows 0 
    debug2: kex_parse_kexinit: reserved 0 
    debug2: mac_init: found hmac-md5
    debug1: kex: server->client aes128-ctr hmac-md5 none
    debug2: mac_init: found hmac-md5
    debug1: kex: client->server aes128-ctr hmac-md5 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug2: dh_gen_key: priv key bits set: 118/256
    debug2: bits set: 484/1024
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug3: check_host_in_hostfile: filename /home/kris/.ssh/known_hosts
    debug3: check_host_in_hostfile: match line 1
    debug1: Host '(SERVER HOST)' is known and matches the RSA host key.
    debug1: Found key in /home/kris/.ssh/known_hosts:1
    debug2: bits set: 522/1024
    debug1: ssh_rsa_verify: signature correct
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug2: service_accept: ssh-userauth
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug2: key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX" ((nil))
    debug1: Authentications that can continue: publickey,gssapi-with-mic,password
    debug3: start over, passed a different list publickey,gssapi-with-mic,password
    debug3: preferred publickey
    debug3: authmethod_lookup publickey
    debug3: remaining preferred: 
    debug3: authmethod_is_enabled publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
    debug3: no such identity: "/home/kris/.ssh/id_rsa_kriscraig_git_CRAIGCOM-LINUX"
    debug2: we did not send a packet, disable method
    debug1: No more authentication methods to try.
    Permission denied (publickey,gssapi-with-mic,password).

Burası benim sıkışıp kaldığım yer

Günlükten görebileceğiniz gibi, özel anahtar dosyasını açmaya çalıştıktan sonra "böyle bir kimlik yok" döndürüyor. Bence bu reddetme müşteri tarafında gerçekleşiyor. Söyleyebileceğim kadarıyla, herhangi bir şekilde sunucuya bir şey yollamıyor; sadece bağlantıyı açma ve aniden kapatma.

Hayatım boyunca, neden her iki CentOS kutusundaki anahtar dosyalarda neden korktuğunu çözemiyorum! İzinler mükemmel bir şekilde ayarlanmış, dosyalar okunabilir, ne de sunucu SELinux kullanıyor, aynı anahtarlar Windows istemcisinden mükemmel çalışıyor.

Sysadmin şapkasını takmakta iyiyim; ama günün sonunda ben bir geliştiriciyim, bir BT çalışanı değilim. Bu SSH hata ayıklama seviyesi beni uzmanlık alanımın dışına çıkardı. Söylemekten nefret ediyorum, ama basitçe fikir tükendi. İnternette bulabildiğim her şeye göre, bu çalışıyor olmalı. Ama değil. Neyi kaçırıyorum?

Yardımınız için teşekkürler! Umarım, biriniz bu sorunu tanıyacak ve kıçımı doğru yöne başlatacaksınız. Daha fazla ayrıntıya ihtiyacınız olursa, lütfen sormaya çekinmeyin.

--Kris

linux  git  ssh  centos  openssh 
— Kris Craig
kaynak
Ah ve evet, uygun genel anahtar dizeleri yetkili_keylere eklendi. Ama dediğim gibi, o kadar uzağa gideceğini bile sanmıyorum.
Dışarıda bırakacağım tek şey, sunucunun (müşteri # 2) ve müşteri # 1'in doğru makinede konuşmasıdır. Bağlanmak için DNS veya IP kullanıp kullanmadığınızdan bahsetmediniz (örnekleminiz CRAIGCOM-LINUX adını kullanıyor olsa da).
— tink
Bunu sunucuda / var / log / secure kontrol ederek doğruladım. Her seferinde bağlantıları alıyordu; Ancak, Linux istemcileri bağlantıları açtıktan hemen sonra herhangi bir veri göndermeden aniden kapattılar.
1
@calspring Mesajın tamamını okudunuz mu? İzinleri doğrulamak ilk denediğim şeydi. Ayrıca, bunun Gitolite ile ilgisi yok. Gitolite kimlik bilgileri reddedilenler değildir. Reddedilen kimlik bilgileri, sunucunun kendisine bağlanmak için kullanılanlardır. Kayıtlar bunu çok net bir şekilde verdim, bu yüzden yazımın çoğunu okumadığınız izlenimini edindim.
— Kris Craig,
1
Donanım özellikleri göz önüne alındığında, iyi bir QA mühendisi, bir faktör olma ihtimali düşük olsa bile, bu gibi değişkenleri asla iskonto etmez. Böyle bir sorunu gidermenin en iyi yolu, test sonuçlarının güvenilirliğini sağlamak için bilinmeyen değişkenlerin minimumda tutulmasını talep eden Bilimsel Yöntemi kullanmaktır. Donanım özelliklerini çok net bir şekilde ayırdım, böylece daha uygun verileri etkilemeyeceklerdi.
— Kris Craig,

Yanıtlar:

2

Lütfen ssh-agent'ı kullanın.

  • İlk ajana anahtar ekleyin: ssh-add ~/.ssh/$keyfile.
  • Ardından, anahtarın başarıyla yüklendiğini doğrulayın: ssh-add -l
  • Ardından uzaktaki kutunuza ssh göndermeyi deneyin. (Aracı kimlik doğrulamasını yapmalıdır.)

Anahtarınızda gerçekten bir sorun varsa, eklemeye çalıştığınızda bir kez fark etmeniz gerekir.

— Michas
kaynak
Bu aslında, manuel olarak atılmış olan adımları otomatikleştiriyordu. Ssh-agent programı, en azından söyleyebileceğim kadarıyla, daha önce yapılmayan hiçbir şeyi yapmaz.
— Kris Craig,
Ssh-agent'ın amacı, anahtar yönetimini gerçek bağlantıdan ayırmak ve bu nedenle durumunuzu hata ayıklamak için mükemmel bir araçtır. Sonuca bağlı olarak, sorunun nereye bakılacağını bilirsiniz. - Bu nedenle tekrar soru: ssh-add, anahtarınızı sorunsuz bir şekilde içe aktarabiliyor mu?
— michas,
~ / .Ssh dizinini geçemediğiniz anlaşılıyor sudo ssh -i id_rsa_kriscraig_git_CRAIGCOM-LINUX kullanıcısı @ ip'i deneyin, bu işe yararsa chmod + x ~ / .ssh / * ve chmod 700 ~ / .ssh chmod 600 ~ / .ssh / *
— linuxdev2013 15:15
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.