înregistrare Logare
Puncte:0
Federico Gentile avatar Ubuntu

De ce pot să fac SSH la o mașină de la distanță chiar și cu cheile greșite?

drapel fr
Federico Gentile

Descriere: Am creat o conexiune ssh între PC-ul meu Windows și Raspberry Pi. Pentru asta am urmat urmatorii pasi:

Pasul 1: obțineți cumva adresa IP a Raspberry Pi. Ar trebui să fie cam așa: 192.168.1.52

Pasul 2: Deschideți un shell și accesați Raspberry Pi prin ssh:

ssh [email protected]

Veți avea nevoie de parolă.

Pasul 3: În directorul de acasă al computerului la distanță, utilizați aceste comenzi:

mkdir .ssh

Pasul 4: Securizați conexiunea ssh prin cheie privată/publică. În computerul local, utilizați aceste comenzi:

ssh-keygen -f .ssh/fede_windows -t rsa -b 4096

Dacă mașina dvs. locală este bazată pe Linux, rulați această linie:

chmod 600 .ssh/fede_windows # dacă Linux

In cele din urma:

scp .ssh/fede_windows.pub [email protected]:.ssh

Pasul 5: În computerul de la distanță, utilizați aceste comenzi:

sudo nano /etc/ssh/sshd_config

și modificați următoarele rânduri ale fișierului de configurare:

ChallengeResponseAuthentication nr
PasswordAuthentication nr
Utilizați PAM nr

In cele din urma:

sudo systemctl reload sshd

Pasul 6: În computerul de la distanță, utilizați aceste comenzi:

cat ~/.ssh/fede_windows.pub >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

Pasul 7: În computerul local, rulați această comandă pentru a vă conecta la cel de la distanță:

ssh -i .ssh/fede_windows [email protected]

Problemă: Când efectuez din nou toți acești pași pe PC-ul meu Ubuntu generând de data aceasta o cheie numită fede_ubuntu, se pare că pot să-mi ssh Raspberry Pi, indiferent de ce inserez în comandă:

ssh -i .ssh/fede_xyz [email protected]

Funcționează tot timpul și acest lucru nu ar trebui să se întâmple, deoarece ar trebui să fie limitat doar la cheia pe care tocmai am creat-o. Dacă trec la aparatul meu Windows, totul funcționează conform așteptărilor și numai dacă specific cheia potrivită funcționează.

Întrebare: Ați putea să sugerați un posibil motiv al acestei probleme și cum să o remediați, vă rog?

EDITAȚI | ×: tastând următoarea comandă ssh -i .ssh/key_that_does_not_exits -v [email protected] Eu iau:

