Blog

Aquí van a bulto todas las entradas que voy añadiendo. Acabo de empezar, y para lo que hay tampoco es que haga falta un sistema de clasificación decimal, digo yo. Si eso, cuando la cosa avance, ya iremos viendo.

31
Oct
2021

Cómo delegar fondos en un «stake pool»

Para ser capaces de delegar fondos en un determinado Stake Pool será necesario cumplir tres condiciones:

  1. La dirección de payment en la cual tenemos los fondos que deseamos delegar deberá estar asociada a una dirección de stake.
  2. Dicha dirección de stake debe estar convenientemente registrada en la en la cadena de bloques mediante un certificado de registro. Este certificado deberá ser remitido a la cadena de bloques con una transferencia específica que comporta un depósito. En el momento de escribir estas líneas, el depósito es de 2 ₳ 
  3. Será necesario, además, un certificado de delegación que asocie la dirección de stake con el pool seleccionado, que deberá ser remitido a la cadena de bloques con una transferencia estándar con la tarifa mínima.

Una vez realizado el proceso completo, los fondos depositados en la dirección de payment asociada a la clave de stake en cuestión participarán del monto total de fondos delegados al pool, colaborando en la creación de bloques por parte de ese pool y recibiendo recompensas por ello en la misma dirección de stake.

Dado el procedimiento, podemos ver también que cambiar de pool es tan sencillo como crear un nuevo certificado de delegación y remitirlo a la cadena de bloques, lo que implica una transacción estándar con tarifa mínima. El depósito inicial de 2 ₳ es necesario realizarlo solamente una vez para habilitar nuestra dirección a participar en el proceso de delegación. 

  • Crear una dirección de payment asociada a una dirección de stake

Para obtener una dirección de payment asociada a una dirección de stake, el procedimiento es muy sencillo, ya que basta con generar la dirección aportando la clave de verificación de stake, además de la clave de verificación de payment. En este ejemplo, para distinguir la dirección de payment asociada a stake de una dirección de payment regular, la llamaremos paymentwithstake.addr

cardano-cli address build \
--payment-verification-key-file payment.vkey \
--stake-verification-key-file stake.vkey \
--out-file paymentwithstake.addr \
--testnet-magic $MAGIC_NUM

  • Registrar la dirección de Stake

  • Crear un certificado de registro

Antes de poder empezar a delegar fondos es necesario registrar la dirección de stake en la cadena de bloques. Y el primer paso para ellos es crear un certificado de registro de dicha dirección.

cardano-cli stake-address registration-certificate \
--stake-verification-key-file stake.vkey \
--out-file stake.cert

A continuación, es encesario remitir el certificado a la cadena de bloques. Para ello, realizaremos una transacción desde la dirección de pago , en este caso, paymentwithstake.addr en la cual hay que incluir, de la tarifa estándar, el depósito antes mencionado. Ambas se deducen del balance de la dirección de pago a la hora de especificar el cambio devuelto.

Es importante señalar que en este tipo de transacción no se transfieren fondos a ninguna dirección. Tanto la tarifa como el depósito son descontados durante la transacción al calcular el balance resultante que es devuelto en la misma dirección de pago. El destino de ambas cantidades podemos entenderlo como una especie de servicio de tesorería dentro sistema de Cardano, el mismo que genera y administra las recompensas y la expansión monetaria del sistema. Los pasos para realizar la transacción son los habituales:

  • Obtenemos el balance de la dirección de pago

cardano-cli query utxo --address $(cat paymentwithstake.addr) --testnet-magic $MAGIC_NUM

                          TxHash                                 TxIx        Amount
--------------------------------------------------------------------------------------
96c74decbb8079ef017efabe5901ef40ff046a9c1f74ddd0c5eefc46353b53e5     0        1000000000 lovelace + TxOutDatumHashNone

  • Comprobamos la tarifa de registro

Si no lo hemos hecho antes, obtenemos los parámetros del protocolo que guardaremos en el archivo params.json. Entre otras muchas cosas, podemos obtener la tarifa por registrar la dirección de stake que, como ya hemos dicho, en este momento es de 2 ₳.

cardano-cli query protocol-parameters \
--testnet-magic $MAGIC_NUM \
--out-file params.json

  • Calcular el TTL (Time To Live)

Obtenemos el slot actual de la cadena para calcular el TTL (Time To Live) de la transacción

cardano-cli query tip --testnet-magic $MAGIC_NUM

{
    "epoch": 166,
    "hash": "13e9f47d0a19feb5f860a4b7b571162479ad103331cff1c56d24c116a937ae8f",
    "slot": 41347556,
    "block": 3036045,
    "era": "Alonzo",
    "syncProgress": "100.00"
}

Sabiendo que el tiempo entre dos slots es de un segundo, basta con sumar al slot actual un tiempo que consideremos razonable para armar la transacción sin prisas (normalmente, unos pocos minutos es suficiente)

  • Construimos el borrador de la transacción

Esto es necesario como paso previo para poder calcular la tarifa de la transacción. En este caso podemos dar un valor ‘0’ a los parámetros específicos de la transacción, tales como la tarifa, el cambio o el ttl.

cardano-cli shelley transaction build-raw \
--tx-in 96c74decbb8079ef017efabe5901ef40ff046a9c1f74ddd0c5eefc46353b53e5#0 \
--tx-out $(cat paymentwithstake.addr)+0 \
--ttl 0 \
--fee 0 \
--out-file tx.draft \
--certificate-file stake.cert

  • Calcular la tarifa mínima

A partir del borrador, calculamos la tarifa mínima

Es interesante comprobar que la tarifa de la transacción no depende para nada de las cantidades a transferir.

cardano-cli transaction calculate-min-fee \
--tx-body-file tx.draft \
--tx-in-count 1 \
--tx-out-count 1 \
--witness-count 1 \
--byron-witness-count 0 \
--testnet-magic $MAGIC_NUM \
--protocol-params-file protocol.json
 
172761 Lovelace

  • Construir la transacción definitiva

Aquí es donde podemos observar como la única dirección de salida es la misma que aquella de la que se obtienen los fondos y que se especifica solamente para recibir el «cambio» de la transacción, el cual es básicamente el balance inicial menos la tarifa y el depósito.

En mi caso, el cálculo de dicho cambio es el siguiente: 1000.000.000 – 2.000.000 – 172.761 = 997.827.239

cardano-cli transaction build-raw \
--tx-in 96c74decbb8079ef017efabe5901ef40ff046a9c1f74ddd0c5eefc46353b53e5#0 \
--tx-out $(cat paymentwithstake.addr)+997827239 \
--ttl 41444206 \
--fee 172761 \
--out-file tx.raw \
--certificate-file stake.cert

  • Firmar la transacción

Aquí podemos observar una caracterísitica específica de este tipo de transacción con respecto a una transacción convencional de movimiento de fondos: En este caso se proporcionan ambas claves de firma: la de pago y la de stake.

cardano-cli transaction sign \
--tx-body-file tx.raw \
--signing-key-file payment.skey \
--signing-key-file stake.skey \
--testnet-magic $MAGIC_NUM \
--out-file tx.signed

  • Enviar la transacción firmada

cardano-cli transaction submit \
--tx-file tx.signed \
--testnet-magic $MAGIC_NUM

Transaction successfully submitted.

Y… voilà!

  • Registrar la delegación en un determinado pool

  • Crear el certificado de delegación

Si deseamos delegar en un determinado pool, necesitaremos conocer el identificador de dicho pool. Se trata de un valor público que contiene la información necesaria para asociar nuestros fondos al pool sin necesidad de conocer sus claves y, por lo tanto, sin comprometer la seguridad del mismo.

cardano-cli stake-address delegation-certificate \
    --stake-verification-key-file stake.vkey \
    --stake-pool-id <stake pool ID> \
    --out-file deleg.cert

Igual que antes, hay que remitir este nuevo certificado a la cadena de bloques mediante una transacción que, en este caso, no implica realizar ningún depósito más allá de la tarifa estándar. Los pasos serán los mismos que en la transacción anterior.

 

Publicado por David en Blog, Cardano, 0 comentarios
30
Oct
2021
Acceso remoto SSH con clave pública y Google 2FA

Acceso remoto SSH con clave pública y Google 2FA

Las dos maneras más populares de asegurar una conexión SSH son el acceso mediante clave pública y la autenticación en dos pasos (2FA). La primera es la que más tradición tiene y la que llevo años utilizando en mis máquinas domésticas. La segunda es algo más reciente y nunca la había utilizado antes, así que me apeteció probarla para aumentar la seguridad. Hay decenas de tutoriales que explican el procedimiento, bastante sencillo, por cierto. Pero como el objeto de este blog es facilitarme las cosas a mí mismo y evitarme el ponerme a rebuscar, aquí dejo el enlace a la guía oficial de Ubuntu sobre el tema: Configure SSH to use 2FA

La verdad es que el acceso mediante 2FA es una chulada. Metes la contraseña y te pide un código del Google Authenticator. Sin embargo, una vez disipada la ilusión inicial pensé que no estaría de más sustituir el paso de introducir la contraseña por una autenticación mediante clave pública. Mucho más cómodo y, sobre todo, mucho más seguro. Así que configuré un par de claves RSA para entrar al servidor (proceso que aunque he realizado decenas de veces siempre se me olvida, así que también lo he dejado descrito por aquí).

La sorpresa vino cuando intenté la conexión. El hecho de haber configurado el acceso mediante clave hizo que la entrada al servidor fuera inmediata, sin solicitar el código de validación. Investigando un poco me entero de que, al parecer, el acceso mediante clave anula por defecto cualquier otro método de autenticación. Toda la configuración para el Google 2FA a hacer puñetas. Menudo chasco!

Así que vuelta a investigar la manera de poder mantener ambos modos de autenticación aunque, eso sí, sin necesidad de introducir la contraseña. De momento dos factores ya me parecen suficientes. Mejor dejar la autenticación multifactor (MFA) para más adelante.

Partimos de la configuración previa del archivo del servidor SSH, que coloco aquí mientras le busco un sitio mejor

sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication yes
PermitRootLogin prohibit-password

La cuestión es que si deseamos mantener ambos métodos de autenticación, de manera que ya no nos pida la contraseña (gracias a la clave RSA) pero nos continúe pidiendo el código de verificación, deberemos indicárselo explícitamente. Para ello, añadiremos una línea especificando dos posibles vías de autorización: O proporcionamos una clave pública y una contraseña, o bien una clave pública y un código de verificación.Las dos posibilidades están descritas en forma de dos listas de métodos. Las listas están separadas por un espacio. Y en cada lista, los métodos requeridos están separados por comas. Si los requisitos de una lista no se dan, entonces se pasa a la siguiente.
Como la configuración de este parámetro parece algo liosa, dejo aquí este enlace en el que lo explican todo muy bien y de manera muy detallada.

AuthenticationMethods publickey,password publickey,keyboard-interactive

Luego debemos modificar el archivo de configuración de PAM para que no nos pida la contraseña

sudo nano /etc/pam.d/sshd

Y comentamos la siguiente línea

#@include common-auth

Y ya está. Si os estáis preguntando por qué es necesario decirle a PAM que no pida contraseña en lugar de quitarla directamente de la lista de los métodos de autorización, os diré que yo me pregunto lo mismo. Lo único que sé es que hice la prueba y no funcionó, pero con el método descrito va como la seda.

Publicado por David en Blog, Seguridad, SSH, 0 comentarios