Apache Tunning (y II). Ajustando el parámetro MaxClients

Josemaría | 24 de febrero de 2013 | 3 comentarios

apache Como ya habíamos hablado por aquí, uno de los parámetros críticos en un servidor Apache es MaxClients, el número máximo de conexiones que es capaz de manejar simultaneamente. Es crítico porque cada tarea de Apache consume una determinada cantidad de memoria y si la suma de la memoria que consumen todos de forma simultanea es mayor que la memoria RAM que la máquina tiene libre comenzará a hacer swapping a disco y, si esta situación se mantiene, corremos un riesgo importante de que se nos quede virtualmente congelada. Una instalación de Apache por defecto toma un valor de 150 para este parámetro y esto es una verdadera burrada para casi cualquier servidor web con menos de 1 Gbytes (o incluso con bastante mas) que use contenidos dinámicos medianamente pesados.

Hace bien poco, buscando por ahí algún enlace para profundizar un poco más en estos temas, me encontré con este artículo de una empresa de hosting donde te proponen un script para ajustar el valor más adecuado a tus necesidades. Había dos cosas que no me gustaban en él script propuesto. Por un lado, tomaban el valor más conservador, es decir, el resultante de dividir la memoria libre entre lo que ocupa el proceso de Apache mayor. En segundo lugar, hacen el cálculo de la memoria libre sin tener en cuenta la que está ocupada por cache o buffers y que podría liberarse en caso de necesidad. Yo le he hecho algunos cambios para salvar ambos puntos y dejarlo un poco más bonito e informativo y me ha salido esto:

#!/bin/bash
clear

# Primero analizamos los procesos de apache funcionando actualmente
LISTA=`ps -aylC apache2 |grep apache2 |awk '{print $8'} |sort -n`

echo "Lista ordenada de la memoria, en bytes, ocupada por los procesos de Apache corriendo en este momento:"
COUNT=0
SUMA=0
for ITEM in $LISTA
do
        COUNT=`expr $COUNT + 1`
        SUMA=`expr $SUMA + $ITEM`
        echo "$COUNT -> $ITEM"
        if [ $COUNT -eq 1 ]
        then
                MENOR=$ITEM
        fi
done

MAYOR=$ITEM
MEDIA=`expr $SUMA / $COUNT`

# Pasamos las cantidades a Kbytes
MENOR=`expr $MENOR / 1024`
MAYOR=`expr $MAYOR / 1024`
MEDIA=`expr $MEDIA / 1024`

echo "El proceso de Apache más grande ocupa" $MAYOR "Kbytes y el menor" $MENOR "Kbytes"
echo "La media de la memoria ocupada por un proceso es de $MEDIA Kbytes"

echo "Detenemos Apache..."
apache2ctl graceful-stop > /dev/null

# Limpiamos los caches y buffers del servidor
sync
echo 3 > /proc/sys/vm/drop_caches

# Calculamos la memoria libre del sistema
FREEMEM=`free -m |head -n 2 |tail -n 1 |awk '{free=($4); print free}'`
echo "La memoria libre del servidor, después de liberar cache y buffers, es de $FREEMEM Kbytes"

echo "Arrancamos Apache de nuevo..."
apache2ctl start > /dev/null

echo "MaxClients debería de estar entre" `expr $FREEMEM / $MAYOR` "y" `expr $FREEMEM / $MENOR`
echo "Usando el valor medio de la memoria ocupada, un valor recomendable de MaxClients sería de" `expr $FREEMEM / $MEDIA`

El script de aquí arriba imprime una lista de la memoria ocupada por todos procesos de Apache activos en el momento de ejecutarlo. Luego toma el mayor, el menor y la media de todos ellos y calcula la memoria libre del sistema. Para ello, antes detiene Apache (con un graceful-stop para no fastidiar a nadie que esté viendo nuestra web en ese momento) y libera los buffers y caches de memoria. Por último, arranca de nuevo Apache y nos da como salida dos valores: una horquilla entre el valor que debería de tomar MaxClient usando el menor y el mayor valor de los procesos tomados en la instantánea anterior y un valor recomendado que sale de usar el valor medio de todos ellos.

