SSH ana bilgisayarı doğrulama hatalarını işlemek için en sorunsuz iş akışı?

Bu, hepimizin karşılaştığı ve muhtemelen fazla düşünmeden elle çözdüğü basit bir konudur.

Sunucular değiştikçe, yeniden sağlandıklarında veya IP adreslerinin yeniden tahsis edilmesinden dolayı, aşağıdaki SSH ana bilgisayar doğrulama mesajını alırız. Bu ssh tanımlama hatalarını çözmek için iş akışını kolaylaştırmakla ilgileniyorum.

Aşağıdaki mesaj göz önüne alındığında, genellikle vi /root/.ssh/known_hosts +434ve ddrahatsız edici satırı kaldırır ( ).

Diğer kuruluşlardaki geliştiricilerin / kullanıcıların bu mesajı görmedeki tüm known_hosts dosyalarının sıkıntıdan silindiğini gördüm . O kadar ileri gitmesem de, bununla baş etmenin daha zarif bir yolu olduğunu biliyorum.

İpuçları?

[root@xt ~]# ssh las-db1

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.

ssh-keygenBelirli girdileri ana bilgisayardan kaldırmak için komutu kullanabilirsiniz :

ssh-keygen -R las-db1

Bu komutu yoksa, her zaman sed kullanabilirsiniz:

sed -i '/las-db1/d' /root/.ssh/known_hosts

Bir kukla kullanıcısı olarak, bunu çözme yöntemim aslında kukla sunucumun SSH ana bilgisayar anahtarlarımı toplamasını ve bunları SSH bağlantısı yapan tüm sistemlerimde yayınlamasını sağlamaktır.

Bu şekilde onları kaldırmak için endişelenmeme gerek yok. Her otuz dakikada bir ajanlarımı çalıştırdığımdan beri, kuklaların yüzde doksan dokuzu benim için anahtarları çalıştırdı ve güncellendi. Benim için istisnalar çok nadir, bu yüzden beklemek istemiyorsam, bilinen sistemlerin hızlı bir şekilde düzenlenmesini önemsemiyorum.

class ssh::hostkeys {

  @@sshkey { "${::clientcert}_rsa":
    type => rsa,
    key => $sshrsakey,
    tag => 'rsa_key',
  }

  if 'true' == $common::params::sshclient {
    Sshkey <<| tag == 'rsa_key' |>> {
      ensure => present
    }
  }

  file {'/etc/ssh/ssh_known_hosts':
    ensure => present,
    owner => 'root',
    group => 'root',
    mode => 0644,
  }

}

Güvenliğin daha az endişe verici olduğu çok özel durumlarda size yardımcı olabilecek bir öneri eklemek istiyorum.

Sık sık yeniden kurulan makinelerle bir laboratuar ortamım var. Her zaman, yeni ana bilgisayar anahtarları oluşturulur (ana bilgisayar anahtarını bir yere kaydedebilir ve kurulum sonrası komut dosyasında ayarlayabilirdim).

Bu laboratuar ortamında güvenlik benim için bir sorun olmadığından ve anahtarlar çok sık değiştiğinden, .ssh / config dosyasında aşağıdakiler var:

Host lab-*
  User kenny
  IdentityFile ~/.ssh/lab_id_rsa
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null

Bu, laboratuar makinelerime bağlanmanın bir daha asla bu hataya yol açmayacağından ve ssh istemcimin sadece ana bilgisayar anahtarını kontrol etmeden bağlanacağından emin olmanızı sağlar.

Bu, yalnızca güvenlik sizi hiç ilgilendirmiyorsa yapmanız gereken bir şeydir, çünkü bu sizi ortadaki adam saldırısı için savunmasız bir konuma sokar.

Göre openssh 5.6 sürüm notu , artık ana tuşlarını kullanmak gerekmez:

Ana bilgisayar tabanlı kimlik doğrulama artık sertifika ana bilgisayar anahtarlarını kullanabilir. CA anahtarları, sshd (8) 'de açıklandığı gibi @ cert-otorite işaretleyicisini kullanarak bir bilinen_hosts dosyasında belirtilmelidir.

Uyarı : Bu özelliği üretimde kullanan hiç kimseyi duymadım. Kendi sorumluluğunuzda kullanın (ancak openssh geliştiricilerinin böyle bir katil özelliği çok fazla test ve kod denetimi olmadan serbest bırakmayacak kadar paranoyak olduğuna inanıyorum).

SSHFP DNS ResourceRecord, ssh istemcinizden ne kadar faydalanacağına bağlı olarak yardımcı olabilir. Tüm ssh ortak anahtar parmak izlerinizi ana bilgisayar adıyla birlikte orada saklayın.

Önceden DNSSEC veya DNS'yi SSL üzerinden uygulayın.
http://www.ietf.org/rfc/rfc4255.txt

FreeIPA.org, PKI Sertifikalarının yanı sıra ana bilgisayar ve kullanıcı anahtarı yönetimini de yönetir. Ayrıca, yeni anahtarlar oluşturulduğunda SSHFP DNS kayıtlarını otomatik olarak yükler.

Sistem Güvenlik Hizmetleri Arka Plan Programı (SSSD), ana bilgisayar SSH anahtarlarını önbelleğe almak ve almak üzere yapılandırılabilir; böylece uygulamalar ve hizmetler, ana bilgisayar anahtarları için yalnızca bir konuma bakmak zorunda kalır. SSSD, FreeIPA'yı kimlik bilgi sağlayıcılarından biri olarak kullanabildiği için, FreeIPA evrensel ve merkezi bir anahtar deposu sağlar. Yöneticilerin ana bilgisayar SSH anahtarlarını dağıtma, güncelleme veya doğrulama konusunda endişelenmeleri gerekmez.

http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html