jueves, abril 10, 2014

Especulemos, ya que hablamos de especulaciones.

Terremoto en el norte

No se necesita hablar mucho de esto, es lo primero que se sabe y aquí surgen las primeras especulaciones, en base a la historia sísmica del país (Chile), ya lo sabe ud. casas derrumbadas, tsunamis, mucha gente muerta, desaparecida, autoridades inoperantes, opositores sacando ventaja política, noticieros y canales de televisión buscando el drama humano, etc. Especulaciones al fin y al cabo, que todos hacemos, sin saber lo que realmente pasa.

Ley de la Oferta y la Demanda

Básicamente, esta supuesta "ley" que no obliga a nadie a hacer algo o penaliza a alguien por no acatarla, dice que si alguien vende 10 panes, y el en el barrio hay 20 personas que consumen habitualmente 5 panes al desayuno, querrán más panes para comprar (aumenta la demanda), y como la oferta es poca, entonces suben los precios. Por otro lado, si ahora el panadero tiene para vender 200 panes, significa que le podrían sobrar panes, ya que las 20 personas comprarían 100 panes en total (sube la oferta, se mantiene la demanda), bajan los precios.

Así de simple parece la cosa, sube la demanda, baja la oferta, suben los precios. ¿Esto es especulación?. Quien sabe... si es una "ley", alguien o algunos deben asumir de que se cumple, siempre.

Escasez de recursos post-terremoto

Lo que muchos ya supimos, en nuestra realidad cercana (terremoto 2010), es que cuando hubo el terremoto, se cortaron caminos, se apagó la luz, se rompieron cañerías, en fin, como consecuencia, no se pudo hacer pan, procesar leche, abrir supermercados, etc. ¿Especulación?. No, así fue. ¿Debiera haber ocurrido igual ahora, con el terremoto en el norte?. Bueno, alguien podría decir que responder que sí sería especular. Pero nuestra historia nos indica que eso ocurre después de un terremoto de esa magnitud (sobre 8.0). ¿Podemos asegurar de que después de un terremoto no se produzca desabastecimiento?. Sí, se podría, pero creo que Chile no está preparado para eso aún (estoy especulando).

Rol de un Estado

Creo, en lo personal, que un Estado debería al menos entregar un estado de situación después de una catástrofe para poder saber en qué situación se encuentran los afectados y cómo se les podría ayudar. En este caso, saber qué les faltará a los nortinos y cómo hacerles llegar los bienes de "necesidad básica". Pero parece que de eso hubo poco, sólo leímos en algunas noticias que ciertos bienes estaban escaseando y la gente reclamaba porque algunos almacenes estaban subiendo los precios. Aquí es, estimado lector, donde comenzaré a manipular su entendimiento, ponga atención.

La Noticia del Momento

Si ud. busca en Google, noticias sobre la especulación en el norte, verá numerosos artículos relacionados con que, hay almacenes (no supermercados) que están subiendo los precios, y muestran declaraciones de las fiscalías que hablan de que los especuladores serán apresados, condenados, perseguidos, qué sé yo. Una por ahí dice en el último párrafo: "El persecutor, además, indicó que hasta el momento no se registran denuncias formales por esta esta materia y entregó algunas claves a los usuarios para denunciar esta situación a las policías.". No hay denuncias formales, vaya, eso suena a "especulación" sobre la existencia de especuladores. Probablemente, algún nortino me dirá: "Pero si es verdad", mientras no lo haga, es especulación que exista subida de precios o que yo crea que no exista. ¿Con cuál afirmación se quedaría ud?.

Bueno, lo que me llamó la atención es que las noticias hablan de "comerciantes" o "almacenes", pero no de supermercados. Lo primero que se me vino a la mente fue: "Yo sé que los medios de comunicación suelen proteger a los supermercados grandes, como Jumbo, porque es un cacho meterse con sus abogados o perder los ingresos por publicidad". Así que busqué en Google, sobre noticias acerca de los supermercados en el norte, post-terremoto. Y encontré titulares como estos: "Supermercados se la juegan con precios "normales" en el norte", ¿en qué diario? La Cuarta, el diario "popular", o titulares relacionados con la reapertura de los supermercados. Algunos podríamos interpretar esto como "Nuestros héroes, los supermercados", y nuestros villanos "Los almacenes". ¿No, verdad? ¿Sí, tal vez?

