Puncte:0

Mi-am mărit dimensiunea discului VM pe Google Cloud Platform și acum conectarea SSH cere o parolă?

drapel in

Am mărit dimensiunea discului pe instanța mea VM care rulează pe Google Cloud Platform. A existat o schimbare simplă de la 200 GB la 400 GB, fără alte modificări efectuate pe Instanță. Când am pornit instanța după ce am făcut modificările și am încercat să mă autent prin cheile SSH private fără parolă pe PuTTY, serverul mi-a refuzat cheile și nici eu nu pot deschide SSH prin browser (spune doar conectare și apoi nu m-am putut conecta, reîncercând).

De atunci, am resetat cheile, am generat noi chei publice și private, mi-am verificat firewall-ul, autentificarea sistemului de operare și chiar am rulat niște scripturi de depanare, toate care nu duc la nimic. După ce am setat o dată enable-oslogin ca adevărat, deși PuTTY mi-a cerut o parolă pentru a mă autentifica prin cheia mea SSH și nu am setat niciodată nicio parolă? Am setat codul de conectare la fals și chiar l-am eliminat din metadatele mele, dar încă îmi cere o parolă pe care nu am setat-o.

Dacă cineva are vreo idee despre ce s-ar putea întâmpla, aș fi de mare ajutor. Mulțumesc foarte mult.

John Hanley avatar
drapel cn
Activați consola serială Compute Engine și examinați jurnalele de pornire/pornire pentru a determina de ce perechea de chei SSH nu este acceptată.
Puncte:0
drapel fr

Este acest disc pe care ați actualizat unitatea sistemului de operare sau o altă unitate? Dacă este volumul sistemului de operare, atunci poate permisiunile de /home/${USER}/.ssh/authorized_keys s-a schimbat. Dacă aceste permisiuni se încurcă, atunci nu puteți SSH folosind cheile publice și trebuie să activați temporar autentificarea parolei în /etc/ssh/sshd_config pentru a vă autentifica și a modifica permisiunile. Nu puteți face multe odată ce sunteți blocat, dar dacă există vreo modalitate de a vă conecta din nou, urmați acești pași pentru a restabili permisiunile, astfel încât SSH să funcționeze din nou. De asemenea, aceasta presupune că aveți cheile SSH /home/${USER}/.ssh.

Pentru ca SSH să funcționeze, /Acasă directorul trebuie să fie deținut de root cu o mască 755:

rădăcină chown:rădăcină /home
chmod 755 /home

The /home/${USER} directorul trebuie să fie deținut de ${USER} și au permisiunile 700.

chown ${USER}:${USER} /home/${USER}
chmod 700 /home/${USER}

The /home/${USER}/.ssh directorul trebuie să fie deținut de ${USER} cu permisiunile 700.

chown ${USER}:${USER} /home/${USER}/.ssh
chmod 700 /home/${USER}/.ssh

În cele din urmă, fișierul /home/${USER}/.ssh/authorized_keys trebuie să fie deținut de ${USER} și să aibă permisiunile 600

chown ${USER}:${USER} /home/${USER}/.ssh/authorized_keys
chmod 600 /home/${USER}/.ssh/authorized_keys

În cele din urmă, încercați să accesați SSH în instanța dvs.:

ssh -i /path/to/pub/key ${USER}@${IP_ADDRESS}

Acesta este ceea ce m-a salvat când am greșit accidental permisiunile pentru instanța mea AWS. Iată ce am găsit online cu privire la problema ta:

https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh https://cloud.google.com/compute/docs/troubleshooting/troubleshoot-os-login

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.