Aquesta wiki forma part dels materials d'un curs | |
|---|---|
| Curs: | DissenyXarxesLinux, LinuxAdministracioAvancada |
| Fitxers: | GestioRemota.pdf (GestioRemota.odp), |
| Repositori SVN: | http://[email protected]/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.
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.
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
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ó:
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.
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.
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
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
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:
La sintaxi de SSH segueix un esquema similar al del correu electrònic:
[email protected]_maquina_remota
Els següents són exemples de connexió amb SSH a una màquina remota:
[email protected]:~$ ssh [email protected] [email protected]:~$ ssh [email protected] [email protected]:~$ 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:
Acacha Wiki$ 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]
[[email protected]]hostname [command]
ssh [usuari de la maquina de destí]@[Ip o Hostname de la maquina de destí]
ssh [Ip o Hostmane de la maquina de destí]
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:
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.
La comanda ssh-keygen s'encarrega de la creació dels parells de claus pública/privada. Per defecte, els fitxers depenent del protocol escollit:
Les comandes exactes a utilitzar per generar les claus en cadascun dels casos anteriors són:
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 [email protected]
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 [email protected] "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 [email protected] [email protected]'s password: Now try logging into the machine, with "ssh '[email protected]'", 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 [email protected]:~/.ssh [email protected]'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 [email protected] [email protected]'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 [email protected] Last login: Sat Jul 1 19:42:02 2006 from ....... ................... 192.168.1.50$
Recursos:
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 [email protected] [email protected]'s password: Now try logging into the machine, with "ssh '[email protected]'", 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.
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
$ ssh-keygen -R IP_O_NOM_MAQUINA
Per exemple
$ ssh-keygen -R 192.168.0.7
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 ssh-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:
$ ssh-add ~/.ssh/id_dsa Need passphrase for /home/mah/.ssh/id_dsa ([email protected]). Enter passphrase:
Recursos:
Script per automatizar la connexió per claus
#!/bin/bash set -e OLDDIR=`pwd`; if [ -z "$1" ]; then echo Need [email protected] 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
Els fitxers de configuració poden ser:
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:
TCPKeepAlive yes ServerAliveInterval 120 Protocol 2,1
Soluciona un problema amb Nautilus.
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 [email protected] 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 [email protected] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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
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:
[email protected]:/PATH_AL_FITXER
Per exemple:
scp $HOME/file1 [email protected]:$HOME
Copia el fitxer file1 de la carpeta home local a la carpeta home del servidor sga2.upc.es.
Versió segura de la comanda ftp.
$ sftp -i /home/sergi/.ssh/id_dsa acacha,[email protected]:/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.
També podeu utilitzar l'eina gràfica multiplataforma Filezilla o fins i tot pode utilitzar el Nautilus ( navegador de fitxers del Gnome), tant amb l'opció de menú Llocs > Connecta a un Servidor com directament des del Nautilus posant a la barra de navegació (Menú Vés i Ubicació ) la URL que voleu utilitzar. Per exemple:
sftp://[email protected]:/home/frs/project/w/we/webfaltes
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 [email protected]_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
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 [email protected] $ while [ 1 ]; do date; sleep 300; done $ ssh [email protected] (des de tech) [email protected]:~$: ssh -p 2222 [email protected]
http://www.debianadmin.com/howto-use-ssh-local-and-remote-port-forwarding.html
Recursos:
Hi ha 2 tipus de túnels SSH:
És important tenir en compte que intervenen 3 màquines:
Observeu la gràfica de l'apartat anterior.
Recursos:
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.
~# The following connections are open: #1 127.0.0.1 (t4 r2 i0/0 o0/0 fd 7/7)
Afegiu al fitxer ~/.ssh/config:
Host revTelnetTunnel HostName mail.my_isp.net RemoteForward 2323:localhost:23 GatewayPorts no
Recursos:
Consulteu Squid#Utilitzar_un_proxy_remot_amb_t.C3.BAnels_SSH
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:
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:
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
Recursos:
ssh -f [email protected] -L 2000:personal-server.com:25 -N
On:
TODO: posar els comandes com a links interns i esborrar aquest missatge!
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:
Si uns dona aquest error al connectar-vos via SSH és per que la carpeta arrel no és de l'usuari root. Consulteu #Connection reset by peer. Bad ownership or modes for chroot directory
Un exemple:
$ cd /var/www/chroot_guifihotspot.iesebre.com $ ls -la total 24 drwxr-xr-x 4 root root 4096 2011-05-31 19:37 . drwxr-xr-x 10 root root 4096 2011-05-31 19:25 .. -rw------- 1 guifihotspot guifihotspot 65 2011-05-31 19:37 .bash_history drwx------ 2 guifihotspot guifihotspot 4096 2011-05-31 19:34 .cache drwxr-xr-x 2 guifihotspot guifihotspot 4096 2011-05-31 19:25 guifihotspot.iesebre.com -rw-r--r-- 1 guifihotspot guifihotspot 14 2011-05-31 19:27 README
En aquest cas l'usuari és guifihotspot i la configuració del servidor SSH:
Match User guifihotspot ChrootDirectory /var/www/chroot_guifihotspot.iesebre.com AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftp
No es tracta d'un error, això és normal! De fet el que hem fet es crear un usuari que només es pot connectar per SFTP i no pas per línia d'ordres remota amb SSH.
$ ssh [email protected] [email protected]'s password: This service allows sftp connections only. Connection to 192.168.0.9 closed.
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. Les carpetes que hi han dins de l'arrel poden ser de l'usuari que entra al servidor sftp.
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
Es pot desactivar canviant el paràmetre LogLEVEL. Per exemple:
logLevel QUIET
Consulteu l'article:
Nautilus
Consulteu l'article DSH.
Consulteu l'article CSH.
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:
Consulteu xhost.
Consulteu LPI_106.2._Configurar_un_gestor_de_pantalla#XDMCP
Recursos:
Vegeu l'article rsync
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:
També són recomanables els paquets de KDE:
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:
Consulteu tsclient i:
https://help.ubuntu.com/community/VNC
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:
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:
Recursos:
Consulteu l'article FreeNX.
Consulteu l'article LTSP.
Es pot fer que un usuari concret només pugui executar un ordre concreta (normalment s'utilitza per crear jails]]). Per exemple anem a crear un usuari que al connectar-se li mostri el "trenet" de l'ordre sl:
Creeu un usuari:
$ sudo adduser sl
I poseu-li una paraula de pas que heu de recordar.
Editeu el servidor SSH:
$ sudo joe /etc/ssh/sshd_config
Afegiu les següents línies al final del fitxer:
Match User sl ForceCommand /usr/games/sl
Hem posat el path complet de sl:
$ which sl /usr/games/sl
Apliqueu els canvis:
$ sudo /etc/init.d/ssh restart
Ara connecteu-vos i vegeu el resultat:
$ ssh [email protected]
Match User svnuser ForceCommand svnserve -t
command="svnserve" ssh-rsa AAA...LONG AND TEDIOUS KEY...== [email protected]
For a long time I had a trouble with slow remote login to all my Ubuntu servers (all 2). Slow login means 2-3 seconds in my case. It is not so dramatic of course but when the login is via key you want that everything works like a flash - ultimately we have not the 486SX. Long googleing suggested only standard solutions like:
1. UseDNS no in /etc/ssh/sshd_config — speeds up login in case of slow DNS. I have a local cash DNS, thus everything was fast without it. 2. Forced IPv4 in the SSH client didn't help — probably not everybody has such problem with speed.
And my question with bounty at askubuntu.com was despondently hanging there for weeks without any answer…
It appeared, the /etc/motd file in Ubuntu which was used by our grandparents for really important tasks, should be used quite "creatively" – motd was generated to the 10th version at the crontab task, that fulfilled tons of tasks, among them checking for updates on the canonical server (and much more). Switch off via the 'update-motd –disable'.
It isn't so easy in the 10th version, because the motd generation was carried to the PAM modules, which are fulfilled straight in the moment of login and eat up those precious 2-3 seconds of time, while user is impatiently looking in the black Terminal window. What to do:
1. In the files /etc/pam.d/login and /etc/pam.d/sshd cut out the string «session optional pam_motd.so»
2. Pull down the paid monitoring components set by default:
aptitude remove landscape-client landscape-common
After that you can finally edit the /etc/motd as you like it.
In the /etc/ssh/sshd_config look whether there is the 'PrintMotd yes', if you still need it.
Ready! Login to server is now immediate :-)
PS. If you login with a key, at the same length RSA key is checked faster than DSA (approximately by 4 times) — you can see the differ even on the modern hardware in the keys from 2048.
To learn more about Svarychevski Michail and his latest projects you can visit his personal site at at http://3.14.by/en/
Vegeu routerOS, concretament:
RouterOS#Evitar_atacs_for.C3.A7a_Bruta_contra_SSH_o_altres_protocols
man ssh man dsh