La Doctrina del Shock

Bueno, "La Doctrina del Shock" es una etiqueta utilizada para un concepto relacionado con el interés económico de ciertas personas. Digamos que, en resumen, parten de las ideas de Milton Friedman para que la economía como la conocemos (al menos en Chile) se abra paso y sea exitosa. Aunque, no todo lo "exitoso" es bueno. En este caso, la Doctrina del Shock hace referencia a que a una sociedad se le somete bruscamente a aceptar nuevas políticas económicas con miras a una libre economía de mercado, esto es, para muchos (pero lo pongo en duda) a que la ley de la oferta y la demanda funcione tiqui-taca, hayan más competidores, y en esta competencia por la venta de productos, los precios se regulen.

Pero las ideas de Milton Friedman tienen algunos inconvenientes, ya que él estima que toda regulación estatal o empresas públicas son un estorbo para el modelo y el Estado debería deshacerse de estas, vendiéndolas a un bajo precio. Esto produce, en países de estados grandes, mucho desempleo, le gente se opone en general, hay protestas, etc. La pregunta es, ¿cómo se somete bruscamente a una sociedad a aceptar estas ideas?. Una alternativa, es lo que ocurrió en Chile el año 1973. Un golpe de estado, que dejó a la población atemorizada y bueno... ya ud. puede averiguar qué pasó económicamente, antes, durante y después de este golpe. Otra alternativa es un desastre natural.

En EEUU, antes del Huracán Katrina, se quería terminar con las escuelas públicas, pues la educación es un negocio lucrativo y habían varias escuelas públicas en Nueva Orleans que "controlaban la oferta y la demanda", hasta que ocurrió lo del Huracán. Un economista dijo, entonces, algo como: "Lo que nosotros no pudimos hacer en 3 años, Dios lo hizo en 3 días", y parece que fanfarroneaba diciendo que Dios estaba de parte de ellos. Y así, lograron privatizar con facilidad la educación en ese lugar.

En Chile, hace algunos años, hubo una "polémica" entre panaderos y supermercados, debido a que estos últimos bajaban mucho el precio del pan para así, según los panaderos, sacarlos del mercado. Esto es, que la gente preferiría comprar en el supermercado, en vez de comprar en las panaderías. Esto haría quebrar a los panaderos, y luego los supermercados retomarían el precio normal o, incluso, subirlo. Como ya no habrían más panaderías, era "grito y plata" para los supermercados. Algunos indicaron en ese entonces (especulando o no) que los supermercados incluso vendían el pan bajo el precio de costo (es decir, lo que el propio supermercado pagaba por hacer o conseguir el pan), teniendo perdidas, pero como eran grandes empresas, podían sobrevivir lo suficiente como para ganar la competencia y hacer desaparecer a las panaderías.

Aquí la gran especulación

En el norte, ocurrió un desastre. Tal vez no con consecuencias similares al 2010, pero dado que ahora ya no hay tantas víctimas en general (a diferencia de 1960), los humanos luchan por otras cosas. En este caso, los recursos: el pan, la leche, el agua. Tener el control de estos recursos, es un negocio lucrativo. Si ud. busca el significado de especulación, uno de los significados es que se refiere al hecho de comprar algo, para después venderlo más caro.

Lo que no he leído en los reportajes, es cómo un "almacen" consigue o hace el pan, la leche, el agua que vende. ¿De dónde consigue, y a qué precio, los sumistros?. Si no hay agua potable, ¿quién le vende al almacén el agua?. ¿Dónde consigue la harina?. ¿Se la venderán cara como ellos mismos suben el precio del pan?. En Chile, el agua es privada. Es controlada por grandes empresas. ¿Si ellos no pueden entregar el agua, de dónde sale entonces?. La municipalidad regala el agua. Es una opción. ¿Entonces, quién fiscaliza que el agua regalada no sea utilizada para obtener rentas de manera fácil?.

