Puncte:0

ssh-keyscan to known_hosts nu produce rezultate

drapel gb
A L

Cand execut:

ssh-keyscan -H 172.22.56.2

Obțin următoarea ieșire:

# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31

Daca incerc atunci:

ssh-keyscan -H 172.22.56.2 >> ~/.ssh/known_hosts

Nefiind familiarizat cu ssh-keyscan, dar crezând că rezultatul trebuie să fie .. nu ceea ce căutam, am încercat și variante ale lui -t precum:

ssh-keyscan -H -t rsa 172.22.56.2 >> ~/.ssh/known_hosts

Toate rezultatele sunt aceleași. Permisiunile pe fișier sunt:

-rw-r--r-- 1 nume de utilizator nume de utilizator 886

„Numele de utilizator” este cel care rulează comenzile de mai sus.. Asta mă lasă cu următoarele întrebări:

  1. Ce comunică/însemnă ieșirea mea ssh-keyscan? M-aș aștepta la ceva de genul |1|weofijgojw = șir sshkey aici.
  2. De ce nu este scris nimic în ~/.ssh/known_hosts, indiferent? Nu există indicii cu privire la problemele care mi-au fost comunicate / comanda preia

Vă mulțumesc anticipat pentru orice informație!

ACTUALIZARE 1:

utilizator@nume gazdă:~$ ssh [email protected]
Imposibil de negociat cu 172.22.56.2 portul 22: nu a fost găsită nicio metodă de schimb de chei. Oferta lor: diffie-hellman-group1-sha1

utilizator@nume gazdă:~$ ssh [email protected] -oKexAlgorithms=+diffie-hellman-group1-sha1
Imposibil de negociat cu 172.22.56.2 portul 22: nu s-a găsit niciun tip de cheie de gazdă potrivit. Oferta lor: ssh-dss

utilizator@nume gazdă:~$ ssh [email protected] -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss
Imposibil de negociat cu 172.22.56.2 portul 22: nu s-a găsit niciun cifru care se potrivește. Oferta lor: 3des-cbc

utilizator@nume gazdă:~$ ssh [email protected] -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+3des-cbc

Autenticitatea gazdei „172.22.56.2 (172.22.56.2)” nu poate fi stabilită.
Amprenta cheii DSA este SHA256:HwdMfb3k5KwrwQkFIRe6ZXilbObYhNzLbwb0zvk2n8U.
Sigur doriți să continuați conectarea (da/nu/[amprenta])? ^C

utilizator@nume gazdă:~$ ssh-keyscan -H 172.22.56.2
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31
# 172.22.56.2:22 SSH-2.0-RomSShell_4.31

Adăugarea în „-vv” se aplică numai aplicației ssh, nu ssh-keyscan, așa că nu am găsit nimic util din asta.

Din punct de vedere tehnic, s-a răspuns la întrebările formulate inițial, dar asta are mai mult de-a face cu lipsa mea de viziune completă pentru anchetă - se pare că în acest moment adevărata întrebare este:

  • De ce ssh-keyscan nu returnează niciun rezultat când ssh la aceeași gazdă produce o solicitare a cheii SSH?

Ar trebui să deschid o nouă întrebare sau pur și simplu să-mi modific mesajul inițial? Mulțumesc!

