git

Muchas veces nos encontramos con que a la hora de clonar un repositorio desde Git mediante SSH este no utiliza el puerto por defecto y nos da error al ejecutar el comando clone, para corregir este error solo basta con ejecutar el comando de la siguiente forma:

git clone ssh://usuario@servidor.com:2222/ejemplo/proyecto.git

Espero que esta información les sea útil, saludos.

Para los que no conocen a VIM, es una versión mejorada del editor de texto VI y es uno de los editores mas populares en las distribuciones Linux y es una herramienta que todo sysadmin debe conocer.

Un amigo me pidió hace unos días que lo ayudara a aprender esta herramienta, y en mi búsqueda de material para ofrecerle encontré esta joya y decidí compartirla.

https://anderrasovazquez.github.io/curso-de-vim/

Es un pequeño curso realizado por Ander Raso Vazquez con la finalidad de enseñar lo básico del uso de esta gran herramienta.

Espero que esta información les sea útil, saludos.

Cuando PhpMyAdmin nos muestra el error 1146 y/o nos muestra una advertencia relacionada con controluser solo basta abrir el archivo /etc/phpmyadmin/config.inc.php con su editor favorito y modificar lo siguiente:

$cfg['Servers'][$i]['controluser'] = $dbuser;
$cfg['Servers'][$i]['controlpass'] = $dbpass;

Para que quede de la siguiente forma:

$cfg['Servers'][$i]['controluser'] = ''; //$dbuser;
$cfg['Servers'][$i]['controlpass'] = '': //$dbpass;

Guardamos el archivo, reiniciamos el servidor web y listo.

Espero que esta información les sea útil, saludos…

Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123. Está diseñado para resistir los efectos de la latencia variable.

Para instalar NTP en Debian solo debe ejecutar el siguiente comando como root:

apt -y install ntp

Luego debe ejecutar el siguiente comando para ponerlo en marcha con la configuración por defecto:

systemctl enable ntp
systemctl start ntp

Para sincronizar el servidor con los proveedores de hora públicos ejecute lo siguiente:

ntpq -p

Normalmente no es necesario modificar la configuración que viene predeterminada pero si necesita hacerlo solo debe editar el archivo /etc/ntp.conf con su editor favorito.

Acá les dejo las direcciones de varios servidores publico:

  • pool.ntp.org (servidores aleatorios en todo el mundo)
  • europe.pool.ntp.org (servidores aleatorios en Europa)
  • it.pool.ntp.org (servidores aleatorios en Italia)

Espero que esta información les sea útil, saludos.

Mas información:

Muchas veces necesitamos hacer algún script en bash donde queremos que tenga ciertas características, y muchas veces queremos que las salidas por pantalla de ese script se vean distintas para llamar la atención.

bash_colors

Pues bien, se puede usar colores para el texto en el bash de una forma sencilla.

Esta es la lista de algunos de los códigos de color para nuestro texto:

  • Negro = 0;30
  • Gris oscuro = 1;30
  • Azul = 0;34
  • Azul claro = 1;34
  • Verde = 0;32
  • Verde claro = 1;32
  • Cyan = 0;36
  • Cyan claro = 1;36
  • Rojo = 0;31
  • Rojo claro = 1;31
  • Púrpura = 0;35
  • Púrpura claro = 1;35
  • Café = 0;33
  • Amarillo = 1;33
  • Gris = 0;37
  • Blanco = 1;37

El comando echo se debe de ejecutar con el parámetro -e haciendo que bash interprete el comando \e (o sea el escape) de esta manera:

