Názory k článku
Hrátky z řádky: používáme ssh

Při generování se nás program zeptá na tzv. passphrase. Když ji vyplníte, zvýšíte tím sice bezpečnost, ale opět budete muset zadávat nějaké heslo. Takže passphrasi nevyplníme.

Spíše bych doporučoval heslo vyplnit, ale používat ssh-agenta. Je to bezpečnější, aniž by to příliš ubíralo na pohodlí (heslo pak stačí zadat jednou).

ssh-agent bude v pristim pokracovani. Clanek ma omezenou delku a vse se do nej nevejde

Nevim jak autor, ale ja prikazy, co chcu provest na vzdalenem stroji, pisu do zavorek.

ssh root@example.com dd if=/dev/urandom | dd of=/dev/null (dle autora)

ssh root@example.com "dd if=/dev/urandom" | dd of=/dev/null (ja-aspon je na prvni pohled jasne, co se provede vzdalene a co lokalne

Kde su tie zatvorky? :)

chtel jsem rict uvozovky

"Při generování se nás program zeptá na tzv. passphrase. Když ji vyplníte, zvýšíte tím sice bezpečnost, ale opět budete muset zadávat nějaké heslo. Takže passphrasi nevyplníme."

Tohle je teda vrchol vseho. Vykasleme se na vsechny hesla. Svet je tak krasny, sladky, ruzovy...

Tady se bavime o passphrase ke klici. Tam si muzete zadavat co chcete a neposila se to nikam. To je kouzlo rsa klice. A druhe kouzlo je, ze jednim klicem muzete mit pod palcem treba 20 serveru, takze bych to heslo doporucil a rozhodne silnejsi nez vase bezne 'a' na roota.

Práveže se to nikam neposílá, takže jediné, co chráníme je samotný public key. Kdo se o něj bojí, může jej mít na tokenu nebo alespoň USB klíčence. Pokud na počítači nemáte jiné lidi nebo neznámé lidi, tak pravděpodobnost ukradení je taky malá. Z důvodu tak malé hrozby a o tolik zjednodušené práce taky často nevidím důvod v použití passphrase.

Hmm, moznost ukradeni klice je naopak velice znacna, navic pak staci ziskat jediny kraticky soubor a behem mziku ovladnout spoustu stroju. Takze klic bez hesla ma smysl jen pro velice specificke zalezitosti a predevsim s omezenymi pravy.

Napriklad je to vhodne reseni pro spousteni scriptu z crona, ale rozhodne by takovy klic v zadnem pripadne nemel mit na vzdalenem stroji roota.

a jak byste ovladal farmu testovacich pocitacu, kam se potrebujete dostat z ruznych automaticky poustenych skriptu a delat tam veci jako root?

tak povolit ssh bez passphrase v kluci iba pre specificke prikazy alebo skripty

naopak, oceňuji jednoduchost v kostce, o možnosti klíče jsem se doposud nikde nedověděl...

Presne takove lidi jako jste Vy hledame - kontaktujte redakci a napiste vlastni dil. Kazdy ma sve omezene mnozstvi tipu. Muzete treba popsat vami pouzivane aplikace. Serial se ubira smerem, ktery zase spouste lidi svedci. Tezko se zavdecit vsem

Mozna se budete divit, ale spousta lidi, treba .ssh/config nezna a nevyuziva. Pritom je to prima vec.
Stejne tak vykonavani prikazu na vzdalenem stroji. Ja to treba pouzivam k zalohovani konfiguraci mnoba linux/unix stroju. Snad se mi vse vejde do pristiho dilu

Kdo je maximalista a i tohle mu přijde dlouhé, může si vytvořit třeba skript nebo alias

Cifix, jsem se snad uklepl. Chtel jsem rict:
Kdo je maximalista a i tohle mu přijde dlouhé, může si vytvořit třeba skript nebo alias -> snad minimalista, ne?

hehe ;-) Jak se to vezme. Ja myslel maximalistu ve zkracovani, Vy asi minimalistu ve psani :-)

Fukncni minimalismus je o nejefektivnejsim zpusobu vykonani cinnosti, pro velmi velmi line adminy :)

Toto jsem neznal. diky

Mne používanie kľúčov v ssh už dávnejšie uľahčilo prácu, napriek tomu oceňujem tento príspevok, nakoľko viem, koľko mne trvalo, kým som sa k tomu dopracoval.

Manažujem vo firme niekoľko unix grafických staníc (SUN Blade 1500 Solaris 9). Udržiavam súbor, kde mám zoznam unix staníc - suny.txt. Hromadné činnosti sa potom dajú riešiť veľmi jednoducho:

  for ws in `cat suny.txt` ; do echo $ws `ssh $ws "ypwhich"` ; done

a mám výpis kde v riadku je názov stroja a vedľa neho server na ktorý sa v NIS daná WS overuje. Príkaz ypwhich môžem nahradiť hocičím čo ma zaujíma - najčastejšie "grep direktíva /etc/niečo", čím zistím či niektorý konfig sa nelíši od konfigov na iných strojoch.

Pre tých čo sa im nechce udržiavať zoznam strojov je možné použiť nmap, ale v prípade veľkých sietí nmap môže chvíľu trvať. Príklad nájde stroje čo majú otvorený port 22:

  for ws in `nmap -sT 192.168.0.* -p 22 -oG - | grep open | cut -f2 -d\ ` ; do
    echo $ws `ssh $ws "grep server /etc/inet/ntp.conf"`
  done

.

Doporucuji zkusit dsh

kdysi jsem cetl o zajimave vlastnosti SSH, ktera mi ale nikdy nefungovala. slo o to, ze kdyz se binarka SSH prejmenuje (nalinkuje) na DNS jmeno ciloveho stroje, SSH po zavolani takto pojmenovane binarky se automaticky pripoji na tento server. tohle by bylo hodne prakticke, kdyby to fungovalo - stacilo by zadat jmeno ciloveho stroje jako prikaz a tim bych se tam pripojil.

nevim, jestli slo o nejakou jinou implementaci nez OpenSSH nebo se mi tuhle vlastnost nepodarilo zapnout. vite nekdo neco vic?

Nechapu, v cem je rozdil oproti vytvoreni aliasu/skriptu se stejnym jmenem?

v tom, ze bych nic takoveho nemusel delat, pokud by to SSH umelo samo a elegantnejs...

1) pro změnu budu muset přejmenovat nebo pod novým ménem zkopírovat binárku ssh
2) při aktualizaci ssh balíkovací systém o nové binárce nic neví a zůstanou mi tam staré verze (které mohou mít třeba bezpečnostní chybu)

od toho jsou symlinky, se kterymi by to udajne melo fungovat

kazdopadne muj dotaz znel, zda nekdo nevi neco vic o teto vlastnosti a ne jak to resit jinak, takze odpoved otazkou proc to nedelat tak a tak me moc neuspokojuje - sam to pochopitelne jinak resim (zrovna tema aliasy), ale avizovane reseni samotnym SSH by se mi libilo vic

Ehm, snad hardlinky, ne?

Tady jsou lepší symlinky (soft linky). Ve většině případů si člověk vystačí se soft linky. V tomto případě by použití hard linku znamenalo, že po aktualizaci ssh budou bývalé hard linky na ssh obsahovat starou verzi ssh, což asi nechci.

Nebudou

ssh + proxy:

Host somehost
HostName xxx.xxx.xxx.xxx.
User someuser
Compression yes
ProxyCommand connect -S yyy.yyy.yyy.yyy %h %p

ssh + chroot:

Match Group sftpusers
ChrootDirectory /chroot/%u
ForceCommand internal-sftp

(zmente homedir uzivatele - %u - na / a pak bude v /chroot/user1 primo)

V případě, že po přihlášení bez hesla vykonáváte pořád stejnou akci, tak k výraznému zvýšení bezpečnosti přispějete tím, že do veřejného klíče tuto akci vymezíte, popsáno zde (u příkladu se zálohováním pomocí RSYNC a automatického přihlašování bez hesla):

http://troy.jdmz.net/rsync/index.html

jde to prepsat pres sftp? jestli jo, tak spis Match a ForceCommand do sshd_configu...

kdo ma zkusenost? :)

Pri hledani jsem narazil na tento clanek - http://neubia.com/archives/000191.html - kde zminuje pouze rychlostni rozdily, ktere RSA v radech nasobku prohrava.

Jsou i nejake dalsi duvody, pro volby toho ktereho algoritmu, nez jen nejcastejsi operace?

RSA neprohrává všude, právěže je rychlejší při verifikaci, jde tedy o to, komu chcete ulevit (klientu nebo serveru). Pro běžné použití je to jedno, protože tolik času to nežere.