SSH: Diferență între versiuni

De la Wiki.lug.ro
Salt la: navigare, căutare
m (Reveniri la ultima modificare de către 115.76.204.253 (discuţie); revenire la ultima versiune de către Bmbogdan)
m (A protejat "SSH": spam target [edit=autoconfirmed:move=autoconfirmed])
(Nicio diferență)

Versiunea de la data 2 aprilie 2009 16:36

Acest articol a fost publicat original de Adrian Joian sub numele "Sfaturi utile legate de ssh" pe fedorauser.ro sub licență Creative Commons Generic. Articolul a fost preluat cu modificări, urmând a se adăuga la el în continuare după cum este nevoie.

Introducere

SSH sau secure shell este un program care permite accesul securizat la un sistem remote. Tot traficul de date este criptat, inclusiv schimbul de parole, eliminând astfel posibilitatea atacării canalului de comunicație. Nu toată lumea cunoaște puterea și capabilitățile acestui program utilitar, cum ar fi loginul fără parolă, executarea automată de comenzi pe un sistem remote, sau chiar mountarea locală a unui director remote. Acest articol va descrie aceste operați și nu numai.

SSH/SSHD

SSH lucrează în modul client-server ceea ce înseamnă că pe mașina remote la care vrem să ne conectăm trebuie să rulăm un server. Serverul SSH, cunoscut și sub numele de SSHD, vine instalat implicit în majoritatea distribuțiilor Linux și în unele cazuri este pornit tot implicit la bootare. Mai multe informații despre server găsiți cu ajutorul comenzii "man sshd". Trebuie amintit că pentru comunicație este folosit portul 22 TCP, așadar dacă aveți un firewall funcțional pe server, accesul la acest port trebuie gestionat.

Pe calculatorul client, comanda se numește simplu "ssh" iar parametrul principal de care are nevoie este numele utilizatorului și serverului la care trebuie să se conecteze.

# ssh user1@remote_server

Aveți nevoie de o parolă pentru a accesa serverul, iar după introducerea acesteia veți fi prezentat cu o linie de comandă de genul "user1@remote_server:~$". Dacă acest lucru s-a întâmplat, înseamnă că ați reușit să vă logați corect pe mașina remote și puteți rula comenzi pe această mașină. Canalul de comunicație între server și client este criptat, aceasta fiind principala atracție pentru SSH.

Pachetul software SSH folosit sub Linux se numește OpenSSH, este dezvoltat la openssh.com de aceeași echipă care dezvoltă și proiectul OpenBSD. Protocolul de comunicație implementat de OpenSSH se numește SSH2 și este standardizat de IETF. Protocolul este descris într-o serie de RFC-uri publicate de IETF.

O serie de programe utilitare prezente în pachetul OpenSSH vor fi descrise în continuare.

SFTP - o versiune securizată de FTP

Permite ca și FTP copierea de fișiere de pe o mașină pe alta, diferența fiind că în cazul SFTP tunelul prin care se desfășoară comunicația este criptat. În FTP toate comunicațiile, inclusiv schimbul de parolă, între server și client sunt trimise în clar, ceea ce face slujba unui cracker foarte ușoară în a compromite sistemul în cauză. SFTP folosește pe post de server SSHD descris mai sus.

SFTP se rulează în felul următor:

# sftp user1@remote_server

și implementează majoritatea comenzilor pe care FTP le implementează. Pentru cineva obișnuit să transfere fișiere folosind ftp din linia de comandă, sftp nu va prezenta nicio problemă. Este pur și simplu același lucru însă într-un tunel criptat.


SCP - copierea securizată de fișiere

Alte program de transferat fișiere integrat în pachetul OpenSSH este SCP. Se rulează din linia de comandă și permite copierea oricărui fișier sau director de la sau către o mașină remote. Ca și în cazul lui SFTP, scopul utilitarului SCP este să substituie programele gen ftp. Pe post de server se folosește tot SSHD.

Rularea programului arată în felul următor:

# scp fișier.txt user1@remote_server:~/

Această comandă permite copierea lui fișier.txt pe un server remote și plasarea sa în directorul de bază al utilizatorului user1. În loc de ~/ se poate folosi o altă cale de exemplu /tmp sau /home/public sau orice altă cale unde utilizatorul are drept de scriere.

