Usar Synaptic detrás de un cortafuegos

saltar restricciones firewall desde linuxEn el trabajo debido a las políticas de seguridad me resulta francamente difícil realizar ciertas tareas que, en otras condiciones, deberían ser triviales: actualizar el reloj por NTP, firmar o encriptar correos utilizando PGP, añadir claves de repositorios, …

Aunque no me impiden el trabajo diario si que me lo dificultan y hoy es el día en el que he decidido eliminar una de dichas trabas: la posibilidad de importar sin problemas las claves de los distintos repositorios que añado a mi equipo.

Para ello optaremos por usar un servidor que tiene habilitado el puerto 80 que, por razones obvias, suele estar abierto en todos los firewalls ;)

Antecedentes

Cada vez que añado un repositorio a Synaptic

sudo add-apt-repository ppa:tsbarnes/indicator-keylock

me encuentro con mensajes como el siguiente:

Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv EA38F47C53E7A818F3C84A207384429D471E4486

gpg: solicitando clave 471E4486 de hkp servidor keyserver.ubuntu.com

gpgkeys: HTTP fetch error 7: couldn’t connect to host

gpg: no se han encontrados datos OpenPGP válidos

gpg: Cantidad total procesada: 0

en el que me destaca la siguiente información

recuperar claves pgp repositorio synaptic detrás del cortafuegos

Cuando lo normal debería ser

Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver hkp://keyserver.ubuntu.com:80 –recv EA38F47C53E7A818F3C84A207384429D471E4486

gpg: solicitando clave 471E4486 de hkp servidor keyserver.ubuntu.com

gpg: clave 471E4486: «Launchpad Miscellaneous» sin cambiosgpg: Cantidad total procesada: 1

gpg:              sin cambios: 1

Solución

Para evitar el problema que estamos mencionando debemos cambiar el servidor de claves del estándar

keyserver.ubuntu.com

al alternativo (en realidad es el mismo pero utilizando el protocolo hkp por el puerto 80)

hkp://keyserver.ubuntu.com:80

Para ello

  1. modificaremos el fichero /usr/lib/python2.6/dist-packages/softwareproperties/ppa.py teniendo en cuenta que debes tener permisos de administrador para editar el fichero.
  2. buscaremos la cadena keyserver.ubuntu.com.
  3. la cambiaremos por hkp://keyserver.ubuntu.com:80.

Solución alternativa

Si no quieres buscar y reemplazar contenido en el fichero puedes aprovechar lo que aprendimos en el artículo sobre cómo sustituir el contenido de un fichero desde la terminal y lanzar el siguiente comando

sudo sed -i 's/keyserver.ubuntu.com/hkp:\/\/keyserver.ubuntu.com:80/g' /usr/lib/python2.6/dist-packages/softwareproperties/ppa.py

donde

  • -i permite modificar directamente el contenido del fichero (las redirecciones sobre el mismo fichero no sirven con el comando sed)
  • hkp:\/\/ lo usamos para evitar problemas con la expresión regular que estamos usando (no queremos que interprete las barras de hkp)

Conclusión

Modo de evitar las restricciones habituales con los cortafuegos de modo que podamos recuperar  sin problemas las claves de los nuevos repositorios que añadamos en Synaptic.

Por cierto, ¿alguien conoce un servidor parecido para que funcione PGP sin problemas detrás de un firewall? :(

8 thoughts on “Usar Synaptic detrás de un cortafuegos

  1. ArturoM dijo:

    Hola a todos,
    pues mira llevo 3 días peleándome con la Key para poder instalar LibreOffice y vas tu y me resuelves el problema de un plumazo, teniendo en cuenta que ni siquiera sabía de que iba el problema.

    Definitivamente creo que te quiero más que a mi joystick 8-D

  2. Pingback: BlogESfera.com
  3. Danri dijo:

    Fabuloso, después de pelearme con Ubuntu durante las dos últimas semanas intentando actualizar la 10.04 he podido hacerlo sin problema gracias a este truco. El gestor de actualizaciones se negaba a actualizar cualquier paquete, incluso aquellos que provenían de repositorios como el de Canonical. Diez puntos.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s