Así, nos focalizamos superficialmente, en el producto final. En el que comercializa, pero no regala. El almacén. Muerte a los especuladores, muerte a los almacenes que se aprovechan del débil. Gloria y besos a los supermercados que vuelven a ayudarnos.

Milton Friedman decía que no tenía que forzar a la gente a aceptar sus ideas, que la gente misma sería quien pediría casi a gritos que sus ideas fueran implementadas. Este es el caso.

El problema de fondo

Pero el problema de fondo es que los chilenos somos una sociedad difusa, dispersa e interesada. Si esto nos lleva a obtener beneficios, autos, placeres y dinero, eso está bien mientras no estemos del otro lado; del que sueña con un auto, sueña con placeres, pero sólo consigue trabajo por el mínimo y se droga para apaciguar sus penas. Si fuera un religioso y moralista, diría que los terremotos los tenemos bien merecidos, castigos a nuestra indiferencia social, a competir por ser mejor que el otro, a morbosear con el sufrimiento del otro. Si quisiéramos implementar un cambio hacia una sociedad más empática, más solidaria, equitativa, etc., empezaríamos por decir: "Ya, pero comienza tú... no, mejor tú. Tú primero. Si no lo hace él, no lo hago yo..." y así. Saldrían los filósofos individualistas diciendo: "Si quieres un cambio, comienza por ti".

Para mi, la solución parte por saber qué mierda queremos cada uno, si lo lograríamos sólo o si vale la pena trabajar en masa para lograrlo. Probablemente, habrá quienes tendrán que subyugar a otros para lograr lo que quieren o aprovecharse de otros. ¿Aceptamos eso?. Bueno, depende. Creo que si fuésemos una nación que pensara así, sería una alerta para nuestros vecinos porque entonces tendríamos que invadirlos (no sacamos nada con subyugarnos a nosotros mismos), ah.. pero creo que ya lo hicimos en 1879.

Y si no aceptamos ese tipo de sociedad, ¿qué hacemos con quienes si quieren eso?. ¿Se les extermina, se les "re-educa", se les "rehabilita"?. Tal vez, debamos respondernos a la pregunta: ¿Queremos perpetuarnos como sociedad?, ¿Queremos que los "chilenos" existamos para siempre?. No creo que eso nos importe en 100 años más, no vamos a estar.

Basta que alguien no respete a otro, para exista una sociedad violenta. El que no respeta, violenta al otro y este otro tiene dos alternativas, al menos, una es "poner la otra mejilla" y otra es "responderle" de la misma forma.

Cuando me divorcié, vi una tercera alternativa: Separarse. Tal vez, somos una sociedad internamente dividida en aspectos radicales, pero nos unimos en aspectos superficiales (un partido de fútbol, por ejemplo).

Yo voto por ser parte de una sociedad más empática, solidaria, equitativa. El que no quiera eso, que se aparte o yo me apartaré de él.

martes, abril 08, 2014

Git sobre Linux EC2 Amazon

Introducción

La siguiente información se basa en la documentación de git-scm.com y se asume acceso exitoso a una instancia Linux EC2 Amazon.

Aquí haremos una secuencia diferente a la propuesta por la documentación de GIT, partiremos por el capítulo 4 de la documentación, teniendo como conocimiento básico el crear un repositorio, subir un cambio y clonar el proyecto localmente.

El objetivo a conseguir es poder iniciar un proyecto nuevo desde un repositorio remoto y trabajar en forma local desde cero. Donde "remoto" hará referencia al repositorio git en EC2 Amazon ("origin" en terminología git) y "local" hace referencia al repositorio en el ambiente de trabajo ("workspace").

Pasos a Seguir

De acuerdo a la documentación, de los cuatro protocolos, configuraremos el sistema para usar el protocolo SSH, esto porque es la forma principal de acceso a EC2 Amazon, mediante el uso del par de llaves pública y privada.