Comanda arată similar pentru transferul invers (de pe serverul remote pe mașina locală):

# scp user1@remote_server:~/file.txt .

Astfel, fișierul file.txt este copiat de pe serverul remote și este plasat în directorul curent.

Câteva opțiuni folositoare:

-r -pentru a copia directoare în mod recursiv incluzând și subdirectoare;
-P port - pentru a folosi un port care nu este standard 

Interfețe grafice pentru SCP

Dacă nu vă place să executați comenzi în consolă și preferați interfețe grafice puteți să folosiți Midnight Commander (yum install -y mc în Fedora). Acesta oferă un client grafic pentru SCP cu ajutorul opțiunii shell link.

Alte managere de fișiere precum Nautilus și Konqueror sunt capabile de conexiuni SCP. Introducând ssh://user1@remote_server:~/ în bara de adresă, rezultă o conexiunea către o mașină remote, astfel fișierele pot fi copiate ca și cum ar fi disponibile local.

În mediu MS Windows, o aplicație demnă de menționat este WinSCP. Are o interfață asemănătoare cu Total Commander și are un sistem de pluginuri astfel încât este posibil să realizați printre altele și conexiuni TCP.

SSH fără parole - generarea de chei

Introducerea parolei pentru fiecare conectare prin SSH poate deveni la un moment dat enervantă. Pe de altă parte o conexiune nesecurizată reprezintă un risc. Soluția problemei este folosirea sistemului de cheie publică, cheie privată. Perechea de chei poate fi generată cu comanda ssh-keygen. Mai jos este un exemplu de generare de chei de tipul RSA.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Când sunteți întrebat de parolă, puteți apăsa tasta ENTER - în acest fel se va crea o cheie fără parolă. Rețineți că a lăsa o cheie fără parolă poate fi o gaură majoră de securitate. Dacă aveți dificultăți cu reținerea parolelor puteți să folosiți în Kde utilitarul Ksshagent și în gnome gnome-keyring-ssh-askpass.

În momentul când ssh-keygen își termină treaba, veți avea două chei generate. Cheia privată se află în /home/user1/.ssh/id_rsa și aceasta nu trebuie făcută publică niciodată. Cea de a două cheie va fi în /home/user1/.ssh/id_rsa.pub iar aceasta o putem arăta oricui.

Presupunând că vrem să ne conectăm la mașina numită test de pe cea pe care am generat cheile, trebuie să executăm următoarea comandă:

# ssh-copy-id -i ~/.ssh/id_rsa.pub username@mystery

Vom fi rugați să introducem parola pentru login, iar apoi cheia va fi copiată automat, creând dacă este necesar directoarele și rezolvând problema cu permisiunile pe fișiere. Conținutul fișierului de chei publice va fi adăugat în fișierul ~/.ssh/authorized_keys2 pentru chei RSA , și ~/.ssh/authorised_keys pentru chei DSA.

Executarea de comenzi pe o mașină remote

Una din cele mai spectaculoase facilități SSH este automatizarea execuției de comenzi pe mașini remote.

Deci, dacă ne putem loga automat pe o mașină remote, de ce să nu executăm acolo niște comenzi tot automat? De exemplu am putea implementa un fel de "remote alert". Să ne imaginam că pe un sistem remote rulăm un webserver și dorim să fim preveniți când acel sistem rămâne fără resurse. Evident că putem să ne trimitem un mail, putem însă adițional să rulăm o comandă care să cânte o melodie pe sistemul nostru. Codul ar arăta cam așa:

# ssh user1@local_server 'play /usr/share/sounds/gaim/arrive.wav'

X11 - rularea de aplicații grafice de la distanță

Am văzut cum se rulează aplicații remote din linia de comandă, să vedem cum am putea rula aplicații cu o interfață grafică.

Una dintre facilitățile mai puțin folosite ale SSH-ului este forwardarea protocolului X. Acest lucru ne poate permite să rulăm aproape orice aplicație X de la distanță, fără a ne compromite securitatea muncii pe care o depunem. Este de ajuns să ne conectam pe mașina respectiva cu opțiunea -X:

# ssh -X user1@remote_server

Astfel afișarea tuturor aplicațiilor ce necesită X11 executate de acum încolo vor fi forwardate pe serverul X11 local.

