OpenSSH
Len letmo…
bezpečná konfigurácia
/etc/ssh/sshd.conf
– hlavný kofigurák (serverový!). Akonáhle urobíš zmeny, over si správnosť syntaxe sshd -t
(= test, démon si skontroluje preklepy a pod.) a potom ho reštartni service sshd restart
Protocol 2
– OpenSHH ver. 1 je už deprecatedPort 2222
– odľahčenie logu načúvaním na inom porte, než default 22. Bacha, aby port už nebol obsadený inou službou (cat /etc/services
). Pokiaľ server vráti reject s hláškou “No route to host”, komunikáciu blokuje jeho firewall.PermitEmptyPasswords no
– zákaz prihlásenia k účtom bez heslaPermitRootLogin no
– to je samovysvetľujúce, na roota potom su, sudoStrictModes yes
– kontrola oprávnení adresárov jednotlivých užívateľov. Ak bordel, nepovolí pripojenie.- ideál je ovšem vykašlať sa na autentifikáciu účet/heslo a robiť to cez SSH kľúče, alebo nejakú nezávislú autoritu v sieti (Kerberos)
SSH kľúče
Aby bolo jasno, je viac typov overovaní kľúčmi:
- hostiteľské kľúče
- pomocou verejného/privátneho kľúča
Hostiteľský kľúč sa vlastne overuje vždy pri prihlasovaní meno/heslo. Úplne na začiatku sa musí preniesť zo servru na klienta (1. login z klienta – server deklaruje kľúč a ty si ho môžeš overiť inou cestou – mail, telefón a pod.). Ak akceptuješ, tak sa ukladá štandardne do ~/.ssh/known_hosts. V tomto súbore môže byť ľubovoľné množstvo kľúčov.
Druhá možnosť je vygenerovať hostiteľské kľúče na servri a “ručne” ich preniesť ku klientom – ssh-keygen -t dsa -f ssh_host_dsa_key
.
V tomto prípade musíš kľúč “ručábo” upraviť – doplniť meno a IP klienta.
Princíp verejného/privátneho kľúča: vygenerujem si privátny a verejný kľúč. Verejný ide na server (príp. na všetky servery, kde sa budem prihlasovať), privátny zostáva na klientovi. Pri autentifikácii server pošle reťazec klientovi, ktorý ho zašifruje pomocou privátneho kľúča a vráti späť. Server si data rozšifruje verejným kľúčom a overí autenticitu (správnosť dat) užívateľa. Výhoda – kľúč nie je posielaný po sieti. Nevýhoda – pokiaľ chcem pracovať na viacerých klientoch, al. serveroch, všade musia byť nakopírované kľúče:
- na klientovi vyrobím pár kľúčov –
ssh-keygen -t rsa
(kľúč sa hesluje a štandardne sa ukladá do~/.ssh/
) - id.rsa.pub sa bude kopčiť na servery – použi
ssh-copy-id -i id-rsa.pub meno@server
(všimni si, že to predpokladá, že sa už pripojíš pomocou ssh a teda že boli urobené hostiteľské kľúče). Utilita ssh-copy-id kontroluje správny formát počas prenosu. - je celkom dobrou praxou zabezpečiť si privátny kľúč proti prepísaniu –
chmod 400 id_rsa
custom connection options in ssh
To je tedy pěkně chaotickej popis. Doporučuji autorovi, ať si problematiku strukturovaně probere.
Bakoš
6 Apr 14 at 0:30
trhni si nohou.
http://www.root.cz/clanky/jak-se-prihlasovat-na-ssh-bez-zadavani-hesla/
ďobo
19 Jan 16 at 9:32
úpně základní princip, který tady nebyl vypíchnut:
1. vygeneruje se pár klíčů (privátní a veřejný)
2. veřejný jde na server a je ke čtení, privátní jde na klienta a střeží se bedlivě (třeba se zakryptuje passfrází)
3. klient se připojuje k serveru: server zašifruje náhodný text veřejným klíčem a vyzve klienta, ať to rozšifruje privátním klíčem a tím prokáže svojí identitu
4. aby nebylo nutné vždy vypisovat passfrázi, tak se často používá služeb ssh-agenta (udržuje privátní klíče v paměti) – viz link výše
ssh
20 Jun 16 at 12:40
zmenit passphrase
ssh-keygen -p
dobo
23 Oct 18 at 15:28
ssh copy id
https://www.ssh.com/ssh/copy-id
dobo
28 Jan 19 at 12:15