En el Capítulo 4.2, sección SSH Access, se indican tres posibles formas de establecer conexiones hacia Git. Una es usando LDAP, otra es crear múltiples usuarios en el servidor, pero eso implicaría mantener muchas cuentas. Y otra manera, que es la que configuraremos aquí, es tener un sólo usuario llamado "git" que es utilizada por otros usuarios. Aquí surge la pregunta: Si sólo existe un usuario "git", ¿cómo se diferenciará el aporte de cada usuario al proyecto? La respuesta radica en la configuración de git en cada usuario, esa es la información que viaja. Todos los usuarios pueden compartir la misma llave privada (no es la idea) o cada usuario genera su par de llaves pública y privada. El proceso será el siguiente:

1) Instalación básica de Git en Linix EC2 Amazon.
2) Se creará un usuario "git" en el servidor EC2 que utilice la misma llave de acceso del usuario por defecto de EC2.
3) Se creará un proyecto remoto vacío. Se clonará este proyecto desde el ambiente local. Se creará un archivo "readme.txt" que se agregará al repositorio. Se clonará el proyecto nuevamente en otro lugar para apreciar los cambios.
4) Se creará otro usuario de pruebas que se conecte al repositorio Git. Se deberá crear una llave privada y una pública. Al crear la llave, se puede decidir aquí qué formato de identificación tendrá cada usuario, si es que se quiere tener un estándar. Por ejemplo, identificar a cada usuario por su nombre, su email, su nombre.apellido, etc.
5) La llave pública se almacena como "llave autorizada" para el usuario Git en el servidor.
6) Se hará un cambio en el archivo del proyecto con el nuevo usuario.

Instalando Git

Ya que nos conectamos con el usuario por defecto a EC2, instalamos con "sudo" el paquete de git. Utilizamos "yum" por ser la opción en Linux EC2 Amazon.
sudo yum install git-core
Configuramos información básica para Git, en este caso, el administrador del repositorio remoto que creará el proyecto. Configuramos el nombre (user.name), el email (user.email) y luego verificamos la información. Ejecutar los siguientes tres comandos (como ejemplo, van mis datos)
git config --global user.name "Javier Villalobos Arancibia"
git config --global user.email javier.villalobos.arancibia@gmail.com
git config --global -l

Creando el Usuario Git

Nos guiamos por la documentación para administración de usuarios en EC2 Amazon para crear el usuario "git" en el servidor remoto, seguimos tal cual los pasos que allí se indican hasta el paso 2.e, luego, probaremos la conexión de este usuario con el par de llaves pública y privada del usuario "ec2-user". Para esto, necesitamos concatenar la llave pública del usuario ec2-user hacia el archivo authorized_keys del usuario "git".

Estando como usuario "ec2-user" copiamos el archivo authorized_keys de ese usuario al directorio /tmp/ del servidor.
cp authorized_keys /tmp/
Luego cambiamos los permisos del archivo para que el usuario "git" pueda tener acceso a él.
cd /tmp
chmod 666 authorized_keys
Ahora, cambiamos a usuario "git", nos situamos en su directorio ".ssh" y agregamos la llave pública de "ec2-user"
sudo su - git
cd /home/git/.ssh
cat /tmp/authorized_keys >> authorized_keys
Deberíamos probar la conexión a EC2 con el usuario "git" sin tener que generar llave pública o privada. Simplemente, en nuestros clientes SSH ya configurados para el usuario "ec2-user", debemos utilizar el usuario "git".

Si usamos la aplicación "Git Bash" en Windows, podemos probar esta conexión vía consola de la siguiente manera.

1) Por defecto, la conexión SSH de Git Bash utiliza el archivo "id_rsa" como llave privada que está en el directorio .ssh en la carpeta del usuario de windows.
2) La llave privada de tipo "OpenSSH" que hayamos generado para "ec2-user" debemos copiarla con este nuevo nombre "id_rsa" en la carpeta del usuario de windows. Si ya tenemos un archivo "id_rsa" allí y no deseamos perderlo, podemos usar otro nombre, pero al ejecutar el comando SSH, debemos indicar la opción "-i" y la ruta hacia este nuevo nombre
3) Abrimos la aplicación "Git Bash".
4) Escribimos el comando para conexión SSH.
ssh git@dns_público_ec2
Donde "dns_público_ec2" es el DNS público para nuestra instancia EC2. Si necesitamos indicar que la llave privada está en otro lugar o tiene otro nombre diferente a "id_rsa":
ssh -i /c/ruta_hacia_archivo/archivo_llave_privada_openssh git@dns_público_ec2

Proyecto Git Demo

A continuación los pasos para crear un proyecto vacío que se agregará al repositorio. Estas actividades las realizaremos con el usuario "ec2-user" (el administrador Git).

1) Creamos un directorio "git" donde se almacenarán nuestros proyectos remotos (origin).
cd /
mkdir git
sudo chown ec2-user:git git
sudo chmod 770 git
2) En seguida, ingresamos al directorio "git", y creamos la carpeta para un proyecto que llamaremos "demo". Nos guiamos por la documentación de Git al respecto.
cd /git
mkdir demo.git
sudo chown ec2-user:git demo.git
sudo chmod 770 demo.git
cd /git/demo.git
git --bare init
3) Ahora, volvemos a nuestro ambiente local y nos situamos en algún directorio destinado para nuestro "workspace". Se asume a continuación, ambiente windows con "Git Bash" instalado, las configuraciones básicas para Git establecidas (user.name, user.email) y la conexión SSH a EC2 para usuario git funcionando.
4) Una vez en nuestro "workspace", ejecutamos la aplicación Git Bash y clonamos el proyecto "demo".
clone git git@dns_público_ec2:/git/demo.git
Al revisar el directorio, deberíamos visualizar la carpeta "demo" y dentro el directorio ".git" que contiene la información para git.
5) Ingresamos al directorio "demo", creamos un archivo "readme.txt" con algún texto en su interior.
6) Luego hacemos las operaciones básicas para commit y push.
git add readme.txt
git commit -m 'Primer demo'
git push origin master
7) Ya que nuestro directorio remoto fue creado con --bare, no existe "workspace" remoto donde veamos los cambios, así que lo que haremos será irnos a otro directorio local donde clonaremos nuevamente el proyecto "demo".
git clone git@dns_público_ec2:/git/demo.git
Al ejecutar nuevamente el comando "clone" en otro directorio vacío, nuevamente obtendremos una carpeta "demo", pero esta vez, en su interior veremos nuestro archivo "readme.txt" creado anteriormente.

Colaborando con Otros Usuarios

Como mencionamos antes, para agregar a otros usuarios, estos deben generar el par de llaves pública y privada. La llave privada queda en poder el usuario y la llave pública se envía al administrador para agregarla como acceso autorizado del usuario "git".

Hay muchas formas de generar el par de llaves, lo importante es que sea en formato "OpenSSH". La aplicación "Git Bash" permite crear llaves, y el procedimiento es el siguiente:

1) Ejecutar "Git Bash" y ejecutar comando "ssh-keygen".
ssh-keygen -t rsa -C "segundo.usuario"
Al ejecutar este comando, nos preguntará dónde y con qué nombre se almacenará la llave. Si sólo ponemos el nombre, por ejemplo "segundo.usuario", las llaves quedarán guardadas en el directorio donde ejecutamos Git Bash. Si se requiere almacenar en otro lugar, se debe especificar la ruta completa. Si no ponemos nada, por defecto las guardará donde indica (id_rsa en directorio .ssh del usuario de Windows). Luego nos pedirá una "passphrase", podemos especificar alguna o dejarla sin nada, pero si la especificamos, cada vez que necesitemos autenticarnos deberemos ingresarla.

Aquí creamos un par de llaves pública y privada. La opción "-C" es para agregar un comentario, con esto podemos identificar a quién pertenece esta llave cuando la agreguemos como acceso al usuario "git"
2) En el paso anterior, a modo de ejemplo, generamos la llave pública "segundo.usuario.pub" que es la que debe ser enviada al administrador.

Dar Acceso para Usuario Colaborador en Git Remoto

El administrador, deberá copiar el contenido del archivo PUB (llave pública recibida) y agregarlo al archivo "authorized_keys" del usuario "git", esto es, anexar la información manteniendo las otras llaves públicas existentes en el archivo. Si el archivo (llave pública) fue generado en sistema Windows, se debe tener cuidado que el formato de la información sea compatible con Linux y no existan problemas de lectura de la llave (ejecutar comando "dos2unix" para transformar archivo recibido).

