Cu toate software-ul anti-virus, rețea monitorizează gateway-uri în sistemul de operare în sine, sistemul detectează proactiv intruziuni și alte măsuri de securitate un server sau stație de lucru care oră devin simptome paranoice - alimentare cu 100% că mașina nu este, sau nu vor apărea în viitorul apropiat, niște rahaturi sunt imposibile.
Cineva ar putea argumenta, spun ei, „Da, dar cheia privată poate pune o parolă!“ - Sunt de acord, este posibil, dar în acest caz parola va fi cusute în cheia în sine că, în cazul în care este furat, precum și resurse de calcul suficiente și o bună cunoaștere a criptografiei, va oferi o ocazie pentru forța sa bruta activă fără nici o limitare din partea OS - adică brute force sistemul de operare pentru a efectua mult mai complicate (blocarea accesului după 2-3 încercări de autentificare incorecte, și așa mai departe.), decât cheia de forță brută la nivel local!
De asemenea, în cazul în care acesta este pierdut privat (id_rsa), atunci ne putem descurca în condiții de siguranță val servantă și du-te cu durere naklyukatstso albastru (atunci când cheile private SSH sunt pierdute) în cazul în care nu există acces fizic la masina - publice (id_rsa.pub) poate fi recuperat din mediul privat, dar privat din partea publicului este puțin probabil. Există o anumită caracteristică opiniile (RevokedKeys) chei, dar nu e același lucru, că recuperarea - (. Chei revocate nu pot fi folosite pentru utilizator sau autentificarea gazdă și va declanșa un avertisment dacă este utilizat) revocată chei (anulat) nu pot fi folosite pentru autentificare suplimentară !
Nu spune că traficul SSL sau brute force hacking cheie privată RSA este imposibilă - în timpul celui de Al Doilea germanii Mondial, de asemenea, a crezut că mașina cifrul Enigma Wehrmacht invincibil!
Dacă cineva încă decis să utilizeze mecanismul de autentificare SSH doar o cheie RSA, interzicerea mecanismului de parole, apoi efectuați câțiva pași simpli, care sunt descrise mai jos, precum și scris o voință, îmbrăca scutece și să păstreze truselya mai puternic;!)
Crearea unei perechi de chei RSA
Crearea unei perechi de chei RSA nu durează prea mult timp - tastele RSA ssh-keygen-im:
Apoi am mers la consola ca un utilizator „șaman“, directorul home „/ home / șaman“, care implicit este .ssh director cu chei RSA (id_rsa și id_rsa.pub). În exemplu, parola pentru cheia privată nu a fost setată, dar pentru uzul practic este de dorit să se pună cel puțin o parolă pe id_rsa (cheia secretă).
Desigur, toate manipulările descrise aici, crearea cheilor RSA și așa mai departe. rulați pe un server la distanță, pe care o vom autentifica cu cheile.
De asemenea, puteți crea chei pe mașina locală, dar atunci cheia publică va trebui mutată la mașina de la distanță.
Configurația Sshd_config
Dacă veți dezactiva autentificarea prin parolă, atunci în / etc / ssh / sshd_config dezactivați:
PuTTY Nu se poate utiliza fișierul cheie
Pentru cei care, pentru prima dată pe schiuri PuTTY - eroarea „Nu se poate utiliza fișierul cheie“ X: \ id_rsa „(cheia privată OpenSSH SSH-2)“ poate apărea din mai multe motive:
- Versiunea SSH nu este formatată cu cheia id_rsa și versiunea în care aceasta încearcă să fie folosită, tastele pentru SSH-1 și SSH-2 sunt confecționate în diferite formate;
- Tasta id_rsa non-format pentru utilizarea în PuTTY, pentru PuTTY trebuie să convertiți cheile în format .ppk
În cazul în care a generat id_rsa utilități standard ale pachetului OpenSSH (ssh-keygen -t rsa), acesta trebuie să fie exportate într-un format .ppk urmează (CMD realizare - PuTTYgen id_rsa id_rsa.ppk o-) pentru utilizare în clientul SSH PuTTY:
- Rulați puttygen și încărcați cheia privată id_rsa, care a fost creată de utilitare din pachetul OpenSSH și, dacă doriți, puneți o parolă pe ea:
- Salvați cheia privată în formatul .ppk (salvați cheia privată):
Restabiliți cheia publică din partea privată
Pentru a restabili cheia publică (Creați o cheie publică SSH din cheia privată) de la cheia privată deja existentă, efectuați următoarele:
Cu această configurație a serverului OpenSSH pentru Windows, s-ar putea întâmpina eroarea clientului SSH "Serverul OpenSSH a refuzat cheia noastră", iar jurnalul de sistem va primi următoarele mesaje:
Nu a fost găsită nicio descriere a evenimentului cu codul (0) din sursă (sshd). Este posibil ca computerul local să nu aibă datele de registry necesare sau fișiere DLL de mesaje pentru a afișa mesajele de pe computerul la distanță. Încercați să utilizați / AUXSOURCE = pentru a obține această descriere; - mai multe informații despre acest lucru pot fi găsite în ajutor. Înregistrarea evenimentului conține următoarele informații: sshd: PID 1712: eroare: Deconectarea primită de la 192.168.231.1: 13: Imposibil de autentificat.
---
Nu a fost găsită nicio descriere a evenimentului cu codul (0) din sursă (sshd). Este posibil ca computerul local să nu aibă datele de registry necesare sau fișiere DLL de mesaje pentru a afișa mesajele de pe computerul la distanță. Încercați să utilizați / AUXSOURCE = pentru a obține această descriere; - mai multe informații despre acest lucru pot fi găsite în ajutor. Înregistrarea evenimentului conține următoarele informații: sshd: PID 1712: Autentificare refuzată: proprietate rea sau moduri pentru director / home / user.
Este probabil ca eroarea client SSH „OpenSSH Server a refuzat cheia noastră“ va primi în mod inevitabil, și în mod constant, dacă încercăm să folosim un fișier cu caracter personal „.ssh / authorized_keys“ pentru fiecare utilizator!
Singura cale de ieșire în acest caz este folosirea fișierului common_for all users, authorized_keys - "AuthorizedKeysFile / etc / ssh / authorized_keys".
Fiecare utilizator poate crea propriile chei în directorul lor de acasă:
Cu toate acestea, pentru cheile permit accesul, administratorul trebuie să adauge conținutul cheii publice (id_rsa.pub) a fiecărui utilizator în / etc / ssh / authorized_keys, bine, și, desigur, nu uitați să adăugați un utilizator în / etc / passwd.
Conținut recomandat
Articole similare
Trimiteți-le prietenilor: