Known_hosts'a otomatik olarak yeni bir ana bilgisayar ekleyebilir miyim?


249

İşte benim durumum: Merkezi bir istemciden bir dizi sanal makine örneği başlatıp ardından üzerlerine komutlar uygulayacak bir test donanımı kuruyorum ssh. Sanal makineler daha önce kullanılmamış ana bilgisayar adlarına ve IP adreslerine sahip olacak, böylece ~/.ssh/known_hostsmerkezi istemcideki dosyada bulunmayacaklar .

Karşılaştığım sorun, sshyeni bir sanal örneğe karşı çalıştırılan ilk komutun her zaman etkileşimli bir istemle ortaya çıkmasıdır:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

Bunu atlayabilmemin ve yeni ana makinenin istemci makine tarafından zaten bilinmesini sağlayabilmemin bir yolu var mı? Gerçekten Expect'i kullanmak zorunda kalmaktan kaçınmak veya interaktif bilgi istemine cevap vermek için ne gerekiyorsa yapmamayı isterim.


5
Kendi kendine yeten ve fiziksel olarak güvenli bir test ortamı için, otomatik anahtar kabulü işe yarayabilir. Ancak otomatik olarak bir üretim ortamında veya güvenilmeyen bir ağda (İnternet gibi) genel anahtarları kabul etmek, SSH'nin aksi takdirde sağlayacağı ortadaki adam saldırılarına karşı her türlü korumayı tamamen atlar. Sadece sen MITM saldırılarına karşı güvenli olduğundan emin olmak için geçerli bir yol bazılarını bant güvenilen kanal aracılığıyla konağın genel anahtarını doğrulamak etmektir. Orta derecede karmaşık bir anahtar imzalama altyapısı kurmadan bunu otomatikleştirmenin güvenli bir yolu yoktur.
Eil,

Yanıtlar:


141

Set StrictHostKeyCheckingseçeneğini etmek no, Yapılandırma dosyasında veya üzeri -o:

ssh -o StrictHostKeyChecking=no username@hostname.com


62
Bu sizi orta ataklarda adama açıyor, muhtemelen iyi bir fikir değil.
JasperWallace

9
@ JasperWallace, bu genellikle iyi bir tavsiye olsa da, özel kullanım durumu (test VM'lerini dağıtma ve onlara komut gönderme) yeterince güvenli olmalıdır.
Massimo

8
Bu, bir Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts.uyarı vermemesi ve girişin bilinen herhangi bir ana bilgisayar dosyasına eklenmesini önlemek için şunu yapıyorum:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null username@hostname.com
Peter V. Mørch

11
Bu durumun aşağı çekilmesi, soruyu yanıtlamıyor ve ciddi güvenlik açıklarına neden oluyor.
marcv81

12
@Mnebuerquo: Güvenlik konusunda endişeli olsaydınız, o zaman bu soru ile hiçbir ilginiz olmazdı. Bağlanmak istediğiniz sistemin konsolundan toplanan önünüzde doğru ana bilgisayar anahtarına sahip olursunuz ve ilk bağlantıda el ile doğrularsınız. Kesinlikle "otomatik" bir şey yapmazsın.
Ignacio Vazquez-Abrams,

230

IMO, bunu yapmanın en iyi yolu şudur:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

Bu, hem ana bilgisayar adı hem de IP adresi için kapsandığınız ve aynı zamanda ek bir güvenlik önlemi olan hash olacak şekilde yinelenen giriş olmadığından emin olmanızı sağlar.


4
Neden tüm 3 ssh-keyscan'a ihtiyacınız var? Hem ana bilgisayar adı hem de ip için çalıştığı için ilk olanı göremiyor musunuz?
Robert

6
Ssh-keyscan isteğine cevap veren makinenin gerçekten konuşmak istediğine emin misin? Kendini orta saldırıda bir erkeğe açmadıysan.
JasperWallace

2
@JasperWallace Evet, bunun için en azından parmak izine veya daha iyi bir genel anahtara ihtiyacınız var, bu durumda doğrudan bilinen_toplara ekleyebilir ve bu soruyu tartışmaya sokabilirsiniz. Sadece parmak izine sahipseniz, indirilen ortak anahtarı parmak

1
ssh-keyscanHedef ana bilgisayarım varsayılan sürüm 1 anahtar türünü desteklemediğinden çağrılar benim için başarısız oldu. -t rsa,dsaKomuta ekleyerek bu düzeltti.
phasetwenty 18

5
Bu muhtemelen kötü bir fikir. Bu anahtarları güncelleyerek kendinizi ortadaki bir saldırıya açıyorsunuz. Yinelenen girişleri önlemek için ssh-keygen -F [address]bunun yerine dönüş durumunu kontrol edin . medium.com/@wblankenship/…
retrohacker

93

Tembel olanlar için:

ssh-keyscan -H <host> >> ~/.ssh/known_hosts

-H ana bilgisayar adını / IP adresini karma


2
"ssh-keyscan -H <host> >> ~ / .ssh / known_hosts", ssh'nin kullanıcı etkileşimi ile yaptıklarına benzer bir girdi oluşturur. (-H uzaktaki sunucunun ismini hash.)
Sarah Messer

3
MITM saldırılarına karşı savunmasız. Anahtar parmak izini kontrol etmiyorsun.
Mnebuerquo

8
@Mnebuerquo Ne yapılacağını ama nasıl yapılmayacağını, hangisinin yardımcı olacağını söylüyorsunuz.
Ray

4
@jameshfisher Evet, MITM saldırılarına karşı savunmasız, ancak bunu manuel olarak yaparken, sunucunun asıl sunucusuyla gösterilen RSA parmak izini hiç karşılaştırdınız mı? Hayır? Yani bu cevap sizin için yapmanın yoludur. Evet, bu cevabı kullanmak ve el ile yapmak veya diğer güvenlik önlemleri uygulamaması gerektiği takdirde ...
fivef

2
@Mnebuerquo Katılmamış toplu komut dosyalarını kullanarak bir repo klonlamamız gerektiğinde ve bu istemi atlamak istediğimizde, bununla başa çıkmanın daha iyi bir yolunu bize bildirirseniz çok sevinirim. Bunun doğru olmadığını düşünüyorsanız, lütfen gerçek bir çözüme ışık tutun!
Waqas Shah

42

Daha önce de belirtildiği gibi, tuş taramayı kullanmak bunu yapmanın doğru ve göze çarpmayan yolu olacaktır.

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

Yukarıdakiler, SADECE henüz eklenmemişse, bir ana bilgisayar eklemek için hile yapar. Aynı zamanda eşzamanlılık güvenli değildir; Eğer olmamalıdır tmp_hosts dosya sonuçta şişirilmiş olma known_hosts dosyaya yönlendiren, clobbered olsun gibi, bir kez daha aynı anda birden aynı kökenli makinede pasajını yürütmek ...


Anahtarın daha önce bilinen ana bilgisayarlarda olup olmadığını kontrol etmenin bir yolu var mı ssh-keyscan? Bunun nedeni, biraz zaman ve ek ağ bağlantısı gerektirmesidir.
utapyngo

1
Bu dosyanın orijinal posterinin sürümü vardı cat ~/.ssh/tmp_hosts > ~/.ssh/known_hostsancak sonraki bir düzenleme onu değiştirdi >>. Kullanma >>bir hatadır. İlk satırdaki benzersizliğin amacını yendi ve known_hostsçalıştığı her seferinde yeni girdiler bırakmasına neden oldu . (Geri değiştirmek için bir düzenleme yayınladım.)
paulmelnikow

1
Bu, diğerleriyle aynı MITM saldırılarına tabidir.
Mnebuerquo

@ utapyngo ssh-keygen -F size şu anki parmak izini verecektir. 1 dönüş kodu ile geri boş gelirse, o zaman yok. Bir şey basarsa ve dönüş kodu 0 ise, o zaman zaten mevcuttur.
Zengin L

1
MITM'e çok değer veriyorsanız, DNSSEC ve SSHFP kayıtlarını dağıtın veya anahtarları dağıtmak için başka güvenli araçlar kullanın;
Zart

19

ssh-keyscanGenel anahtarı alıp bunu known_hostsdosyanıza eklemek için komutu kullanabilirsiniz .


3
Doğru anahtar olduğundan emin olmak için parmak izinizi kontrol ettiğinizden emin olun. Aksi takdirde, kendinizi MITM saldırılarına açarsınız.
Mnebuerquo

3
@Mnebuerquo Genel bağlamdaki fuar noktası, ancak doğru anahtarın ne olduğunu zaten bilselerdi neden birileri anahtarları programlı olarak toplamaya çalışıyorlardı?
Brian Cline

Bunu yapmanın yolu bu değil. MITM.
jameshfisher

8

Ssh-keyscan'ı oyununuza bu şekilde dahil edebilirsiniz :

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.stdout_lines }}'

1
Bilinen bir geçerli known_hosts dosyası mı yüklüyorsunuz ya da ssh-keyscan yapıyorsunuz ve çıktıları parmak izlerini doğrulamadan bilinen_host'lara atıyor musunuz?
Mnebuerquo

1
Bu sadece bir keyscan çıktısını alır, evet. Bu yüzden aslında StrictHostKeyChecking = no ile aynıdır, sadece ssh seçenekleriyle uğraşmadan güncellenen sessiz bilinen _host'larla aynıdır. Bu çözüm aynı zamanda birden fazla satır döndüren ssh-keyscan'ın bu görevin her zaman 'değişti' olarak işaretlenmesine neden olduğu için iyi sonuç vermez
Zart

Bunu yapmanın yolu bu değil. MITM.
jameshfisher

3
@jameshfisher Katılmamış toplu komut dosyalarını kullanarak bir repo klonlamamız gerektiğinde ve bu istemi atlamak istediğimizde, bununla başa çıkmanın daha iyi bir yolunu bize bildirirseniz çok sevinirim. Bunun doğru olmadığını düşünüyorsanız, lütfen gerçek bir çözüme ışık tutun! Bunu yapmanın doğru yol olmadığını düşünüyorsanız, lütfen "nasıl yapılacağını" bize bildirin!
Waqas Shah

Bilinen_host'lara değer katmak için tamamen geçerli bir yöntemdir, ancak evet MITM'e karşı hassastır. Ancak, iç kullanım için iyi.
Cameron Lowell Palmer

7

bu sadece ilk defa ana bilgisayar anahtarını kabul eden eksiksiz bir çözüm olacaktır.

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'

1
Bunu yapmanın yolu bu değil. MITM.
jameshfisher

6

Benzer bir sorun yaşadım ve verilen cevaplardan bazılarının sadece otomatik bir çözüme giden yolu bulduğumu gördüm. Kullanarak bitirdiğim şey şudur, yardımcı olacağını umuyorum:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

Anahtar ekler known_hostsve parola istemez.


2
MITM saldırılarına karşı savunmasız. Parmak izini kontrol etmiyorsun.
Mnebuerquo

6
Kimse parmak izini kontrol etmiyor.
Brendan Byrd

Bunu yapmanın yolu bu değil. MITM.
jameshfisher

5

Bu yüzden, bir git repo klonlamanın bilinmeyen ana manuel etkileşimi aşağıda gösterildiği gibi atlamak için sıradan bir yol arıyordum:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

RSA anahtar parmak izini not edin ...

Yani, bu bir SSH meselesi, bu genel olarak SSH'ye gitmek için çalışacak ve genel olarak sadece SSH ile ilgili şeyler ...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds

İlk önce nmap'ı günlük sürücünüze yükleyin. nmap, açık portları tespit etmek ve bunun gibi SSH parmak izlerini elle doğrulamak gibi bazı şeyler için oldukça faydalıdır. Ama ne yaptığımıza geri dönelim.

İyi. Ya kontrol ettiğim birçok yerde ya da makineden ödün verdim ya da alçakgönüllü olan her şeyin daha makul bir açıklaması oluyor.

Bu 'parmak izi', aynı parmak izini çözme birden fazla dize riski altında insan rahatlığımız için tek yönlü bir algoritma ile kısaltılmış bir dizedir. Olur, çarpışma denir.