Una forma segura de concatenar la nueva información es seguir los siguientes pasos. Se asume que el archivo recibido "segundo.usuario.pub" se encuentra en el directorio "/tmp" del servidor remoto.
cd /tmp
sudo chown ec2-user:git segundo.usuario.pub
sudo chmod 770 segundo.usuario.pub
Luego, como usuario "git" se concatena la información al archivo "authorized_keys"
sudo su - git
cd /home/git/.ssh
cat /tmp/segundo.usuario.pub >> authorized_keys
El usuario colaborador "segundo.usuario" ya tiene permisos de acceso para "git".

Haciendo una Modificación

El nuevo usuario (segundo.usuario) ya puede hacer "clone" del proyecto. Después que lo haga, podrá hacer un cambio al archivo "readme.txt" y actualizar dicho cambio en el repositorio remoto:
git add readme.txt
git commit -m 'Cambio de segundo.usuario'
git push origin master
A continuación se muestran los cambios realizados en el repositorio remoto (origin), usando la aplicación "Gitk":

En esta imagen se muestra el primer "commit" que es cuando se creó el archivo readme.txt, por el usuario "Usuario ec2-user"

En esta segunda imagen, se muestra el segundo cambio, realizado por el usuario "segundo.usuario".

sábado, abril 05, 2014

Conectar a Linux EC2 Amazon por Consola en Clientes Windows

Introducción
Los servidores Linux EC2 de Amazon, no utilizan un "user" y "password" para autenticarse, en vez de ello utilizan llaves de crifrado públicas y privadas. Cuando se crea una instancia EC2, en el proceso se debe crear un par de estas llaves. EC2 almacena la llave pública y le envía la llave privada al usuario (descarga archivo PEM).

Cuando se conecta a una instancia por consola, el cliente o consola usa la llave privada para generar la firma o credencial y se envía a EC2, quien usa la llave pública que guardó anteriormente para verificar que la firma es correcta.

Por lo tanto, es importante que cuando se crea la instancia y el par de llaves, la llave privada (PEM) no debe perderse.
PUTTY
El programa Putty utiliza una estructura diferente para la información de la llave privada, esta se guarda en un archivo PPK. Ya que EC2 utiliza PEM, lo que se debe hacer es crear el PPK equivalente. De la siguiente forma:
1) Utilizar aplicación PuttyGen

2) Cargar llave PEM

En PuttyGen, oprimir botón "Load" y en cuadro de diálogo, se debe seleccionar "Todos los archivos" en Tipo, que por defecto aparece seleccionado filtrando los archivos de tipo PPK. Al hacer esto, debiera aparecer el archivo PEM que se descargó al crear la instancia EC2 (poner cuidado en el cuadro de diálogo que el directorio mostrado corresponda al lugar donde se almacenó el archivo PEM)

3) Apenas se selecciona el archivo PEM y se pulsa "Abrir", PuttyGen genera el equivalente OpenSSH SSH-2 RSA e indica que se debe usar "Save private key" para guardar esta información en el formato Putty (PPK)

4) Luego de dar "Aceptar" a la notificación anterior, queda en la interfaz de PuttyGen la información cargada que se generó. Tal como decía la notificación, se pulsa "Save private key" para guardar la llave privada en formato PPK. Nótese que están los campos "Key passphrase" y "Confirm passphrase" en blanco. Llenarlos depende de cómo se generó la llave privada originalmente al crear la instancia EC2.

5) Si los campos para "passphrase" se encuentran en blanco, al pulsar "Save private key" aparecerá un cuadro de confirmación alertando esta situación. Pulsar "SI" para continuar con los campos de "passphrase" en blanco. Aparecerá el cuadro de diálogo para guardar la información y se debe ingresar el nombre del par de llaves (Key Pair Name) original, sin extensión, Putty agrega en forma automática la extensión PPK. Tener cuidado de seleccionar un nombre existente de la lista, sólo para después modificar la extensión o agregar algo adicional, una vez que se selecciona un nombre, la aplicación asume que se quiere reemplazar el archivo existente y alerta de esta situación.

