Nos desplazamos hasta el directorio principal:

cd /opt/google/chrome/

Creamos el directorio ‘plugins’:

sudo mkdir plugins

Creamos un enlace simbólico a los plugins que tenemos ya instalados y que se actualizan vía repositorios.

sudo ln -s /usr/lib/mozilla/plugins/* /opt/google/chrome/plugins

O también puedes hacerlo dirigiéndote al directorio /opt/google/chrome/plugins y desde ahí ejecutar:

sudo ln -s ../../flashplugin-installer/libflashplayer.so

Para activar los plugins, según estés en Gnome o KDE puedes hacer lo siguiente:

• Si estás en Gnome, pulsas ALT+F2, y escribes en el lanzador ‘alacarte‘ y nos dirigimos a: Ejecutar > Menú principal > Internet > Google Chrome > Propiedades > Comando. Y escribimos dejando un espacio respecto a lo anterior: –enable-plugins.
• Si estás en KDE, pulsas ALT+F2, y escribes en el lanzador ‘kmenuedit‘: botón “Ejecutar” > Internet > Google Chrome > pestaña “General” y como hemos hecho en el caso anterior, añadimos: –enable-plugins.

Debería de quedar finalmente una línea como esta:

opt/google/chrome/google-chrome %U --enable-extensions --enable-plugins

Por último, para que los cambios realizados surtan efecto, reiniciamos Gnome o KDE:

killall gnome-panel

Y ya podrás disfrutar de cualquier contenido que requiera flash desde tu navegador.

¿Qué es scp?

Wikipedia

Secure Copy o scp es un medio de transferencia segura de archivos entre un host local y otro remoto, o entre dos hosts remotos.

A diferencia de rcp, scp permite encriptar los datos durante su transferencia, evitando así que cualquier usuario pueda extraer información de nuestro paquete de datos.

¿Cómo empezar a usarlo?

Un vistazo rápido a la página de ayuda sobre scp nos muestra su sintáxis:

scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [
[user@]host1:]file1 [...] [ [user@]host2:]file2

Para comprender la funcionalidad de cada opción, puedes visitar la entrada del manual para scp.

Expongamos unos ejemplos que nos permitan familiarizarnos:

• Copiar un archivo de una máquina remota a una local
  • scp username@remotehost:file.txt /local/directory
• Copiar un archivo de una máquina local a una remota
  • scp file.txt username@remotehost:/remote/directory

• Copiar un archivo de una máquina remota a otra remota
  • scp username@remotehost1:/remote/directory/file.txt \
username@remotehost2:/remote/directory
• Copiar varios archivos de tu máquina local al directorio home de tu máquina remota
  • scp file1.txt file2.txt username@remotehost:~
• Copiar múltiples archivos de una máquina remota a tu directorio actual en la máquina local
  • scp username@remotehost:/remote/directory/\{a,b,c\} .
  • scp username@remotehost:/remote/directory/\{file1.txt,file2.txt\} .

También puedes copiar directorios completos utilizando la opción -r para ello:

• Copiar el directorio ‘etc’ de una máquina local a una remota
  • scp -r /etc username@remotehost:/remote/directory

Los casos que hemos explicado para los ficheros también son aplicables en directorios.

Mejorando el rendimiento de scp

Si has echado un vistazo a las opciones que incluye scp habrás advertido -c y -C. En caso de no ser así, damos una breve explicación:

• -c cypher_spec

Nos permite elegir la técnica de cifrado a usar para encriptar la transferencia de datos. Si estamos usando la versión 1 del protocolo, podemos usar: ‘3des‘, ‘blowfish‘ y ‘des‘. 3Des (triple-des) es una triple encriptación-desencriptación que usa 3 llaves diferentes. Blowfish es un codificador de bloques simétricos, muy seguro y bastante más rápido que 3des. Des únicamente está soportado en aquellos clientes ssh que implemente la versión 1 del protocolo y no disponen de soporte para el cifrado 3des.-

Para la versión 2 del protocolo, tenemos: ‘3des-cbc‘, ‘aes128-cbc‘, ‘aes192-cbc‘, ‘aes256-cbc‘, ‘aes128-ctr‘, ‘aes192-ctr‘, ‘aes256-ctr‘, ‘arcfour128‘, ‘arcfour256‘, ‘arcfour‘, ‘blowfish-cbc‘ y ‘cast128-cbc‘.

• -C

Habilita la compresión de los datos.

Por defecto scp usa 3des para encriptar los datos, si quieres puedes aumentar la velocidad de transferencia utilizando blowfish en su lugar. Esto puedes hacerlo especificando la opción -c blowfish

scp -c blowfish local_file username@remote_host:remote_dir

También puedes comprimir los datos que vayas a enviar, en caso de disponer de una conexión lenta.

scp -c blowfish -C local_file username@remote_host:remote_dir

Wikipedia

En criptografía, se denomina una infraestructura de clave pública a una combinación de hardware, software y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no rechazo de transacciones electrónicas. Para un correcto funcionamiento es necesario que intervengan las siguientes partes:

• Un usuario iniciador de la operación.
• Sistemas servidores que dan ocurrencia de la operación y garantizan la validez de los certificados implicados en la operación.
• Un destinatario de los datos cifrados/firmados/enviados garantizados por parte del usuario iniciador de la operación.

¿Qué objetivo nos marcamos?

El propósito de usar la autentificación mediante claves públicas es sacar el mayor partido posible a SSH mediante el uso de clave privada y pública. De forma que al compartir esta última con el servidor, podamos identificarnos automáticamente, sin necesidad de utilizar el esquema clásico de usuario y contraseña, al que estamos acostumbrados.

¿Qué algoritmos de cifrado usar?

SSH permite usar los algoritmos RSA y DSA, pero… ¿cuál de ellos nos conviene más?

• RSA – Es un algoritmo asimétrico cifrador de bloques, que utiliza una clave pública, la cual se distribuye y otra privada, guardada en secreto por su propietario.Su funcionamiento reside en el uso de expresiones exponenciales dentro de la aritmética modular. Obteniendo una completa seguridad, debido a que aún no se conocen formas óptimas de factorizar  un número grande en sus factores primos utilizando ordenadores personales.El RSA se basa en dos problemas matemáticos: el problema de factorizar números grandes y el problema RSA. El descifrado completo de un texto cifrado con RSA es computacionalmente intratable.
  Por otro lado la factorización de números grandes proponen métodos para longitudes de 600-700 bits de longitud. Y generalmente, las claves RSA usan entre 1024-2048 bits.
• DSA – (Digital Signature Algorithm o Algoritmo Estándar de Firmado) es el algoritmo de firmado digital incluido en el DSS (Digital Signature Standard o Estándar de Firmas Digitales) del NIST Norteamericano. Está basado en el problema de los logaritmos discretos y únicamente puede emplearse para las firmas digitales. A diferencia del RSA, que puede emplearse también para encriptar.La elección de este algoritmo como estándar de firmado generó multitud de críticas puesto que perdía bastante flexibilidad respecto al RSA.

La diferencia entre ambos reside en los tiempos obtenidos para la generación, firmado y comprobación de las claves públicas. Usando este benchmark (podéis usar cualquier IDE con la última versión del JDK) se obtuvieron los siguientes tiempos:

El algoritmo DSA es más rápido para generar la firma que para verificarla, al contrario de lo que sucede con RSA. Por lo que para realizar la autentificación en nuestro servidor SSH usaremos este último.

Además, si comparamos el tamaño de las llaves generadas por ambos algoritmos, comprobaremos cómo las utilizadas por RSA son superiores a las de DSA.

Dicho esto, usaremos RSA.

Configuración del servidor

Comprobamos si el equipo donde tenemos instalado sshd tiene activada la versión 2 del protocolo SSH y que esté habilitada la opción para utilizar claves RSA. Para ello buscamos las siguientes directivas en el fichero /etc/ssh/sshd_config:

Protocol 2
RSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Para cada usuario que vaya a conectarse, debe existir el directorio /home/usuario/.ssh y en él el archivo authorized_keys. En caso de no ser así deberemos crearlo de forma manual y posteriormente iniciar el servidor.

cd ~
mkdir .ssh
touch .ssh/authorized_keys
sudo /etc/init.d/sshd start


Generación de los pares de claves RSA

Como antes comentamos, SSH nos permite generar indistintamente claves RSA o DSA (en nuestro caso usaremos la mencionada en primer lugar), creándose para ambas una clave pública y una clave privada.

Dichas claves, pueden generarse en el propio servidor, en el ordenador cliente, o en cualquier otra máquina.

Al final sólo la clave pública debe aparecer en el fichero .ssh/authorized_keys del servidor al que queremos conectarnos.

El usuario interesado en generar el par de claves usará ssh-keygen. En el proceso, se nos pedirá introducir un passphrase, lo que viene a ser una contraseña para poder generar unas claves más fuertes y seguras.

En nuestro caso, vamos a usarla y a explicar posteriormente como indicarle al sistema que sólo nos la pida una vez por sesión, y no cada vez que nos autentifiquemos en el sistema.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/sebas/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sebas/.ssh/id_rsa.
Your public key has been saved in /home/sebas/.ssh/id_rsa.pub.
The key fingerprint is:
63:de:92:6d:00:fa:d9:17:55:45:ce:bc:25:42:8b:4c sebas@TheWorkstation
The key's randomart image is:
+--[ RSA 2048]----+
| E . .oo|
| o o o + |
| . o + . =|
| . . . . .o|
| . S . . |
| . = * . |
| o = = |
| + |
| |
+-----------------+


El anagrama que produce esta versión de ssh-keygen, se denomina randomart y se trata de una representación visual de la huella

digital de nuestra clave, para que sea más legible para el ojo humano y para dispositivos ópticos.

Si lo deseas, puedes usar la herramienta visprint que a través de técnicas de fractales, te permitirá obtener otro tipo de randomart.

Instalación de clave pública y protección de la clave privada

Para validar todo este proceso es necesario colocar nuestra clave pública en el servidor donde tenemos pensado autentificarnos.

Existen varias posibilidades de hacerlo, una de ellas es por ejemplo hacer uso del siguiente comando (Cliente):

[usuario1@localhost usuario1]$ ssh usuario @host_remoto \'cat >> .ssh/authorized_keys' < .ssh/id_dsa.pub

Con este comando añadimos directamente la clave al fichero authorized_keys del servidor remoto de forma automática, ahorrándonos así un poco de trabajo.

También podemos usar (Cliente):

$ ssh-copy-id usuario_remoto@host_remoto

Pero ya que estamos haciendo todo con paso firme y decidido, continuemos haciendo las cosas con buen pie. Así que vamos a usar el comando scp, que trae incluido OpenSSH para hacer una transacción de ficheros entre el cliente y el servidor remoto de la forma más segura posible. Así que usaremos la siguiente orden (Cliente)

$ cd ~/.ssh
$ scp id_rsa.pub usuario@host_remoto/

Recuerda que la clave pública debe ser incluída en el fichero ~/.ssh/authorized_keys de cada máquina donde queramos usar dicha autentificación.

Ahora que ya tenemos la clave pública en el servidor, falta añadirla al fichero authorized_keys de éste (algo que comentamos anteriormente que se podría conseguir de forma directa utilizando el primer comando) (Servidor).

$ cd ~/.ssh
$ cat id_rsa.pub >> authorized_keys
$ shred -v  --remove id_rsa.pub

Conclusión

Si has realizado correctamente todos los pasos que se han ido indicando, ahora podrás conectarte a tu servidor SSH (Si no tienes uno, visita ésta entrada donde te explicamos cómo montar uno) sin necesidad de identificarte, tan sólo haciendo uso de las claves RSA que has generado.

También puedes incrementar un poco la seguridad modificando las siguientes directivas de tu fichero de configuración sshd_config:

PasswordAuthentication no
PermitRootLogin no

Con las que impedirás la conexión como administrador y la autentificación mediante password para los usuarios.

Conocido como Secure Shell (Intérprete Seguro de Órdenes) es el protocolo usado por excelencia para establecer conexión con máquinas remotas a través de una red.
Ampliamente extendido entre los usuarios, se caracteriza por permitir un control completo del ordenador servidor a través de un intérprete de órdenes o a través de X para ejecutar aplicaciones gráficas en caso de disponer de un servidor corriendo.

¿Por qué SSH?

SSH es un protocolo caracterizado por encriptar todas las conexiones que realiza, imposibilitando a terceros descifrar lo que se escribe durante la sesión, incluido el usuario y la contraseña.

Algo imposible con el protocolo FTP, donde la información viaja en texto plano.

Además, combinando los protocolos scp (Secure Copy) y ssfhs (Secure Shell FileSystem) con SSH conseguiremos una forma robusta e impenetrable de compartir ficheros e información entre equipos remotos.

Conociendo a OpenSSH

OpenSSH es un conjunto de aplicaciones que tiene como objetivo permitir comunicaciones cifradas a través de una red, usando para ello el protocolo SSH comentado anteriormente.

El proyecto está liderado por Theo de Raadt y es una alternativa libre a SSH.

Las aplicaciones que vienen incluidas son:

• ssh – Reemplaza a rlogin y telnet.
• scp – Reemplaza a rcp.
• sftp – Reemplaza a ftp para copiar ficheros entre dos computadoras.
• sshd – Servidor demonio SSH.
• ssh-keygen – Herramienta usada para generar claves RSA y DSA usadas para mejorar la seguridad y autentificar al usuario que establece la conexión.
• ssh-agent | ssh-add -  Herramienta para autentificar de forma más sencilla, sin necesidad de estar continuamente el passhrase usado como clave.
• ssh-keyscan – Escanea una lista de clientes y recoge sus claves públicas.

Clientes SSH

Si decides no usar OpenSSH desde Linux, siempre puedes usar alguna de estas aplicaciones libres:

• OSSH – A diferencia de OpenSSH que añade el protocolo SSH2 y extiende el soporte de SSH1. OSSH únicamente implementa SSH1.
• LSH/psst – Implementación libre del protocolo SSH2, estandarizado actualmente por el grupo de trabajo IETF SECSH.
• Dropbear -  Pequeño servidor SSH2 y cliente. Que funciona bajo varias plataformas basadas en POSIX.

Para Windows, puedes encontrar:

• PuTTY – Implementación del protocolo SSH1+SSH2, posiblemente sea el cliente más extendido y usado entre los usuarios.
• WinSCP – GUI basada en sftp y scp. El núcleo que sustenta su protocolo SSH está basado en PuTTY.
• FileZilla – Potente cliente FTP. Diseñado pensando en la usabilidad y facilidad.

No obstante para este tutorial y los venideros, se usará OpenSSH (Linux)/PuTTY (Windows).

Instalación de OpenSSH

Algunas distribuciones traen instalado por defecto un cliente SSH, no obstante explicaremos como realizarla para un sistema Ubuntu.

Instalando a través de terminal

• Para instalar el cliente:         sudo apt-get install openssh-client
• Para instalar el servidor:       sudo apt-get install openssh-server

Primeros pasos con SSH

• Para iniciar el servidor SSH:              service ssh start
• Para parar el servidor SSH:               service ssh stop
• Para reiniciar el servidor SSH:          service ssh restart

Conectándonos a un servidor remoto (Linux) desde un cliente (Linux)

Primero descubramos qué dirección IP tenemos en el servidor. Para ello desde una ventana de terminal escribimos:

/sbin/ifconfig

Nos aseguramos de que el servicio esté ejecutándose:

service ssh start

Y ahora podemos dirigirnos a nuestro cliente y establecer una conexión remota al equipo que ejerce de servidor. Basta con escribir la siguiente orden en la terminal:

ssh usuario_remoto@host_remoto

Dónde:

• usuario_remoto – Será el nombre de usuario con el que queremos iniciar sesión. Debes tener en cuenta que si no está registrado en el equipo, no podrás iniciar sesión con él.
• host_remoto – Es la dirección del equipo que ejerce como servidor. Ahí es donde pondremos la dirección IP que hemos obtenido antes.

La primera vez que establezcas conexión el sistema nos pedirá confirmación, bastará con decir “yes” y una vez introducida la contraseña correcta para el usuario solicitado, nos encontraremos identificados en el equipo remoto.

Los comandos, programas y scripts que lancemos tras conectarnos se ejecutarán en la máquina remota, utilizando los recursos de esta (CPU, memoria, disco, etc…).

Recuerda que podrás hacer todo aquello que se contemple bajo los permisos que posea el usuario con el que hayas iniciado sesión.

Establezcamos una conexión que nos permita ejecutar aplicaciones gráficas.

Ahora que hemos visto cómo conectarnos y trabajar desde nuestra ventana de terminal, vamos a ir un poco más allá, y vamos a ejecutar aplicaciones gráficas.

Un método bastante efectivo consiste en utilizar un túnel SSH para encapsular el protocolo X11, permitiendo transmitir la información de manera segura y sin crear conflictos con los cortafuegos.

Pero para ello debemos configurar un par de parámetros en el fichero sshd_config:

X11Forwarding    yes
AllowTcpForwarding    yes

Con X11Forwarding especificamos si se permite el reenvío por X11. El valor por defecto es ‘yes’. Desactivarlo en ningún momento ayudará a mejorar la seguridad del servidor.

Y lo que intentamos conseguir activando dicha directiva es permitir ejecutar aplicaciones gráficas en el servidor remoto. Recordad que X es un sistema de ventanas creado para dotar de interfaz gráfica a los sistemas Unix.

Por otro lado con AllowTcpForwarding especificamos si se permite el reenvío a través del protocolo TCP. Al igual que pasaba con X11, desactivarlo, en ningún momento proveerá mayor seguridad a nuestro servidor. Su valor por defecto es ‘yes’.

Una vez hecho esto, ya podemos iniciar una sesión SSH y ejecutar aplicaciones gráficas. Para ello bastará con escribir en nuestra terminal:

ssh -X -Y usuario_remoto@host_remota

• -X (X11 forwarding)
• -Y (X11 trusted forwarding)

Ahora podremos ejecutar cualquier aplicación que se encuentre instalada en el servidor. Reproduzcamos una película con mplayer por ejemplo:

mplayer nombre_película

Recuerda que los recursos se tomarán del equipo donde te encuentres conectado.