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

İş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.

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

ssh -o StrictHostKeyChecking=no username@hostname.com

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.

Tembel olanlar için:

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

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

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 ...

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

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 }}'

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([]) }}'

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.

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.

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

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

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

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.

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

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}}"

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