Avertisment: Fișierul de identitate .ssh/key_that_does_not_exits nu este accesibil: Nu există un astfel de fișier sau director.
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f 31 martie 2020
debug1: Citirea datelor de configurare /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config linia 19: include /etc/ssh/ssh_config.d/*.conf nu se potrivește niciun fișier
debug1: /etc/ssh/ssh_config linia 21: Se aplică opțiuni pentru *
debug1: se conectează la 192.168.1.52 [192.168.1.52] portul 22.
debug1: Conexiune stabilită.
debug1: fișier de identitate /home/federico/.ssh/id_rsa tip -1
debug1: fișier de identitate /home/federico/.ssh/id_rsa-cert tip -1
debug1: fișier de identitate /home/federico/.ssh/id_dsa tip -1
debug1: fișier de identitate /home/federico/.ssh/id_dsa-cert tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ecdsa tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ecdsa-cert tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ecdsa_sk tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ecdsa_sk-cert tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ed25519 tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ed25519-cert tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ed25519_sk tip -1
debug1: fișier de identitate /home/federico/.ssh/id_ed25519_sk-cert tip -1
debug1: fișier de identitate /home/federico/.ssh/id_xmss tip -1
debug1: fișier de identitate /home/federico/.ssh/id_xmss-cert tip -1
debug1: șir de versiune locală SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
debug1: versiunea de protocol la distanță 2.0, versiunea software la distanță OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1
depanare1: potrivire: OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1 pat OpenSSH* compat 0x04000000
debug1: se autentifică la 192.168.1.52:22 ca „pi”
depanare1: SSH2_MSG_KEXINIT trimis
depanare1: SSH2_MSG_KEXINIT primit
debug1: kex: algoritm: curve25519-sha256
debug1: kex: algoritm cheie gazdă: ecdsa-sha2-nistp256
debug1: kex: server->cifrare client: [email protected] MAC: <implicit> compresie: niciuna
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compresie: niciunul
debug1: aștept SSH2_MSG_KEX_ECDH_REPLY
debug1: cheie gazdă server: ecdsa-sha2-nistp256 SHA256:hC5w2kDxgHH5eFRY1vOJaS7ipPR+8OWX2tkkEZbF194
debug1: Gazda „192.168.1.52” este cunoscută și se potrivește cu cheia gazdă ECDSA.
debug1: Cheia găsită în /home/federico/.ssh/known_hosts:1
debug1: reintroduceți tastele după 134217728 blocuri
debug1: SSH2_MSG_NEWKEYS trimis
debug1: aștept SSH2_MSG_NEWKEYS
depanare1: SSH2_MSG_NEWKEYS primit
debug1: reintroduceți după 134217728 blocuri
debug1: va încerca cheia: federico@federico RSA SHA256:E96Hu2Ee+IyAuoZ06GxTvo+ZmAkzqfihbAKkFqxU1AU agent
debug1: va încerca cheia: /home/federico/.ssh/id_rsa 
debug1: va încerca cheia: /home/federico/.ssh/id_dsa 
debug1: va încerca cheia: /home/federico/.ssh/id_ecdsa 
debug1: va încerca cheia: /home/federico/.ssh/id_ecdsa_sk 
debug1: va încerca cheia: /home/federico/.ssh/id_ed25519 
debug1: va încerca cheia: /home/federico/.ssh/id_ed25519_sk 
debug1: va încerca cheia: /home/federico/.ssh/id_xmss 
depanare1: SSH2_MSG_EXT_INFO primit
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384, -nistp521>
depanare1: SSH2_MSG_SERVICE_ACCEPT primit
debug1: Autentificări care pot continua: cheie publică, tastatură interactivă
debug1: Următoarea metodă de autentificare: cheie publică
debug1: Oferă cheie publică: federico@federico RSA SHA256:E96Hu2Ee+IyAuoZ06GxTvo+ZmAkzqfihbAKkFqxU1AU agent
debug1: Serverul acceptă cheia: federico@federico RSA SHA256:E96Hu2Ee+IyAuoZ06GxTvo+ZmAkzqfihbAKkFqxU1AU agent
debug1: Autentificarea reușită (cheie publică).
Autentificat la 192.168.1.52 ([192.168.1.52]:22).
depanare1: canal 0: nou [sesiune-client]
debug1: se solicită [email protected]
debug1: Intrarea în sesiunea interactivă.
debug1: gaj: rețea
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: La distanță: /home/pi/.ssh/authorized_keys:2: opțiuni cheie: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: La distanță: /home/pi/.ssh/authorized_keys:2: opțiuni cheie: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Mediul de trimitere.
debug1: Se trimite env LC_ADDRESS = it_IT.UTF-8
debug1: Se trimite env LC_NAME = it_IT.UTF-8
debug1: Se trimite env LC_MONETARY = it_IT.UTF-8
debug1: Se trimite env LC_PAPER = it_IT.UTF-8
debug1: Se trimite env LANG = en_US.UTF-8
debug1: Se trimite env LC_IDENTIFICATION = it_IT.UTF-8
debug1: Se trimite env LC_TELEPHONE = it_IT.UTF-8
debug1: Se trimite env LC_MEASUREMENT = it_IT.UTF-8
debug1: Se trimite env LC_TIME = it_IT.UTF-8
debug1: Se trimite env LC_NUMERIC = it_IT.UTF-8
Ultima conectare: duminica, 22 august 22:26:00 2021 de la 192.168.1.197
151
1 + 2
drapel cc
ubfan1
Probabil că ați preluat un fișier de identitate per gazdă din configurația dvs. - aveți voie cu multipli.
1
Răspunde
Federico Gentile avatar
drapel fr
Federico Gentile
@ubfan1 mulțumesc pentru comentariu! ai putea sa detaliezi putin te rog? practic vorbind, ce ar trebui să schimb în fișierul de configurare?
0
Răspunde
Puncte:4
vidarlo avatar Ubuntu
drapel om
vidarlo

Comanda cat ~/.ssh/fede_windows.pub >> ~/.ssh/authorized_keys anexează cheia pentru chei_autorizate, nu înlocuiește ceea ce este deja acolo.

La a inlocui toate cheile vechi, fugi cat foobar.pub > ~/.ssh/authorized_keys. Acest lucru va trunchia fișierul și apoi va adăuga informații noi.

Puteți adăuga câte chei doriți. Pentru a verifica, pur și simplu deschideți fișierul cu un editor de text și aruncați o privire asupra conținutului.

Capacitatea de a avea multe chei este de fapt o caracteristică de securitate. Înseamnă că puteți folosi chei diferite de la diferite computere, iar dacă un computer este pierdut, trebuie doar să eliminați cheile compromise, nu toate cheile.

0 + 12
Federico Gentile avatar
drapel fr
Federico Gentile
Multumesc pentru raspunsul tau! Ei bine, ideea mea a fost să păstrez ambele chei, nu vreau să elimin cheia Windows pentru că tot vreau să o folosesc când folosesc mașina mea Windows. Dacă folosesc comanda ta, voi elimina cheia Windows și o voi înlocui cu cea Ubuntu, nu?
0
Răspunde
vidarlo avatar
drapel om
vidarlo
Atunci nu face nimic. Puteți adăuga și elimina chei de câte ori doriți.
0
Răspunde
Federico Gentile avatar
drapel fr
Federico Gentile
scuze, dar asta ma deruteaza. Dacă nu fac nimic, atunci am încă problema că, dintr-un motiv necunoscut, pot ssh de pe mașina Ubuntu chiar și cu cheia greșită. Cum îmi rezolvă răspunsul?
0
Răspunde
vidarlo avatar
drapel om
vidarlo
`>>` *adaugă* conținut la un fișier. Ai adăugat ambele chei. Deschideți fișierul într-un editor de text și examinați-l; va afișa ambele taste. Scoateți-l pe cel pe care nu îl doriți.
0
Răspunde
Federico Gentile avatar
drapel fr
Federico Gentile
mmm... am verificat fișierul și am 2 chei: 1 pentru PC-ul meu Windows (pe care încă vreau să-l folosesc pentru a-mi ssh zmeura) și 1 pentru PC-ul meu Ubuntu (pe care, de asemenea, vreau să-l păstrez pentru a-mi ssh în zmeura) . Când le am pe amândouă, practic pot să-mi fac ssh la ajunul zmeurului cu chei care nu există. De exemplu, dacă tast „ssh -i .ssh/key_that_does_not_exist [email protected]” accesează automat zmeura! Acest lucru ar trebui să fie imposibil
0
Răspunde
vidarlo avatar
drapel om
vidarlo
Editați-vă întrebarea cu rezultatul `ssh -v user@host` pentru a vedea ce cheie este trimisă de fapt.
0
Răspunde
Federico Gentile avatar
drapel fr
Federico Gentile
Am adăugat rezultatul așa cum am sugerat :)
0
Răspunde
vidarlo avatar
drapel om
vidarlo
Preia cheia folosită anterior de la [`ssh-agent`](https://en.wikipedia.org/wiki/Ssh-agent).
0
Răspunde
Federico Gentile avatar
drapel fr
Federico Gentile
Oh, văd, practic vorbind, ce ar trebui să modific? Ceva în sshd_config?
0
Răspunde
vidarlo avatar
drapel om
vidarlo
De ce doriți să modificați dacă funcționează așa cum doriți?
0
Răspunde
Federico Gentile avatar
drapel fr
Federico Gentile
Dar dacă pot ssh chiar și cu chei care nu există, este foarte periculos, deoarece ar însemna că nu am nevoie de o cheie deloc. Aceasta este problema întrebării mele: „De ce pot să fac SSH o mașină la distanță chiar și cu cheile greșite?” Aparatul meu Windows poate ssh corect. Mașina mea Ubuntu poate ssh chiar și cu chei greșite sau inexistente. Și acest lucru nu ar trebui să se întâmple.
0
Răspunde
vidarlo avatar
drapel om
vidarlo
Deoarece ssh-agent memorează cheia în cache și o folosește pentru autentificare. https://stackoverflow.com/questions/25464930/how-can-i-remove-an-ssh-key
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.