Ginnungagap avatar
drapel gu
Gazda vizată are o cheie de gazdă RSA?
dave_thompson_085 avatar
drapel jp
@Ginnungagap: OpenSSH din 6.1 acum 9 ani a încercat cel puțin 2 algoritmi, iar rezultatul de aici arată că a încercat 5! OP: liniile `#` doar înregistrează că _încearcă_ să obțină o cheie; dacă reușește da cu `-H`, veți obține o linie sub forma `|1|base64|base64 algorithmname base64` și, din moment ce nu ați făcut-o, înseamnă că serverul nu oferă nicio cheie pe care OpenSSH-ul dvs. o înțelege, deci există nimic de scris în fișierul known_hosts. `ssh -vv` ar trebui să arate în `debug2: algoritmi cheie gazdă:` ce oferă serverul.
A L avatar
drapel gb
A L
@dave_thompson_085 - ty dave! Nefiind foarte ssh saavy, o continuare Q pentru tine dacă nu te deranjează - când încerc să scriu ssh [email protected] - primesc erori pe care cifrurile/etc. nu sunt acceptate, totuși, dacă ofer opțiuni vechi cu -o (KexAlgo/ciphers/hostkeyAlgo) - Mi se dă o amprentă RSA cu un prompt da/nu să accept.. Ty pentru explicarea rezultatului # - am presupus ceva similar!
dave_thompson_085 avatar
drapel jp
Ce opțiuni moștenite? (În amonte) OpenSSH oferă în continuare algoritmul ssh-rsa la conexiune în mod implicit (adică în `myproposal.h`), deși au fost _avertisment_ că îl vor elimina 'în curând' începând cu 8.2 în 2020-02, iar ssh-keyscan a solicitat atât ssh-rsa, cât și cel mai nou/mai bun rsa-sha2-* (care au aceeași _key_ rsa) începând cu 8.1 în 2019-10. Ce folosești și a fost corectat sau reconfigurat?
A L avatar
drapel gb
A L
@dave_thompson_085 - aha - De fapt, am izolat problema prin faptul că ssh-keyscan nu am acele opțiuni moștenite în mod implicit...știți o modalitate de a furniza aceiași parametri opționali moșteniți în actualizarea mea recentă la ssh-keyscan? Ar trebui să-mi reformulez întrebările în acest sens sau să fac o întrebare nouă?
Michael Hampton avatar
drapel cz
După cum puteți vedea, dispozitivul la distanță oferă doar algoritmi și cifruri de schimb de chei _slabi_ învechiți. Un lucru foarte ciudat pentru o [ofertă comercială](https://www.allegrosoft.com/product/iot-edge-device/romsshell/) astăzi. Acestea nu sunt activate în mod implicit în ssh modern astăzi și, după cum a menționat altcineva, vor fi în cele din urmă eliminate complet. Este bizar că o companie ar numi asta „securizat”, dar presupun că probabil că am văzut și mai rău. Ce este exact acest dispozitiv și îl puteți înlocui cu ceva care de fapt are o anumită siguranță?
A L avatar
drapel gb
A L
@MichaelHampton - De acord, în acest caz acestea sunt switch-uri/routere/AP-uri Cisco vechi de un deceniu (sau mai vechi) - și sunt atât de proaste sau mai rele în multe cazuri. Din punct de vedere al securității, șabloanele noastre actuale de sisteme includ echipamente moderne pe care ssh-keyscan nu are probleme de interogare, acest Q a fost pentru vechea flotă cu care mă lupt. Pe scurt - există un plan în curs de a le elimina treptat, dar sunt mii de care aș dori să pot automatiza între timp și acesta este obstacolul major pentru a face asta în prezent. Nu există nicio modalitate de a trece parametrii moșteniți către ssh-keyscan?
Michael Hampton avatar
drapel cz
Probabil că există. Ai verificat pagina de manual?
A L avatar
drapel gb
A L
da - folosesc: https://man.openbsd.org/ssh-keyscan.1 și sursa mea originală pentru opțiunile moștenite pentru a obține chiar și aplicația SSH normală pentru a se conecta sunt de aici: https://www.openssh. com/legacy.html - nimic din argumentele aplicațiilor nu sugerează că pot fi furnizate.. dar am vrut să obțin feedback-ul comunității în cazul în care lipsesc/citesc greșit ceva!
dave_thompson_085 avatar
drapel jp
**AH! DSA!** Da, ssh-keyscan nu încearcă DSA în mod implicit, chiar înainte ca OpenSSH să-l deprecieze (7.0 IIRC).`ssh-keyscan -t dsa` poate funcționa pentru a obține cheia (chiar 8.6 setează DHG1 pentru kx _in scan_, dar mi se pare că 7.4 up nu va seta 3des). Dar pentru a vă _conecta_ cu `ssh` (sau `scp` etc) veți avea nevoie de toate opțiunile pe care le-ați găsit.
A L avatar
drapel gb
A L
@dave_thompson_085 - Ok, bine - e bine de știut! Voi încerca să testez acest lucru în laboratorul meu, între timp doriți să postați un răspuns separat, astfel încât să pot semnala/accept? Aceasta a fost o problemă foarte neplăcută la care sunt sigur că alții din automatizarea rețelei se vor confrunta cu care aș dori să am un răspuns oficial. Dacă termin testarea/confirm înainte de a vedea ceva postat aici, voi scrie eu unul, dar aș prefera să vă acord credit acolo unde este cazul! Va multumesc indiferent de ajutor.
Puncte:1
drapel jp

(Din comentarii plus actualizare)

Problema este că dispozitivul țintă este cu adevărat șchiop și aparent (așa cum a fost diagnosticat de ssh) acceptă numai opțiuni SSH vechi și în mare parte învechite, pe care OpenSSH recent nu le place.

În primul rând, are doar o cheie DSA (scrisă și DSS în SSH). ssh-keyscan în mod implicit, nu a solicitat niciodată o cheie DSA, deși setul de tipuri pe care îl solicită a variat și în mare parte inclus alte noi tipuri care au fost adăugate; de aceea rularea fără opțiuni arată 5 încercări -- pentru a obține tipuri de chei pe care dispozitivul nu le are.Această parte poate fi reparată prin specificare -t dsa.

În al doilea rând, acceptă doar grupul DH 1 pentru KEX și 3des-cbc pentru criptare. Cu toate că ssh nu mai consideră grupul 1 sigur și are nevoie de -oKexAlgorithms= opțiunea de a-l folosi, ssh-keyscan forțează ceea ce arată toate grupuri KEX. Cu toate acestea, nu modifică ssh implicit pentru cifruri, deci ssh-keyscan în OpenSSH 7.4 ar trebui să eșueze în continuare. Dacă downgrade sub 7.4 cred ssh-keyscan -t dsa va functiona. Desigur, retrogradarea este dăunătoare pentru securitate, așa că ar trebui să faceți acest lucru numai pe o maimuță zgârietură, cum ar fi o mașină virtuală sau un container care este apoi aruncat.

Alternativ, după cum ați găsit, ssh poate sa să se acorde -o opțiuni pentru a accepta aceste opțiuni vechi, astfel încât să poată obține cheia gazdă și să o adauge la gazde_cunoscute. Dacă preocuparea dvs. este doar de a evita interacțiunea, adică de a automatiza, utilizați -oStrictHostKeyChecking=nu (sau accept-nou în 7.6 în sus) pentru a face acest lucru fără solicitări. Dacă nu doriți ca noua cheie să fie pusă direct în fișier, utilizați și -oUserKnownHostsFile= pentru a-l pune în altă parte -- deși odată ce ai făcut asta, într-adevăr singurul lucru posibil de făcut cu noul fișier este să-l adaugi la gazde_cunoscute la fel ca ssh ar fi, deci de ce să te deranjezi?

A L avatar
drapel gb
A L
ty sau asta! Voi adăuga pentru oricine care vine aici frustrat de folosirea inventarului ansible a celor de mai sus - ANSIBLE NU UTILizează OPENSSH al sistemului!! Folosește libssh sau paramiko pentru dispozitivele de rețea. Deci, cele de mai sus sunt utile numai pentru automatizarea rețelei dacă construiți alte lucruri pentru ansible cu date.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.