Evidentemente no se trata de algo matemático. Como es lógico, ejecutado en diferentes momentos obtendremos valores distintos ya que ni la RAM que usa nuestro servidor es inmutable ni el tamaño de los procesos de Apache es siempre el mismo ni siguen la misma distribución. Pero para darnos una primera idea del valor con el que tenemos que empezar a jugar creo que es bastante válido. Ya me contáis.

NOTA: En algunas instantáneas el valor de memoria ocupado por el proceso más pequeño de Apache puede ser cero, seguramente porque o está creándose o está destruyéndose en ese momento. En ese caso el valor de la horquilla pierde uno de sus extremos. Sería muy fácil modificar el script para que en ese caso tome el segundo valor y divida por un elemento menos, pero ocurre en tan pocas ocasiones que no creo que merezca la pena hacerlo. Al menos no hoy ;-)


Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Android Apps (y I): ConnectBot

Josemaría | 14 de septiembre de 2012 | Comentar

android Una de las primeras cosas que un administrador de sistemas (de “los de verdad”, no de los que trabajan con Windows, que a esos no les sirve de nada ;-) ) se plantea instalarse en su android es, si o si, un emulador de terminal. ConnectBot admite conexiones ssh y telnet (o locales contra el propio android donde está instalado). Ocupa muy poca memoria (apenas 650KBytes con los datos de conexión de varias máquinas) y aprovecha muy bien la pantalla tanto en vertical como en apaisado. Ambas cosas son indispensables para quién, como yo, tiene un terminal barato de gama baja. Es capaz de mantener varias sesiones abiertas de forma simultanea con diferentes máquinas y soporta copy/paste. Además, es software libre y los fuentes están disponibles en Google Code.

Ejecutando htop en connectbot con un htc wildfire s

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Paquetes RPM, archivos .repo y yum

Josemaría | 6 de enero de 2012 | 1 comentario

herramientasLejos han quedado ya los tiempos en que se usaba la expresión “infierno de las dependencias” o que había que ir por ahí buscando herramientas de terceros o recurrir a rebuscados trucos para gestionar instalaciones y actualizaciones en una distribución Linux con paquetes rpm. Hoy en día la combinación rpm/yum de Fedora, Red Hat, CentOS y otras derivadas tiene poco (o nada) que envidiarle a la pareja dpkg/apt-get de Debian & co. En esta entradilla vamos a dar un pequeño repaso a las opciones más comunes y a alguna de las más útiles.

Para empezar, los comandos usados más frecuentemente son estos:

 
                         Comando                         
Actualizar completamente el sistema. Las opciones --skip-broken --nogpgcheck y --assumeyes (o simplemente -y) son útilesyum update
Tratar de instalar o actualizar un paquete de un fichero local (no lo hace si faltan dependencias)rpm -Uvh fichero.rpm
Instalar un paquete de un fichero local resolviendo las dependencias necesariasyum localinstal fichero.rpm
Instalar un paquete de los repositorios y resolver las dependencias necesariasyum install nombre_paquete
Tratar de eliminar un paquete (no lo hace si hay otros que dependen de él)rpm -e nombre_paquete
Eliminar un paquete y todos los que dependan de él (pedirá confirmación)yum remove nombre_paquete

En un gran porcentaje de casos esto es todo lo que debemos conocer de ambos y lo que tendremos que usar de forma habitual. Pero existen muchas otras opciones útiles y/o interesantes:

 
                         Comando                         
Realiza un "downgrade" del paquete en fichero.rpmrpm -Uvh --oldpackage fichero.rpm
Idem que el anterior, pero usando yumyum dowgrade nombre_paquete
Lista las dependencias necesarias para el paqueterpm -qpR fichero.rpm
Lista todos los ficheros (y su ubicación) que se han instalado con el paqueterpm -ql nombre_paquete
Nos indica el paquete del que ha salido el fichero indicadorpm -qf nombre_fichero
Busca paquetes cuyo nombre sea total o parcialmente el indicadoyum search nombre
Busca el o los paquetes que proporcionan el fichero indicado. Muy útil cuando necesitamos determinada librería.yum whatprovides nombre_fichero
Busca el paquete indicado (admite comodines en el nombre) y nos dice si está instalado o no y otros datos.yum list nombre_paquete
Muestra el historial de uso reciente de yumyum history

Cuando queremos instalar un equipo con exactamente los mismos paquetes que otro dado, tenemos la posibilidad de crear una lista de paquetes instalados con el siguiente comando:

rpm -qa lista_paquetes.txt

Para luego instalarlos en la segunda máquina de esta forma que nos cuentan en Unixcraft:

sudo yum -y install $(cat paquetes.txt)

Para otras posibilidades, tienes buenas referencias aquí para yum y aquí y aquí para rpm (pero con cuidado, que he visto algunos ejemplos que usan opciones que ya no están disponibles, como --repackage) o, por supuesto, en las páginas del manual de cada una de ellas.

Además, yum cuenta con un amplio repertorio de plugins que le permiten mejorar u optimizar su trabajo. Puedes ver la lista de la que dispones en tus repositorios con alguno de los comandos que acabas de aprender (yum list yum-plugin* o yum search yum-plugin funcionarían). Aparte de los que vienen cargados con Fedora por defecto, estos son los que considero imprescindibles:

Y nos falta aún por ver la forma de indicarle al sistema donde están los repositorios de software, o sea, el equivalente al archivo /etc/apt/sources.list de los Debian. Esto se hace en archivos con extensión .repo que deben de crearse en el directorio /etc/yum.repos.d. Lo normal es crear un archivo por cada repositorio o familia de estos. Aquí tenemos también diferentes opciones de personalización. Veamos un ejemplo:

[kde-testing]
name=kde-testing
# baseurl=http://ftp.heanet.ie/pub/kde-redhat/fedora/$releasever/$basearch/testing
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-testing
enabled=1
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
gpgcheck=1
skip_if_unavailable=1

En las páginas del manual de yum.conf (el archivo de configuración de esta herramienta) tienes explicadas estas opciones y otras muchas bajo el epígrafe de repository options.

Y para el que prefiera una utilidad gráfica y, como a mi, no le entusiasme KPackagekit (apper desde fedora 16), puede echarle un vistazo a yumex (mi favorito) o a smart.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

CLI (Command Line Interface) en Routers y Switches CISCO

Josemaría | 10 de noviembre de 2011 | 2 comentarios

textos y apuntesEl siguiente documento es una recopilación en un archivo único de los apuntes que di a lo largo de todo el curso pasado a mis alumnos del módulo de Redes de Área Local (Ciclo Formativo de Sistemas Microinformáticos y Redes) sobre configuración y administración de routers y switches de CISCO usando el Command Line Interface o CLI. Abarca desde una configuración básica de los mismos hasta configuración de protocolos de rutado dinámico, creación de VLANs y algunas nociones muy básicas de seguridad. Ahí queda por si a alguien le viene bien:

Descargar “CLI en Routers y Switches Cisco”

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Chuletillas (y XXXII) – systemctl, una más de servicios en Fedora

Josemaría | 7 de noviembre de 2011 | 3 comentarios

chuleta A partir de la anterior Fedora 15 se introdujo systemd como system y session manager. El cambio fue tan “transparente” que yo ni me enteré de ello. Sin embargo desde el momento en que instalé la beta de Fedora 16, hace ya algo más de un mes, empecé a notar que pasaban cosas raras en mi equipo… Había servicios que no me aparecían activos en el arranque y que no respondían igual a los comandos y herramientas que vimos en una chuletilla anterior.

Los nuevos servicios de Fedora ya no se encuentran en /etc/init.d (aunque alguno queda aún ahí imagino que por compatibilidad) sino que están en el directorio /lib/systemd/system y para interactuar con ellos en línea de comando ya no usamos el comando service, sino systemctl.

systemctl es un comando mucho más rico en opciones y posibilidades que su predeceror, pero como guía de inicio y emergencia, te conviene ir anotando las siguientes.

Para iniciar un servicio, por ejemplo sendmail:

$ sudo systemctl start sendmail.service

Los servicios ahora parecen tener todos ese formato terminado en “.service”. Aparte de start tenemos las opciones clásicas: stop, restart, reload y status. La opción status da mucha más información de lo que teníamos anteriormente:

