Administración gráfica remota con FreeNX

FreeNX es una nueva aplicación cliente/servidor que permite acceder al escritorio GNU/Linux de forma remota al estilo de VNC pero con un método muchísimo más eficiente. VNC traspasa imagenes comprimidas del escritorio remoto, sin embargo FreeNX baja un nivel más y comprime directamente el protocolo de las X, de esta forma se consigue un rendimiento espectacular.

El programa ha sido desarrollado por la empresa NoMachine y ha sido liberado bajo la licencia GPL.

Lo he probado en diversos escenarios y en todos me ha sorprendido:

  1. Servidor GNU/Linux en LAN a 100 Mbps: Es posible trabajar con la máquina remota con total comodidad
  2. Servidor GNU/Linux en ADSL 512Kbps/128Kbps: El rendimiento es inferior al anterior pero se sigue podiendo trabajar comodamente, supera con creces VNC.

Se debe tener en cuenta que FreeNX trabaja utilizando el servicio SSH y por tanto toda la identificación y la comunicación es encriptada, con VNC no lo tenemos de forma nativa y hay que hacer túneles SSH lo que hace inusable el acceso en redes lentas como Internet.

El único posible inconveniente de FreeNX es que no permite acceder al escritorio actual del usuario que este trabajando fisicamente con el servidor (con VNC se puede conseguir usando gemsvnc, x11vnc o vino), pero como ventajas podemos acceder al escritorio de cualquier usuario y suspender la aplicación de forma que en una siguiente conexión recuperemos el estado del escritorio tal y como lo dejamos.

En definitiva estoy encantado con el programa dado que con mi conexión ADSL solo tengo 128 Kbps de subida y el servidor VNC no era muy usable, sin embargo con FreeNX puedo acceder remotamente a mi escritorio (incluso a pantalla completa) sin problemas y con poco retardo.

Para instalar en Ubuntu:

  1. Añadir a “/etc/apt/sources.list”:
    deb http://www.kalyxo.org/debian/ experimental main
    
  2. Actualizar el listado de aplicaciones: “aptitude update”
  3. Es importante disponer ya de un servidor SSH activo, en Ubuntu se instala con “aptitude install openssh-server” y se guardan los archivos de configuración en “/etc/sshd/”. La configuración por defecto suele funcionar y automáticamente en la instalación se activará el servidor. Para probar su funcionamiento podemos usar “ssh usuario@localhost” o “ssh usuario@ip_maquina” si lo hacemos remotamente. Es importante que el firewall (en caso de disponer de uno) del servidor tenga abierto el puerto 22 para poder establecer conexiones SSH y en consecuencia, FreeNX.
  4. Instalar el servidor “aptitude install freenx” y el cliente “aptitude install nxclient” en diferentes máquinas (existen clientes para MS Windows en la página de NoMachine)
  5. Comentar la línea que añadimos a “/etc/apt/sources.list”, es importante no hacer una actualización del sistema (aptitude dist-upgrade/upgrade) con este repositorio activado ya que se nos instalarán programas que no corresponden a Ubuntu. Este repositorio solo lo usamos para instalar FreeNX, nada más.
  6. Actualizar de nuevo el listado de aplicaciones con “aptitude update”
  7. Configurar el servidor, tenemos 2 opciones:
    1. Utilizar la clave SSH por defecto de NX, con esto no tendremos que facilitar ninguna clave a nuestros clientes (aunque seguirá siendo necesario el login/password), esta opción es menos segura ya que estamos permitiendo a cualquiera poder conectarse al servidor NX aunque después se encontrará con la barrera del login/password, sin embargo resulta más sencillo de configurar el acceso de los clientes. Para usar esta vía: “nxsetup –setup-nomachine-key”.
    2. Generar una clave SSH nueva, esta tendrá que ser repartida a todos los clientes que deseen conectarse. Para usar esta vía: “nxsetup”. La clave se guarda en el directorio del usuario “nx”, en Ubuntu será en “/home/.nx/.ssh/”, debemos copiarla (“client.id_dsa.key”) a “/usr/NX/share” (o el directorio donde hayamos instalado en MS Windows) de todos los clientes (si ya existe una, reemplazarla o renombrarla).
  8. A partir de ahora el servicio NX se activará automaticamente en cada arranque, para pararlo se usa “nxserver –stop” y para volverlo a poner en marcha “nxserver –start”.

Para acceder con el cliente:

  1. Ejecutamos “nxclient” o “nxclient –wizard”. Pulsamos Next.
  2. Le damos un nombre a la sesión, indicamos la máquina a la que queremos conectarnos y el tipo de conexión que tenemos (ADSL, LAN…). Pulsamos Next.
  3. Seleccionamos que la conexión será a un UNIX con GNOME y especificamos la resolución con la que queremos que arranque, por ejemplo 1024×768. Activamos la encriptación SSL, así solo es necario que tengamos acceso al puerto 22 de la máquina remota. Pulsamos Next.
  4. Dejamos marcado la creación de un icono en el escritorio y pulsamos Finish.
  5. Ahora ya podemos conectarnos a la máquina remota indicando nuestro login y password

Autor: marble

Posted in Internet | 4 Comments

Desligar un proceso de una terminal

Cuando creamos un proceso en una terminal, éste queda ligado a la terminal como “hijo”. Si la terminal muere, también lo hace el proceso. Para evitar ésto, si estamos en una terminal de escritorio (que es donde más se utiliza) podemos cerrar la terminal con el comando:

exit

y no cerrando la ventana. Ésta es una de las formas que conozco, no sé si pasa lo mismo en las otras terminales que no sean gnome-terminal.

La otra forma, que es la “forma Unix” es con el comando:

disown

Si no le pasamos parámetros, cogerá el último proceso creado. También podemos pasarle como parámetro el PID del proceso si tenemos muchos. O pasarle estas opciones:

Desliga a todos los procesos ejecutados desde la terminal

disown -a

Desliga a todos los procesos ejecutados desde la terminal que esten en marcha (Running).

disown -r

Si os fijais, ejecutando el comando “jobs” vereis en todo momento los procesos que han sido ejecutados en la terminal. Si desligais un proceso desaparece del listado de “jobs”. Para que el proceso se desligue de la terminal pero no se elimine de la lista de jobs podemos pasarle el parámetro -h al disown:

disown -h

Es un comando muy poco conocido y bastante útil. La entrada original de este artículo la puse en mi blog, pero creo que llegará a más gente desde aquí 🙂
Autor: jBilbo

Posted in Linux | Leave a comment

Libreta de direcciones compartida con OpenLDAP

LDAP (Lightweight Directory Access Protocol) es un protocolo de acceso a servicios de directorio. Un directorio es similar a una base de datos pero con información basada en atributos que no cambia frecuentemente y sobre la cual no es necesario hacer consultas complejas. En un directorio la lectura de información es muy rápida.

La información de un directorio puede ser almacenada de diversas formas (backends), lo importante es que con LDAP podemos acceder a dicha información e incluso mantener servidores secundarios con replicas que se actualizan periodicamente (así podriamos equilibrar la carga del servicio).

LDAP podría cubrir perfectamente funciones muy útiles en una intranet como por ejemplo identificación de usuario centralizada (antiguamente se utilizaba NIS en entornos UNIX pero es menos seguro y eficiente), así los usuarios podrian acceder a diversos servicios con un único login/password y la gestión de los mismos sería muchisimo más sencilla para los administradores. También podria proporcionarnos un servició de libreta de direcciones centralizado de forma que desde varios PCs podamos acceder siempre a nuestra agenda de contactos, esto será lo que explicaré en este artículo.

Continue reading

Posted in Internet | 1 Comment

Entidad certificadora personal con OpenSSL

Gracias a OpenSSL podemos tener comunicación encriptadas entre diferentes máquinas utilizando criptología asimetrica, es decir, claves públicas y privadas. Además, es posible montar entidades certificadoras que se encarguen de asegurar que una llave pertenece a quien dice pertenecer, de esta forma conseguimos encriptación y autentificación.

Las entidades certificadoras actuales cobrán por el servicio de firma de llaves y no suele ser precisamente asequible. Por otro lado, montar una entidad certificadora oficial también resulta muy costoso ya que se demandan unas ciertas garantias que destrás del negocio hay una cierta seguridad. Por tanto, es habitual que los administradores de pequeñas redes se creen su propios certificados para firmar sus claves. De esta forma podremos disponer de comunicaciones encriptadas sin necesidad de entidades certificadoras.

Estas entidades oficiales pagan para que aparezcan por defecto sus certificados en navegadores como Mozilla Firefox o Internet Explorer. De esta forma el propio navegador puede comprobar automáticamente que cuando se conecta a un sitio seguro, el certificado que recibe ha sido realmente firmado por una entidad oficial. Eso implica que nuestros certificados no serán reconocidos automáticamente por los navegadores a no ser que los añadamos manualmente, el único inconveniente que aporta esto es que el navegador mostrará un aviso extra al usuario (dependiendo de la configuración) advirtiendo que no reconoce la entidad certificadora.

Vamos a ver como configurar OpenSSL para montar nuestro servicio de certificación personal. Lo primero es tener OpenSSL instalado en el sistema (aptitude install openssl), la configuración la encontraremos en “/etc/ssl” y será allí donde editemos el fichero “openssl.cnf”. Os pongo un extracto del archivo con lo más importante:

...

[ ca ]
default_ca  = CA_default

[ CA_default ]
dir     = /etc/ssl/marblestationCA  # Where everything is kept
certs       = $dir/certs  # Where the issued certs are kept
crl_dir     = $dir/crl  # Where the issued crl are kept
database    = $dir/index.txt  # database index file.
new_certs_dir   = $dir/newcerts     # default place for new certs

certificate = $dir/MSca.crt     # The CA certificate
serial      = $dir/serial       # The current serial number
crl     = $dir/crl.pem      # The current CR

private_key = $dir/private/MSca.key # The private key

default_days    = 3650

...

En esta sección del fichero se define donde se va a almacenar toda la información, en mi caso lo guardaré todo en “/etc/ssl/marblestationCA”. Dentro de ese directorio creare toda una serie de subdirectorios que guardaran la información necesaria e imprescindible como por ejemplo el certificado o clave de la entidad (tanto privada como pública). También he puesto que por defecto se generen claves con un periodo de caducidad de 10 años ya que quiero olvidarme de renovar por una buena temporada.

Tendremos que crear la estructura de directorios y ficheros:

mkdir /etc/ssl/marblestationCA/
mkdir /etc/ssl/marblestationCA/certs
mkdir /etc/ssl/marblestationCA/private
mkdir /etc/ssl/marblestationCA/newcerts
mkdir /etc/ssl/marblestationCA/crl
echo "01" > /etc/ssl/marblestationCA/serial
touch /etc/ssl/marblestationCA/index.txt

A continuación crearemos la clave pública/privada de nuestra entidad certificadora:

cd /etc/ssl/marblestationCA/
openssl req -nodes -new -x509 -keyout private/MSca.key -out MSca.crt -days 3650

Es importante especificar el mismo nombre para la clave privada (MSca.key) y pública (MSca.crt) que pusimos en nuestra configuración de OpenSSL. En cuanto a las preguntas que nos haga para generar la clave:

Country Name (2 letter code) [ES]:
State or Province Name (full name) [Catalunya]:
Locality Name (eg, city) []:Tarragona
Organization Name (eg, company) [Marble Station]:
Organizational Unit Name (eg, section) []:Ejemplo
Common Name (eg, YOUR name) []:midominio.com
Email Address []:admin@midominio.com

Cabe destacar que en “Common Name” debemos poner el nombre de dominio correspondiente a la máquina donde estará la entidad certificadora.

Ahora ya tenemos nuestro servicio de certificaciones montado, las claves que hemos generado nos serviran para firmar terceras claves que serán utilizadas por ejemplo por los diferentes ordenadores de nuestra red.

Imaginemos que en el mismo servidor donde hemos montado nuestros certificados para firmar, tenemos un servidor web Apache seguro (SSL) y necesitamos un certificado firmado por nuestra entidad personal. Lo primero que tendremos que hacer será crear una petición de certificado junto a una clave privada:

openssl req -nodes -new -keyout midominio.key -out midominio.csr

Nos volverá a realizar las respectivas preguntas, debemos responder acorde para la máquina donde se va a utilizar la clave. En “midominio.key” tendremos la clave privada generada y en “midominio.csr” la petición de certificado. La entidad certificadora solo necesita acceso al segundo, vamos a generar ahora el certificado firmado por nuestra entidad personal:

openssl ca -out midominio.crt -in midominio.csr

Esto generará el archivo “midominio.crt” con el certificado firmado listo para ser usado por el solicitante. Además se guardará información referente al certificado firmado en “/etc/ssl/marblestationCA/” de forma que siempre tendremos un listado de todo lo que hemos firmado, también podremos revocar firmas (man openssl) en caso de que sea necesario.

Como comenté, ibamos a utilizarlo para nuestro servidor Apache pero también podria ser compartido por otros servicios en la misma máquina, como por ejemplo un servicio de POP3/IMAP (recomiendo dovecot) y SMTP (recomiendo exim). Es importante asegurarnos que estas aplicaciones tengan acceso de lectura al certificado y que el resto de usuarios del sistema no puedan leerlo (sobretodo la llave privada .key).

Habitualmente suelo ubicar los certificados de servicios en /etc/ssl/certs y /etc/ssl/private de la máquina que los vaya a usar:

mv midominio.crt /etc/ssl/certs
mv midominio.key /etc/ssl/private

La petición de certificado midominio.csr no lo vamos a necesitar más puesto que ya hemos generado el certificado.

Ahora podriamos seguir generando nuevos certificados para después firmarlos y repartirlos entre las máquinas de nuestra red que dispongan de servicios con conexión segura.

En resumen, hemos llevado a cabo dos acciones:

  1. Generación de los certificados de nuestra entidad certificadora no oficial (clave pública “MSca.crt” y clave privada “MSca.key”), se guardará toda la información en “/etc/ssl/marblestationCA/”
  2. Generación de certificados firmados para los servicios o máquinas de nuestra red, se guardará automáticamente la información necesaria en “/etc/ssl/marblestationCA/” y la clave pública/certificado firmado se guardarán en la máquina que los vaya a usar (“/etc/ssl/certs”, “/etc/ssl/private” respectivamente):
    1. Generación de una clave privada (midominio.key) con peticion de certificado (midominio.csr).
    2. Firma de la petición con nuestro certificado de entidad.
    3. El solicitante recibirá su certificado firmado (midominio.crt) que usará en conjunto con su clave privada para su servicio (podremos eliminar la petición midominio.csr).

Autor: marble

Posted in Seguretat | 4 Comments

la vida

la vida es muy bella y hay que saberla aprovechary no dejar pasar las cosas sino hacerlas con mucho gusto y que la pases bien con lo que haces y con lo que eres este consejo les doy ha mis buenos amigos
Autor:

Posted in Cultura | Leave a comment