FAQ \u2013 najcz\u0119\u015bciej zadawane pytania o klucze SSH<\/a><\/li>\n<\/ul>\n<\/nav>\nDwa pliki, jedna zasada<\/h2>\n
Para kluczy to dwa powi\u0105zane matematycznie pliki. Klucz prywatny zostaje na Twoim komputerze i nie opuszcza go nigdy. Klucz publiczny wgrywasz na serwer i mo\u017cesz go rozdawa\u0107 bez obaw, bo s\u0142u\u017cy wy\u0142\u0105cznie do sprawdzenia, czy druga strona posiada odpowiadaj\u0105cy mu klucz prywatny.<\/p>\n
Podczas logowania serwer stawia zadanie, kt\u00f3re da si\u0119 rozwi\u0105za\u0107 tylko kluczem prywatnym. Has\u0142o nigdy nie jest przesy\u0142ane, wi\u0119c nie ma czego przechwyci\u0107 ani zgadn\u0105\u0107. Serwery RapidDC obs\u0142uguj\u0105 uwierzytelnianie kluczem, a sam klucz mo\u017cesz wskaza\u0107 ju\u017c przy zak\u0142adaniu maszyny.<\/p>\n
Generowanie pary kluczy<\/h2>\n
Na Linuksie, macOS i w Windows 10 lub nowszym wystarczy wbudowany klient:<\/p>\n
ssh-keygen -t ed25519 -C \"laptop-robocze\"\r\n<\/code><\/pre>\nKilka uwag do tego polecenia. Typ ed25519<\/code> jest dzi\u015b domy\u015blnym wyborem: kr\u00f3tszy i szybszy od RSA przy por\u00f3wnywalnym bezpiecze\u0144stwie. Je\u015bli musisz obs\u0142u\u017cy\u0107 bardzo stary serwer, u\u017cyj -t rsa -b 4096<\/code>. Komentarz po -C<\/code> to tylko etykieta, ale bardzo pomaga, gdy po roku patrzysz na list\u0119 kluczy i pr\u00f3bujesz sobie przypomnie\u0107, kt\u00f3ry komputer jest kt\u00f3ry.<\/p>\nProgram zapyta o has\u0142o do klucza. Ustaw je. To has\u0142o chroni plik na dysku, wi\u0119c je\u015bli laptop zginie, sam klucz nadal jest bezu\u017cyteczny dla znalazcy. \u017beby nie wpisywa\u0107 go przy ka\u017cdym po\u0142\u0105czeniu, dodaj klucz do agenta poleceniem ssh-add<\/code>.<\/p>\nPowstan\u0105 dwa pliki: ~\/.ssh\/id_ed25519<\/code> (prywatny, nie wysy\u0142aj go nigdzie) oraz ~\/.ssh\/id_ed25519.pub<\/code> (publiczny).<\/p>\nWgranie klucza na serwer<\/h2>\n
Najpro\u015bciej jednym poleceniem:<\/p>\n
ssh-copy-id uzytkownik@adres-ip-serwera\r\n<\/code><\/pre>\nPolecenie zaloguje si\u0119 has\u0142em ostatni raz i dopisze klucz publiczny do pliku ~\/.ssh\/authorized_keys<\/code> na serwerze. Je\u015bli ssh-copy-id<\/code> nie jest dost\u0119pne, ten sam efekt uzyskasz r\u0119cznie: utw\u00f3rz na serwerze katalog ~\/.ssh<\/code> z uprawnieniami 700, plik authorized_keys<\/code> z uprawnieniami 600 i wklej do niego zawarto\u015b\u0107 klucza publicznego. Uprawnienia s\u0105 tu istotne, bo serwer SSH z zasady ignoruje pliki dost\u0119pne dla innych u\u017cytkownik\u00f3w.<\/p>\nTeraz najwa\u017cniejszy krok, kt\u00f3ry \u0142atwo pomin\u0105\u0107: otw\u00f3rz drugie okno terminala i zaloguj si\u0119 kluczem, zanim cokolwiek zmienisz w konfiguracji<\/strong>. Pierwsze po\u0142\u0105czenie zostaw otwarte. To jest Twoja droga powrotna, je\u015bli co\u015b p\u00f3jdzie nie tak.<\/p>\nTrzy ustawienia, kt\u00f3re warto zmieni\u0107<\/h2>\n
Konfiguracja serwera znajduje si\u0119 w \/etc\/ssh\/sshd_config<\/code>. Po sprawdzeniu, \u017ce logowanie kluczem dzia\u0142a, zmie\u0144 trzy rzeczy:<\/p>\nPasswordAuthentication no\r\nPermitRootLogin prohibit-password\r\nPubkeyAuthentication yes\r\n<\/code><\/pre>\nPierwsza linia wy\u0142\u0105cza has\u0142a i to ona odcina automaty. Druga pozwala na logowanie na konto root wy\u0142\u0105cznie kluczem, co jest rozs\u0105dnym kompromisem mi\u0119dzy wygod\u0105 a bezpiecze\u0144stwem. Je\u015bli pracujesz na koncie zwyk\u0142ego u\u017cytkownika z sudo<\/code>, mo\u017cesz ustawi\u0107 tam no<\/code>.<\/p>\nPo zapisaniu prze\u0142aduj us\u0142ug\u0119 poleceniem systemctl reload sshd<\/code>, a nast\u0119pnie w nowym<\/strong> oknie sprawd\u017a, czy nadal si\u0119 logujesz. Dopiero gdy to zadzia\u0142a, zamknij pierwsze po\u0142\u0105czenie. Gdy co\u015b p\u00f3jdzie \u017ale, zostaje konsola z panelu maszyny, ale znacznie wygodniej jest po prostu nie zamyka\u0107 otwartej sesji.<\/p>\nZmiana portu i co ona naprawd\u0119 daje<\/h2>\n
Przeniesienie SSH z portu 22 na inny ogranicza ha\u0142as w logach, bo wi\u0119kszo\u015b\u0107 automat\u00f3w skanuje wy\u0142\u0105cznie porty standardowe. Nie jest to jednak zabezpieczenie, tylko sprz\u0105tanie: skanowanie ca\u0142ego zakresu port\u00f3w zajmuje chwil\u0119 i wystarczy, by us\u0142ug\u0119 odnale\u017a\u0107.<\/p>\n
Realne zabezpieczenie daje po\u0142\u0105czenie trzech rzeczy: logowania wy\u0142\u0105cznie kluczem, zapory przepuszczaj\u0105cej ruch na port SSH tylko z zaufanych adres\u00f3w oraz narz\u0119dzia blokuj\u0105cego powtarzaj\u0105ce si\u0119 nieudane pr\u00f3by. O samej zaporze pisali\u015bmy we wpisie o tym, czym jest zapora sieciowa<\/a>.<\/p>\nPraca z kilku komputer\u00f3w<\/h2>\n
Klucz jest przypisany do maszyny, nie do cz\u0142owieka, wi\u0119c nie kopiuj klucza prywatnego mi\u0119dzy urz\u0105dzeniami. Wygeneruj osobn\u0105 par\u0119 na ka\u017cdym komputerze i dopisz kolejne klucze publiczne do authorized_keys<\/code> na serwerze. Plik przyjmuje dowoln\u0105 liczb\u0119 wpis\u00f3w, po jednym w linii.<\/p>\nTa sama zasada obowi\u0105zuje w zespole. Ka\u017cda osoba ma w\u0142asny klucz, a odebranie dost\u0119pu sprowadza si\u0119 do usuni\u0119cia jednej linii z pliku. Przy wsp\u00f3\u0142dzielonym ha\u015ble odebranie dost\u0119pu jednej osobie oznacza zmian\u0119 has\u0142a wszystkim.<\/p>\n
Podsumowanie<\/h2>\n
Konfiguracja zajmuje kwadrans i zostaje z Tob\u0105 na lata. Wygeneruj par\u0119, wgraj klucz publiczny, sprawd\u017a logowanie w drugim oknie, wy\u0142\u0105cz has\u0142a i dopiero wtedy zamknij pierwsz\u0105 sesj\u0119.<\/p>\n
Je\u015bli dopiero planujesz w\u0142asn\u0105 maszyn\u0119, serwery VPS RapidDC<\/a> dzia\u0142aj\u0105 na pe\u0142nej wirtualizacji KVM, daj\u0105 dost\u0119p root, dedykowany adres IP i obs\u0142uguj\u0105 klucze SSH, a reinstalacje s\u0105 nielimitowane, wi\u0119c eksperymentowanie nic nie kosztuje. Zanim zaczniesz, przejrzyj wpis o \u0142\u0105czeniu si\u0119 z serwerem VPS przez SSH<\/a>.<\/p>\nFAQ \u2013 najcz\u0119\u015bciej zadawane pytania o klucze SSH<\/h2>\nCo si\u0119 stanie, gdy zgubi\u0119 klucz prywatny?<\/h3>\n
Stracisz dost\u0119p do serwera t\u0105 drog\u0105. Dlatego warto mie\u0107 drugi klucz z innego urz\u0105dzenia dopisany do authorized_keys<\/code> albo dost\u0119p do konsoli z panelu maszyny. Klucza prywatnego nie da si\u0119 odtworzy\u0107 z publicznego.<\/p>\nCzy has\u0142o do klucza jest konieczne?<\/h3>\n
Formalnie nie, ale bez niego plik klucza wystarcza do zalogowania si\u0119 ka\u017cdemu, kto go zdob\u0119dzie. Z has\u0142em i agentem SSH wpisujesz je raz na sesj\u0119, wi\u0119c koszt wygody jest minimalny wobec zysku.<\/p>\n
Czym r\u00f3\u017cni si\u0119 ed25519 od RSA?<\/h3>\n
Ed25519 daje kr\u00f3tszy klucz, szybsze uwierzytelnianie i bezpiecze\u0144stwo por\u00f3wnywalne z RSA 4096. RSA wybieraj tylko wtedy, gdy serwer docelowy jest na tyle stary, \u017ce nie obs\u0142uguje nowszego algorytmu.<\/p>\n
Czy mog\u0119 u\u017cywa\u0107 jednego klucza na kilku serwerach?<\/h3>\n
Tak i jest to typowa praktyka. Ten sam klucz publiczny dopisujesz na ka\u017cdym serwerze, do kt\u00f3rego chcesz mie\u0107 dost\u0119p. Osobne klucze generuj per urz\u0105dzenie, a nie per serwer.<\/p>\n
Jak sprawdzi\u0107, \u017ce logowanie has\u0142em naprawd\u0119 zosta\u0142o wy\u0142\u0105czone?<\/h3>\n
Spr\u00f3buj po\u0142\u0105czy\u0107 si\u0119 z pomini\u0119ciem kluczy poleceniem ssh -o PubkeyAuthentication=no uzytkownik@adres<\/code>. Poprawnie skonfigurowany serwer odrzuci takie po\u0142\u0105czenie bez pytania o has\u0142o.<\/p>\n