VPSs y mas.

lunes, 22 de enero de 2018

Propuesta de una fuente confiable de enrutamiento para la región de LAC

Introducción

Recientemente fue publicado un artículo por Job Snijders llamado: “A New Source For Authoritative Routing Data”, su traducción viene a ser algo como: “Una nueva fuente de información de enrutamiento autoritativa”. (Snijders 2017)
El documento trata sobre un trabajo donde explica como varios expertos y en contribución con varias instituciones construyeron una manera de proveer a la comunidad información confiable sobre enrutamiento. Para ir entrando en detalles técnicos podemos verlo como algo entre un IRR (“Internet Routing Registry - Wikipedia” n.d.) y RPKI (“Resource Public Key Infrastructure - Wikipedia” n.d.)
En este documento se describe una propuesta de LACNIC a la comunidad, con el fin de proveer una fuente de información autoritativa confiable sobre enrutamiento que pueda utilizarse por parte de los operadores de Internet de la región.

Un poco de historia

En el post de Job Snijder se explica cómo se tomó como fuente de información confiable la base de datos de Whois de ARIN y especificamente un campo llamado Origin el cual especifica cual AS (Sistema Autónomo) es quien anunciará determinado prefijo.
Posteriormente lo que se hace con esa información es construir un archivo JSON (“JSON - Wikipedia, La Enciclopedia Libre” n.d.) el cual puede ser utilizado fácilmente por programadores y diferente software de forma muy similar a lo que hace un IRR actualmente.

¿Qué hicimos en Lacnic?

Luego de analizar el post anterior y nuestras opciones, concluimos que el campo OriginAS prácticamente no es utilizado en el WHOIS de LACNIC, por lo que no estaríamos en condiciones de extraer esa información a partir de esa fuente. Sin embargo, dado el gran porcentaje de ROAs creados en varios países de la región (“Statistics — RIPE Network Coordination Centre” n.d.), creemos conveniente utilizar RPKI como fuente de información.

¿Cómo se tomó la información de RPKI?

Para utilizar la informacion de RPKI de LACNIC trabajamos con el validador RPKI de RIPE (“Tools and Resources” n.d.), con la diferencia que removimos todos los TAL (Trust Anchor Locator) exceptuando el de LACNIC. De esta manera el validador unicamente estaría procesando los ROAs correspondientes a nuestra región. Finalmente lo que hicimos fue exportar los ROAs en formato JSON, una funcionalidad que ofrece el propio validador.

Proceso de la información de RPKI

Finalmente, utilizando un script en python3 y en base al JSON exportado del Validador de RIPE construimos un nuevo archivo de JSON, (“Tools and Resources” n.d., “Website” n.d.) con una similitud sintáctica de 95% al del proyecto previo (“Website” n.d.)(Job Snijders y compañía). En este sentido, la manera como se crea la fecha, las posiciones relativas en el archivo, los nombres de las llaves son identicos, de esta manera facilitamos la interoperatividad con scripts y software ya existente.
Adicionalmente, esta misma información se publica en format RPSL(“Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre” n.d.), un formato que es más habitual para los operadores. De esta forma, se puede elegir entre ambos formatos para procesar o utilizar la información autoritativa.

Avances actuales

En base a todo lo mencionado anteriormente actualmente:
  • Se publica diariamente un dump de todos los ROAs en formato JSON
  • Se publica en RPSL la información correspondiente al AS de Origen y el prefijo (tanto v4 como v6) Lo anterior viene acompañado de un un hash de comprobación bajo SHA384 URL http://stats.labs.lacnic.net/RPKI/RPKItoJSON/

Espacio para mejoras

Sabemos que existen muchas cosas para mejorar, por el momento debemos mencionar:
  1. Publicar los archivos en un server con soporte de https

Conclusiones

Dentro de Lacnic este proyecto aun se encuentra en una etapa Alfa, a lo sumo Beta. Dependeremos 100% de los comentarios recibidos de la comunidad si deseamos llevar esta idea a un ambiente con carácter de producción. Por ello no dude en comunicarse con nosotros, somos muy buenos recibiendo quejas, comentarios y felicitaciones.

Consideraciones adicionales

En los ROAs es posible especificar una longitud máxima y mínima de prefijos a publicar, sin embargo esto no tendría una forma similar de replicarlo en el archivo de salida. Una posibilidad en IPv4 sería generar los prefijos intermedios con el mismo sistema autónomo de origen, pero en IPv6 esto no sería posible por la cantidad de direcciones involucradas. Otra posibilidad es no utilizar las longitudes mínima y máxima en los ROAs, ya que esa es la situación análoga a los IRRs. El formato JSON de salida es fácilmente convertible a RPSL, con lo cual se pueden utilizar las mismas herramientas que se utilizan para procesar la información de un IRR. Un punto a analizar es si resulta necesario poder contar con otros objetos que no están incluidos en esta base de datos auto-generada.

Por:

  • Alejandro Acosta alejandro \at lacnic dot net
  • Guillermo Cicileo guillermo \at lacnic dot net

Referencias

  1. “Internet Routing Registry - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Internet_Routing_Registry.
  2. “JSON - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/JSON.
  3. “Resource Public Key Infrastructure - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure.
  4. “Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/Routing_Policy_Specification_Language.
  5. Snijders, Job. 2017. “A New Source For Authoritative Routing Data: ARIN WHOIS.” Medium. Medium. December 19, 2017. https://medium.com/@jobsnijders/a-new-source-for-authoritative-routing-data-arin-whois-5ea6e1f774ed.
  6. “Statistics — RIPE Network Coordination Centre.” n.d. Accessed January 19, 2018. https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html.
  7. “Tools and Resources.” n.d. RIPE Network Coordination Centre. Accessed January 19, 2018. https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources.
  8. “Website.” n.d. Accessed January 19, 2018a. http://stats.labs.lacnic.net/RPKI/RPKItoJSON/.

lunes, 1 de enero de 2018

Solucion de errores: SSH "Permission denied (publickey)". Luego de upgrade. Facil y rapido

En caso de que estes recibiendo el siguiente error al hacer un ssh:


"Permission denied (publickey)."

pero extrañamente venía funcionando todo quizás fue por un upgrade de openssh o del sistema operativo.
Lo primero que te recomiendo es realizar un ssh y con algo de debug (por ejemplo con el -v)

Quedarías así:


$ ssh -v -l alejandro miserver.com

Verás algo así:

$ ssh -v -l alejandro miserver.com
OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /Users/alejandroacosta/.ssh/config
debug1: /Users/alejandroacosta/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 49: Applying options for *
debug1: Connecting to miserver port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_rsa-cert type -1
debug1: identity file /Users/alejandroacosta/.ssh/id_dsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to miserver.com:22 as 'alejandro'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:0CjzVIchz9571bMTChmp6cMZ+9QVogt9mHSaK8JA5VQ
debug1: Host '[miserver.com]:22' is known and matches the ECDSA host key.
debug1: Found key in /Users/alejandroacosta/.ssh/known_hosts:20
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Skipping ssh-dss key /Users/alejandroacosta/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/alejandroacosta/.ssh/id_rsa
debug1: Trying private key: /Users/alejandroacosta/.ssh/id_ecdsa
debug1: Trying private key: /Users/alejandroacosta/.ssh/id_ed25519
debug1: No more authentication methods to try.
alejandro@miserver.com: Permission denied (publickey).


La linea mas importante es:

"debug1: Skipping ssh-dss key /Users/alejandroacosta/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes"


Existen varias maneras de solucionarlo, muchas estan mencionadas en:

https://stackoverflow.com/questions/39715135/problems-deploying-code-with-capistrano-since-upgrading-to-macos-10-12-sierra

y

https://rolfje.wordpress.com/2016/11/12/macos-sierra-ssh-permission-denied/


Sin embargo si estas urgido, corriendo puedes solucionarlo inmediatamente haciendo esto:

Solución

echo "Host *" >> ~/.ssh/config
echo "PubkeyAcceptedKeyTypes=+ssh-dss" >> ~/.ssh/config


Mas información:

https://ro-che.info/articles/2015-12-21-permission-denied-publickey-ssh-update