Gestió Remota. SSH, RSYNC, X-WINDOWS

De Guifi.net - Wiki Català

Revisió de 03:40, 4 des 2013; Al (Discussió | contribucions)

(dif) ←Versió més antiga | Versió actual (dif) | Versió més nova→ (dif)
25px Aquesta wiki forma part dels materials d'un curs
Curs:
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

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:

  1. Mitjançant l'ús dels fitxers /etc/hosts.equiv o /etc/ssh/shosts.equiv de la màquina remota a la qual ens connectem.
  2. Igual que l'anterior però a nivell d'usuari, és a dir, mitjançant els fitxers $HOME/.ssh/rhosts i $HOME/.ssh/shosts
  3. 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:
    1. El client envia una petició de connexió al servidor juntament amb la clau pública.
    2. 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).
    3. 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.
    4. 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:

  1. $HOME/.ssh/identity (clau privada) i $HOME/.ssh/identity.pub (clau pública)
  2. $HOME/.ssh/id_dsa (clau privada) i $HOME/.ssh/id_dsa.pub (clau pública) si el protocol escollit es DSA.
  3. $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:

  1. ssh-keygen
  2. ssh-keygen -t dsa
  3. 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:

Script

Script per automatizar la connexió per claus 

#!/bin/bash 
set -e
OLDDIR=`pwd`;
if [ -z "$1" ]; then
  echo Need user@host info;
  exit 1;
fi;
cd $HOME;
if [ -e "./.ssh/id_dsa.pub" ]; then
  cat ./.ssh/id_dsa.pub | ssh $1 'cat >> .ssh/authorized_keys';
else
  ssh-keygen -t dsa;
  cat ./.ssh/id_dsa.pub | ssh $1 'cat >> .ssh/authorized_keys';
fi;
cd $OLDDIR

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: 

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)

Fitxer:RemoteForwardingSSH.gif
$ 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:

SSH Tunneling

Fitxer:SSHTunnel.gif

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:

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:

  1. La del nostre usuari per la comanda sudo
  2. 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:

Fitxer:TunelSSHGoogle.jpg

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

Fitxer:SSHTunel.png


Recursos:

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:

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

Fitxer:VNC1.jpg

Servidor:

Fitxer:VNC4.png

Fitxer:VNC2.jpg

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:

Fitxer:RDP1.jpg

Fitxer:RDP2.jpg

Fitxer:RDP3.jpg

Fitxer:RDP5.jpg

Fitxer:RDP6.jpg

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:

FreeNX

Consulteu l'article FreeNX.

LTSP

Consulteu l'article LTSP.

Scripts de força bruta

Recursos

Fonts d'informació

man ssh
man dsh
Obtingut de «http://ca.wiki.guifi.net/w/index.php?title=Gestió_Remota._SSH,_RSYNC,_X-WINDOWS&oldid=3547»
Eines de l'usuari