Puncte:0

Nu se poate ssh în VM nou creat (cu cheia folosită la creare)

drapel cn

Prin urmare, furnizorul meu de cloud te-a cerut să tai/lipi sau să trageți/să plasați cheia id_rsa.pub atunci când creați instanța. Procesul de furnizare plasează cheia respectivă în locul potrivit ca parte a procesului.

Acest lucru funcționează bine pentru lucrătorii mei care sunt toți pe Linux/Windows. Sunt pe un Mac (Monterey 12.3). Eșuează fie de la mac-ul meu nativ, fie de la o VM linux care rulează pe Mac-ul meu. Simptome (nume/IP-uri schimbate pentru a-i proteja pe vinovați):

bozo$ ssh -v utilizator@new_ip

ssh -v [email protected]
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 ianuarie 2017
debug1: Citirea datelor de configurare /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config linia 58: Aplicarea opțiunilor pentru *
debug1: se conectează la 10.333.80.223 [10.333.380.223] portul 22.
debug1: Conexiune stabilită.
debug1: fișier de identitate /home/me/.ssh/id_rsa tip 1
debug1: key_load_public: Nu există un astfel de fișier sau director
debug1: fișier de identitate /home/me/.ssh/id_rsa-cert tip -1
debug1: key_load_public: Nu există un astfel de fișier sau director
debug1: fișier de identitate /home/me/.ssh/id_dsa tip -1
debug1: key_load_public: Nu există un astfel de fișier sau director
debug1: fișier de identitate /home/me/.ssh/id_dsa-cert tip -1
debug1: key_load_public: Nu există un astfel de fișier sau director
debug1: fișier de identitate /home/me/.ssh/id_ecdsa tip -1
debug1: key_load_public: Nu există un astfel de fișier sau director
debug1: fișier de identitate /home/me/.ssh/id_ecdsa-cert tip -1
debug1: key_load_public: Nu există un astfel de fișier sau director
debug1: fișier de identitate /home/me/.ssh/id_ed25519 tip -1
debug1: key_load_public: Nu există un astfel de fișier sau director
debug1: fișier de identitate /home/me/.ssh/id_ed25519-cert tip -1
debug1: Activarea modului de compatibilitate pentru protocolul 2.0
debug1: șir de versiune locală SSH-2.0-OpenSSH_7.4
debug1: versiunea 2.0 a protocolului la distanță, versiunea software la distanță OpenSSH_7.4
debug1: potrivire: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: se autentifică la 10.333.380.223:22 ca „eu”
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: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: aștept SSH2_MSG_KEX_ECDH_REPLY
debug1: cheie gazdă server: ecdsa-sha2-nistp256 SHA256:P95KW1jM38eMCM172VHOjR5DY58Oo0qbgs1ZnZHwY+U
debug1: Gazda „10.333.380.223” este cunoscută și se potrivește cu cheia gazdă ECDSA.
debug1: Cheia găsită în /home/me/.ssh/known_hosts:1
debug1: reintroduceți cheia după 134217728 blocuri
debug1: SSH2_MSG_NEWKEYS trimis
debug1: aștept SSH2_MSG_NEWKEYS
depanare1: SSH2_MSG_NEWKEYS primit
debug1: reintroduceți cheia după 134217728 blocuri
depanare1: SSH2_MSG_EXT_INFO primit
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
depanare1: SSH2_MSG_SERVICE_ACCEPT primit
debug1: autentificări care pot continua: publickey,gssapi-keyex,gssapi-with-mic
debug1: Următoarea metodă de autentificare: gssapi-keyex
debug1: nu există un context valid de schimb de chei
debug1: Următoarea metodă de autentificare: gssapi-with-mic
debug1: Eșec GSS nespecificat. Codul minor poate oferi mai multe informații
Nu există acreditări Kerberos disponibile (cache-ul implicit: KEYRING:persistent:1001)

debug1: Eșec GSS nespecificat. Codul minor poate oferi mai multe informații
Nu există acreditări Kerberos disponibile (cache-ul implicit: KEYRING:persistent:1001)

debug1: Următoarea metodă de autentificare: cheie publică
debug1: Oferă cheia publică RSA: /home/me/.ssh/id_rsa
debug1: autentificări care pot continua: publickey,gssapi-keyex,gssapi-with-mic
debug1: Se încearcă cheia privată: /home/me/.ssh/id_dsa
debug1: Se încearcă cheia privată: /home/me/.ssh/id_ecdsa
debug1: Se încearcă cheia privată: /home/me/.ssh/id_ed25519
debug1: Nu mai sunt metode de autentificare de încercat.
Permisiune refuzată (publickey,gssapi-keyex,gssapi-with-mic).

Rețineți că permisiunile mele pentru .ssh, id_rsa.pub, id_rsa și .. sunt toate corecte.

[jump_me@localhost .ssh]$ ls -ld id_rsa id_rsa.pub . ..
drwx------. 2 me me 73 Mar 21 22:25 .
drwx------. 4 me me 4096 Mar 21 22:24 ..
-rw-------. 1 me me 1675 Feb 19 2019 id_rsa
-rw-r--r--. 1 me me 400 Feb 19 2019 id_rsa.pub

În plus, rețineți că singura modalitate de a intra este prin tastele ssh predefinite. Nu este disponibil niciun nume de utilizator/pwd, așa că nu vă puteți autentifica pentru a schimba nimic pe VM.

Idei?

dave_thompson_085 avatar
drapel jp
Clientul dvs. oferă cheia, dar serverul nu o acceptă. Încercați `dif
drapel cn
Mulțumesc Dave. Diferența revine curată (codul de returnare 0) și da, folosind utilizatorul furnizat corect. Numele de utilizator din cheie, desigur, nu se potrivește cu numele de utilizator furnizat, dar asta pentru că se potrivește cu numele de utilizator de pe client.
dave_thompson_085 avatar
drapel jp
Atunci sunt în pierdere. Vedeți dacă cineva se poate uita la jurnalele serverului pentru vreo indicație de ce nu-i place cheia dvs. -- deși sshd în mod normal nu înregistrează prea multe :-(

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.