Gestió Remota. SSH, RSYNC, X-WINDOWS
De Guifi.net - Wiki Català
25px
Aquesta wiki forma part dels materials d'un curs
| |
---|---|
Curs: | DissenyXarxesLinux, LinuxAdministracioAvancada |
Fitxers: | GestioRemota.pdf (GestioRemota.odp) |
Repositori SVN: | http://anonymous@svn.projectes.lafarga.cat/svn/iceupc/LinuxAdministracioAvan%c3%a7ada |
Usuari: | anonymous |
Paraula de pas: | sense paraula de pas |
Autors: | Sergi Tur Badenas |
SSH (Secure SHell) És el nom que rep un protocol per a la transferència d'arxius i gestió de maquines remotes amb connexió segura. En base a aquest protocol hi han diferents programes per a la realitzar aquest tipus de tasques. ssh - OpenSSH SSH client (programa d'accés remot) dsh - Distributed shell, o dancer’s shell.
Contingut
- 1 SSH (Secure shell)
- 2 OpenSSH
- 2.1 Instal·lació d'OpenSSH
- 2.2 Ports
- 2.3 Instal·lació en sistemes no Debian
- 2.4 Servidor SSH
- 2.5 Client SSH
- 2.6 SSH backdoor o Remote Forwarding
- 2.7 SSH Tunneling
- 2.7.1 Local versus Remote forwarding
- 2.7.2 Permetent a màquines remotes accedir a les redireccions locals
- 2.7.3 Consultar les connexions establertes a través del túnel
- 2.7.4 Establir el túnel en el fitxer de configuració
- 2.7.5 Utilitzar un proxy remot mitjançant un tunel SSH
- 2.7.6 Exemple 1
- 2.7.7 Exemple 2
- 2.7.8 Exemple 3
- 2.7.9 Exemple 4
- 2.8 SSH Jail
- 2.9 Reutilitzant connexions SSH
- 2.10 Fitxers de lo
- 2.11 Connexions remotes SSH amb Nautilus
- 3 DSH
- 4 X Arquitectura client-servidor
- 5 XDMCP
- 6 Rsync
- 7 Eines d'accés remot a escriptoris
- 8 Scripts de força bruta
- 9 Recursos
SSH (Secure shell)
Una mica d'història...
SSH 1.2.12 va ser desenvolupat per el programador finlandès, Tatu Ylönen, que va fer public el seu treball sota la llicencia lliure. Al poc temps va patentar el seu programa amb marca registrada "SSH™" i una empresa amb fins comercials. Les següents versions que van aparèixer van deixar de ser lliures i eren destinades per ús no comercial. Els desenvolupadors de OpenBSD van crear el projecte OpenSSH com a objectiu era crear un SSH totalment lliure.
SSH (http://en.wikipedia.org/wiki/SSH) és l'evolució de l'antic RSH (remote shell) afegint encriptació de dades a la comunicació entre màquines per millorar la seguretat. SSH (http://es.wikipedia.org/wiki/Secure_Shell) permet entre d'altres coses copiar fitxers, executar comandes en màquines remotes i connectar-se a màquines remotes.
Característiques
OpenSSH té l'aplicació client i el servidor i totes dues s'instal·len utilitzant un mateix paquet (ssh).
Existeixen múltiples implementacions d'SSH. La més famosa en els entorns linux és OpenSSH però també existeixen versions de pagament com les implementacions de la empresa SSH.com. En principi haurien de ser implementacions anàlogues però existeixen algunes petites diferències. En aquests documents ens centrarem en OpenSSH.
En principi un client d'OpenSSH es connecta perfectament a un servidor SSH comercial i viceversa. Tot i així, existeixen algunes diferències en el protocol ftp que impedeixen utilitzar algunes eines basades en ssh com p. ex. rsync.
Instal·lar el daemon SSH
$ apt-get install ssh
OpenSSH
Instal·lació d'OpenSSH
Per instal·lar openSSH hem d'executar:
$ sudo apt-get install ssh S'està llegint la llista de paquets... Fet S'està construint l'arbre de dependències Reading state information... Fet The following packages were automatically installed and are no longer required: libnxcompext0 libnxcomp0 nxagent expect nxlibs nxproxy Use 'apt-get autoremove' to remove them. S'instal·laran els següents paquets extres: openssh-client openssh-server Paquets suggerits: ssh-askpass rssh S'instal·laran els següents paquets NOUS: openssh-client openssh-server ssh 0 actualitzats, 3 nous a instal·lar, 0 a eliminar i 2 no actualitzats. Es necessita obtenir 831kB d'arxius. Després de desempaquetar s'usaran 2023kB d'espai en disc addicional. Voleu continuar [S/n]? s Des:1 http://archive.ubuntu.com edgy/main openssh-client 1:4.3p2-5ubuntu1 [612kB] Des:2 http://archive.ubuntu.com edgy/main openssh-server 1:4.3p2-5ubuntu1 [217kB] Des:3 http://archive.ubuntu.com edgy/main ssh 1:4.3p2-5ubuntu1 [1098B] 831kB descarregats en 1s (557kB/s) S'estan preconfigurant els paquets... S'està seleccionant el paquet openssh-client prèviament no seleccionat. (S'està llegint la base de dades ... hi ha 174799 fitxers i directoris instal·lats actualment.) S'està desempaquetant openssh-client (de .../openssh-client_1%3a4.3p2-5ubuntu1_i386.deb) ... S'està seleccionant el paquet openssh-server prèviament no seleccionat. S'està desempaquetant openssh-server (de .../openssh-server_1%3a4.3p2-5ubuntu1_i386.deb) ... S'està seleccionant el paquet ssh prèviament no seleccionat. S'està desempaquetant ssh (de .../ssh_1%3a4.3p2-5ubuntu1_all.deb) ... S'està configurant openssh-client (4.3p2-5ubuntu1) ... S'està configurant openssh-server (4.3p2-5ubuntu1) ... Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... * Restarting OpenBSD Secure Shell server... [ ok ] S'està configurant ssh (4.3p2-5ubuntu1) ...
Hi ha un parell de fets a destacar sobre la instal·lació:
- SSH és un paquet buit, que l'únic que fa és instal·lar les dependències openssh-client i openssh-server, client i servidor respectivament d'OpenSSH.
- Es creen unes claus SSH2 RSA i DSA per identificar el servidor
Les claus es guarden a la carpeta /etc/ssh, amb els noms ssh_host_dsa_key, ssh_host_dsa_key.pub, ssh_host_rsa_key i ssh_host_rsa_key.pub
$ cd /etc/ss $ ls *key* ssh_host_dsa_key ssh_host_dsa_key.pub ssh_host_rsa_key ssh_host_rsa_key.pub
Sovint el client ja està instal·lat.
Podem consultar els fitxers que instal·la openssh-client amb la comanda:
$ dpkg -L openssh-client
Tenim les següents comandes/aplicacions/servidors:
$ $ dpkg -L openssh-client | grep bin /usr/bin /usr/bin/ssh /usr/bin/scp /usr/bin/ssh-add /usr/bin/ssh-agent /usr/bin/ssh-keygen /usr/bin/ssh-keyscan /usr/bin/sftp /usr/bin/ssh-copy-id /usr/bin/ssh-argv0 /usr/bin/slogin
I els següents fitxers de configuració:
$ dpkg -L openssh-client | grep etc /etc /etc/ssh /etc/ssh/ssh_config /etc/ssh/moduli
Pel que fa al servidor, procedint de forma anàloga al client, l'aplicació/dimoni que ens ofereix és:
$ dpkg -L openssh-server | grep bin /usr/sbin /usr/sbin/sshd
$ dpkg -L openssh-server | grep etc /etc /etc/init.d /etc/init.d/ssh /etc/default /etc/default/ssh /etc/pam.d /etc/pam.d/ssh
De la resta de fitxers destacar la documentació del client i del servidor que es troben a les carpetes /usr/share/doc/openssh-client i /usr/share/doc/openssh-server.
Ports
El servidor SSH té reservat per la IANA el port 22:
$ cat /etc/services | grep ssh ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp
El port habitual és el TCP.
Instal·lació en sistemes no Debian
Fedora i sistemes amb YUM
No hi ha paquet "tonto" SSH. Per instal·lar el servidor cal executar:
# yum install openssh-server
A Fedora 11 ja es trobava instal·lat, i només faltava executar-los per primer cop amb:
# /etc/init.d/sshd start
Cal tenir en compte que el servei no s'executa sempre per defecte a l'inici del sistema. Si voleu que sigui així heu d'executar:
$ sudo chkconfig --add sshd
El primer cop observareu que es generen les claus. Podeu comprovar que està en execució amb nmap:
$ nmap localhost -p 22
Servidor SSH
Control del servei SSH. Execució, parada, status i reconfiguració de SSH
Seguint els estàndards de Debian GNU/Linux (basat en el sistema d'scripts d'inicialització SystemV (http://en.wikipedia.org/wiki/System_V)) l'script de control del dimoni ssh és:
/etc/init.d/ssh
Les accions que podem fer amb el servei són start|stop|reload|force-reload|restart.
Cada cop que fem un canvi a la configuració de SSH (fitxer /etc/ssh/sshd_config) haurem de fer un restart o un reload del servei:
$ sudo /etc/init.d/ssh reload
Tal com podem veure executant:
$ sudo updatedb $ locate bind9 | grep rc /etc/rc0.d/K85bind9 /etc/rc1.d/K85bind9 /etc/rc2.d/S15bind9 /etc/rc3.d/S15bind9 /etc/rc4.d/S15bind9 /etc/rc5.d/S15bind9 /etc/rc6.d/K85bind9
El servei SSH s'executa a partir del nivell 2 (cal destacar que no està disponible el nivell SINGLE USER MODE rcS.d).
Podeu trobar més informació a l'article Configuració de serveis en Linux
Fitxers de configuració servidor
El servidor SSH l'executa el dimoni sshd (man sshd). La carpeta /etc/ssh conté els fitxers de configuració del dimoni sshd (i també els del client ssh). El fitxer de configuració principal és /etc/ssh/sshd_config. En aquest fitxer es configuren entre d'altres el port del servei, les claus d'identificació del servidor, si admet o no X11Forwarding, la versió de protocol SSH, si es permet l'accés a root per SSH, etc...
# Package generated configuration file # See the sshd(8) manpage for details # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 Protocol 2 # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #Privilege Separation is turned on for security UsePrivilegeSeparation yes # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO # Authentication: LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To enable empty passwords, change to yes (NOT RECOMMENDED) PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosGetAFSToken no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net # Allow client to pass locale environment variables AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes
Recursos:
Client SSH
Accés remot a màquines. Sintaxi
La sintaxi de SSH segueix un esquema similar al del correu electrònic:
usuari@nom_maquina_remota
Els següents són exemples de connexió amb SSH a una màquina remota:
sergi@casa:~$ ssh sergi@www.upc.edu sergi@casa:~$ ssh sergi@192.168.1.1 sergi@casa:~$ ssh 192.168.1.1
Si no posem l'usuari (3er cas), intenta connectar amb l'usuari que estem utilitzant actualment (segons el prompt, l'usuari sergi). Les línies 2 i 3 són doncs equivalents.
La sintaxi completa segons el manual és:
$ ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-w tunnel:tunnel] [user@]hostname [command]
- Per establir la comunicació amb una maquina que tingui SSH el procés seria:
ssh [usuari de la maquina de destí]@[Ip o Hostname de la maquina de destí]
- Si el usuari amb el que estem treballant des de l'origen existeix a la maquina de destí un altre procés seria:
ssh [Ip o Hostmane de la maquina de destí]
- En cas de que volguéssim de que no ens preguntes la contrasenya cada vegada que connectem amb la maquina remota hem de copiar l'arxiu
a la carpeta
de la maquina de destí i canviar el nom per
- De vegades necessitem que quan fem una connexió remota tenim que carregar aplicacions amb entorn gràfic i ho faríem:
ssh -X [usuari de la maquina de destí]@[Ip o Hostmane de la maquina de destí]
El mecanisme utilitzat al connectar-se a una màquina remota varia segons el mètode empleat i la versió del protocol SSH.
Versió 1 del protocol SSH:
- Mitjançant l'ús dels fitxers /etc/hosts.equiv o /etc/ssh/shosts.equiv de la màquina remota a la qual ens connectem.
- Igual que l'anterior però a nivell d'usuari, és a dir, mitjançant els fitxers $HOME/.ssh/rhosts i $HOME/.ssh/shosts
- Utilitzant autenticació basada en RSA. RSA es basa en criptografia de clau pública. El fitxer $HOME/.ssh/authorized_keys del servidor remot al qual ens connectem ha de contenir la clau pública del parell de claus que utilitzem per a connectar-nos. En resum, el procés de connexió és el següent:
- El client envia una petició de connexió al servidor juntament amb la clau pública.
- El servidor comprova si la clau existeix al fitxer $HOME/.ssh/authorized_keys. Si no és aixi es continua amb el procés normal (mitjançant contrasenya).
- Si el servidor identifica la clau pública com a vàlida, envia un "repte" al client. Aquest repte consisteix normalment en un número aleatori encriptat mitjançant la clau pública de l'usuari.
- El client ha de ser capaç de desencriptar mitjançant la clau privada el número aleatori. D'aquesta forma el servidor autentifica a l'usuari que es connecta.
Versió 2 del protocol SSH:
La versió 2 del protocol SSH inclou millores en seguretat, afegint mecanismes addicionals de seguretat (AES, DES, BLOWFISH, CAST128, etc.) i de control de la integritat de la transmissió (hmac-md5, hrac-sha1).
Pel que fa al mecanisme de connexió, s'afegeix la possibilitat de connectar-se utilitzant DSA (Digital Signature Algorithm) o RSA.
Generació de claus. ssh-keygen
La comanda ssh-keygen s'encarrega de la creació dels parells de claus pública/privada. Per defecte, els fitxers depenent del protocol escollit:
- $HOME/.ssh/identity (clau privada) i $HOME/.ssh/identity.pub (clau pública)
- $HOME/.ssh/id_dsa (clau privada) i $HOME/.ssh/id_dsa.pub (clau pública) si el protocol escollit es DSA.
- $HOME/.ssh/id_rsa (clau privada) i $HOME/.ssh/id_rsa.pub (clau pública) si el protocol escollit es RSA.
Les comandes exactes a utilitzar per generar les claus en cadascun dels casos anteriors són:
- ssh-keygen
- ssh-keygen -t dsa
- ssh-keygen -t rsa
El nom dels fitxers per defecte es pot canviar utilitzant el paràmetre -f. Durant la creació de la clau se'ns preguntarà per la possibilitat de protegir l'ús de la clau amb contrasenya. Si la nostra intenció és automatitzar tasques podem anular aquest pas si no introduïm cap contrasenya (Enter). Veiem un exemple de creació d'una clau dsa
$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/sergi.tur/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/sergi.tur/.ssh/id_dsa. Your public key has been saved in /home/sergi.tur/.ssh/id_dsa.pub. The key fingerprint is: 9b:06:0f:d2:6b:15:43:42:84:1a:c2:e1:81:fc:e4:12 sergi.tur@casa
Veiem un exemple pas a pas, del que cal fer per aconseguir autenticar-se a una màquina remota via SSH sense l'ús de contrasenya:
NOTA: Hi ha una alternativa per tal de fer els següents passos en una sola comanda:
cat ~/.ssh/id_dsa.pub | ssh sergi.tur@192.168.1.50 "mkdir ~/.ssh;chmod 700 ~/.ssh ; cat - >> ~/.ssh/authorized_keys"
NOTA 2: El paquet openssh-client ens ofereix una comanda per fer la còpia d'aquest fitxer:
$ ssh-copy-id -i ~/.ssh/id_dsa.pub sergi@192.168.1.2 sergi@192.168.1.2's password: Now try logging into the machine, with "ssh 'sergi@192.168.1.2'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
NOTA: Si dona l'error mkdir: no s'ha pogut crear el directori «~/.ssh»: File exists no us preocupeu, això vol dir simplement que ja existia la carpeta .ssh i que no calia crear-la.
Imaginem que la màquina remota ssh té la IP 192.168.1.50
Copiem la clau pública a la màquina remota. Atenció!: no us equivoqueu i mai compartiu amb ningú la vostra clau privada:
$ scp id_dsa.pub sergi.tur@192.168.1.50:~/.ssh sergi.tur@192.168.1.50's password: id_dsa.pub 100% 1116 1.1KB/s 00:00
Accedim a la màquina remota per tal d'afegir la clau pública que acabem de copiar al fitxer authorized_keys:
$ ssh sergi.tur@192.168.1.50 sergi.tur@192.168.1.50's password: ..... Last login: Sat Jul 1 09:18:38 2006 ...... 192.168.1.50$ cd .ssh/ 192.168.1.50$ cat id_dsa.pub >> authorized_keys
Atenció, utilitzeu >> i no pas > si voleu respectar les claus que ja hi hagin al fitxer
És recomanable executar la comanda per comptar línies wc:
$ wc -l authorized_keys
Abans i després d'afegir la clau per tal d'assegurar-se que la clau s'ha afegit a una nova línia. Sortim:
192.168.1.50$ exit logout Connection to 192.168.1.50 closed.
I comprovem que tot funciona correctament, connectant-nos a la màquina remota un altre cop, però aquest cop sense la necessitat de la contrasenya
$ ssh sergi.tur@192.168.1.50 Last login: Sat Jul 1 19:42:02 2006 from ....... ................... 192.168.1.50$
Recursos:
ssh-copy-id
El paquet openssh-client ens ofereix una comanda per tal d'automatitzar la entrada a un servidor remot amb claus en comptes de paraula de pas:
$ ssh-copy-id -i ~/.ssh/id_dsa.pub sergi@192.168.1.2 sergi@192.168.1.2's password: Now try logging into the machine, with "ssh 'sergi@192.168.1.2'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
Ara ja haurieu de poder entrar al servidor remot sense paraula de pas.
Obtenir el fingerprint d'un servidor
Ve donada per l'empremta digital de la clau RSA. La podem consultar amb
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 13:91:24:4d:d7:d8:fa:16:22:a8:27:63:04:7c:2b:16 /etc/ssh/ssh_host_rsa_key.pub
Eliminar una clau de servidor
$ ssh-keygen -R IP_O_NOM_MAQUINA
Per exemple
$ ssh-keygen -R 192.168.0.7
ssh-agent
Si no volem crear les claus sense contrasenya podem utilitzar ssh-agent.
ssh-agent s'encarrega de recordar les paraules de pas. Per a que funcioni cal que s'estigui executant com a dimoni o procés en segon pla. Amb Gnome és automàtica ja que el GDM arranca automàticament ssh-agent al iniciar la sessió gràfica. Amb KDE cal assegurar-se que el fitxer /usr/kde/3.4/env/agent-startup.sh té permisos d'execució i que carrega ssh-agent.
Si s'utilitza startx per arrancar X Window cal modificar el fitxer .xsession. Un exemple:
ssh-agent startkde
L'ordre sss-add afegeix la nostra clau pública a la base de dades de ssh-agent de forma que ja no ens calgui la paraula de pas per utilitzar aquesta clau pública.
Recursos:
Hey hey hey, take a gadenr at what' you've done
Fitxers de configuració del client
Els fitxers de configuració poden ser:
- Fitxers de configuració per usuari: Es troben a la carpeta $HOME/.ssh.
- Fitxers de configuració per a tota la màquina: Es troben a la carpeta /etc/ssh.
Fitxer ~/.ssh/config
- Fitxer de configuració d'usuari: ~/.ssh/config
- Fitxer de configuració de màquina: /etc/ssh/ssh_config
En aquests fitxers es configuren els perfils de SSH. Un perfil és una configuració específica per a connectar-se a un servidor o grup de servidors específics. Per exemple:
Host portatil Hostname portatil.edu IdentityFile ~/.ssh/portatil Port 22
Ens indica que quan utilitzem el perfil portatil ens connectem a la màquina portatil.edu, mitjançant la clau privada ~/.ssh/portatil.
Unes altres línies típiques de configuració poden ser:
Host * ForwardX11 yes
Configura el client per tal que utilitzi sempre X11Forwarding.
Recursos:
Mantenir connexions TCP vives
TCPKeepAlive yes ServerAliveInterval 120 Protocol 2,1
Soluciona un problema amb Nautilus.
Fitxer known_hosts
Aquest fitxer emmagatzema les claus públiques dels servidors als quals ens connectem habitualment. Aquest fitxer permet establir un mecanisme addicional de seguretat que ens permet identificar atacs del tipus Man In The Middle, on el servidor SSH és substituït per un altra màquina que es fa passar pel servidor. Amb aquest tipus d'atac, el servidor fals pot capturar les contrasenyes d'accés del client.
Tots els servidors de SSH tenen una clau única (key fingerprint) que els diferencia de la resta. Aquesta clau com hem vist a l'apartat d'instal·lació de SSH, es genera a l'instal·lar el servidor. Si ens fixem, la primera vegada que ens connectem a una màquina amb SSH:
$ ssh sergi.tur@10.0.2.2 The authenticity of host 'tjener (10.0.2.2)' can't be established. RSA key fingerprint is ab:37:e2:3f:6f:16:27:5e:9a:02:a1:e1:9a:34:7f:69. Are you sure you want to continue connecting (yes/no)?yes password:
Ens mostra la clau del servidor SSH al qual ens connectem i si ens hi volem connectarAquest és un moment clau de seguretat. El primer que que ens connectem a un servidor SSH em de conèixer el seu fingerprint per tal d'estar segurs que ningú s'està fent passar pel servidor. Podem consultar el fingerprint d'un servidor executant (des del servidor):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 13:91:24:4d:d7:d8:fa:16:22:a8:27:63:04:7c:2b:16 /etc/ssh/ssh_host_rsa_key.pub
Si acceptem, la clau del servidor quedarà emmagatzemada al fitxer known_hosts. La pròxima vegada que ens connectem al servidor comprovarà si la clau és la mateixa. En el cas que hagi variat ens mostrarà el següent missatge:
$ ssh sergi.tur@10.0.2.2 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is f2:92:1d:da:81:2a:d7:16:0a:48:f0:43:20:1c:f4:b5. Please contact your system administrator. Add correct host key in ~/.ssh/known_hosts to get rid of this message. Offending key in ~/.ssh/known_hosts:5 Password authentication is disabled to avoid man-in-the-middle attacks. X11 forwarding is disabled to avoid man-in-the-middle attacks. Permission denied (publickey,password,keyboard-interactive).
A vegades ens trobem amb aquest error, però no es tracta de cap atac (màquines amb ips dinàmiques dins d'una xarxa local, diferents servidors SSH accessibles des d'un mateix gateway amb SNAT, etc). Per solucionar aquest problema podem executar:
$ sed -i '5d' ~/.ssh/known_hosts
També podeu utilitzar
$ ssh-keygen -R IP_O_NOM_MAQUINA
Per exemple:
$ ssh-keygen -R 192.168.0.7
Comandes ssh addicionals
scp
Aquesta comanda permet la còpia remota de fitxers. Funciona de forma anàloga a la comanda cp, però utilitza (de la mateixa forma que veurem més endavant amb rsync) prefixos de conexió a màquina remota:
usuari@host:/PATH_AL_FITXER
Per exemple:
scp $HOME/file1 sergi@sga2.upc.es:$HOME
Copia el fitxer file1 de la carpeta home local a la carpeta home del servidor sga2.upc.es.
sftp
Versió segura de la comanda ftp.
$ sftp -i /home/sergi/.ssh/id_dsa acacha,webfaltes@shell.sourceforge.net:/home/frs/project/w/we/webfaltes Connecting to frs.sourceforge.net... sftp> cd /home/frs/project/w/we/webfaltes sftp> put webfaltes_2.4.tar.gz Uploading webfaltes_2.4.tar.gz to /home/frs/project/w/we/webfaltes/webfaltes_2.4.
X11Forwarding
X11Forwarding és una tècnica que ens permet redireccionar la sortida de les aplicacions X a un servidor remot. En el cas d'una comunicació mitjançant SSH, si utilitzem X11Forwarding el que fem és redireccionar la sortida de les aplicacions X executades al servidor remot al nostre servidor X en local. Com veurem en l'apartat dedicat a les X, la redirecció X es controla amb la variable DISPLAY.
En el cas de SSH, a l'activar el X11Forwarding, la màquina local fa de proxy SSH i s'encarrega de fer totes les gestions per tal que al connectar-nos a la màquina remota les aplicacions gràfiques es direccionin a la nostra màquina. S'estableix la variable DISPLAY a localhost:11.0 (o un número mai inferior a 10, segons la configuració típica del servidor SSH).
Per establir una connexió amb X11 forwarding via SSH heu de connectar-vos a un servidor SSH amb l'opció -X:
$ ssh -X usuari@ip_servidor_ssh
També és important comprovar que el servidor per connexions X11 forwarding:
- Al fitxer /etc/ssh2/sshd2_config
AllowX11Forwarding yes
Al client també es pot activar el X11 forwading per a tots els usuari modificant el fitxer /etc/ssh/ssh_config:
Host * ForwardX11 yes
També es pot posar al fitxer ~/.ssh/config:
Host * ForwardX11 yes
SSH backdoor o Remote Forwarding
Permet accedir via SSH a una màquina darrera d'un firewall. Si la màquina té accés cap a l'exterior aleshores es possible saltar-se el tallafocs si tenim accés a la màquina (ginger)
$ ssh -R 2222:localhost:22 thedude@blackbox.example.com $ while [ 1 ]; do date; sleep 300; done $ ssh thedude@blackbox.example.com (des de tech) thedude@blackbox:~$: ssh -p 2222 root@localhost
http://www.debianadmin.com/howto-use-ssh-local-and-remote-port-forwarding.html
Recursos:
- http://www.skolelinux.no/~klaus/newnotater_Sarge/x102.html
- http://www.ibm.com/developerworks/linux/library/l-10sysadtips/index.html?ca=drs-
SSH Tunneling
Local versus Remote forwarding
Hi ha 2 tipus de túnels SSH:
- local (outgoing): Redirecciona el tràfic dirigit a un port local cap a un port remot.
- remot (incoming): Fa el contrari. Redirecciona el tràfic que es dirigeix cap a un port remot cap a un port local.
És important tenir en compte que intervenen 3 màquines:
- client
- sshdserver
- appserver
Observeu la gràfica de l'apartat anterior.
Recursos:
- http://www.hackinglinuxexposed.com/articles/20030309.html
- http://www.ssh.com/support/documentation/online/ssh/winhelp/32/Local_And_Remote_Forwarding.html
Permetent a màquines remotes accedir a les redireccions locals
Per defecte, les redireccions dels túnels SSH només són accessibles des de la màquina local. Podeu utilitzar la opció -g per permetre l'accés al port des de màquines remotes:
$ man ssh | grep "\-g" -g Allows remote hosts to connect to local forwarded ports.
Consultar les connexions establertes a través del túnel
~# The following connections are open: #1 127.0.0.1 (t4 r2 i0/0 o0/0 fd 7/7)
Establir el túnel en el fitxer de configuració
Afegiu al fitxer ~/.ssh/config:
Host revTelnetTunnel HostName mail.my_isp.net RemoteForward 2323:localhost:23 GatewayPorts no
Recursos:
Utilitzar un proxy remot mitjançant un tunel SSH
Consulteu Squid#Utilitzar_un_proxy_remot_amb_t.C3.BAnels_SSH
Exemple 1
Es possible connectar-se parcialment de forma segura a qualsevol màquina remota encara que aquesta no proporciona cap servei segur fent servir un túnel SSH. Quan diem parcialment ens referim al fet que la comunicació només estarà xifrada en una part de la comunicació. Suposem el següent sistema de màquines:
origen ---> mig ---> destinació
Amb aquest sistema, si tenim accés a la màquina mig la podem utilitzar per fer un túnel SSH. des de l'ordinador origen executem:
$ ssh -L 6666:destinacio:23 -l sergi mig
Si ens autentiquem correctament, haurem establert una connexió interactiva amb l’ordinador mig com a usuari sergi, i a més, qualsevol connexió al port 666 des d'origen serà redireccionada a el port 23 de la màquina destinació. Estem per tant permeten una connexió Telnet com la següent:
$ telnet origen 6666
o equivalentment:
$ telnet localhost 6666
D'aquesta manera, el tram de comunicacions que va d'origen a mig estarà xifrat. Sovint aquest tram és el més important d'assegurar ja que correspon a la xarxa LAN a la que estem. La xarxa LAN, sovint és el tram més perillós, degut a les vulnerabilitats d'aquest tipus de xarxes. Consulteu:
Exemple 2
Hi ha moltes raons per les que podem voler crear un túnel SSH. Per exemple podem utilitzar túnels SSH per securitzar qualsevol connexió no segura.
Per exemple imagineu-vos que no volem que les nostres cerques a Google puguin ser interceptades. Podem crear un túnel amb la següent comanda:
$ sudo ssh -L 81:www.google.com:80 localhost
Ens preguntara dues contrasenyes:
- La del nostre usuari per la comanda sudo
- La de l'usuari de root a la màquina local per tal de crear el tunel
Ara tenim un túnel SSH a la web de google. Si accedim a la web http://localhost:81:
Ens trobem la pàgina de Google, però les dades viatgen a través de SSH per un túnel segur.
Si utilitzem ports privilegiats (per sota de 1024) necessitem utilitzar el superusuari. Per exemple si executem:
$ ssh -L 81:www.google.com:80 localhost Privileged ports can only be forwarded by root.
Ens avisa que no podem fer-ho. Un altre possibilitat és utilitzar un port per sobre de 1024:
$ ssh -L 4000:www.google.com:80 localhost
Exemple 3
Recursos:
- http://www.e-ghost.deusto.es/docs/articulo.ssh.html
- http://www.oreillynet.com/pub/a/wireless/2001/02/23/wep.html
Exemple 4
ssh -f user@personal-server.com -L 2000:personal-server.com:25 -N
On:
- -f: SSH s'executarà en en segon terme (background). F ve de fork.
- -N: Indica que no s'executarà cap comanda
SSH Jail
Les gàbies o jail impedeixen que els usuaris que es connecten a un sistema remot puguin accedir a fitxers que no són del seu usuari/home.
Per fer que un usuari només pugui utilitzar SFTP dins de la seva gàbia cal editar la configuració del servidor SSH:
$ sudo joe /etc/ssh/sshd_config
I canvieu la línia:
Subsystem sftp /usr/lib/openssh/sftp-server
Per
Subsystem sftp internal-sftp
Afegiu al final el següent:
Match User guifi ChrootDirectory /usr/share/chroot_guifi AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp
On guifi és l'usuari de sistema que voleu que funcioni amb gàbia.
$ adduser guifi
També es pot fer amb grups.
La gàbia és troba a la carpeta:
/usr/share/chroot_guifi
La gàbia sempre ha de ser del root (usuari i grup) i amb permisos 755
$ sudo mkdir /usr/share/chroot_guifi
Cal canviar la home per defecte de l'usuari guif al fitxer /etc/passwd:
guifi:x:1001:1002:,,,:/usr/share/chroot_guifi/wordpress_guifiTerresEbre:/bin/bash
I aplicar la configuració al servidor SSH:
$ sudo /etc/init.d/ssh restart
Recursos:
Resolució de problemes
Request for subsystem 'sftp' failed on channel 0
Connection reset by peer. Bad ownership or modes for chroot directory
Si al intentar connectar amb un usuari engabiat us dona l'error:
Connection to terresdelebre.guifi.net closed by remote host. Couldn't read packet: Connection reset by peer
Consulteu el fitxer de log de SSH al servidor:
$ sudo tail -f /var/log/auth.log ... Feb 21 09:50:56 acacha sshd[32370]: Address 87.111.152.22 maps to cliente-87936.iberbanda.es, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! Feb 21 09:51:27 acacha sshd[32370]: Accepted password for guifi from 87.111.152.22 port 37862 ssh2 Feb 21 09:51:27 acacha sshd[32370]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory Feb 21 09:51:27 acacha sshd[32370]: pam_unix(sshd:session): session opened for user guifi by (uid=0) Feb 21 09:51:27 acacha sshd[32378]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory Feb 21 09:51:27 acacha sshd[32378]: fatal: bad ownership or modes for chroot directory "/usr/share/wordpress_guifiTerresEbre" Feb 21 09:51:27 acacha sshd[32370]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory Feb 21 09:51:27 acacha sshd[32370]: pam_unix(sshd:session): session closed for user guifi
La carpeta que s'indica com a chroot ha de ser propietat de root i amb permisos d'escriptura només per a root.
Reutilitzant connexions SSH
Fitxers de lo
El log de SSH el podeu trobar a:
/var/log/auth.log
La millor manera de consultar el log és utilitzar l'ordre tail:
$ sudo tail -f /var/log/auth.log
Log del servidor (login i logLEVEL)
Es pot desactivar canviant el paràmetre LogLEVEL. Per exemple:
logLevel QUIET
Connexions remotes SSH amb Nautilus
Consulteu l'article:
Nautilus
DSH
Consulteu l'article DSH.
X Arquitectura client-servidor
Els primers sistemes gràfics es varen crear al MIT allà per l'any 1984. Aquests sistemes van ser pensats per a ser executats en grans màquines, també anomenades main-frames, que aporten la capacitat de càlcul a terminals "tontes" que simplement disposen d'un controlador gràfic i dels dispositius necessaris d'interacció amb l'usuari.
En aquests sistemes el Servidor és aquella màquina que mostra els gràfics, és a dir, els terminals amb el controlador gràfic.
Com saben les aplicacions gràfiques quin servidor X han d'executar? Vàries opcions:
- Variable d'entorn DISPLAY.
- Mitjançant el paràmetre -display. A l'executar l'aplicació podem utilitzar aquesta comanda per controlar quin servidor X utilitzarem.
xhost
Consulteu xhost.
XDMCP
Consulteu LPI_106.2._Configurar_un_gestor_de_pantalla#XDMCP
Recursos:
- http://www.movingtofreedom.org/2007/02/16/howto-remote-desktop-with-vnc-in-ubuntu-edgy-gnu-linux/
- http://ubuntuguide.org/wiki/Ubuntu_Edgy#Remote_Login_via_XDMCP
Rsync
Vegeu l'article rsync
Eines d'accés remot a escriptoris
VNC
Virtual Network Computing (VNC) (http://en.wikipedia.org/wiki/VNC) és un sistema basat en RFB (Remote FrameBuffer). VNC és independent de la plataforma i trobem implementacions de clients i servidors per a tots el Sistemes Operatius. Un dels avantatges respecte a altres tecnologies és que suporta connexió de múltiples clients al mateix temps a una mateixa màquina. El codi font original de VNC és un codi obert sota llicència GNU/GPL (GNU General Public License). VNC va ser desenvolupat pels laboratoris AT&T.
Hi ha moltes aplicacions per utilitzar VNS en sistemes Linux. Si executem la comanda:
$ sudo apt-cache search vnc Password: libvncauth-dev - Virtual network computing authentication headers and static lib libvncauth0 - Virtual network computing authentication library tsclient - front-end for viewing of remote desktops in GNOME vnc-common - Virtual network computing server software xvncviewer - Virtual network computing client software for X tightvnc-java - TightVNC java applet and command line program vnc-java - VNC java applet and command line program conspy - Remote control of Linux virtual consoles directvnc - VNC client using the framebuffer as display gnome-rdp - Remote Desktop Client for the GNOME Desktop iprelay - User-space bandwidth shaping TCP proxy daemon kcemirror - Windows CE remote control tool like VNC libsvncpp-dev - Subversion C++ library (development files) libsvncpp0c2a - Subversion C++ shared library libsvnqt2 - Qt wrapper library for subversion libvncserver-dev - easy API to write one's own VNC server linuxvnc - VNC server to monitor a tty rfb - VNC Server for X11 - exports current display svncviewer - virtual network computing client software for SVGA tightvncserver - virtual network computing server software tkvnc - Displays a list of (defined) machines to start VNC to vncommand - VNC server which monitors a specified program vncserver - Virtual network computing server software vncsnapshot - A utility that takes JPEG snapshots from VNC servers vtgrab - A VNC like console monitoring x11vnc - VNC server which uses your current X11 session x2vnc - A dual-screen hack - link an MS-Windows and X display xtightvncviewer - virtual network computing client software for X xwnc - Mix of Xvnc and XDarwin with improved protocol vino - VNC server for GNOME krdc - Remote Desktop Connection for KDE krfb - Desktop Sharing for KDE vnc4-common - Virtual network computing server software vnc4server - Virtual network computing server software xvnc4viewer - Virtual network computing client software for X
Veiem que hi ha una infinitat d'opcions per escollir.
Ubuntu, amb el sistema Gnome, ja porta instal·lat per defecte els paquets:
- vino
- vnc-common
- xvncviewer
- tsclient
També són recomanables els paquets de KDE:
- krdc
- krfb
Les següents pantalles mostren com s'ha d'utilitzar VNC amb els paquets que proporciona Ubuntu/Gnome:
'Client:
Missing image VNC3.png Image:VNC3.png
Servidor:
RDP
RDP Remote Desktop Protocol (http://en.wikipedia.org/wiki/Remote_Desktop_Protocol) és un protocol multicanal que permet connectar-se a computadores remotes Windows. Hi ha clients per a gairebé totes les plataformes. Suporta 24 bits, encriptació de 128bits, suport audio remot, impressores, sistema de fitxers. El princiapl inconvenient és que només suporta Windows XP professional (no Home Edition). És un protocol lent i no permet més d'una connexió al mateix temps.
Les següents captures de pantalla mostren els passos a seguir per connectar-se a una màquina Windows des de l'aplicació tsclient d'Ubuntu:
El primer que cal fer és permetre l'accés d'escriptori remot a Windows i assegurar-se que cap firewall o aplicació similar no ens estigui bloquejant el pas:
Recursos:
Registre de Windows
Sembla que hi han diferents opcions del registre de Windows que s'han de modificar per poder accedir remotament:
Per executar el registre de Windows obres una consola de dos o o executes directament la comanda:
regedit
Registres:
- HKLM/SRV/HKLMSYSTEMCurrentControlSetControlTerminal Server:
- REG_DWORD value fDenyTSConnection: canviar 1 a 0
- HKEY_LOCAL_MACHINE \ SYSTEM \CurrentControlSet \ Control \ Terminal Server.
- Valor fDenyTSConnections: Canviar el valor de 1 a 0
Recursos:
- http://www.lockergnome.com/nexus/windows/2005/12/07/enabling-remote-desktop-on-remote-computer/
- http://element14.wordpress.com/2006/06/18/windows-server-hacks-remotely-enable-remote-desktop/
- http://www.windowsdevcenter.com/pub/a/windows/2004/05/04/serverhacks_remote.html
FreeNX
Consulteu l'article FreeNX.
LTSP
Consulteu l'article LTSP.
Scripts de força bruta
- http://linuxmafia.com/pub/linux/security/sshd_sentry/sshd_sentry
- http://www.securiteam.com/tools/5JP0520G0Q.html
- http://denyhosts.sourceforge.net/
Recursos
- Guia per configurar usuaris-client i servidor
- SSH a la wikipedia (diferents idiomes).
- OpenSSH a la wikipedia (en)
- Criptogràfia de clau pública
- Rsync web oficial.
- Easy Automated Snapshot-Style Backups with Linux and Rsync.
- X11 a la wikipedia (diferents idiomes)
- X - Modelo cliente - servidor.
- http://www.unix.com.ua/orelly/networking_2ndEd/ssh/ch03_05.htm
Fonts d'informació
- http://www.wikilearning.com/ssh_una_historia_ajetreada-wkccp-6415-1.htm
- http://www.ubuntu-es.org/index.php?q=node/19491
- http://xarxantoni.net:8080/mediawiki/index.php/Gesti%C3%B3_Remota._SSH%2C_RSYNC%2C_X-WINDOWS#OpenSSH
man ssh man dsh