Ne olursa olsun, aşağıdaki bağlamda görebileceğimiz orijinal dizgiye geri dönelim.

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

Bu yüzden, vaktinden önce, asıl ev sahibinden bir tür kimlik isteme yolumuz var.

Bu noktada manuel olarak otomatik olarak savunmasızız - dizeler eşleşiyor, parmak izini oluşturan temel verilere sahibiz ve gelecekte bu temel verileri (çarpışmaları önler) isteyebiliriz.

Şimdi bu dizgiyi ana bilgisayarların gerçekliğini sormayacak şekilde kullanmak için ...

Bu durumda known_hosts dosyası düz metin girişleri kullanmaz. Bunları gördüğünüzde karma girişleri bilirsiniz, xyz.com veya 123.45.67.89 yerine rasgele karakterlere sahip hash gibi görünürler.

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

İlk yorum satırı çıldırtıcı bir şekilde ortaya çıkıyor - ancak ">" veya ">>" kongre ile basit bir yönlendirme ile ondan kurtulabilirsiniz.

Bir "ev sahibi" ve güveni tanımlamak için kullanılacak sınırsız veri elde etmek için elimden gelenin en iyisini yaptığım gibi, bu kimliği ~ / .ssh dizinimdeki known_hosts dosyasına ekleyeceğim. Şimdi bilinen bir ev sahibi olarak tanımlanacağı için, siz gençken yukarıda belirtilen istemleri alamayacağım.

Bana sadık kaldığın için teşekkürler, işte geliyorsun. Bitbucket RSA anahtarını ekliyorum, böylece CI iş akışının bir parçası olarak etkileşimli olmayan bir şekilde git depolarım ile etkileşime girebiliyorum, ama ne istersen onu yap.

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

Demek bugün böyle bir bakire kalıyorsun. Kendi zamanınızdaki benzer talimatları izleyerek aynı şeyi github ile yapabilirsiniz.

Çok fazla yığın taşması mesajı gördüm ve anahtarı herhangi bir denetime gerek kalmadan programlı olarak anahtarı kör olarak eklemenizi söylüyor. Farklı ağlardaki farklı makinelerden anahtarı ne kadar çok kontrol ederseniz, ana makinenin söylediği kişi olduğundan o kadar çok güvenirsiniz ve bu güvenlik katmanından umut edebileceğiniz en iyi şey budur.

YANLIŞ ssh -oStrictHostKeyChecking = hostname yok [komut]

YANLIŞ ssh-keyscan -t rsa -H ana bilgisayar adı >> ~ / .ssh / known_hosts

Yukarıdakilerden hiçbirini yapma lütfen. Orta saldırıda bir adam aracılığıyla veri aktarımlarınızdan gizlice dinlemekten kaçınmak için şansınızı artırma fırsatı verilir - bu fırsatı yakalayın. Aradaki fark kelimenin tam anlamıyla, sahip olduğunuz RSA anahtarının iyi niyetli sunucudan biri olduğunu ve şimdi bu bilgileri nasıl karşılaştıracağınızı bildiğinizden emin olun ki bağlantıya güvenebilirsiniz. Sadece farklı bilgisayarlardan yapılan daha fazla karşılaştırmayı unutmayın ve ağlar genellikle bağlantıya güvenme yeteneğinizi arttırır.


Bence bu, bu sorunun en iyi çözümü. Ancak, Amazon EC2 gibi bir konuda Nmap kullanırken çok dikkatli olun, Nmap'ın yaptığı bağlantı noktası taraması hakkında bir uyarı aldım! Portscanning yapmadan önce formlarını doldurun!
Waqas Shah,

...iyi evet. EC2'den neden port taraması yaptığını bilmiyorum. Hesabınıza giriş yaptıysanız, anahtarları gerçek makinelerden alabilirsiniz. Bu, üzerinde kontrolünüz olmayan makineler için daha fazla. Yerel bir makinenin AWS bağlantı noktası tarama kısıtlamalarına tabi olmayan bir makineniz olacağını varsayardım. Ancak, nmap'ı AWS ile çalıştırmanız gereken son durumdaysanız, bu uyarının yardımcı olacağını düşünüyorum.
BradChesney79

SSH ana bilgisayar anahtarını iş istasyonunuzdan okumak için nmap kullanma ve bu değere güvenme, SSH ile StructHostKeyChecking kapalı durumdayken farklı olmaktan farklıdır. Tıpkı ortadaki bir adamın saldırısına karşı savunmasız.
Micah R Ledbetter

... @ MicahRLedbetter bu yüzden "farklı bilgisayarlardan ve ağlardan daha fazla karşılaştırma yapmak genellikle bağlantıya güvenme yeteneğinizi artıracak" demiştim. Ama bu benim amacım. Hedef sunucunuzu yalnızca bir dizi ortam koşulundan kontrol ederseniz, herhangi bir tutarsızlığı nasıl bildiniz? Daha iyi bir önerin var mı?
BradChesney79

1
Burası güvenlik tiyatrosu. Daha büyük güvenlik görünümü oluşturmak için karmaşık bir şey yapmak. Ana bilgisayardan anahtarını istemek için kaç farklı yöntem kullandığınız önemli değildir. Aynı kişiye, onlara güvenip güvenemediğini sormak gibi (belki arayabilir, e-posta, metin ve salyangoz postası). Her zaman evet derler, ama yanlış kişiye soruyorsan, önemli değil.
vastlysuperiorman

5

Ben tek satırlık script, biraz uzun ama yararlı kullanarak, katları IP adreslerine sahip bilgisayarlar için bu görevi yapmak digvebash

(host=github.com; ssh-keyscan -H $host; for ip in $(dig @8.8.8.8 github.com +short); do ssh-keyscan -H $host,$ip; ssh-keyscan -H $ip; done) 2> /dev/null >> .ssh/known_hosts

5

Aşağıdaki, ~ / .ssh / known_hosts içindeki yinelenen girişleri engeller:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi

1
Bunu yapmanın yolu bu değil. MITM.
jameshfisher

Bu cevabı en çok sevdim. Benden başkası için önemli olmayan rastgele bir VPS'nin ilk kurulumunu başlatmak için, MITM riski ufukta kaybolur. Sonsuz quibble ... ilk satır olması gerekiyormkdir -p ~/.ssh/known_hosts;
Martin Bramwell

5

Bu makineleri nasıl yapıyorsun? dns güncelleme komut dosyasını çalıştırabilir misiniz? IPA Domain'e katılabilir misiniz?

FreeIPA otomatik olarak yapar, ama ihtiyacınız aslında hepsi SSHFP dns kayıtları ve DNSSEC (freeipa varsayılan olarak devre dışı olarak yapılandırılabilir seçeneklere (DNSSEC) sağlamasıdır) sizin dilimine.

Mevcut SSHFP kayıtlarını çalıştırarak ana bilgisayarınızdan alabilirsiniz.

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com SSHFP 1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com SSHFP 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com SSHFP IN 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com SSHFP 3 DE 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

daha sonra yayınlandıktan sonra VerifyHostKeyDNS yesssh_config veya ~ / .ssh / config

Eğer / google DNSSEC’i kullanmaya karar verirse, hostkey isteminde bulunmadan ssh yapabilirsiniz.

ssh jersey.jacobdevans.com

AMA etki alanım henüz imzalanmadı, bu yüzden şimdilik göreceksiniz ...

hata ayıklama1: Sunucu ana bilgisayar anahtarı: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1: DNS'de 4 güvensiz parmak izi bulundu

debug1: eşleşen ana bilgisayar anahtar parmak izi

DNS'de bulundu 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' sunucusunun gerçekliği kurulamadı. ECDSA anahtar parmak izi SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s'dir. DNS'de bulunan ana bilgisayar anahtar parmak izinin eşleştirilmesi. Bağlanmaya devam etmek istediğinizden emin misiniz (evet / hayır)? Hayır


4

Bunu doğru şekilde yapmak için, gerçekten yapmak istediğiniz şey, VM'lerin ana bilgisayar ortak anahtarlarını oluşturdukça bunları toplamak ve bunları bir dosyaya bırakmaktır known_hosts. -o GlobalKnownHostsFile=...Bağlanmanız gerektiğine inandığınız ana bilgisayara bağlandığınızdan emin olmak için bu dosyayı işaret ederek kullanabilirsiniz . Bunu nasıl yapacağınız, sanal makineleri nasıl ayarladığınıza bağlıdır, ancak sanal dosya sisteminden okumak, eğer mümkünse, hatta ana makinenin /etc/ssh/ssh_host_rsa_key.pubyapılandırma sırasında içeriğini yazdırmasını sağlamak bu işi yapabilir.

Bununla birlikte, ne tür bir ortamda çalıştığınıza ve öngörülen rakiplerinizin kim olduğuna bağlı olarak, bunun faydası olmayabilir. Diğer bağlantılarda basit bir "ilk bağlantıda depo" yapmak (tarama yoluyla veya sadece ilk "gerçek" bağlantı sırasında) yukarıdaki diğer cevaplarda açıklandığı gibi oldukça kolay olabilir ve yine de bir miktar güvenlik sağlayabilir. Ancak, bunu yaparsanız, kullanıcı tarafından bilinen hosts dosyasını ( -o UserKnownHostsFile=...) bu belirli test kurulumu için özel bir dosyaya değiştirmenizi şiddetle tavsiye ediyorum ; bu, kişisel olarak bilinen ana bilgisayar dosyalarınızı test bilgileriyle kirletmekten kaçınır ve VM'lerinizi silerken artık gereksiz ortak anahtarları temizlemenizi kolaylaştırır.


4

Bu bütün

  • SSH anahtar tarama
  • ssh-copy-id
  • ECSDA anahtar uyarısı

iş beni sinirlendirmeye devam etti, ben de seçtim

Hepsine hükmedecek tek bir senaryo

Bu, https://askubuntu.com/a/949731/129227 adresindeki betiğin bir çeşididir. Amadu Bah'in cevabı https://serverfault.com/a/858957/162693 .

örnek çağrı

./sshcheck somedomain site1 site2 site3

Betik, isimlerin sitelerinde dolaşacak ve .ssh / config ve .ssh / known_hosts dosyasını değiştirecek ve istek üzerine ssh-copy-id yapacaktır - son özellik için sadece ssh test çağrılarının başarısız olmasına izin verin; şifre isteği.

sshcheck betiği

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check known_hosts entry for server
#
checkknown() {
  local l_server="$1"
  #echo $l_server
  local l_sid="$(ssh-keyscan $l_server 2>/dev/null)" 
  #echo $l_sid
  if (! grep "$l_sid" $sknown) > /dev/null 
  then
    color_msg $blue "adding $l_server to $sknown"
    ssh-keyscan $l_server >> $sknown 2>&1
  fi
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
    checkknown $l_server
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config
sknown=~/.ssh/known_hosts

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    #for server in $(echo $* | sort)
    ##do
    #  checkknown $server 
    #done
    ;;
esac

2

Ana bilgisayar koleksiyonu nasıl yapılır?

bir ana bilgisayar koleksiyonu tanımla

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com

Ardından anahtarları bilinen ana bilgisayarlara eklemek için iki görev tanımlayın:

- command: "ssh-keyscan {{item}}"
   register: known_host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_host_keys.results}}"

0

En iyisi, her yeni sunucunun / sunucunun parmak izini kontrol etmeniz olabilir. Sunucuyu doğrulamanın tek yolu budur. Bu olmadan, SSH bağlantınız ortadaki adam saldırısına maruz kalabilir .

Parmak izini kontrol etmeyi göz ardı etmek istediğinizden eminseniz StrictHostKeyChecking=accept-new, OpenSSH sürüm 7.6'da (2017-10-03) sunulan ikinci en iyi, daha az güvenli seçenek kullanmaktır :

İlk "yeni kabul et", hiç görülmemiş anahtarları otomatik olarak kabul eder, ancak değiştirilen veya geçersiz ana bilgisayar anahtarları için bağlantıları reddeder.

Etmeyin eski değerini kullanmak asla hiç sunucunun doğruluğunu kontrol eder. (Bu ayarın anlamı daha sonra bazı sürümleri çevrilmiş olacak olsa da .)StrictHostKeyChecking=no=no

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.