☰

¿Por qué los servidores de claves pgp no responden cuando solicito claves?

tag-icon • tag-icon gnupg pgp
¿Por qué los servidores de claves pgp no responden cuando solicito claves?

Probé la línea de comandos de Linux (bash 4.4.23 en el kernel de Arch Linux 4.18.16) con varios servidores de claves:

$ gpg -v --keyserver subkeys.pgp.net --recv-keys F434104235DA97EB
gpg: using character set 'utf-8'
gpg: keyserver receive failed: Server indicated a failure
$ gpg -v --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys F434104235DA97EB
gpg: using character set 'utf-8'
gpg: keyserver receive failed: Server indicated a failure
$ gpg --debug-level 9 --keyserver  hkp://keyserver.ubuntu.com:80 --recv-keys F434104235DA97EB
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/user/.gnupg
gpg: DBG: chan_3 <- # Config: /home/user/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.2.11 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.2.11
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keyserver.ubuntu.com:80
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0xF434104235DA97EB
gpg: DBG: chan_3 <- ERR 167772379 Server indicated a failure <Dirmngr>
gpg: keyserver receive failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
$

Probé la interfaz web dehttps://pgp.surfnet.nl/. responde

Servicio No Disponible

El servidor no puede atender temporalmente su solicitud debido a un tiempo de inactividad por mantenimiento o problemas de capacidad. Por favor, inténtelo de nuevo más tarde.

Probé la interfaz web dehttps://pgp.mit.edu. Este responde:

Error de proxy

El servidor proxy recibió una respuesta no válida de un servidor ascendente. El servidor proxy no pudo manejar la solicitud GET /pks/lookup.

Motivo: Error al leer desde el servidor remoto

Probé la interfaz web enhttps://pgp.key-server.ioLa respuesta es:

Hint! Double-check if the keyserver is up and running at the expected address:port (127.0.0.1:11369).
cURL error 52: Empty reply from server
#0 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/RequestFsm.php(103): GuzzleHttp\Exception\RequestException::wrapException(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Ring\Exception\ConnectException))
#1 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/RequestFsm.php(132): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
#2 /var/www/pgp.key-server.io/vendor/react/promise/src/FulfilledPromise.php(25): GuzzleHttp\RequestFsm->GuzzleHttp\{closure}(Array)
#3 /var/www/pgp.key-server.io/vendor/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php(55): React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)
#4 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/Message/FutureResponse.php(43): GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)
#5 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/RequestFsm.php(134): GuzzleHttp\Message\FutureResponse::proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))
#6 /var/www/pgp.key-server.io/vendor/guzzlehttp/guzzle/src/Client.php(165): GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
#7 /var/www/pgp.key-server.io/vendor/jenssegers/proxy/src/Adapter/Guzzle/GuzzleAdapter.php(54): GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request))
#8 /var/www/pgp.key-server.io/vendor/jenssegers/proxy/src/Proxy.php(80): Proxy\Adapter\Guzzle\GuzzleAdapter->send(Object(Symfony\Component\HttpFoundation\Request), 'http://127.0.0....')
#9 /var/www/pgp.key-server.io/src/ctubio/HKPProxy/Keyserver/Router.php(46): Proxy\Proxy->to('http://127.0.0....')
#10 /var/www/pgp.key-server.io/src/ctubio/HKPProxy/Keyserver/Router.php(14): ctubio\HKPProxy\Keyserver\Router::getHKPResponse('/pks/lookup?sea...')
#11 /var/www/pgp.key-server.io/src/ctubio/HKPProxy/Keyserver.php(19): ctubio\HKPProxy\Keyserver\Router::getResponse()
#12 /var/www/pgp.key-server.io/pub/php-proxy-keyserver.php(14): ctubio\HKPProxy\Keyserver::getResponse()
#13 {main}

Varios otros servidores de claves dicen "No se encontraron resultados" a cualquier clave que solicite.

  • ¿Qué está pasando? ¿Es un problema temporal? Pero ¿por qué todos los servidores de claves estarían fuera de línea al mismo tiempo?
  • ¿Tiene algo que ver con el acceso a todos los servidores clave bloqueados por mi conexión (entonces, ¿por qué puedo acceder a las interfaces web que luego fallarán?)?
  • ¿Es que estoy buscando cadenas no válidas? No lo creo; Busqué varios diferentes, el del ejemplo aquí (F434104235DA97EB) debería ser el quefirmado estopaquete en github...
  • ¿Es que no me estoy conectando a los servidores de claves correctos?

Respuesta1

Probé tu comando subkeys.pgp.nety tuve el mismo problema. Busqué un poco sobre ese servidor de claves y no encontré nada relevante, aparte de que la gente se queja de que falla. keyserver.ubuntu.comsin embargo funciona para mí.

[Editar] Desde que @blubberdiblubse señaló, el pool.sks-keyservers.netservidor de claves también desapareció. Pruebe uno de esos en su lugar:

  • hkps://keys.gnupg.net
  • hkps://keyserver.ubuntu.com
  • hkps://keys.openpgp.org

La respuesta anterior ya no es válida pero puede ser relevante como referencia

De acuerdo aesteHay un servidor de claves que consta de un grupo de otros servidores de claves más confiables. Este es: pool.sks-keyservers.net. Hay más información sobre suPágina web.

Intenté usarlo pool.sks-keyservers.netcomo servidor de claves y el comando pudo importar la clave sin problemas.

Entonces, para resumir y responder a sus preguntas:

  • Los servidores de claves a veces parecen no ser confiables. Tal vez esos servidores de claves sean viejos y no reciban mantenimiento hoy en día, pueden estar desconectados temporalmente o simplemente muertos. pool.sks-keyservers.netParece funcional en este momento y confiable, pero esto puede cambiar con el tiempo.
  • La interfaz web para esos servidores de claves puede mostrar una página en su navegador, pero luego la búsqueda de claves puede fallar si el servidor de claves subyacente donde se almacenan las claves está inactivo, o es posible que no encuentren la clave si el servidor no está sincronizado con otros servidores de claves.

información relacionada