echo -e ‘Esto es \e[0;31mrojo\e[0m y esto es \e[1;34mazul resaltado\e[0m’

Resultado: Esto es rojo y esto es azul

echo -e ‘Así se escribe \e[1;34mG\e[0m\e[1;31mo\e[0m\e[1;33mo\e[0m\e[1;34mg\e[0m\e[1;32ml\e[0m\e[1;31me\e[0m’

Resultado: Así se escribe Google

En resumen para poder utilizarlo solo hay que poner los caracteres que quieras que tengan color entre los caracteres de escape de esta manera:

‘\e[CODIGOm(texto)\e[0m’ (el texto sin los paréntesis)

Colores de fondo

De la misma forma podemos cambiar el color de fondo mediante los siguientes valores:

  • Negro = 40
  • Rojo = 41
  • Verde = 42
  • Amarillo = 43
  • Azul = 44
  • Rosa = 45
  • Cyan = 46
  • Blanco = 47

Para utilizarlo solo debemos seguir la siguiente sintaxis:

echo -e "\e[42mMuestra\e[49m"

Como se puede apreciar en la imagen que acompaña este post las combinaciones pueden ser bastante grandes y solo hace falta un poco de creatividad para crear resultados llamativos. Cabe destacar que el código \e[49m regresa el color de fondo al original.

A veces no podemos utilizar nuestro servidor principal, ya que estamos cambiándolo, actualizándolo, peleándonos con dependencias o trabajando en configuración o plug-ins. Por lo que necesitamos algo para reemplazarlo momentáneamente.

Tampoco se quiere algo demasiado grande porque es para un apaño. Tal vez no tengamos nodeJs instalado, o python en los que nos podemos crear un servidor web con pocas líneas. Y tampoco queremos tener que instalar demasiadas cosas.

Como alternativa ligera podemos usar netcat el cual viene instalado por defecto en muchas distribuciones.

Sólo tenemos que ejecutar lo siguiente:

$ sudo -c sh 'while true; do nc -l -p 80 < respuesta.html; done'

Sin sudo y con usuario root si no disponemos de él en el sistema. Con esto, vamos a poner constantemente en escucha el puerto 80 y procesando todas las peticiones de la misma forma, devolviendo los contenidos de respuesta.html.

Las pruebas pueden realizarse como un usuario normal (no root) si utilizamos un puerto mayor de 1024, por ejemplo el 8000, 8080, 1234, etc:

$ while true; do nc -l -p 8000 < respuesta.html; done

Como la respuesta debe ser muy rápida, en principio no tenemos necesidad de algo más complicado (esperemos que no vengan demasiadas visitas mientras trabajamos). Pero este sistema no soportará usuarios concurrentes, recordemos que es sólo un servidor temporal y puede que a algún usuario le dé algún problema en conectar. Podemos guardar un registro de todo lo que ha pasado con:

$ sudo -c sh 'while true; do nc -l -p 80 < respuesta.html; done > log'

o como usuario:

$ while true; do nc -l -p 8000 < respuesta.html; done > log

Creando respuesta.html

Como habrás podido ver respuesta.html no es un archivo HTML normal, en realidad aquí hay que poner toda la respuesta completa (con cabeceras incluidas), podemos hacer algo sencillo primero:

HTTP/1.1 200 OK
Server: LittleServer
Content-Type: text/html;charset=UTF-8<html>
<body>
<h1>Lo sentimos, estamos de mantenimiento</h1>
Disculpe las molestias, en un momento estaremos con usted.

&lt;/body&gt;
&lt;/html&gt;

La página a partir de la etiqueta <html>, podemos poner el código HTML que queramos. Aunque ahora estaremos contestando con un código de salida exitoso, lo que significa que los usuarios no se cabrearán (bueno sí, pero al menos verán una explicación), pero los buscadores y robots sí que la tomarán con nosotros, porque se creerán que ésta es la página buena, es más todas las páginas del servidor responderán lo mismo.

Respondiendo para que los buscadores no nos tengan en cuenta

Para ello tenemos que poner en nuestra cabecera un error 503 (Servicio no disponible). Esto será bueno porque no devolveremos un 200 (OK) para las páginas temporales, ni devolveremos un 404 (Not found / No encontrado) para el resto de páginas que no estén en nuestro servidor pero si deberán estar y el buscador de turno lo sabe (esto último sería horrible para nuestro posicionamiento, porque el buscador se creería que esas páginas ya no existen y las desindexará).

Para ello, nuestro archivo de respuesta.html será el siguiente:

HTTP/1.1 503 Service Unavailable
Server: Maintenance
Retry-After: 3600
Content-Type: text/html;charset=UTF-8&lt;html&gt;
&lt;body&gt;
<h1>Lo sentimos, estamos de mantenimiento</h1>
Disculpe las molestias, en un momento estaremos con usted.

&lt;/body&gt;
&lt;/html&gt;

Además, añadiremos Retry-After para que vuelvan dentro de un rato a ver si todo está bien. No se garantiza que los buscadores vuelvan dentro de una hora (3600 segundos), pero es normal que vuelvan cuando tengan un rato después de una hora.

Queremos complicarnos la vida

Si has llegado hasta aquí, eres de los que le gustan complicarse la vida e inventar cosas, así que, para dejar un poco a la imaginación y para hacer un servidor web un poco más completo.

Vamos a crear un script que procesará la petición HTTP que se realice (tenemos que recordar que cuantas más cosas metamos, más vulnerable será nuestro sistema, y un script aquí es tremendamente vulnerable).

dispatcher.sh

#!/bin/bash
I=0
while read RAWINPUT; do
if [ ${#RAWINPUT} -le 1 ]
then
break
fi
INPUT[$I]=$RAWINPUT
I=$(($I+1))
doneread -a FIRSTLINE <<< ${INPUT[0]}
METHOD=${FIRSTLINE[0]}
REQUEST=${FIRSTLINE[1]}
HTTPVER=${FIRSTLINE[2]}

echo $HTTPVER 503 Service Unavailable
echo "Retry-After: 3600"
echo "Server: Bash-Maintenance"
case "$REQUEST" in
"/logo.jpg")
FILE="my-logo-file.jpg"
echo "Content-Type: image/jpeg"
echo "Content-Length: "$(stat -c%s "$FILE")
echo
cat $FILE
;;
"/fortune")
CONTENT=$(fortune)
echo "Content-Type: text/html; charset=utf-8"
echo "Content-Length: "${#CONTENT}
echo
echo $CONTENT
;;
*)
FILE="respuesta.html"
echo "Content-Type: text/html; charset=utf-8"
echo "Content-Length: "$(stat -c%s "$FILE")
echo
cat $FILE
;;
esac

Ahora tenemos 3 respuestas posibles:

  • Una para una imagen que llamaremos a través de http://nuestroservidor/logo.jpg y que llamará a la imagen my-logo-file.jpg
  • Otra que llamará al programa fortune, para que nos devuelva una frase aleatoria.
  • Otra que atenderá todas las demás peticiones (*) y servirá el archivo respuesta.html.

Para hacer que netcat utilice este archivo, depende de la versión, por un lado podemos llamar a:

$ sudo sh -c 'while true; do nc -v -l -p 80 -c dispatcher.sh; done'

como usuario:

$ while true; do nc -v -l -p 8000 -c dispatcher.sh; done

Aunque en muchas versiones de GNU/Linux viene otra versión instalada que no soporta -c, pero no todo está perdido:

$ rm /tmp/bashwebtmp; mkfifo /tmp/bashwebtmp; sudo -c sh 'while true; do cat /tmp/f | bash dispatcher.sh | nc -v -l -p 80 > /tmp/f; done';

como usuario:

$ rm /tmp/bashwebtmp; mkfifo /tmp/bashwebtmp; while true; do cat /tmp/f | bash dispatcher.sh | nc -v -l -p 8000 > /tmp/f; done;

No debemos olvidar borrar la pipe /tmp/bashwebtmp cuando terminemos de usar el programa.

Una cosa más, no debemos abusar de este script y no debemos enviar contenidos muy grandes, por ejemplo, no abusar de las imágenes, como decía antes, sólo soporta una conexión, si hacemos que esta conexión se extienda en el tiempo perderemos capacidad de atender más conexiones.

Visto en: Poesía Binaria

Asegúrate de estar recibiendo regularmente actualizaciones de las llaves

Si no refrescas regularmente tus llaves públicas implica que no recibas a tiempo la información sobre las llaves que han expirado o las revocaciones, lo cual es muy importante.

Si realizas un simple “gpg –refresh-keys”, revelas a cualquiera y al operador de servidor de llaves todo el conjunto de llaves que te interesa refrescar.

Para evitar esto puedes hacer actualizaciones regulares de llaves usando Parcimonie para refrescar tu llavero. Parcimonie es un daemon que refresca lentamente tu llavero desde un servidor de llaves a través de Tor. El propósito es hacer más difícil para un atacante correlacionar las actualizaciones de las llaves con tu llavero. Parcimonie es un paquete que se encuentra en Debian y Ubuntu.

También puedes usar un simple cronjob, como el siguiente para refrescar tus llaves, esto requiere que tu computadora este conectada a la red a la 1am, y potencialmente revela al mundo todas las llaves que estés actualizando en tu llavero.

No uses pgp.mit.edu

El servidor de llaves pgp.mit.edu ha estado sin funcionar adecuadamente por años, especialmente para cierto tipo de actualizaciones de llaves.

Depender específicamente de un único servidor de llaves te hace vulnerable a las posibles fallas de ese servidor de llaves, si el servidor de llaves se queda fuera de la piscina principal por cualquier razón, puede que nunca lleguen las actualizaciones al resto de la piscina. Utilizar la piscina es más robusto que usar un único servidor de llaves.

Considera mejor utilizar sks keyservers pool . En gpg.conf:

keyserver hkp://pool.sks-keyservers.net

La transición a una llave primaria más fuerte

Muchas personas siguen teniendo llaves DSA de 1024-bit. Debes considerar hacer la transición a un algoritmo de función hash más fuerte y de más bits. Ahora se sabe que este tamaño está dentro de lo que Well Funded Organizations pueden llegar a vulnerar. Este algoritmo de función hash ya está también envejeciendo.

Se recomienda hacer una llave 4096bit RSA con el algoritmo de función hash SHA512, realizando un aviso de transición que esté firmado por ambas llaves y hacerlo del conocimiento de todos. Este es un buen documento (EN) que detalla exactamente los pasos para que generes una llave así, asegurándose de obtener al algoritmo de función de digest adecuado.

Considera hacer que tu servidor de llaves por defecto use un servidor de llaves que tenga transporte HKPS

En lugar de un hkp sin cifrado por defecto puedes usar hkps. Esto hace menos evidente tu mapa de relaciones sociales de cualquiera que pueda estar fisgoneando el tráfico de tus datos por la red. Si realizas un gpg –refresh-keys en un servidor de llaves que es sólo hkp, entonces alguien monitoreando tu tráfico vera cada una de las llaves que tienes en tu llavero cuando pidas las actualizaciones de las llaves.

Nota: para poder utilizar el paquete hkps usuarios Debian/Ubuntu necesitarán instalar el paquete gnupg-curl

Puedes usar hkps.pool.sks-keyservers.net como tu servidor de llaves por defecto, este es un servidor piscina que contiene los servidores disponibles que usan hkps. Esta piscina contiene únicamente servidores que han sido certificados por sks-keyservers.net CA. Puede ser usado mediante los siguientes parámetros en gpg.conf:

~/.gnupg/gpg.conf:
 keyserver hkps://hkps.pool.sks-keyservers.net
 keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

Además, hkps:/keys.indymedia.org, hkps://keys.mayfirst.org and hkps://keys.riseup.net ofrecen esto (aunque es recomendable que mejor utilices la piscina).

Finalmente, si optas por designar la piscina como tu servidor de llaves, debes también agregar la siguiente opción:

~/.gnupg/gpg.conf:
 keyserver-options no-honor-keyserver-url

Cuando se genera una llave, los usuarios pueden designar un servidor de llaves específico desde el cual se pueden descargar sus llaves. La opción de arriba va a omitir esa especificación y utilizará la piscina, lo cual es útil porque (1) previene que alguien designe un método inseguro para que podamos bajar su llave y (2) si el servidor designado usa hkps, refrescar las llaves no funcionará porque el ca-cert no va a coincidir y por lo tanto las llaves no se van a refrescar.

Asigna una fecha de vencimiento si no tienes una

Las personas suelen preferir que sus llaves no expiren, pero tú sí debes querer que expiren. ¿Porqué? Porque siempre podrás extender su fecha de vencimiento, aún después de que hayan expirado. Este “vencimiento” es de hecho una válvula de seguridad o un “sistema de seguridad de hombre-muerto” que automáticamente se activará en algún momento. Si tienes acceso a los datos secretos de tus llaves lo puedes desactivar. El objetivo es implementar algo que deshabilite tu llave en caso de que pierdas acceso a ella y que no tengas certificado de revocación.

Asignar una fecha de vencimiento significa que necesitarás extender esa fecha en algún punto del futuro. Es una pequeña tarea que necesitarás recordar hacer.

Puedes pensar que es molesto y que no quieres tener que lidiar con ello, pero de hecho es bueno hacerlo regularmente. Indica a los usuarios que su llave sigue estando activa, y que el propietario de la llave la utiliza. Además, mucha gente no firmará una llave que no tenga fecha de vencimiento.

Para asignar una fecha de vencimiento a tu llave, simplemente necesitas ejecutar:

gpg --edit-key <fingerprint>

Ahora selecciona la sub-llave a la que quieres asignar una fecha de vencimiento (por ejemplo, la primera), o ninguna para asignar el vencimiento en tu llave primaria y luego ejecuta el comando “expire”

gpg> key 1
gpg> expire

Ahora asigna un valor razonable, (por ejemplo, 2 años) guarda la llave y salga:

Key is valid for? (0) 2y
gpg> save

Ahora debes enviar tu llave a los servidores de llaves para publicar este cambio:

gpg --send-key

Agenda un evento en el calendario para recordarte sobre la fecha de vencimiento de tu llave

No lo vas a recordar, así que lo mejor es pedir un recordatorio. Agenda una alerta un mes o más antes de la fecha para que puedas hacer el cambio con algo de tiempo. No quieres tener que apresurarte cuando tengas que manejar tus llaves.

Siempre puedes extender la fecha de expiración (aún cuando la llave ya expiro), así que no necesitas generar una nueva llave cada vez, sólo necesitas extender a fecha de vencimiento para después.

¿Tienes un certificado de revocación?

Si llegas a olvidar tu frase de contraseña o si tu llave privada queda comprometida o la pierdes, la única esperanza que te queda es esperar a que expire la llave (esto no es una buena solución), o activar tu certificado de revocación publicándolo a los servidores de llaves. Al hacer esto notificarás a otros que esta llave ha sido revocada.

Una llave revocada puede seguir utilizándose para verificar firmas anteriores o descifrar datos (si es que sigues teniendo acceso a la llave privada), pero no puede ser usada para cifrar nuevos mensajes para ti.

Para saber como generar y utilizar el certificado haz clic aquí.

Utiliza únicamente tu llave primaria para certificación (y tal vez también firmar). Ten una subllave por separado para cifrar.*

(extra) Ten una subllave por separado para firmar y mantén tu llave primaria completamente fuera de linea.

En este escenario, tu llave primaria es utilizada solo para certificación, lo que no sucede con frecuencia.

No confíes en el ID de la llave

Los IDs de llaves que son cortas, por ejemplo 0x2861A790, son de 32 bits. Hemos visto que son fácilmente falsificadas por otra llave con el mismo ID. Las OpenPGP IDs largas (por ejemplo 0xA1E6148633874A3D) son de 64 bits. Son fáciles para un ataque de colisión (trivially collidable) (EN), lo que es potencialmente un serio problema (EN).

Si quieres tratar con un identificador criptográficamente fuerte para una llave, debes usar la huella digital completa. Nunca debes confiar en la ID corta de la llave.

Probablemente deberías al menos tener:

keyid-format 0xlong y with-fingerprint en las opciones gpg.conf para incrementar el tamaño en el que se muestra el ID de la llave a 64-bit bajo uso regular y para mostrar siempre la huella digital.

Asegúrate de que tu llave es OpenPGPv4

De acuerdo con el RFC4880 Las llaves V3 están ya desaprobadas, contienen 3 vulnerabilidades. Primero, es relativamente fácil construir una llave V3 que tenga el mismo ID que otra llave porque el ID de la llave son simplemente los 64 bits del módulo público. Segundo porque la huella digital de una llave V3 hace las funciones de digest del material de la llave pero no de su extensión, por lo que hay una mayor oportunidad para colisiones de huellas digitales. Tercero, hay puntos débiles en el algoritmo MD5 que hace que los desarrolladores prefieran otros algoritmos. Ver abajo la discusión sobre ID’s de llaves y huellas digitales.

Para determinar si tu llave es una llave V3 puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets |grep version

Las llaves primarias deben ser DSA-2 o RSA de 4096 bits o más. (RSA de preferencia)

Para revisar si estás utilizando DSA-2 o RSA puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 '^:public key packet:$' | grep algo

Si el algoritmo reportado es 1, quiere decir que estas usando RSA. Si es 17 entonces es DSA y necesitarás confirmar que las siguientes revisiones reporten un tamaño de llave mayor a 1024, de otro modo no estás utilizando DSA-2.

Si el algoritmo reportado es 19, estás usando ECDSA, si es 18 es ECC. En ese caso la siguiente comprobación del tamaño de bits de la llave no es un criterio apropiado para este tipo de llaves ya que los tamaños de llave se reducirán significativamente.

Para revisar el tamaño de bits de la llave primaria puedes hacer lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A2 'public key' | grep 'pkey\[0\]:'

Las auto-firmas no deben usar MD5, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 1,'

Si ves que se genera algún resultado ‘digest algo 1’, entonces tienes algunas auto-firmas que están usando MD5, ya que el algoritmo digest 1 es MD5. Ve el OpenPGP RFC 4880, section 9.4 (EN) que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las auto-firmas no deben usar SHA1, puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep -A 2 signature | grep 'digest algo 2,'

Si obtienes cualquier resultado ‘digest algo 2’ quiere decir que tienes algunas auto-firmas que están utilizando SHA1, ya que el algoritmo digest 2 es SHA1.

Ve el OpenPGP RFC 4880, section 9.4 que tiene una tabla que mapea algoritmos hash a números.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

cert-digest-algo SHA512

Las preferencias del algoritmo digest deben incluir al menos un miembro de la familia SHA-2 con una prioridad más alta que las MD5 y SHA1 juntas

Puedes revisar esto con:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'pref-hash-algos'

e inspeccionar los resultados. El orden de preferencia está basado en cuál número está primero de izquierda a derecha. Si ves un número ‘3’, ‘2’, o ‘1’ antes del ‘11’, ‘10’, ‘9’ u ‘8’, quiere decir que has especificado en tus preferencias preferir un algoritmo digest más débil.

Para corregir esto, necesitas regenerar una llave después de agregar lo siguiente en tu gpg.conf:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Las llaves primarias deben tener una fecha de vencimiento razonable (no más de 2 años en el futuro) Puedes revisar cuáles son las fechas de vencimiento de tus llaves haciendo lo siguiente:

gpg --export-options export-minimal --export <fingerprint> | gpg --list-packets | grep 'key expires after'

Después inspecciona visualmente cuáles son los resultados para confirmarlo, la fecha en la lista será relativa a la creación de la llave lo cual puede ser difícil de interpretar.

Otro modo de revisar el vencimiento es simplemente:

gpg --list-keys <fingerprint>

Lo cual debe mostrar las fechas de creación y vencimiento de la llave primaria y de cada sub-llave asociada. Si no ves nada que mencione “expires” en este resultado, quiere decir entonces que no designaste una fecha de vencimiento apropiadamente.

Para corregirlo:

gpg --edit-key <fingerprint>
 gpg> expire
 ...
 gpg> save

Actualiza tu configuración GPG por defecto

Si estás utilizando GnuPG, asegúrate de tener las configuraciones optimas en gpg.conf, para esto puedes utilizar el siguiente script.

No incluyas un “comentario” en tu ID de usuario

Si crees que necesitas un lugar para un “comentario” en tu OpenPGP User ID piénsalo bien dos veces lee más sobre esto (EN). Probablemente no lo necesites ni lo quieras. Tener un espacio para un comentario dificulta a mucha gente saber qué es lo que están certificando.

Visto en riseup.net.

Muchas personas no le dan la importancia requerida a un certificado de revocación hasta que es demasiado tarde, básicamente un certificado de revocación te permite cancelar tu llave pública en cualquier momento que pierda acceso a tu llave privada o esta se vea comprometida.

Si el certificado de revocación queda comprometido, la persona que lo comprometa podrá revocar la llave pública en circulación, sin embargo no podrá acceder a la llave secreta y tampoco podrá generar falsas firmas, descifrar mensajes o cualquier otra cosa que pueda hacer el usuario del par de llaves. Realmente lo único negativo de esto es que deshabilita el par de llaves.

Para generar el certificado de revocación solo debe ejecutar el siguiente comando:

gpg -a -o revoke.asc --gen-revoke <ID_Llave>

Para revocar la llave en caso de que haya sido comprometida solo debe ejecutar el siguiente comando:

gpg --import revoke.asc

Si se ejecuta “gpg –list-key” podrá ver que la llave ha sido cancelada, ahora solo falta subir de nuevo la llave a los servidores de llaves para que todos puedan ver que fue revocada, para esto solo hace falta ejecutar el siguiente comando:

gpg --keyserver pool.sks-keyservers.net --send-keys <ID_Llave>

Espero les sea útil, saludos…

Mas información: