[ Pobierz całość w formacie PDF ]
.Za pomoc¹ ssh mo¿esz uruchamiaæ polecenia na hoScie zdalnym.Znów sk³adnia jestbardzo prosta.Niech u¿ytkownikmaggieobejrzy zawartoSæ katalogu g³Ã³wnegohosta vchianti.vbrew.com.Mo¿e to zrobiæ nastêpuj¹co:$ ssh vchianti.vbrew.com ls -CF /maggie@vchianti.vbrew.com's password:bin/ console@ dos/ home/ lost+found/ pub@ tmp/ vmlinuz@boot/ dev/ etc/ initrd/ mnt/ root/ usr/ vmlinuz.old@cdrom/ disk/ floppy/ lib/ proc/ sbin/ var/Polecenie ssh mo¿esz umieSciæ w potoku poleceñ i przekazywaæ wejScie/wyjScieprogramu do lub z innego programu, tak jak w innych poleceniach, z t¹ ró¿nic¹, ¿ewejScie lub wyjScie s¹ kierowane do lub z hosta zdalnego przez po³¹czenie ssh.Otoprzyk³ad, jak mo¿esz wykorzystaæ tê mo¿liwoSæ w po³¹czeniu z poleceniem tar doprzekopiowania ca³ego katalogu (z podkatalogami i plikami) z hosta zdalnego nahost lokalny: Konfigurowanie zdalnego logowania i uruchamiania 227$ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf -maggie@vchianti.vbrew.com's password:etc/GNUstepetc/Muttrcetc/Netetc/X11etc/adduser.conf.Polecenie do wykonania wziêliSmy tutaj w cudzys³Ã³w, aby by³o jasne, co przekazu-jemy jako argument do ssh i co jest u¿ywane przez lokaln¹ pow³okê.Polecenie to wy-konuje tar na hoScie zdalnym, które z kolei archiwizuje katalog /etc i wypisuje wynikna standardowe wyjScie.ZastosowaliSmy potok, przez który przekazujemy standar-dowe wyjScie do polecenia tar dzia³aj¹cego na hoScie lokalnym w trybie odczytywa-nia ze standardowego wejScia.Znów zostaliSmy poproszeni o wprowadzenie has³a.Teraz mo¿esz zobaczyæ, dla-czego zachêcaliSmy ciê do skonfigurowania ssh tak, ¿eby nie pyta³o o has³a za ka¿-dym razem! Skonfigurujmy teraz naszego lokalnego klienta ssh tak, by nie pyta³o has³o przy ³¹czeniu siê z hostem vchianti.vbrew.com.WspomnieliSmy wczeSniejo pliku.ssh/authorized_keys.W³aSnie on jest u¿ywany do tego celu.Plik.ssh/authori-zed_keys zawiera klucze publiczne wszelkich zdalnych kont u¿ytkowników, na którechcemy siê automatycznie logowaæ.Automatyczne logowanie mo¿esz ustawiæ, ko-piuj¹c zawartoSæ pliku.ssh/identity.pub z konta zdalnego do lokalnego pliku.ssh/au-thorized_keys.Istotne jest, by prawa dostêpu do pliku.ssh/authorized_keys pozwala³yna dostêp tylko tobie i tylko na zapis i odczyt.W przeciwnym razie ktoS móg³byukraSæ klucze i zalogowaæ siê na zdalne konto.Aby mieæ pewnoSæ, ¿e prawa dostêpus¹ poprawne, zmieñ.ssh/authorized_keys w nastêpuj¹cy sposób:$ chmod 600 ~/.ssh/authorized_keysKlucze publiczne to jeden d³ugi wiersz czystego tekstu.Je¿eli u¿ywasz funkcji ko-piowania i wklejania do powielania kluczy w twoim pliku lokalnym, pamiêtaj o usu-niêciu wszelkich znaków koñca wiersza, które mog³y zostaæ przez przypadek wsta-wione.Plik.ssh/authorized_keys mo¿e zawieraæ wiele takich kluczy, ale ka¿dy z nichmusi znajdowaæ siê w oddzielnym wierszu.Pakiet narzêdzi ssh i oferuje wiele przydatnych funkcji i opcji, które warto poznaæ.W poszukiwaniu dodatkowych informacji zajrzyj do podrêcznika elektronicznegoi dokumentacji dostarczanej wraz z pakietem. 13System informacjisieciowejRozdzia³ 13: System informacji sieciowejGdy obs³ugujesz sieæ lokaln¹, zwykle twoim g³Ã³wnym celem jest zapewnienieswoim u¿ytkownikom takiego Srodowiska, w którym sieæ jest przezroczysta.Warun-kiem jest synchronizacja na wszystkich hostach w sieci takich danych, jak informacjeo kontach u¿ytkowników.Wówczas u¿ytkownicy mog¹ swobodnie przesiadaæ siêz komputera na komputer bez potrzeby pamiêtania ró¿nych hase³ i kopiowania da-nych miêdzy maszynami.Dane, które s¹ przechowywane centralnie, nie musz¹ byæreplikowane, jeSli istnieje jakiS wygodny sposób na dostanie siê do nich z hostapod³¹czonego do sieci.Centralne przechowywanie istotnych informacji administra-cyjnych ma szereg zalet.Gwarantuje spójnoSæ danych.Daje wiêksz¹ swobodê u¿yt-kownikom poprzez mo¿liwoSæ przesiadania siê z hosta do hosta.U³atwia ¿ycie ad-ministratorowi systemu, który zarz¹dza tylko jednym egzemplarzem informacji.WczeSniej omówiliSmy wa¿ny przyk³ad centralizacji danych, pochodz¹cy z Interne-tu system nazw domen (DNS).DNS udostêpnia ograniczony zakres informacji,z których najwa¿niejsze to t³umaczenie nazw hostów na adresy IP i odwrotnie.Innetypy danych nie maj¹ swoich specjalistycznych us³ug.Co wiêcej, je¿eli zarz¹dzasz tyl-ko ma³¹ sieci¹ LAN bez dostêpu do Internetu, korzySci ze skonfigurowania DNS-umog¹ nie byæ warte pracy, jak¹ trzeba w to w³o¿yæ.Dlatego w³aSnie firma Sun stworzy³a system informacji sieciowej (Network InformationSystem NIS).NIS to funkcje ogólnego dostêpu do bazy danych.Za ich pomoc¹ mo-¿na dystrybuowaæ do wszystkich hostów w sieci na przyk³ad informacje zawartew plikach passwd i group.Dziêki temu sieæ jest widoczna jako jeden system, z tymi sa-mymi kontami na wszystkich hostach.Podobnie mo¿esz wykorzystaæ NIS-a do dys-trybuowania informacji o nazwie hosta zawartych w pliku /etc/hosts do wszystkichinnych maszyn w sieci.NIS jest oparty na RPC i sk³ada siê z serwera, bibliotek strony klienta i kilku narzêdziadministracyjnych.Pierwotnie nosi³ nazwê Yellow Pages (lub YP); nadal mo¿na spo- 230 Rozdzia³ 13: System informacji sieciowejtkaæ siê z odwo³aniami do niej.Jednak okaza³o siê, ¿e nazwa ta jest znakiem towaro-wym firmy British Telecom, która za¿¹da³a, by Sun przesta³ jej u¿ywaæ
[ Pobierz całość w formacie PDF ]