X11 Forwarding se poate configura ca permanent prin editarea fișierului de configurare /etc/ssh/ssh_config file opțiunea dorită fiind "ForwardX11 yes".

Tunele folosind SSH

SSH are abilitatea de a forwarda porturi TCP. Astfel, poate face ca un port remote să apară pe o interfață locală sau vice versa. Odată ce acest forwarding a fost făcut, un program se poate conecta la portul local și poate folosi serviciile remote ca și cum ar fi locale.

În exemplul următor descriem criptarea comunicației dintre un server IRC și un client IRC cu ajutorul unui tunel simplu setat prin ssh. Mașina locală este "localhost" și are o adresă ip "127.0.0.1", de pe această mașină pornim tunelul și rulăm clientul IRC. Mașina remote este "server.example.com" pe care rulăm serverul SSH și serverul IRC unde trebuie să ajungă datele clientului nostru IRC (folosesc pentru simplicitate exemplul din man ssh).

Începem prin a construi tunelul:

# ssh -f -L 1234:localhost:6667 server.example.com sleep 10

apoi pornim clientul IRC prin tunelul construit anterior:

# irc -c '#users' -p 1234 pinky 127.0.0.1

Utilizatorul pinky intră pe canalul #users folosind tunelul ssh care începe pe mașina locală a utilizatorului la portul TCP 1234 și se termină pe server.example.com la portul 6667 care este portul standard pentru servicii IRC.


Exemplu tunelare SAMBA

Ne folosim de facilitatea de tunelare pentru a face un mount SAMBA pe un canal encriptat. Pentru aceasta avem nevoie ca serverul SAMBA și serverul de ssh să ruleze pe aceeași mașină remote. Tunelarea SAMBA se face în doi pași: setarea tunelului și apoi mountarea shareului SAMBA prin tunel.

# ssh -L 9999:localhost:139 user@server

Comanda de mai sus va forwarda portul 139 de pe mașina remote către "localhost" pe portul 9999. SSH vă permite forwardarea de porturi privilegiate TCP numai în cazul rulări ca root, așadar pentru utilizatorii non-root singura soluție este să ruleze pe porturi peste 1024.

Tunelul este up, dar cum mountăm?

O problemă este că rezoluția de nume se face în SAMBA prin UDP și ssh nu poate să forwardeze trafic UDP. Trucul este să îi indicăm comenzii "smbmount" să se conecteze la interfața de rețea specifică și la portul TCP în mod direct, fără a folosi rezoluția de nume (examinați "man smbmount" pentru mai multe informații).

Pentru a mounta prin SSH deschideți un nou shell și înlocuiți [mount-point] și [username] cu valorile relevante pentru dumneavoastră:

# smbmount //localhost/share [mount-point] -o username=[username],ip=localhost,port=9999

În mod normal //localhost ar trebui să fie numele NET-BIOS al serverului SAMBA, dar în acest caz opțiunea "ip=" trece peste el și rezoluția de nume nu este folosita, "smbmount" se conectează direct la interfața de rețea "localhost" pe portul 9999. Este de obicei o bună idee de-a unmounta share-ul SAMBA înainte închiderii conexiuni prin tunel (vezi comanda smbumount).

Tunele VNC prin SSH

Acesta nu este cu mult diferit de tunelul SAMBA, de obicei VNC folosește portul 5900 TCP care poate fi forwardat cu succes. Exemplul următor va permite unui utilizator să se conecteze la o sesiune existentă X11 sau RDP pe o mașină linux.

Porniți tunelul ssh de pe mașina locală către server astfel:

# ssh -L 5900:localhost:5900 [user]@[linux-box]

Porniți orice tip de VNCVIEWER și conectați-vă pe localhost portul 5900, apoi introduceți parola.

Trecerea peste mai multe hopuri cu ssh

Comanda folosită pentru a ne conecta de la workstation1 la workstation2 folosind hostul server ca un proxy:

# ssh -t user@server "ssh user@workstation2"

Vom fi nevoiți să introducem parola de două ori, prima dată pentru hostul server, apoi pentru hostul workstation2. Forwardarea X -ului va funcționa și ea cu condiția configurări corecte a ambelor noduri.

Surse:

[www.debian-administration.com]

[www.polishlinux.org]

[1]