6) Para probar la conexión por consola, se debe tomar en cuenta el DNS Público de la instancia y el usuario de conexión (generalmente "ec2-user"). Ahora se debe utilizar la aplicación Putty



En el campo Host Name, escribimos la URL de conexión con formato "user@dns_public". En Port usamos 22, y en Connection Type, seleccionamos SSH. Opcionalmente, puede guardarse esta configuración dando un nombre en el campo "Saved Sessions" y pulsando el botón "Save". Al volver a conectar, se selecciona la sesión de la lista y se pulsa "Load". Pero eso no es todo, falta indicarle a Putty, qué llave usar.
7) En las opciones de configuración de la izquierda de la interfaz anterior, ir a Connection -> SSH -> Auth.



Pulsar el botón "Browse..." en la derecha y buscar el archivo PPK antes generado, y eso es todo. Oprimir "Open" para establecer la conexión.
SSH Secure Shell Client
Este cliente para SSH utiliza otro formato para las llaves privadas. Pero el proceso es similar a con Putty. Eso sí, que necesitaremos nuevamente a PuttyGen.

1) Utilizar aplicación PuttyGen

2) Cargar llave PEM

En PuttyGen, oprimir botón "Load" y en cuadro de diálogo, se debe seleccionar "Todos los archivos" en Tipo, que por defecto aparece seleccionado filtrando los archivos de tipo PPK. Al hacer esto, debiera aparecer el archivo PEM que se descargó al crear la instancia EC2 (poner cuidado en el cuadro de diálogo que el directorio mostrado corresponda al lugar donde se almacenó el archivo PEM)

3) Apenas se selecciona el archivo PEM y se pulsa "Abrir", PuttyGen genera el equivalente OpenSSH SSH-2 RSA e indica que se debe usar "Save private key" para guardar esta información en el formato Putty (PPK)

4) Luego de dar "Aceptar" a la notificación anterior, queda en la interfaz de PuttyGen la información cargada que se generó. Ahora, a diferencia de generar la llave privada PPK para Putty, debemos convertirla a otro formato. Esto lo hacemos desde la opción "Export ssh.com key" en el menú "Conversions" de PuttyGen. Al seleccionar esta opción, nuevamente nos alertará si los campos para "passphrase" están en blanco. Llenarlos depende de cómo se generó la llave privada originalmente al crear la instancia EC2. Decimos que "SI" para continuar y se abrirá el cuadro de diálogo para almacenar la llave privada en el nuevo formato. Escribimos el nombre del par de llaves (Key Pair Name) original, sin extensión. Tener cuidado de seleccionar un nombre existente de la lista, sólo para después modificar la extensión o agregar algo adicional, una vez que se selecciona un nombre, la aplicación asume que se quiere reemplazar el archivo existente y alerta de esta situación.

5) Si vemos la información generada, veremos que ahora tenemos un archivo sin extensión que contiene nuestra llave privada. Luego, en la interfaz pulsamos el botón "Save public key" para guardar la llave pública en formato PUB. En el cuadro de diálogo para guardar la información, nuevamente escribimos el nombre del par de llaves (Key Pair Name) original, pero esta vez agregamos la extensión ".pub"
6) La aplicación SSH Secure Shell Client guarda sus llaves en el directorio "Application Data\SSH\UserKeys" que se encuentra en la carpeta del usuario de windows. Allí se deben copiar las dos llaves generadas anteriormente, el archivo sin extensión y el archivo PUB.
7) Al abrir la aplicación SSH Secure Shell Client se debe crear un perfil de conexión, en "Profiles" (opción que se encuentra bajo la barra de menúes)



Al seleccionar "Add Profile...", sólo se crea el nombre para el perfil. Luego, se debe seleccionar "Edit Profile..." para agregar la configuración.
8) Aquí se agrega la información para Host Name (escribir el DNS Público de la instancia EC2), el usuario (generalmente "ec2-user") y en Port number, ingresar 22. Se pulsa OK, para guardar la información
9) Para conectarse, se selecciona el perfil creado y se realiza la conexión.