Puncte:0

SSH eșuat după dezactivarea autentificare rădăcină

drapel dk

După ce am generat cheia privată și publică pentru un client RHEL și am stocat cheia publică în folderul authorized_keys al serverului RHEL 7, am dezactivat autentificarea rădăcină pe server mergând la /etc/ssh/sshd_config si setarea PermitRootLogin la nr. După aceea am repornit serviciul sshd.

Acum, când încerc să fac ssh de la client la server, se spune

Permisiune refuzată (publickey,gssapi-keyex,gssapi-with-mic,parolă)

De ce primesc acest mesaj?

drapel cn
Unde ai pus cheia autorizată pe server? Cu ce ​​utilizator te conectezi? ce comanda folosita?
Raghav Gupta avatar
drapel dk
@shearn89 Am pus cheia publică a clientului sub fișierul authorized_key al serverului în directorul - /root/.ssh . Mă conectez ca utilizator root. Ce vrei să spui prin ce comandă folosită? Întrebați pentru ce comandă?
Puncte:5
drapel it

Comportamentul tău este complet normal. Schimba-ti PermitRootLogin nr pentru a se conforma mai mult nevoilor tale PermitRootLogin fără parolă

Asigurați-vă că aveți cheia potrivită la locul potrivit (de obicei ~/.ssh/authorized_keys) cu bunul proprietar:group și cu chmod 600 și 700 pe ~/.ssh/authorized_keys și ~/.ssh.

Raghav Gupta avatar
drapel dk
A încercat asta. După aceasta, acum, când fac ssh de la client, îmi cere parola. De ce e așa? Parola nu ar trebui să fie cerută atunci când faceți ssh.

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.