Pobierz spakowaną witrynę gorzow-wlkp.pl/linuxJeżeli pragniesz poznać Linuksa Mandrake (obecnie Mandriva), to... dobrze trafiłeś. Witryna została zauważona przez twórców magazynu KOMPUTER ŚWIAT 5/2004(141) str. 46 poprzez umieszczenie linku oraz magazynu CHIP 4/2004 (str.114) poprzez umieszczenie artykułu opisującego ten serwis internetowy. Jak na hobbystyczną stronę o Linuksie to miłe ;) Acha... na stronie mandrakelinux.pl/informacje podano też link z opisem cytuję "duży zbiór praktycznych informacji o Mandrake" (mam ją w swoim archiwum - klub.chip.pl/twarogal).
Zapraszam do zadawania pytań na FORUM oraz mailem. Chętnie udzielę (bezpłatnie) odpowiedzi. Oficjalne ceny za jedną poradę na stronie MandrakeSoftPL (mam ją w moim archiwum z dnia 2.05.2004) wahają się od 20 do 350 zł.
Lista artykułów o SSH dostępnych na tej witrynie:
- Podstawy: część pierwsza (jesteśmy na
niej) zawiera wyjaśnienia podstawowych tematów związanych z
najprostszym skonfigurowaniem ssh. Logowanie do shella odbywa się
tam poprzez wpisanie hasła systemowego usera. Ponadto
polecam notatkę o szyfrowanym sftp.
- Podstawy: część druga, to
tłumaczenie z angielskiego na polski doskonałego artykułu o
konfigurowaniu ssh autorstwa Vincenta Danena.
- VNC, czyli zdalne przejmowanie Pulpitu
w szyfrowanym tunelu SSH.
- Uruchomienie programu wymagającego X-Window pod tunelem ssh (opcja X11Forwarding yes w sshd)
Strona domowa projektu: http://openssh.org/
Serwer sshd nie jest przeznaczony dla nowicjuszy
linuksowych, którzy dopiero zaczynają przygodę z Pingwinem.
Kiedy powinieneś zainteresować się tym następcą telnetu?
Wyłącznie gdy chcesz umożliwić zdalny dostęp do Twojego Linuksa.
Oczywiście umiesz odróżnić serwer OpenSSH (czyli demon
sshd wraz z plikami konfiguracyjnymi) od klienta ssh
;) Największą zaletą OpenSSH to szyfrowanie transmisji i haseł
(jeżeli do logowania używasz kluczy, a następnie haseł). Waże jest
też to, że otrzymujemy produkt bezpłatny i legalny.
* * *
Dla porządku przyjmuję, że jesteś tuż po instalacji systemu
Mandrake/Mandriva. Skonfigurowałeś połączenie z Internetem np. na łączu SDI-HIS, zapewniłeś
właściwy poziom bezpieczeństwa (poleceniem msec
4), wykonałeś udostępnienie Internetu dla domowej sieci +
dhcpd (zleceniem drakgw), skonfigurowałeś ewentualnego
klienta Samby,
zapewniłeś bezpieczeństwo swojemu serwerowi poprzez firewall- shorewall (zleceniem drakfirewall).
Oczywiście nie jest to instrukcja instalacji i konfiguracji, a
jedynie przypomnienie - myślę, że znasz temat, skoro zabrałeś się
za SSH. Przyjmuję, że przeczytałeś strony o instalowaniu, poziomach bezpieczeństwa oraz BHP no i udostępniłeś port 22 na
firewallu.
* * *
Jeżeli przeczytałeś powyższe i wiesz o czym tam piszę, to bądź
dobrej myśli - reszta już będzie prostsza :)
Konfiguracja serwera sshd
(OpenSSH).
- Podczas instalacji Mandrake wybierz pakiet
serwer OpenSSH (DODATKOWE PAKIETY- SERWERY- openssh). Jeżeli
tego nie zrobiłeś, to doinstaluj pakiet z płytki CD. Pod KDE po
prostu wybierz: MANDRAKE CONTROL CENTER- ZARZĄDZANIE
OPROGRAMOWANIEM- INSTALACJA OPROGRAMOWANIA- ZNAJDŹ W NAZWACH:
ssh i zainstaluj openssh-server oraz jeżeli nie ma
jeszcze w systemie openssh-clients
- Jeżeli instalujesz serwer sshd na nowo (np.
podczas reinstalacji systemu, przy zachowaniu danych z partycji
montowanej jako /home), to usuń na wszelki wypadek zawartość
pliku /home/użytkownik/.ssh/known_hosts . Restartuj
system.
- Jako root wejdź do katalogu /etc/ssh i
wylistuj jego zawartość zleceniem ls -la .
Zapisz sobie na kartce prawa pliku /etc/ssh/sshd_config (u
mnie było root.adm 640) . Skopiuj go do jakiegoś archiwum.
Następnie wprowadź mój plik sshd_config do swojego Linuksa jako
/etc/ssh/sshd_config i nadaj mu właściwe prawa. Włącz (lub restartuj) serwer sshd . Ambitnych
zapraszam do przeczytania opisu pliku
/etc/ssh/sshd_config.
- Dopilnuj, aby w pliku /etc/hosts.deny był
wpis ALL: ALL (z ewentualnym dopuszczeniem 127.0.0.1 czyli
localhost). Nie jest to co prawda ściśle związane z konfiguracją
sshd, ale o bezpieczeństwie należy ciągle przypominać ;-) Więcej o
plikach hosts znajdziesz tutaj.
- Dodaj do pliku /etc/hosts.allow wpis dający
PEŁNE prawa dla hostów. Po zakończeniu konfiguracji i uzyskaniu
prawidłowej pracy-połączenia ssh, zmienisz ALL na ssh
oraz sshd. Moja propozycja nie jest może zbyt bezpieczna,
ale unikniesz w ten sposób kilku problemów podczas pierwszego
konfigurowania połączenia. Nie trzeba restartować systemu (ani
demonów), aby zmiana wpisu w /etc/hosts.allow nabrała
legalności.
Teraz wpisz do pliku /etc/hosts.allow
sshd: 127.0.0.1
ssh: 127.0.0.1
sshd: 192.168.0.1
ssh: 192.168.0.1
sshd: 218.56.248.234
ssh: 218.56.248.234
sshd: 217.97.58.25
ssh: 217.97.58.25
Wyjaśnienie:
127.0.0.1 to numer, z którego korzystasz podczas testowania
serwera w tzw. pentelce (łączysz się sam ze sobą).
192.168.0.1 to Twój wewnętrzny numer IP serwera.
218.56.248.234 to Twój zewnętrzny numer IP serwera (ten od
TPSA).
217.97.58.25 to numer odległego
komputera z netu, któremu pozwolisz zalogować się na serwerze
sshd.
Jeżeli w pliku /etc/hosts.allow dasz wpis:
ssh: ALL
sshd: ALL
to z każdego IP będzie można się logować (niezbyt bezpieczne
rozwiązanie, choć przydatne gdy szukasz przyczyn wadliwego
działania serwera sshd - w takich
okolicznościach daj w/w wpis na obu komputerach: kliencie i
serwerze)
Konfiguracja klienta ssh.
- Podczas instalacji Mandrake standardowo
instaluje pakiet ssh-klient. Plik konfiguracyjny klienta
ssh możesz zostawić na razie w wersji domyślnej.
- Zaloguj się na swoim linuksowym serwerze jako
zwykły użytkownik i wydaj polecenie:
ssh localhost
lub
ssh 127.0.0.1
Jeżeli się nie uda, to w celach testowych powtórz, ale na koncie
roota. Jeżeli klient (pod rootem) zadziała i umożliwi logowanie się
na serwer (zainstalowany zresztą na tym samym komputerze), a nie
możesz tego powtórzyć na zwykłym koncie, to prawdopodobnie masz problem z prawami do pliku ssh. Przyjmuję,
że wszystko poszło jak należy.
- Podaj odległemu znajomemu swój adres (np.
pd126.wroclaw.sdi.tpnet.pl z nr IP 218.56.248.234),
nazwę swojego konta linuksowego np. antek i linuksowe
(shellowe) hasło do niego np. dhya51R,.K . Następnie poproś,
aby wpisał do swojego pliku /etc/hosts.allow wiersz (na
końcu): ALL: 218.56.248.234 . Gdy wszystko zadziała i
połączenie w obie strony będzie dobrze skonfigurowane, ten wpis
Twój znajomy powinien poprawić na dwa wiersze sshd:
218.56.248.234 oraz ssh: 218.56.248.234
Twój znajomy niech teraz spróbuje zalogować się na Twój komputer
(pamiętaj, aby wpisać jego IP do pliku /etc/hosts.allow).
Twój znajomy powinien wpisać pod Linuksem, w powłoce tekstowej
polecenie:
ssh nazwakonta@pd126.wroclaw.sdi.tpnet.pl
lub
ssh nazwakonta@218.56.248.234
lub
ssh pd126.wroclaw.sdi.tpnet.pl -l antek (antek
to przykładowy login)
lub
ssh -C nazwahosta -l user (flaga -C
spowoduje, że transmisja będzie skompresowana, o ile serwer
sshd ma włączoną taką opcję)
NIGDY nie wpisuj polecenia z hasłem: ssh nazwakonta:hasło@pd126.wroclaw.sdi.tpnet.pl , gdyż ułatwisz
przechwycenie hasła shellowego. Polecam w ogóle rezygnację z tego
typu logowania i używanie kluczy publicznych (plus dodatkowo użycie
haseł) - zapraszam na sąsiednią stronę, gdzie umieściłem
tłumaczenie ciekawego artykułu pobranego z witryny Mandrake o
konfiguracji OpenSSH. Gdy już klient i serwer będzie prawidłowo
działał na Twoim serwerze, to możesz zalogować się na odległym,
zaprzyjaźnionym shellu.
Opis opcji klienta ssh (uzyskany poprzez zlecenie ssh --help) wraz z moim tłumaczeniem na polski.
Powtórze jeszcze raz, gdyż ten punkt
jest najczęściej zapominany przez nowicjuszy: pamiętaj, aby dodać
jego IP do Twojego pliku /etc/hosts.allow no i żeby na odległym
serwerze wpisano Twój IP do pliku hosts.allow.
*
Usuwanie problemów. Inne
wyjaśnienia..
W razie problemów uruchom klienta ssh z opcją -v
(verbose czyli gadatliwy). Przykład takiego zlecenia:
ssh antek@192.168.0.1 -v
lub z opcją tworzenia pliku zawierającego
komunikaty sshproblem.txt:
ssh antek@192.168.0.1 -v>>1
| tee
/home/antek/Desktop/sshproblem.txt
Więcej na temat zlecenia tee znajdziesz tutaj.
* * *
Często miałem listy z pytaniami o przyczynę
odmowy połączenia ssh z klienta domowej sieci na serwer. Jak się
okazywało wszystkie punkty były wykonywane prawidłowo, ale o jednym
czasami zapominano... że serwer-router dynamicznie przydzielał
adresy IP swoim klientom i zmiany adresów IP klienta nie zawsze
pokrywały się z tym wpisanym do pliku /etc/ hosts.allow.
W Mandrake 10.0 istnieje kilka dodatkowych
"problemów":
W pliku /etc/hosts.allow nie wystarczy wpisać ALL: 192.168.1.4 (ten nr IP to adres klienta w domowej
sieci, z którego chcemy się logować na sshd). Trzeba koniecznie dać
dwa wpisy:
ssh: 192.168.1.4
sshd: 192.168.1.4
Mandrake 10.0 zainstalowany w WYŻSZYM poziomie
bezpieczeństwa potrafi skutecznie zablokować połączenie z sshd w
ramach... ochrony przed włamaniami. Niestety, na stronach Mandrake
nie ma opisu jak "ręcznie" poprawić zabezpieczenia, więc podczas
instalacji należy wybrać nie WYŻSZY (dla serwerów) poziom
bezpieczeństwa, ale WYSOKI i po instalacji poprawić na WYŻSZY (msec 4). Więcej na ten temat na stronie o instalowaniu Mandrake 10.0. Acha...
oryginalny plik konfiguracyjny sshd_config w Mandrake
10.0 zapewnia prawidłowe działanie, więc nie trzeba go
poprawiać. W Mandrake 10.1 nie ma problemów znanych z Mdk 10.0 i można go instalować w WYŻSZYM (DLA SERWERÓW) POZIOMIE BEZPIECZEŃSTWA.
* * *
Jeżeli logujesz się z linuksowego klienta na
którym przeinstalowywałeś system, a zostwiłeś w nim zawartość
katalogu /home (pliki userów są stare), to spotkasz się z odmową ze
strony serwera. Czemu? To proste - w katalogu
/home/antek/.ssh jest plik known_hosts (znane hosty),
który ma nieaktualną zawartość. Wyczyść go i spróbuj zalogować się
na nowo.
* * *
Sprawdź, czy włącza się autostart serwera sshd (w
MANDRAKE CONTROL CENTER- USŁUGI lub poleceniem drakservices lub drakxservices).
Bardziej finezyjny sposób, to przeglądnięcie zawartości katalogu
/etc/rc3.d (lub rc5.d w zależności od tego jak startuje system - w
powłoce czy okienkach). Więcej o autostarcie tutaj.
Możesz restartować serwer sshd w powłoce tekstowej wydając
jako root polecenie:
/etc/rc.d/init.d/sshd start
/etc/rc.d/init.d/sshd stop
/etc/rc.d/init.d/sshd restart
W razie kłopotów możesz wydać parę poleceń:
chkconfig -- del sshd
chkconfig -- add sshd
* * *
Po każdej zmianie konfiguracji serwera sshd (w pliku /etc/ssh/sshd_config) należy restatrtować sshd. To niby oczywiste, ale miałem z internetu zgłoszenia, że... serwer sshd nie przyjmuje zmian konfiguracji (początkujący admin potrafi czasami jeszcze mnie zaskoczyć problemem technicznym takiego typu :)
* * *
Na Mandrake 9.x przy ustawieniu msec 4 masz
restrykcyjnie ustalone prawa do pliku /usr/bin/ssh (i bardzo
dobrze). Niestety może to zablokować klienta ssh na Twoim
serwerze. Aby zwykły użytkownik miał prawo odpalać ssh,
powinien być przydzielony do grupy ntools (czasami przydaje
się też dodanie do grupy xgrp). Pamiętaj, że głupotą będzie
dodawanie WSZYSTKICH użytkowników kont do grupy ntools - nie
ma po co ryzykować. Obniża to przecież w jakimś stopniu
bezpieczeństwo serwera.
Ten punkt jest bardzo ważny - miałem wiele listów od
zdesperowanych internautów, którzy nie mogli odpalić pod zwykłym
użytkownikiem klienta ssh (na tym samym komputerze, co
zainstalowany był serwer sshd). Wszystko było dobrze, ale... pod
kontem roota. Niestety, nie zwrócili uwagi, że po wybraniu
WYŻSZEGO(4) POZIOMU BEZPIECZEŃSTWA) plik /usr/bin/ssh ma
restrykcyjne prawa 750 root.ntools (czyli
-rwxr-x---). Jeżeli użytkownik nie należy do grupy
ntools, to jak sam widzisz - nie ma prawa do uruchomienia
ssh.
Aby sprawdzić prawa do pliku /usr/bin/ssh wykonaj jako root:
cd /usr/bin
ls -la|more (i spacjami przepuszczaj po kolei zawartość
ekranu, aż znajdziesz plik ssh)
Na wszelki wypadek przypominam składnię poleceń
umożliwiających (po instalacji) dopisanie użytkownika (np.
antek) do istniejącej już grupy (np. ntools). Należy
otworzyć sesję na koncie roota i wpisać: gpasswd -a antek
ntools . Restartuj system. Usunięcie wykonasz zleceniem:
gpasswd -d antek ntools
Ponieważ standardowe polecenia z wiersza poleceń
dotyczace użytkowników i grup (useradd - dodawanie kont,
usermod - modyfikacja kont, userdel - kasowanie kont,
groupadd - tworzenie nowych grup, groupmod -
moyfikacja grup, groupdel - kasowanie grup) są trochę
rozbudowane i łatwo w nich zrobić błąd, polecam inne:
userconf (edycja użytkowników, grup, ich haseł),
adduserdrake (dodawanie użytkowników) lub usercfg.
Więcej o dodawaniu i modyfikacji kont userów i grup znajdziesz tutaj.
* * *
Przypominam, że firewall ma dopuszczać połączenie dla usługi ssh
na porcie 22. Do konfiguracji firewalla możesz użyć MANDRAKE
CONTROL CENTER- BEZPIECZEŃSTWO- FIREWALL. To samo uzyskasz
zleceniem mcc lub drakfirewall
(/usr/sbin/drakfirewall). Jeżeli sshd będzie współpracować
WYŁĄCZNIE z klientem z domowej sieci, to zostaw otwarty port 22 na
firewallu, ale popraw plik /etc/ssh/sshd_config zmieniając w
nim wpis domyślny ListenAddress 0.0.0.0 na ListenAddress
192.168.0.1 (IP 192.168.0.1 to przykładowy nr IP wew. serwera).
Bardziej precyzyjne ustawienie firewalla pod Mandrake umieściłem na
stronie opisującej shorewalla.
Osobnym problemem są programy zabezpieczające serwer (firewall,
shorewall czy portsentry). Wiecej o portsentry opowiedziałem na
stronie BHP.
Tutaj jedynie powiem, że portsentry bezlitośnie umieści
prawie każdego, kto wykonał nieuprawniony krok wobec serwera.
Niestety, nawet taki komputer, który wpisał nr IP w przeglądarce
internetowej licząc na obecność witryny www (w przypadku braku
Apacha będzie taki krok oceniony jako próba włamu poprzez port 80
i... nr IP gościa zostanie dopisane do pliku /etc/hosts.deny). Może
się zdażyć, że portsentry zablokuje... siebie samego (swój
serwer), gdy nieuważnie do przeglądarki internetowej wpiszesz swój
IP lub domenę ;)
* * *
Ze względu na
bezpieczeństwo polecam przeczytać notatkę z
sąsiedniej strony o blokowaniu lub umożliwianiu odległym
użytkownikom logowania się na serwerze sshd poprzez dodanie
opcji AllowUsers , DenyGroups oraz AllowGroups
w pliku /etc/ssh/ sshd_config . Generalnie polecam zablokować
wszystkich, poza tym komputerem, z którego chcesz się zalogowywać i
userem na serwerze sshd.
DenyUsers czesiek@jakasdomena.pl antek
t*
Jak widzisz można w jednym wierszu umieścić kilka reguł
(oddzielonych spacjami). W takim zapisie serwer:
- nie dopuści do zalogowania na konto użytkownika
czesiek przez osobę łączącą się z jakasdomena.pl
- nie dopuści do zalogowania na konto użytkownika
antek przez osobę łączącą się z dowolnego komputera
- nie dopuści do zalogowania na konto użytkownika,
którego login zaczyna się na literę "t" (łączącącego się z dowolnego komputera)
Gdy będziesz używał opcji DenyUsers i AllowUsers
jednocześnie, to DenyUsers zawsze będzie miało
pierwszeństwo.
DenyUsers * czyli serwer nie wpuści
żadnego użytkownika, nawet jeżeli opcją AllowUsers dasz
jednoczesne przyzwolenie.
Jeśli w sshd_config nie zostanie użyta żadna z opcji
Allow/Deny, to serwer sshd dopuszcza logowanie
poprzez odpowiedni interfejs (patrz poniżej) na konta wszystkich użytkowników (o
ile nie wykonasz innych zabezpieczeń) z każdego komputera.
* * *
Opcja ListenAddress
0.0.0.0 jest miejscem wskazania IP serwera, na którym trwa
nasłuch sshd. Wpis 0.0.0.0 symbolizuje wszystkie adresy IP.
Jeżeli zezwolisz na logowanie wyłącznie z domowej sieci to wpisz IP
wewnętrzne serwera np. ListenAddress
192.168.1.1 . Oczywiście nie zapomnij wówczas na serwerze właściwie
skonfigurować firewalla tak, by zezwalał na połączenie z domowej
sieci, ale odrzucał wezwania z Internetu.
* * *
Jeżeli utworzysz plik /etc/ nologin, to
tylko root będzie mógł się zalogować na serwer przez SSH (o ile
jego konfiguracja na to pozwoli, choć ze względów bezpieczeństwa
nigdy nie powinna). Próby zalogowania się innych userów zostaną
odrzucone. Zobaczą oni jedynie zawartość wspomnianego pliku (np.
"serwer sshd poszedl spac ;P"). W momencie usunięcia
/etc/ nologin userzy będą mogli normalnie logować się przez
SSH.
Jak to wykorzystać w zabezpieczeniu serwera sshd? Można poprzez
cron o ściśle określonej porze usuwać (a potem wstawiać) plik
/etc/nologin , aby umożliwić/zablokować logowanie na konto zwykłego
usera. Oczywiście ze względów bezpieczeństwa dodatkowo należy zablokować logowanie na konto roota poprzez plik /etc/securetty
Przypominam, że konfiguracja serwera sshd nie powinna zezwalać
na logowanie się na konto roota bezpośrednio. Powinno być dozwolone
logowanie na konto zwykłego usera, a dopiero potem zleceniem su na konto roota.
* * *
Jeżeli chcesz łaczyć się z klienta windowsowego na serwer
linuksowy, to wybierz program putty ze strony domowej
programu www.chiark.greenend.org.uk/~sgtatham/putty/.
Zaznacz w nim opcje zgodnie z załączonym obrazkiem.
Wymusi to użycie klucza SSH2.
Następnie wpisz adres serwera i zaloguj się (tutaj na konto
antek serwera 192.168.1.1).
Putty przechowuje informacje o połączeniach, zapisanych sesjach
oraz kluczach w rejestrze Windows (uruchom windowsowy regedit):
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
*
Inne klienty ssh pod Windows to: SSHWin np. SSHWin-2.4.0-pl2 oraz ttssh. W programie SSHWin mamy
klienta ssh czyli SSH Secure Shell Client oraz klienta sftp
SSH Secure File Transfer Client. Przerzucanie plików (po
nawiązaniu połączenia) odbywa się poprzez zwykłe przeciąganie
myszką plików z okna Exploratora do okna programu. Zaglądnij także na stronę: www.bitvise.com/tunnelier.html
* * *
Na stronie www.mandrakesecure.net/en/docs/openssh.php
MandrakeSoft umieściła opracowanie dotyczące OpenSSH.
Tak wygląda fragment przypominający propozycję (domyślną wersję w
Mandrake) pliku /etc/ssh/sshd_config
Port 22
Protocol 2,1
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PasswordAuthentication yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PAMAuthenticationViaKbdInt no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
KeepAlive yes
UsePrivilegeSeparation yes
Compression yes
Subsystem sftp /usr/lib/ssh/sftp-server
Przetłumaczyłem z angielskiego na polski plik konfiguracyjny
/etc/ssh/sshd_config . Umieściłem w nim moje ustawienia.
Możesz w swoim oryginalnym pliku zostawić wyłącznie wiersze
oznaczone niebieskim kolorem, a pominąć
komentarze.
# $OpenBSD: sshd_config,v 1.56 2002/06/20 23:37:12 markus Exp
$
##########################################
# Jest to plik konfiguracyjny serwera sshd.
# Przegladnij sshd_config(5) dla uzyskania dodatkowych
informacji.
# Ten sshd zostal skompilowany ze sciezka:
# PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
#
# UWAGA: po zainstalowaniu sshd popraw plik /etc/hosts.allow
# (sshd: IPklienta oraz w nowym wierszu ssh: IPklienta)
# Pamietaj o potrzebie dopuszczenia sshd w firewallu
##########################################
# Nr portu na ktorym nasluchuje Twoj serwer (demon sshd)
Port 22
# Dostepne protokoly: ssh2 i ssh1
Protocol 2,1
# Na jakim IP Twojego serwera będzie nasluchiwac sshd
# (wazne w przypadku kilku kart sieciowych na serwerze)
# TU nasluchuje na wszystkich dostępnych adresach serwera
# czyli wszystkich kartach sieciowych i ew. modemie.
ListenAddress 0.0.0.0
#ListenAddress ::
#
# Klucz HostKey dla protokolu version 1
HostKey /etc/ssh/ssh_host_key
# Klucz HostKeys dla protokolu version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#
# Dlugosc zycia (w sekundach) klucza "version 1 server key"
KeyRegenerationInterval 3600
# Dlugosc klucza (w bitach) klucza "version 1 serwer key"
ServerKeyBits 768
# Logging (NIE WIEM CO OZNACZAJA PONIZSZE WIERSZE)
# obsoletes (przestarzaly) QuietMode (cichy tryb)
# and FascistLogging (faszystowski logging)
# SyslogFacility czyli SyslogUdogodnienie
#SyslogFacility AUTH
#LogLevel INFO
#
################################
# Parametry autentykacji. (Authentication)
################################
#
# Czas oczekiwania (w sekundach)
LoginGraceTime 600
# Czy mozna logowac sie zdalnie na konto roota.
# Wpisz "no" i jak root loguj sie poprzez konto
# zwyklego uzytkownika i komendy su lub su -l
PermitRootLogin no
StrictModes yes
################################
# Czy zgadzasz sie na autentykacje RSA ? (TAK!!!)
# Klucz RSA mozna uzyc zamiast lub rownoczesnie z haslem.
# Zaraz wybierzesz wlasciwe opcje.
# Teraz chwila wyjasnien: Nalezy odroznic ssh (narzedzie
klienckie)
# i demona sshd (czyli serwer).
# Tutaj konfigurujemy co prawda sshd, ale pamietac nalezy, ze
odlegly
# klient tez musi prawidlowo sie przygotowac.
# Do poprawnej pracy OPENSSH musimy dokonac konfiguracji
demona
# sshd oraz klienta ssh.
# Jezeli zdecydowalismy sie na uzywanie ssh z kluczami RSA
(zamiast
# lub rownoczenie z haslami), kazdy user (czyli Ty oraz twoi
kumple)
# przed uzyciem powinien wygenerowac swoja wlasna pare kluczy
komenda:
# $ ssh-keygen (w Mandrake może byc zrobiony automatycznie).
# W takiej chwili będziesz musial podac tzw. paszport (zapisz
sobie na kartce)
# W podfolderze /home/antek/.ssh zostana utworzone dwa pliki:
# Identity - ktory zawiera PRYWATNY KLUCZ i nie powinien
byc udostepniany
# nikomu (pamiętaj o restrykcyjnych prawach do tego pliku)
# identity.pub - czyli klucz publiczny.
# Jezeli zamierzamy jako klient pracowac przez ssh na odleglym
serwerze,
# to zawartosc tego klucza powinnismy skopiowac do katalogu
odleglego
# uzytkownika, nza ktorego konto logujemy sie - do pliku np.
# /home/antek/.ssh/ w pliku authorized_keys.
# Oczywiscie wowczas proby logowania na odlegly serwer musza
# byc podejmowane na konto antek i uwaga: wskazane jest na
poczatku
#
aby logowac sie z konta antek na konto tez antek.
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile
.ssh/authorized_keys
#
# Autentykacja rhosts (czyli dopuszczanie do logowania wg listy
tzw.
# "zaufanych" maszyn zamiast zmuszania ich do podawania hasel)
# nie powinna byc uzywana ze wzgledow bezpieczenstwa.
# Wystarczy bowiem, ze ktos sie wlamie i dobierze do plikow
# ~/.rhosts .shorts...
# JEZELI WYBRALES "no" (a to polecam) TO MOŻESZ ZAHASZOWAC
KILKA
# KOLEJNYCH OPCJI, gdyz nie maja one w takim razie znaczenia.
# Wszak zrezygnowales z tego rodzaju autentykacji.
RhostsAuthentication no
#
# Ignorowanie plikow ~/.rhosts i ~/.shosts, ktore
maja wykaz "zaufanych"
# stacji, z ktorych odlegly uzytkownik może sie zalogowac bez
podania hasla.
# Oczywiscie wpisz "yes" i nie pozwol (ze wzgledu bezpieczenstwa)
na
# czytanie plikow ~/.rhosts i ~/.shosts w
zastepstwie autoryzowania haslem.
IgnoreRhosts yes
#
# Jezeli w autentykacji rhosts wybrales opcje
"RhostsAuthentication yes"
# to możesz zmusic klientow zapisanych w w/w plikach ~/.rhosts i
~/.shosts by
# dodatkowo legitymowaly sie kluczem "host keys" znajdujacym
# sie w /etc/ssh/ssh_known_hosts (pamietasz jak opisalem
koniecznosc
# skonfigurowania ssh u odleglego klienta poprzez
wygenerowanie
# kluczy komenda: [ $ ssh-keygenktory ]) ?
#RhostsRSAAuthentication no
# i podobnie j.w. ale wobec protokolu version 2
#HostbasedAuthentication no
#
# Zmien ponizsze na NIE (!!!) jezeli nie masz zaufania do
klienckich
# kluczy zapisanych w ~/.ssh/known_hosts (w autentykacji
# RhostsRSAAuthentication i HostbasedAuthentication).
# Czy serwer ma ignorowac nadzor nad komputerami w/w
uzytkownikow?
# Inaczej mowiac - czy serwer ma zadowolic sie tescia kluczy
od
# klientow zapisanych w ~/.ssh/known_hosts ?
IgnoreUserKnownHosts no
#
# Aby wylaczyc tunelowanie (co jest fatalnym pomyslem) - wyczysc
wpisy
# hasel i zmien na "no"
PasswordAuthentication yes
# Zezwolenie na puste hasla
PermitEmptyPasswords no
#
# NIE WIEM O CO TUTAJ CHODZI.
# Uncomment to disable s/key passwords czyli
# Wyhaszuj po to, aby wylaczyc s/klucz hasel
#ChallengeResponseAuthentication no
#
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#AFSTokenPassing no
# Kerberos TGT Passing only works with the AFS kaserver
#KerberosTgtPassing no
#
# Set this to 'yes' to enable PAM keyboard-interactive
authentication
# Warning: enabling this may bypass the setting of
'PasswordAuthentication'
# Wiecej o PAM jest tutaj
#PAMAuthenticationViaKbdInt yes
#
# Szyfrowanie przez ssh polaczenia graficznego za pomoca
X-Window
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
#
# Pojawi sie komunikat powitalny o tresci pobranej z pliku
/etc/motd
PrintMotd yes
#
# Pojawi sie komunikat powitalny o tresci z pliku tekstowego
/etc/issue
#Banner /etc/issue
# Polecam jednak utworzyc inny plik np. /etc/ssh/banner z jakims tekstem
# Oczywiscie nalezy wowczas wpisac ponizej odpowiednia sciezke
dostepu
Banner /etc/ssh/baner
#
# Pojawi sie informacja z data ostatniego logowania
PrintLastLog yes
#
KeepAlive yes
#
#UseLogin no
#
#Wiele kodów w OpenSSH które działały wyłącznie pod rootem,
obecnie funkcjonują pod nieuprzywilejowanym użytkownikiem. Ponieważ
znacząco podnosi to bezpieczeństwo OpenSSH, powinno się
udostępnić cechę UsePrivilegeSeparation . Niestety, opcja ta
nie działa zbyt dobrze (w wersji OpenSSH 3.4p1) z innymi systemami
unixowymi, można jednak się spodziewać, że następna wersja
OpenSSH będzie pozbawiona błędów
UsePrivilegeSeparation yes
#
# Zezwolenie na kompresje danych podczas połączenia
Compression yes
#
MaxStartups 10
#
# Sprawdzanie zgodnosci nazwy odległego klienta
# (pełnej domeny) z IP. Domyślnie niedostępne.
#VerifyReverseMapping no
#ReverseMappingCheck yes
#
#CheckMail yes
#
#UseLogin no
#
# Zezwolenie na szyfrowane polaczenie sftp.
Subsystem sftp
/usr/lib/ssh/sftp-server
Na koniec słowo o szyfrowanym
ftp.
Na zwykłym ftp hasło i dane przerzucane są w
postaci jawnej (nie są szyfrowane). Tymczasem SSH oferuje swój
serwer FTP pod nazwą sftp, pracujący
domyślnie na porcie 115/tcp, 115/udp (ew. 22), więc musisz
udostępnić odpowiednie porty na firewallu (np. 115 TCP/UDP)
. SFTP jest niezbyt rozbudowany, ale szyfruje i zastępuje w
podstawowych zadaniach zwykły ftp. Aby włączyć sftp należy umieścić
(lub odhaszować #) wpis w pliku sshd_config:
Subsystem sftp
/usr/local/libexec/sftp-server
Wiersz ten znajduje się prawdopodobnie na samym dole domyślnie
wypełnionego pliku /etc/ssh/ sshd_config
Po restarcie sshd zleceniem /etc/rc.d/init.d/sshd restart mamy serwer sftp
gotowy do pracy.
*
Klienty sFTP dla
Linuksa
Na linuksowym komputerze-kliencie zainstaluj: scp oraz sftp.
scp
Polecenie scp jest bardziej podobne do polecenia
systemowego cp (kopiuj) niż do ftp. Jest to program
prymitywny, ale praktyczny do użycia w skryptach. Oto kilka
przykładów zleceń:
scp
antek@jakasdomena.pl:backup.tar.gz
czyli kopiowanie pliku backup.tar.gz z katalogu domowego
użytkownika antek na sererze jakasdomena.pl do
bieżącego katalogu.
scp -r
antek@jakasdomena.pl:public_html
czyli kopiowanie (-r: z podkatalogami) zawartości public_html z katalogu użytkownika antek na serwerze jakasdomena.pl do bieżącego katalogu.
scp -l 100 -C httpd.conf
antek@jakasdomena.pl:backup/
czyli kopiowanie pliku httpd.conf z bieżącego katalogu do
podkatalogu backup w katalogu domowym użytkownika
antek na jakasdomena.pl . Dodatkowo "w locie"
wykonywana jest kompresja tego pliku (-C), a szybkość jego
przerzucania po sieci ograniczona jest (-l) do 100 kilobitów na
sekundę.
sftp
Polecenie sftp jest odpowiednikiem polecenia ftp. Jest to
program interaktywny, pracujący także w trybie teksowym. Są w nim
dostępne takie polecenia jak mkdir, get, put, chmod itp. sFTP
obsługiwane jest tylko przez drugą wersję SSH. Oto kilka przykładów
użycia narzędzia:
sftp -C heniek@serwer.pl
czyli połączenie się przez sFTP z serwerem serwer.pl jako
użytkownik heniek. Kompresja "w locie" jest włączona (-C). Po
podaniu hasła pracujemy jak ze zwykłym poleceniem ftp.
sftp -C heniek@serwer.pl:/etc/hosts
hosts.bak
czyli pobranie z serwer.pl jako użytkownik heniek pliku /etc/hosts
i zapisanie go w bieżącym katalogu pod nazwą hosts.bak. Ten
przykład pokazuje, że sftp może pobierać pliki w podobny sposób do
scp.
*
Klient sFTP dla
Windows
Wersja windowsowa programów-klientów jest
dostępna pod nazwą WinSCP3 na stronie http://winscp.vse.cz oraz http://winscp.net/.
Zwróć uwagę, że program pracuje na porcie 22.
Przykład zrzutu pokazuje chwilę logowania na serwer sshd o nr IP
192.168.1.1 na konto usera antek. Zaznaczono
narzędzie SFTP. Klikamy w klawisz LOGIN.
W razie problemów musisz wykonać czynności sprawdzające podobnie
jak przy normalnym połączeniu ssh, czyli np. czy na serwerze sshd
są otwarte odpowiednie porty. Zwróć szczególną uwagę na zgodność
kluczy (serwerowych i klienckich). Polecane są SSH2. Zwróć uwagę na dwa ponizsze obrazki. Przy okazji zobacz, że zaznaczyłem
zezwolenie na kompresowanie przerzucanych plików. Oczywiście opcje
trzeba uaktywnić zarówno na kliencie ssh, SFTP, jak i
na serwerze sshd (w pliku /etc/ssh/sshd_config) . Na
serwerze sshd są to wpisy: Compression yes , Protocol 2,1 oraz Subsystem sftp /usr/lib/ssh/sftp-server
A to zobaczymy po zalogowaniu: na lewym panelu katalogi windowsowego
komputera, na prawym katalogi linuksowego usera antek (na
serwerze linuksowym z włączonym OpenSSHd).
Przerzucanie plików jest niezwykle proste: myszką należy
przeciągnąć odpowiednie pliki z panelu na panel.
*
Inny klient sftp dla Windows to program SSHWin. Po
zainstalowaniu kliknij w ikonkę SSH Secure File Transfer
Client, następnie QUICK CONNECT, podaj dane do logowania na
konto, a następnie myszką "przeciągnij" plik z Exploratora do okna
programu.
*
Mam w tym miejscu jedną uwagę: jeżeli na linuksowym serwerze
sshd konto antek ma (z przyczyn bezpieczeństwa) brak
dostępu do shella (shell false), to oczywiście połączenie
SFTP nie nastąpi. Więcej o blokowaniu dostępu do shella dla
zwykłych userów na stronie o
BHP.
Czy połączenie SFTP jest bezpieczne? Uważam, że nie
powinno się zezwalać na takie połączenia na serwerze-routerze
dostępowym do Internetu. Czemu? Gdyż SFTP wymaga dostępu do
shella dla usera logującego się na serwer sshd (logowanie na
konto ftp zwykłego usera poprzez serwer ProFTPd nie wymaga
dostępu do shella). Ten fakt zmniejsza zalety SFTP.
Natomiast jeżeli serwer sshd zainstalujemy na zwykłym
komputerze dostępowym do Internetu (nie na serwerze-routerze), to
można zaryzykować zezwolenie na dostęp do shella dla wybranych
userów. Przypominam, że można stworzyć przekierowanie na routerze i
serwer sshd zainstalować na kliencie w domowej sieci w
stefie DMZ, ale to inna opowieść...
*
LINKI
Sympatyczny opis ustawienia profilu połączenia ssh (autorstwa Rafała Świątkowskiego)
jest na stronie: http://www.pg.gda.pl/OI/var/content.php?n=00024 (mam kopię w swoim archiwum)
http://www.rzg.mpg.de/networking/tunnelling.html (wersja angielska) mam kopię w swoim archiwum
SSH w środowisku Windows (mam kopię w swoim archiwum)
opcje klienta ssh (tłumaczenie z angielskiego)
*
Jeżeli musisz pod tunelem ssh uruchomić długo trwające polecenie i wylogować się, ale tak by nie przerwać pracy tego zlecenia, to wystarczy wpisać:
nohup nazwapolecenia
Zlecenie nohup wykonuje określone polecenie i ignoruje sygnały zakończenia procesu (zwłaszcza te wysłane podczas wylogowania się). Dzięki temu polecenie będzie działać po wylogowaniu użytkownika. Na koniec prac szukaj w katalogu domowym pliku nohup.out
Przypominam, że niektóre programy mają opcje zabezpieczające przed wyłączeniem po wylogowaniu. Przykładowo klient ftp: wget uruchomiony z flagą -b będzie działał do momentu zakończenia działania, nawet po wylogowaniu usera z powłoki (opcja & na końcu od razu umieści proces w tle). Wpisz zlecenie:
wget -b ftp://adresserwera/katalog/nazwapliku &
wciśnij klawisz ENTER. Pokaże się komunikat, wciśnij powtórnie ENTER i dalej pracuj w powłoce lub wyloguj się.
*
Uwaga: z powodu namnożenia się różnych złodziejskich witryn www, które kopiują moje strony i umieszczają je u siebie wraz z komercyjnymi reklamami (na których zarabiają) informuję, że wszelkie prawa są zastrzeżone.
Uwaga.
Aby uniknąć zasysania całej witryny gorzow-wlkp.pl/linux za pomocą programów typu TeleportPro, WebCopier itd. informuję, że udostępniłem spakowaną wersję (w formacie RAR).
|