$ sudo systemctl status vboxdrv.service

          vboxdrv.service - LSB: VirtualBox Linux kernel module
          Loaded: loaded (/etc/rc.d/init.d/vboxdrv)
          Active: active (exited) since Mon, 07 Nov 2011 18:45:22 +0100; 3s ago
         Process: 5550 ExecStop=/etc/rc.d/init.d/vboxdrv stop (code=exited, status=0/SUCCESS)
         Process: 5572 ExecStart=/etc/rc.d/init.d/vboxdrv start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/vboxdrv.service

Por último, para habilitar el inicio automático de un servicio en el arranque o para deshabilitarlo, respectivamente, tenemos las opciones enable y disable:

$ sudo systemctl enable cups.service

ln -s '/lib/systemd/system/cups.service' '/etc/systemd/system/printer.target.wants/cups.service'
ln -s '/lib/systemd/system/cups.socket' '/etc/systemd/system/sockets.target.wants/cups.socket'
ln -s '/lib/systemd/system/cups.path' '/etc/systemd/system/multi-user.target.wants/cups.path'
$ sudo systemctl disable cups.service

rm '/etc/systemd/system/sockets.target.wants/cups.socket'
rm '/etc/systemd/system/printer.target.wants/cups.service'
rm '/etc/systemd/system/multi-user.target.wants/cups.path'

Quién quiera saber algo más de las novedades y mejoras que aporta systemd, puede empezar por esta serie de cuatro artículos que Diego Calleja ha escrito durante el último año:

  1. systemd, otro reemplazo de init
  2. Novedades en systemd
  3. Novedades en systemd, II
  4. Novedades en systemd, III

Y quien quiera experimentar con más opciones de systemctl, ya sabe: man systemctl ;-)

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Chuletillas (y XXX) – Gestionar daemons (o servicios) en el arranque de Fedora

Josemaría | 12 de marzo de 2011 | 1 comentario

chuleta Los daemons (o servicios según la terminología más popular acuñada por los entornos windows) son aquellos programas que se ejecutan en nuestro ordenador en segundo plano y, habitualmente, desde el arranque del mismo, permaneciendo a la espera de prestar algún servicio. Normalmente nos incomoda tener que ejecutarlos manualmente cuando no están activos, pero una mala elección de los servicios que se ejecutan en el arranque de la máquina ocasiona que nuestro ordenador consuma unos recursos que no precisa o que tenga un arranque más lento de lo que nos gusta.

Hoy vamos a ver la forma de gestionar los daemons en Fedora y, sin que sirva de precedente, vamos a empezar por los métodos gráficos para que los más comodones no tengan que leer el texto hasta el final. En el menú de administración tenemos un programita denominado Administración de Servicios (ejecutable también con la orden system-config-services).

system-config-services en Fedora 14

La pantalla es bastante intuitiva. Los dos iconos delante del nombre de cada servicio nos indican si está habilitado su arranque de forma automático al inicio y si está ejecutándose en estos momentos. Podemos manipular estos parámetros con los botones Enable/Disable y Start/Stop respectivamente. Mediante el botón Customize podemos ajustar los niveles de ejecución (o runlevels) particulares para los que queremos que el servicio se inicie. En la mayoría de los casos nos basta saber que el terminal gráfico con el que trabajamos habitualmente se corresponde con el nivel 5 y el modo de texto multiusuario con soporte de red corresponde con el nivel 3 (el nivel 5 se define en realidad como el nivel 3 con las X).

ntsysv es una pequeña aplicación que nos permite hacer lo mismo desde la línea de comandos pero con la comodidad de usar un rudimentario interfaz gráfico construido con las ncurses.

ntsysv en Fedora 14

Se ejecuta con privilegios de root y por defecto nos muestra y permite modificar los servicios que se inician en el arranque del nivel de ejecución en el que nos encontramos cuando usamos la herramienta. Si quisiéramos consultar o modificar el inicio en otro runlevel lo indicaremos con el parámetro --level (ntsysv --level 5, por ejemplo). Los servicios se marcan y desmarcan usando la barra de espacios. Si seleccionamos un servicio este se iniciará inmediatamente y, además, lo hará a partir de este momento en cada arranque. Si lo deseleccionamos y estaba activo se parará también de forma instantánea.

chkconfig es, tal vez, la herramienta más versátil para esta tarea. Además de darnos información y permitirnos modificar el arranque y parada de los servicios en sus diferentes runlevels, nos permite añadir o eliminar servicios. Algunas ejemplos útiles son los siguientes:

Mediante los parámetros --add y --del podemos incluir nuevos servicios o eliminar los existentes, pero piensa al añadir uno nuevo que no puedes hacerlo con cualquier programa. Si este no cumple con los requisitos indispensables chkconfig te devolverá un error.

El comando service es el último que vamos a ver. Este nos permite detener o iniciar cualquiera de los servicios y, en algunos casos, reiniciarlos o ver su estado. Cualquiera de nuestros servicios debería de responder correctamente, al menos, a los siguientes comandos:

Habitualmente pueden responder, además, a alguna de las órdenes siguientes:

NOTA: Los usuarios de Ubuntu tienen disponible chkconfig (aunque no viene instalado por defecto con la distribución) y service.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Chuletillas (y XXIX) ?? Captura de pantalla de las X desde la shell

Josemaría | 3 de febrero de 2011 | 3 comentarios

chuleta Existen muchas ocasiones en las que nos interesa obtener un volcado de la pantalla de nuestros Linux desde la línea de comandos y si has llegado hasta aquí haciendo una búsqueda es que tienes alguna de ellas en la cabeza. La mejor forma de hacerlo es usar el comando xwd:

xwd -root | convert xwd:- pantallazo.png

Si quisiéramos realizar un volcado automático a intervalos regulares podríamos, de forma burda, (nunca he sido muy elegante haciendo scripts, para que engañarnos) hacer algo como esto:

#!/bin/sh
number=$(ls pantallazo* | wc -l)
file=pantallazo_$number.png
xwd -root | convert xwd:- $file

Y ya está. Ahora sólo tendríamos que programar la ejecución de este scritpt mediante cron con la regularidad que deseemos.

NOTA: La salida de xwd la convertimos a formato png mediante el comando convert perteneciente a las librerías de ImageMagick que, por tanto, deberían de estar instaladas en nuestro sistema.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes
Categorías: chuletillas, línea de comandos
Etiquetas:

Chuletillas (y XXII) – Montar un servicio FTP sobre un directorio local

Josemaría | 4 de febrero de 2010 | 1 comentario

chuleta Mi servicio de hosting me proporciona casi 1000 Gbytes de espacio en disco (750 de base más algunos extras por referencias) de los que estoy usando unos 800 Mbytes y cerca de 120 GBytes de transferencia diaria de la que apenas aprovecho un par ¿Por qué no usar estos recursos extra para hacer backups incrementales de mis datos locales? Yo uso para este fin un sencillo script que usa rdiff-backup el cual me permite conexión con una máquina remota a través de ssh, pero no de ftp. Y mi hosting no me da conexión por ssh. Una solución sencilla a esto podría ser montar mi servidor ftp sobre un directorio local usando FUSE y, a partir de ahí, usar mi script de la forma habitual.

Para seguir esta chuletilla necesitas tener instalado curlftpfs, una utilidad que permite el uso de curl sobre FUSE disponible entre los paquetes estables tanto de Fedora como de Ubuntu y de Debian. Una vez instalado, sólo debes de ejecutar lo siguiente con privilegios de root:

# curlftpfs -o allow_other ftp://user:pass@ftp.server.com /mnt/ftp

Donde user y pass son los datos de tu cuenta de ftp, ftp.server.com el nombre de tu servidor ftp y /mnt/ftp el directorio local donde quieres montarlo. Fácil ¿verdad? Bueno, vamos a mejorarlo un poco…

Si queremos que el montaje se realice de forma más cómoda, sólo tenemos que incluir esta línea en nuestro fichero /etc/fstab:

curlftpfs#user:pass@ftp.server.com /mnt/ftp fuse allow_other,rw,user,noauto 0 0

El directorio no se montará de forma automática en el arranque del sistema como el resto de las unidades (gracias al parámetro noauto) pero a partir de ahora montarlo y desmontarlo será tan fácil como ejecutar mount /mnt/ftp o umount /mnt/ftp respectivamente.

Por último, si nos preocupa que el usuario y la contraseña de nuestra cuenta de ftp sea visible dentro de un archivo legible por todos los usuarios del sistema (o, también, visualizando la lista de procesos en ejecución) podemos guardar estos datos en un fichero llamado .netrc dentro del directorio del usuario root. El formato del fichero sería este:

machine ftp.server.com
login user
password pass

Y ahora la línea en nuestro fichero fstab quedaría así

curlftpfs#ftp.server.com /mnt/ftp fuse allow_other,rw,user,noauto 0 0

Dos apuntes finales. Recuerda que tus datos viajarán en claro a través de la red, así que si guardas información especialmente sensible procura cifrarla antes y trata de usar en todo momento la línea de comandos para acceder a esta nueva unidad. La utilidades gráficas no son eficientes para este tipo de accesos.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Chuletillas (y XI) – Resolver dependencias circulares con rpm

Josemaría | 9 de marzo de 2009 | Comentar

chuleta El problema de las dependencias circulares en las distribuciones basadas en rpm es un verdadero coñazo que, por desgracia, se presenta bastante a menudo. Ocurre cuando la desinstalación de la versión antigua de una librería no es posible y bloquea la instalación de una nueva versión y, por tanto, la instalación de los paquetes que la requieren como imprescindible. El último caso que se me ha presentado, y que me ha hecho recordar esto, ha sido con las pruebas de la versión alpha de fedora 11 y concretamente con las liberías glibc. La versión glibc-common-2.9.90-2.i386 me bloqueaba la instalación de glibc-common-2.9.90-8.1.i586 y no me dejaba instalar el compilador gcc que dependía de esta última.

La solución es tan sencilla como instalar el paquete manualmente usando la opción --nodeps. Los paquetes rpm de Fedora están disponibles para su descarga directa y ordenados según la versión de la distribución en estas páginas. En el caso que os cuento, las glibc-common-2.9.90-8.1.i586 están aquí. Una vez descargadas se instalan así:

[root@localhost downloads]# rpm -Uhv glibc-common-2.9.90-8.1.i586 --nodeps

Y listo. Ya puedo seguir con la instalación del gcc para, luego, volver a tener disponible VirtualBox. Pero esto es ya una historia que merece ser contada en otra ocasión ;-)

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Chuletillas (y IV) – Generar parejas de claves con OpenSSH

Josemaría | 4 de junio de 2008 | 1 comentario

chleta Imagino que a estas alturas ya lo sabe todo el mundo pero, por si acaso, insisto: Todos los certificados y parejas de claves generados durante los dos últimos años desde una distribución Debian o derivada (Ubuntu, Xandros, Mepis, Mint, etc.) y que se usen para cifrar una comunicación segura por https, para dar acceso a un servidor por ssh, etc., han de ser revocadas y vueltas a crear desde una distribución actualizada lo antes posible. Quién quiera algo más de información de lo que ha pasado con esto y de las posibles consecuencias puede leerse este post de Hispasec o, en inglés, este otro de Metasploit.

Generar una pareja de claves nueva para acceder por ssh a un servidor es tan fácil como esto:

josemaria@penique:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/josemaria/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/josemaria
.ssh/id_rsa.
Your public key has been saved in /home/josemaria/.ssh/id_rsa.pub.
The key fingerprint is:
8a:75:13:c9:95:f6:c0:89:e0:4c:97:5e:7a:13:f7:63

La clave pública se guarda en el fichero id_rsa.pub dentro de un directorio oculto llamado .ssh que se encuentra en nuestro $HOME. La clave privada, que no debe de salir de ahí salvo para hacer copias de seguridad, se encuentra en ese mismo directorio.

El comando para cambiar la contraseña de una pareja de claves es este (pero, ojo, esto no sustituye la clave débil por otra y, por tanto, no corrige este problema):

josemaria@penique:~$ ssh-keygen -p

ACTUALIZACI?N: Mercè Molist publica hoy a través de su blog una nota informativa sobre este error y una entrevista con Jordi Mallach, desarrollador de Debian.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes