Difference between revisions of "SSH keys (Español)"

From ArchWiki
Jump to: navigation, search
(rm temporary i18n template)
m (Generando las llaves SSH: Pequeñas correcciones ortográficas)
 
(30 intermediate revisions by 6 users not shown)
Line 1: Line 1:
[[Category:Networking (Español)]]
+
[[Category:Secure Shell (Español)]]
[[Category:Security (Español)]]
+
[[en:SSH keys]]
[[en:SSH Keys]]
+
[[it:SSH keys]]
[[it:SSH Keys]]
+
[[ja:SSH ]]
[[ru:SSH Keys]]
+
[[ru:SSH keys]]
[[sr:SSH Keys]]
+
[[sr:SSH keys]]
[[tr:SSH_Anahtarları]]
+
[[zh-hans:SSH keys]]
[[zh-CN:SSH Keys]]
+
{{Translateme (Español)|En  proceso de traducción}}
==¿Que son las Llaves SSH?==
 
  
Al usar una llave SSH ( una publica y una privada para ser precisos), usted puede conectarse fácilmente a un servidor, o a múltiples servidores, sin tener que ingresar un password cada vez.
+
Al usar una llave SSH ( una publica y una privada para ser precisos), se puede conectarse fácilmente a un servidor, o a múltiples servidores, sin tener que ingresar una contraseña cada vez [[Wikipedia:es:Criptografía_asimétrica|Criptografía_asimétrica]] y [[Wikipedia:es:Protocolos_desafío-respuesta|Protocolos_desafío-respuesta]].
 +
Una ventaja inmediata de este método sobre el clásico método de autenticación con contraseña, es que es posible autenticarse sin necesidad de enviar la contraseña por la red, así que alguien espiando la red no podrá interceptar e intentar descifrar la contraseña ya que esta nunca sera enviada. Adicionalmente, el uso de llaves de SSH virtualmente elimina el riesgo de ataques de fuerza bruta al reducir la probabilidad de que un atacante adivine las credenciales correctamente.
  
Es posible configurar tus llaves sin una frase-de-paso, sin embargo eso seria imprudente, si alguien obtiene su clave, podría usarla. Esta guiá describe como configurar su sistema para que las llaves-de-paso sean recordadas de forma segura.
+
Ademas de ofrecer seguridad adicional, autenticación con llaves SSH puede ser mas conveniente que el método tradicional de autenticación con contraseña. Cuando se usa con un programa conocido como Agente SSH, las llaves SSH le permiten conectarse con uno o múltiples servidores sin necesidad de tener que recordar la contraseña de cada sistema.
  
===Generando las llaves SSH===
+
Llaves SSH también tienen algunas desventajas y puede que no funcionen en todos los ambientes, pero en muchas circunstancias pueden ofrecer bastantes ventajas. Un entendimiento general de como funcionan las llaves SSH le ayudaran a decidir como y cuando usarlas para satisfacer su caso especifico.
Si todavía no tiene OpenSSH instalado, instalelo ahora ya que no viene por defecto en Arch.
 
  
      #pacman -S openssh
+
Este articulo asume que el lector tiene un conocimiento básico del protocolo de [[Secure Shell (Español)|Shell Segura]] y que el paquete {{Pkg|openssh}} ha sido [[Help:Reading_(Español)#Instalaci.C3.B3n_de_paquetes|instalado]].
  
Las llaves pueden ser generadas corriendo el comando ssh-keygen como usuario
+
== Informacion preliminar ==
  
$ ssh-keygen -b 1024 -t dsa
 
Generating public/private dsa key pair.
 
Enter file in which to save the key (/home/mith/.ssh/id_dsa):
 
Enter passphrase (empty for no passphrase):
 
Enter same passphrase again:
 
Your identification has been saved in /home/mith/.ssh/id_dsa.
 
Your public key has been saved in /home/mith/.ssh/id_dsa.pub.
 
The key fingerprint is:
 
x6:68:xx:93:98:8x:87:95:7x:2x:4x:x9:81:xx:56:94 mith@middleearth
 
  
Le pedirá por una locación (debe dejar la que le muestre  por defecto), sin embargo la frase-de-paso es el punto importante! Debe ser consiente del criterio que hace una buena frase-de-paso.
+
Las llaves de SSH siempre son generadas en pares con una llamada ''llave privada'' y otra llamada ''llave pública''. La llave privada solo es conocida por el usuario y debe ser guardada con cuidado. En contraste, la llave pública puede ser compartida libremente con cualquier servidor SSH con el que se quiere conectar.
  
¿Que acabamos de hacer? Generamos un par de llave publica/privada dsa({{ic|-t dsa}}) de 1024 bits de largo({{ic|-b 1024}}) con el comando ssh-keygen.
+
Si un servidor SSH tiene su llave pública y nota que hay un intento de conexión, usa su llave pública para construir y enviar un desafío. Este desafío es un mensaje encriptado y debe ser respondido apropiadamente antes de que el servidor le dé acceso. Lo que hace este mensaje particularmente seguro es que solo se puede descifrar con la llave privada. Mientras que la llave pública puede ser usada para encriptar el mensaje, no puede ser usada para descifrarlo. Solo el usuario, que tiene la llave privada puede ser capaz de descifrar correctamente el desafío y producir la respuesta adecuada.
  
Si quiere crear un par de llave RSA en vez de DSA solo debe usar {{ic|-t rsa}} ( no debe especificar el largo "-b" por defecto el largo para RSA es de 2048 y es suficiente)
+
Este intercambio de desafío-respuesta ocurre como una tarea de fondo y es invisible para el usuario. Mientras se tenga la llave privada, la cual es guardada normalmente en la carpeta {{ic|~/.ssh/}}, su cliente SSH debería ser capaz de responder apropiadamente al servidor.
  
{{Note|NOTA: Una llave DSA debe ser exactamente de 1024 bits por especificación. Una llave RSA puede ser entre 768 bits y 4096 bits.}}
+
Una llave privada es un secreto a guardar, por ende se aconseja que cuando se guarde se haga de manera encriptada. Cuando la llave encriptada es requerida, una contraseña debe ser ingresada para descifrarla. Aunque superficialmente esto parece como si se estuviera poniendo una contraseña para ingresar al servidor de SSH, esta contraseña solo se usa para descifrar la llave privada en el sistema local. Esta contraseña no se transmite sobre la red.
  
===Copiando las llaves al servidor remoto===
+
== Generando las llaves SSH ==
Ahora que hemos generados las llaves, necesitamos copiarlas al servidor remoto. Por defecto, para OpenSSH, la llave publica necesita ser concatenada dentro de {{ic|~/.ssh/authorized_keys}}.
 
  
$ scp ~/.ssh/id_dsa.pub mith@metawire.org:
+
Un par de llaves SSH puede ser generado ejecutando el comando {{ic|ssh-keygen}}, por defecto usando seguridad 2048-bit RSA (y SHA256) la cual de acuerdo a {{man|1|ssh-keygen}} es "''considerada generalmente suficiente''" y debe ser compatible con virtualmente todos los servidores y clientes:
  
Esto copia la llave publica ({{ic|id_dsa.pub}}) al servidor remoto vía {{ic|scp}} ( notese los {{ic|:}} al final de la dirección del servidor). el archivo acabara en el directorio home, pero se puede especificar la dirección que uno desee.
+
{{hc
 +
|$ ssh-keygen
 +
|<nowiki>Generating public/private rsa key pair.
 +
Enter file in which to save the key (/home/<username>/.ssh/id_rsa):  ### Ubicación de las llaves
 +
Enter passphrase (empty for no passphrase):                           ### Contraseña de la llave
 +
Enter same passphrase again:                                          ### Repetir la contraseña
 +
Your identification has been saved in /home/<username>/.ssh/id_rsa.   ### Nombre llave privada
 +
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub.  ### Nombre llave publica
 +
The key fingerprint is:
 +
SHA256:gGJtSsV8BM+7w018d39Ji57F8iO6c0N2GZq3/RY2NhI username@hostname
 +
The key's randomart image is:
 +
+---[RSA 2048]----+
 +
|  ooo.          |
 +
|  oo+.          |
 +
|  + +.+          |
 +
| o +  +    E . |
 +
|  .  . S . . =.o|
 +
|    . + . . B+@o|
 +
|      + .  oo*=O|
 +
|      .  ..+=o+|
 +
|          o=ooo+|
 +
+----[SHA256]-----+</nowiki>}}
  
Inmediatamente en el servidor remoto, necesitamos crear el directorio {{ic|~/.ssh}}, en el caso de no existir, y concatenar la llave al archivo {{ic|authorized_keys}}:
+
La [http://www.cs.berkeley.edu/~dawnsong/papers/randomart.pdf imagen de arte aleatorio] fue [http://www.openssh.com/txt/release-5.1 introducida en OpenSSH 5.1] como una forma más simple de identificar la huella de la llave.
  
  $ ssh mith@metawire.org
+
También es posible agregar un comentario opcional a la llave publica con el parámetro {{ic|-C}}, para identificar la llave más fácilmente en lugares como {{ic|~/.ssh/known_hosts}}, {{ic|~/.ssh/authorized_keys}} y {{ic|ssh-add -L}}. Por ejemplo:
  mith@metawire.org's password:
+
 
 +
$ ssh-keygen -C "$(whoami)@$(hostname)-$(date -I)"    ### usuario@nombredemaquina-fecha
 +
 
 +
Creara un comentario diciendo el usuario que creo la llave, en que maquina y la fecha.
 +
 
 +
El parámetro {{ic|-o}}, puede ser usado para guardar la llave privada en el nuevo formato de OpenSSH, el cual ha incrementado la resistencia a ataques de fuerza bruta, pero no es soportado por versiones de OpenSSH anteriores a 6.5 [https://lwn.net/Articles/583485/ lanzamiento 2014-01-29]. Use el parámetro {{ic|-a}} para especificar el numero de rondas de KDF. De acuerdo a {{man|1|ssh-keygen}}, llaves de Ed25519 siempre usan el nuevo formato de llave privada.
 +
 
 +
=== Seleccionar el tipo autenticación de la llave ===
 +
 
 +
OpenSSH soporta varios algoritmos (para llaves de autenticacion), los cuales se pueden dividir en dos grupos dependiendo en las propiedades matemáticas que se usan:
 +
 
 +
# [[Wikipedia:es:DSA|DSA]] y [[Wikipedia:es:RSA|RSA]], que dependen en la [[wikipedia:es:Factorización_de_enteros#Dificultad_y_complejidad|dificultad práctica]] de factorizar el producto de dos números primos largos.
 +
# [[Wikipedia:es:ECDSA|ECDSA]] y [[Wikipedia:Curve25519|Ed25519]], que dependen del problema de curva eliptica del [[Wikipedia:es:Logaritmo_discreto|logaritmo discreto]].
 +
 
 +
[[Wikipedia:es:Criptografía_de_curva_elíptica|Criptografía de curva elíptica]] (ECC) es una adición relativamente reciente al ecosistema de llaves publicas criptográficas. Una de sus ventajas más importantes es la habilidad de proveer el mismo nivel de seguridad con llaves más cortas, lo cual se transforma en menos recursos usados al crear, cifrar o descifrar mensajes y reduce los costos de transmisión y guardado.
 +
 
 +
OpenSSH 7.0 hizo llaves de tipo [https://www.archlinux.org/news/openssh-70p1-deprecates-ssh-dss-keys/ DSA obsoletas] debido a vulnerabilidades descubiertas, así que las únicas opciones en el sistema criptográfico son RSA  o alguno de los dos tipos de ECC.
 +
 
 +
Llaves de [[#RSA]] proveerán mayor portabilidad, mientras que [[#Ed25519]] le proveeran la mejor seguridad requiriendo versiones recientes de servidor y cliente. [[#Ed25519]] es probablemente más compatible que Ed25519 (aunque menos que RSA), pero sospechas sobre su seguridad existen (ver abajo).
 +
 
 +
{{Nota|Estas llaves son usadas al autenticar un usuario, seleccionar una llave más segura no quiere decir que más recursos de CPU se usaran cuando se transfieren datos por SSH.}}
 +
 
 +
==== RSA ====
 +
 
 +
{{ic|ssh-keygen}} usa por defecto RSA, así que no hay necesidad de especificarlo con el parámetro {{ic|-t}}. Este provee la  mejor compatibilidad de todos los algoritmos, pero requiere que la llave sea más larga para proveer suficiente seguridad.
 +
 
 +
El tamaño mínimo de la llave es 1024 bits,por defecto es 2048 (vea {{man|1|ssh-keygen}}), el máximo es 16384.
 +
 
 +
Si se desea generar un par de llaves RSA más seguro, simplemente use el parámetro {{ic|-b}} con el valor bit deseado:
 +
 
 +
{{hc
 +
|$ ssh-keygen -b 4096
 +
|<nowiki>Generating public/private rsa key pair.
 +
Enter file in which to save the key (/home/<username>/.ssh/id_rsa):
 +
Enter passphrase (empty for no passphrase):
 +
Enter same passphrase again:
 +
Your identification has been saved in /home/<username>/.ssh/id_rsa.
 +
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub.
 +
The key fingerprint is:
 +
SHA256:+Pqo84NC+vAQQ9lUV0z+/zPHsyCe8oZpy6hLkIa7qfk <username>@<hostname>
 +
The key's randomart image is:
 +
+---[RSA 4096]----+
 +
|  ... .+o      |
 +
|  +  . ..      |
 +
| o .    .      |
 +
|. . .  .  .      |
 +
|o. +  . S  .    |
 +
| o+ .  .    .    |
 +
|o+  o  . o. o . |
 +
|.=+ + .oo=..o o+o|
 +
|+=E..**+oo=+  o*|
 +
+----[SHA256]-----+</nowiki>}}
 +
 
 +
Es importante tener en cuenta que existen desventajas en llaves más largas.[https://security.stackexchange.com/a/25377][https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096] Las preguntas frecuentes del proyecto GnuPG dice: "''Si se desea más seguridad que RSA-2048, la mejor opción es usar curvas elípticas en lugar de seguir usando RSA''".[https://www.gnupg.org/faq/gnupg-faq.html#please_use_ecc]
 +
 
 +
En contraste, en un reporte de [https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml sistema Criptográfico de la NSA] se sugiere una llave mínima de 3072-bit para RSA mientras "''[se prepara] la transición al algoritmo resistente a computadores cuanticos''".[http://www.keylength.com/en/6/]
 +
 
 +
==== ECDSA ====
 +
 
 +
El algoritmo de firmado de curva elíptica (ECDSA, siglas en ingles), fue introducido como el algoritmo recomendado de autenticación [http://www.openssh.com/txt/release-5.7 en OpenSSH 5.7]. Algunos vendedores deshabilitaron la implementación requerida debido a potenciales brechas de patentes.
 +
 
 +
Hay dos fuentes de preocupación con este algoritmo:
 +
 
 +
# ''Preocupación política'', la confianza de productos producidos por NIST [https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters es cuestionada] después de revelaciones que la NSA insertan backdoors en software, hardware y estándares publicados. Criptografos conocidos [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 expresaron] [http://safecurves.cr.yp.to/rigid.html dudas]
 +
# [https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf sobre] las curvas fabricadas por NIST, y como voluntariamente en el pasado las ha hecho [https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html más] [http://www.scientificamerican.com/article/nsa-nist-encryption-scandal/ susceptibles].
 +
# ''Preocupación técnica'', sobre la dificultad de [http://blog.cr.yp.to/20140323-ecdsa.html implementar el estándar adecuadamente] y la [http://www.gossamer-threads.com/lists/openssh/dev/57162#57162 lentitud y fallas de diseño] que reducen la seguridad en implementaciones insuficientemente precavidas.
 +
 
 +
Estas preocupaciones están mejor resumidas en [https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4 libssh curve25519 introduction] (en ingles). Aunque las preocupaciones políticas todavía son debatidas, hay un [https://news.ycombinator.com/item?id=7597653 consenso] que [[#Ed25519]] es técnicamente superior y debería ser preferida.
 +
 
 +
==== Ed25519 ====
 +
 
 +
[http://ed25519.cr.yp.to/ Ed25519] fue introducida en [http://www.openssh.com/txt/release-6.5 OpenSSH 6.5]  en Enero de 2014: "''Ed25519 es un esquema de firmado con curva elíptica que ofrece mejor seguridad que ECDSA y rendimiento como DSA''". Sus mejores ventajas son su velocidad, resistencia a ataques de canal de lado y la ausencia de constantes embebidas en el codigo.[https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt] Vea también [https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/ este blog] por un desarrollador de Mozilla explicando como funciona.
 +
 
 +
Esta implementado en varias [[Wikipedia:Curve25519#Popularity|aplicaciones y librerías]] y es el  [https://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/ algoritmo por defecto] (lo cual diferente a ''firmado'' de llaves) en OpenSSH.
 +
 
 +
Un par de llaves SSH de tipo Ed25519 se pueden generar ejecutando:
 +
 
 +
$ ssh-keygen -t ed25519
 +
 
 +
No hay necesidad de elegir el tamaño de la llave, ya que todas las llaves Ed25519 tienen 256 bits. Estas también dependen del [http://www.gossamer-threads.com/lists/openssh/dev/57162#57162 nuevo formato de llaves] el cual "''usa derivation de llaves basada en la función de bcrypt, lo cual hace que ataques de fuerza bruta en contra de llaves robadas sean mucho más lentos''".
 +
 
 +
Por esas razones, compatibilidad con versiones antiguas de OpenSSH o con [[Secure_Shell_(Español)#Otros_servidores_y_clientes_SSH|otros servidores y clientes SSH]] puede ser complicada.
 +
 
 +
=== Selección de ubicación y contraseña ===
 +
 
 +
Al ejecutar el comando {{ic|ssh-keygen}}, se le preguntara por la ubicación deseada de su llave privada. Por defecto, las llaves son guardadas en la carpeta {{ic|~/.ssh/}} y se les nombra de acuerdo y tipo de encriptado usado. Se recomiendo aceptar la ubicación y nombre por defecto para que los ejemplos en de este articulo funcionen sin problemas.
 +
 
 +
Cuando se le pregunte por una contraseña, seleccione algo que no sea fácil de adivinar. Una contraseña aleatoria y larga es generalmente mucho más difícil de descifrar si cae en manos equivocadas.
 +
 
 +
También es posible crear su llave privada sin contraseña. Mientras que esto es conveniente, es necesario que entienda los riesgos asociados. Sin una contraseña, su llave privada va a ser guardada en el disco de manera no encriptada. Todos aquellos que ganen acceso al archivo de su llave privada podrán asumir su identidad en un servidor SSH. Además, sin contraseña, también debe confiar en el usuario root, que puede pasar permisos de archivos y puede acceder a su llave en cualquier momento.
 +
 
 +
==== Cambiar la contraseña de la llave privada sin cambiar la llave ====
 +
 
 +
Si la contraseña seleccionada originalmente ya no se desea o debe ser cambiada, se puede ejecutar el comando {{ic|ssh-keygen}} para cambiar la contraseña sin cambiar el contenido de la llave.
 +
 
 +
Para cambiar la contraseña de una llave privada RSA, ejecute:
 +
$ ssh-keygen -f ~/.ssh/id_rsa -p
 +
 
 +
==== Manejo de llaves múltiples ====
 +
 
 +
Es posible —aunque [http://security.stackexchange.com/questions/10963/whats-the-common-pragmatic-strategy-for-managing-key-pairs no se considera buena práctica]— usar la misma llave de SSH para múltiples servidores.
 +
 
 +
Claro que es relativamente fácil mantener diferentes llaves para diferente servidores usando la directiva {{ic|IdentityFile}} en su archivo de configuración de OpenSSH:
 +
 
 +
{{hc|~/.ssh/config|
 +
Host SERVIDOR1
 +
  IdentitiesOnly yes
 +
  IdentityFile ~/.ssh/id_rsa_SERVIDOR1
 +
 
 +
Host SERVIDOR2
 +
  IdentitiesOnly yes
 +
  IdentityFile ~/.ssh/id_ed25519_SERVIDOR2
 +
}}
 +
 
 +
Vea {{man|5|ssh_config}} para una descripción completa de estas opciones.
 +
 
 +
== Copiar llaves a un servidor remoto ==
 +
 
 +
Una vez se generen un  par de llaves, es necesario copiar la llave pública al servidor remoto para que se pueda usar autenticación vía SSH. La llave publica lleva el mismo nombre que la llave privada excepto que tiene una extensión {{ic|.pub}}. Nótese que la llave privada no se comparte y permanece en la maquina local.
 +
 
 +
=== Método simple ===
 +
 
 +
{{Nota|1=Este método puede que falle si el servidor usa una shell diferente a {{ic|sh}}, por ejemplo {{ic|tcsh}} y usa OpenSSH mas antiguo que 6.6.1p1. Vea [https://bugzilla.redhat.com/show_bug.cgi?id=1045191 este reporte de bug].}}
 +
 
 +
Si la llave publica esta en {{ic|~/.ssh/id_rsa.pub}}, simplemente ejecute el siguiente comando:
 +
 
 +
$ ssh-copy-id servidor-remoto.org
 +
 
 +
Si el usuario difiere en la maquina remota, asegúrese de prefijar el usuario seguido  por {{ic|@}} al nombre del servidor.
 +
 
 +
$ ssh-copy-id nombreusuarion@servidor-remoto.org
 +
 
 +
Si el nombre del archivo de la llave publica es diferente  a {{ic|~/.ssh/id_rsa.pub}}, obtendrá un error diciendo {{ic|/usr/bin/ssh-copy-id: ERROR: No identities found}} (Identidad no encontrada). En este caso, se debe proveer la ubicación del archivo de la llave publica explícitamente.
 +
 
 +
$ ssh-copy-id -i ~/.ssh/id_ed25519.pub nombreusuarion@servidor-remoto.org
 +
 
 +
Si el servidor esta esperando una conexión en un puerto diferente al 22 (por defecto), necesita incluirlo en el comando.
 +
 
 +
$ ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 221 nombreusuarion@servidor-remoto.org
 +
 
 +
=== Método manual ===
 +
 
 +
Por defecto, para OpenSSH, la llave publica necesita ser agregada en el archivo {{ic|~/.ssh/authorized_keys}}. Se inicia copiando la llave publica al servidor remoto.
 +
 
 +
$ scp ~/.ssh/id_ed25519.pub nombreusuarion@servidor-remoto.org:
 +
 
 +
Esto copiara la llave publica ({{ic|id_ed25519.pub}}) en el directorio raíz del usuario en el servidor remoto vía {{ic|scp}} (nótese los {{ic|:}} al final de la dirección del servidor).
 +
 
 +
En el servidor remoto, sera necesario crear el directorio {{ic|~/.ssh}} en caso de no existir, y agregar la llave al archivo {{ic|authorized_keys}}:
 +
 
 +
  $ ssh nombreusuarion@servidor-remoto.org
 +
  nombreusuarion@servidor-remoto.org's password:
 
  $ mkdir ~/.ssh
 
  $ mkdir ~/.ssh
  $ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
+
$ chmod 700 ~/.ssh
  $ rm ~/id_dsa.pub
+
  $ cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
 +
  $ rm ~/id_ed25519.pub
 
  $ chmod 600 ~/.ssh/authorized_keys
 
  $ chmod 600 ~/.ssh/authorized_keys
  
 
Los últimos dos comando eliminan la llave publica del servidor ( la cual ya no se necesita), y otorgan los permisos correctos al archivo {{ic|authorized_keys}}.
 
Los últimos dos comando eliminan la llave publica del servidor ( la cual ya no se necesita), y otorgan los permisos correctos al archivo {{ic|authorized_keys}}.
  
Si se desconecta del servidor, e intenta re-conectar, este le debería preguntar por la frase-de-paso de la llave:
+
== Agentes de SSH ==
  
$ ssh mith@metawire.org
+
Si la llave privada esta encriptada con una contraseña, esta debe ser introducida cada vez que se intente conectar a un servidor. Cada ejecución individual de programas como {{ic|ssh}} o {{ic|scp}} necesitaran la contraseña para descifrar la llave privada antes de autentificar y proceder.
Enter passphrase for key '/home/mith/.ssh/id_dsa':
 
  
Si no le permite acceder con la llave, vuelva a verificar los permisos del archivo {{ic|authorized_keys}}.
+
Un Agente de SSH es un programa el cual guarda su llave descifrada y la provee a los diferentes clientes de SSH en su nombre. En este caso, la contraseña solo es proporcionada una vez, al agregar la llave al cache del Agente de SSH. Esto es muy conveniente al hacer conexiones de SSH frecuentes.
  
También verifique los permisos del directorio {{ic|~/.ssh}}, los cuales deberían NO dejar escribir para 'group' y 'other'. Ejecute el siguiente comando para desabilitar los permisos de escritura para 'group' y 'other' en el directorio {{ic|~/.ssh}}:
+
Un Agente esta típicamente configurado a ejecutarse automáticamente cuando se inicie la sesión y persistirá hasta el cierre de la misma. Una variedad de Agentes, GUIs y configuraciones están disponibles para lograr este objetivo. Esta sección proveerá una reseña de un numero de diferentes soluciones que se pueden adaptar a las necesidades especificas.
  
$ chmod go-w ~/.ssh
+
=== ssh-agent ===
  
==Recuerde la  frase-de-paso==
+
{{ic|ssh-agent}} es el agente por defecto incluido en OpenSSH. Puede ser usado directamente o puede ser usado como back-end de algún otro programa, algunos ejemplos serán discutidos en la parte inferior.
Ahora puede acceder al servidor usando la llave en vez del password, pero como se facilita el asunto, ¿aun necesita entrar la frase-de-paso? La respuesta es usar un agente SSH, ¡un programa que recuerda las frases-de-paso de sus llaves! Hay muchas herramientas disponibles para esto, solo debe conocerlas y elegir la que le parezca mas apropiada a sus necesidades.
 
  
===Agente SSH===
+
Cuando se ejecuta {{ic|ssh-agent}}, se mostrará en pantalla las variables de entorno que serán usadas, y una tarea de fondo sera creada.
ssh-agent el el agente por defecto que incluye OpenSSH.
 
  
 
  $ ssh-agent
 
  $ ssh-agent
Line 78: Line 237:
 
  echo Agent pid 2148;
 
  echo Agent pid 2148;
  
Cuando ejecuta {{ic|ssh-agent}}, se mostrara en pantalla las variables de entorno que serán usadas. Para hacer uso de estas variables, ejecute {{ic|eval}}.
+
Para hacer uso de estas variables, ejecute {{ic|eval}}.
  
 
  $ eval `ssh-agent`
 
  $ eval `ssh-agent`
 
  Agent pid 2157
 
  Agent pid 2157
  
Puede agregarlo al archivo {{ic|/etc/profile}} para que se ejecute cada vez que inicia sesión:
+
Ahora que {{ic|ssh-agent}} se esta ejecutando, es necesario agregar la llave privada.
  
  # echo 'eval `ssh-agent`' >> /etc/profile
+
  $ ssh-add ~/.ssh/id_ed25519
 +
Enter passphrase for /home/user/.ssh/id_ed25519:
 +
Identity added: /home/user/.ssh/id_ed25519 (/home/user/.ssh/id_ed25519)
  
Note las forma correcta de poner las comillas, las externas son simples, mientras que dentro se usan las invertidas.
+
Si la llave esta encriptada, {{ic|ssh-add}} preguntara por la contraseña. Una vez que la llave  privada ha sido añadida satisfactoriamente al agente, sera posible hacer conexiones de SSH sin necesidad de ingresar la contraseña.
 +
 +
{{Sugerencia|Para hacer que todos los clientes de {{ic|ssh}}, incluyendo {{ic|git}} guarden la llave en el agente en el primer uso, agregue la configuración {{ic|AddKeysToAgent yes}} al archivo {{ic|~/.ssh/config}}. Otros valores posibles son {{ic|confirm}}, {{ic|ask}} y {{ic|no}} (por defecto).}}
  
Ahora que el {{ic|ssh-agent}} esta corriendo, necesitamos decirle que tenemos una llave privada, y donde esta.
+
Para iniciar el agente automáticamente y asegurarse que solamente un proceso de {{ic|ssh-agent}} se esta ejecutando, agregue lo siguiente al archivo {{ic|~/.bashrc}}:
 +
 
 +
{{bc|<nowiki>
 +
if ! pgrep -u "$USER" ssh-agent > /dev/null; then
 +
    ssh-agent > ~/.ssh-agent-thing
 +
fi
 +
if [[ "$SSH_AGENT_PID" == "" ]]; then
 +
    eval "$(<~/.ssh-agent-thing)"
 +
fi
 +
</nowiki>}}
  
$ ssh-add ~/.ssh/id_dsa
+
Esto ejecutara un proceso de {{ic|ssh-agent}} si no existe alguno. Si hay un proceso ejecutándose, se tomara el resultado de {{ic|ssh-agent}} y se evaluara para configurar las variables de entorno necesarias.
Enter passphrase for /home/user/.ssh/id_dsa:
 
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
 
  
Nos preguntara por nuestra frase-de-paso, la ingresamos, y es todo. Ahora puede ingresar al servidor remoto sin tener que entrar su password.
+
También existen GUIs para {{ic|ssh-agent}} y agentes alternativos descritos posteriormente que evitan este problema.
 
La única desventaja es que cada nueva instancia de {{ic|ssh-agent}} necesita ser ejecutada por cada consola (shell) que se abra, esto significa que se debe correr {{ic|ssh-agent}} cada vez en cada consola. Hay una solución para esto, con un programa o mas bien un script llamado [http://www.gentoo.org/proj/en/keychain/index.xml keychain] que cubrirá las siguientes sesiones.
 
  
====Usando GnuPG Agent====
+
==== Iniciar ssh-agent con systemd/user ====
El agente [[GnuPG]], es distribuido en el paquete {Package Official|gnupg2}}, posee una emulación del agente de OpenSSH. si usas GPG debería considerar usar este agente para mantener cuidadas sus llaves. De otra forma puede interesarle el dialogo de entrada de PIN que provee que gestiona las frases-de-paso, es diferente al de keychain.
 
  
Para empezar a usar el agente GPG  primero hay que correr {{ic|gpg-agent}} con las opciones {{ic|--enable-ssh-support}}. Por ejemplo (no olvide darle los permisos de ejecución):
+
Es posible usar [[Systemd/User_(Español)|systemd/user]] lo cual facilita el inicio del agente.
  
{{hc|/etc/profile.d/gpg-agent.sh|<nowiki>
+
{{hc|~/.config/systemd/user/ssh-agent.service|<nowiki>
#!/bin/sh
+
[Unit]
 +
Description=SSH key agent
  
# Inicia el agente GnuPG y habilita la emulación del agente de OpenSSH
+
[Service]
gnupginf="${HOME}/.gnupg/gpg-agent.info"
+
Type=simple
 +
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
 +
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK
  
if pgrep -u "${USER}" gpg-agent >/dev/null 2>&1; then
+
[Install]
    eval `cat $gnupginf`
+
WantedBy=</nowiki>''default''.target
    eval `cut -d= -f1 $gnupginf | xargs echo export`
+
}}
else
 
    eval `gpg-agent --enable-ssh-support --daemon`
 
fi
 
</nowiki>}}
 
  
Una vez que gpg-agent este corriendo puede usar {{ic|ssh-add}} para verificar las llaves, justo como lo hizo con ssh-agent. La lista de las llaves aprobadas se guarda en el archivo {{ic|~/.gnupg/sshcontrol}}. Cuando su calve es aprobada obtendrá un dialogo de entrada de PIN pidiendo la frase-de-paso ( si es necesario). Puede controlar el almacenamiento de las frases-de-entrada en el archivo {{ic|~/.gnupg/gpg-agent.conf}}. El siguiente ejemplo hará que gpg-agent mantenga las llaves por 3 horas:
+
Agregue {{ic|1=SSH_AUTH_SOCK  DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket"}} al archivo {{ic|~/.pam_environment}}. Después [[Systemd_(Español)#Usar las unidades|active]] o [[Systemd_(Español)#Usar las unidades|active inicio automatico]] de la unidad.
  
  # Cache settings
+
{{Nota|SI esta usando GNOME, esta variable de entorno es sobre escrita por defecto. Vea [[GNOME/Keyring#Disable keyring daemon components]].}}
  default-cache-ttl 10800
 
  default-cache-ttl-ssh 10800
 
  
Otra configuración útil para este archivo es incluir un programa para la entrada del PIN (GTK, QT o ncurses ):
+
=== Agente GnuPG ===
  
  # Environment file
+
El [[GnuPG_(Español)#gpg-agent|gpg-agent]] tiene emulación de OpenSSH. Vea [[GnuPG#SSH agent]] para la configuracion necesaria.
  write-env-file /home/username/.gnupg/gpg-agent.info
 
 
 
  # Keyboard control
 
  #no-grab
 
   
 
  # PIN entry program
 
  #pinentry-program /usr/bin/pinentry-curses
 
  #pinentry-program /usr/bin/pinentry-qt4
 
  pinentry-program /usr/bin/pinentry-gtk-2
 
  
====Usando  keychain====
+
=== Keychain ===
  
 
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] administra una o mas llaves privadas, que se le hayan especificado. Cuando se inicializa, preguntara por la frase-de-paso para la clave privada, y la guardara. De esta manera sus llaves privadas estarán protegidas por password, pero no deberá ingresar su password una y otra vez.
 
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] administra una o mas llaves privadas, que se le hayan especificado. Cuando se inicializa, preguntara por la frase-de-paso para la clave privada, y la guardara. De esta manera sus llaves privadas estarán protegidas por password, pero no deberá ingresar su password una y otra vez.
  
Instalar keychain de los repositorios extra:
+
[[Help:Reading_(Español)#Instalaci.C3.B3n_de_paquetes|Instale]] el paquete {{Pkg|keychain}}, disponible en los [[Official repositories (Español)|repositorios oficiales]]
 
 
 
# pacman -S keychain
 
  
 
Cree el siguiente archivo y hágalo ejecutable:
 
Cree el siguiente archivo y hágalo ejecutable:
Line 167: Line 319:
 
{{Tip| Si quiere mayor seguridad reemplace -Q con --clear pero es menos conveniente.}}
 
{{Tip| Si quiere mayor seguridad reemplace -Q con --clear pero es menos conveniente.}}
  
Si es necesario, reemplace {{ic|~/.ssh/id_dsa}} con {{ic|~/.ssh/id_rsa}}. Para aquellos que usan una shell que no es Bash, vean{{ic|keychain --help}} o {{ic|man keychain}} para detalles en otras Shells.
+
Si es necesario, reemplace {{ic|~/.ssh/id_dsa}} con {{ic|~/.ssh/id_rsa}}. Para aquellos que usan una shell que no es Bash, vean{{ic|keychain --help}} o {{man|1|keychain}} para detalles en otras Shells.
 
   
 
   
  
 
Cierre su shell y vuélvala a abrir, Keychain deberá aparecer y si es la primera vez que corre, le preguntara por la frase-de-paso de la llave privada especificada.
 
Cierre su shell y vuélvala a abrir, Keychain deberá aparecer y si es la primera vez que corre, le preguntara por la frase-de-paso de la llave privada especificada.
+
 
====Usando ssh-agent y x11-show-askpass====
+
=== x11-show-askpass ===
  
 
Necesita iniciar ssh-agent cada vez que inicia una nueva sesión de X. El ssh-agent se cerrara cuando al sesión de X termine
 
Necesita iniciar ssh-agent cada vez que inicia una nueva sesión de X. El ssh-agent se cerrara cuando al sesión de X termine
Line 184: Line 336:
 
Luego de instalarlo, cierre su sesión de X y recarguela a partir de ahora se le preguntara su frase-de-paso en el inicio de la sesión X.
 
Luego de instalarlo, cierre su sesión de X y recarguela a partir de ahora se le preguntara su frase-de-paso en el inicio de la sesión X.
  
===GNOME Keyring (llavero)===
+
=== GNOME Keyring (llavero) ===
 +
 
 
Si usa el escritorio [[GNOME]], la herramienta [[Gnome Keyring]] puede ser usada como un agente de SSH. Visite el articulo [[Gnome Keyring]].
 
Si usa el escritorio [[GNOME]], la herramienta [[Gnome Keyring]] puede ser usada como un agente de SSH. Visite el articulo [[Gnome Keyring]].
  
==Resolucion de problemas==
+
== Resolución de problemas ==
 +
 
 
Si cree que el servidor SSH esta ignorando sus claves, asegúrese de que tiene los permisos adecuados sobre los archivos relevantes.
 
Si cree que el servidor SSH esta ignorando sus claves, asegúrese de que tiene los permisos adecuados sobre los archivos relevantes.
  

Latest revision as of 15:19, 6 May 2018

Tango-preferences-desktop-locale.pngEste artículo o sección necesita ser traducido.Tango-preferences-desktop-locale.png

Notas: En proceso de traducción (Discusión)

Al usar una llave SSH ( una publica y una privada para ser precisos), se puede conectarse fácilmente a un servidor, o a múltiples servidores, sin tener que ingresar una contraseña cada vez Criptografía_asimétrica y Protocolos_desafío-respuesta. Una ventaja inmediata de este método sobre el clásico método de autenticación con contraseña, es que es posible autenticarse sin necesidad de enviar la contraseña por la red, así que alguien espiando la red no podrá interceptar e intentar descifrar la contraseña ya que esta nunca sera enviada. Adicionalmente, el uso de llaves de SSH virtualmente elimina el riesgo de ataques de fuerza bruta al reducir la probabilidad de que un atacante adivine las credenciales correctamente.

Ademas de ofrecer seguridad adicional, autenticación con llaves SSH puede ser mas conveniente que el método tradicional de autenticación con contraseña. Cuando se usa con un programa conocido como Agente SSH, las llaves SSH le permiten conectarse con uno o múltiples servidores sin necesidad de tener que recordar la contraseña de cada sistema.

Llaves SSH también tienen algunas desventajas y puede que no funcionen en todos los ambientes, pero en muchas circunstancias pueden ofrecer bastantes ventajas. Un entendimiento general de como funcionan las llaves SSH le ayudaran a decidir como y cuando usarlas para satisfacer su caso especifico.

Este articulo asume que el lector tiene un conocimiento básico del protocolo de Shell Segura y que el paquete openssh ha sido instalado.

Informacion preliminar

Las llaves de SSH siempre son generadas en pares con una llamada llave privada y otra llamada llave pública. La llave privada solo es conocida por el usuario y debe ser guardada con cuidado. En contraste, la llave pública puede ser compartida libremente con cualquier servidor SSH con el que se quiere conectar.

Si un servidor SSH tiene su llave pública y nota que hay un intento de conexión, usa su llave pública para construir y enviar un desafío. Este desafío es un mensaje encriptado y debe ser respondido apropiadamente antes de que el servidor le dé acceso. Lo que hace este mensaje particularmente seguro es que solo se puede descifrar con la llave privada. Mientras que la llave pública puede ser usada para encriptar el mensaje, no puede ser usada para descifrarlo. Solo el usuario, que tiene la llave privada puede ser capaz de descifrar correctamente el desafío y producir la respuesta adecuada.

Este intercambio de desafío-respuesta ocurre como una tarea de fondo y es invisible para el usuario. Mientras se tenga la llave privada, la cual es guardada normalmente en la carpeta ~/.ssh/, su cliente SSH debería ser capaz de responder apropiadamente al servidor.

Una llave privada es un secreto a guardar, por ende se aconseja que cuando se guarde se haga de manera encriptada. Cuando la llave encriptada es requerida, una contraseña debe ser ingresada para descifrarla. Aunque superficialmente esto parece como si se estuviera poniendo una contraseña para ingresar al servidor de SSH, esta contraseña solo se usa para descifrar la llave privada en el sistema local. Esta contraseña no se transmite sobre la red.

Generando las llaves SSH

Un par de llaves SSH puede ser generado ejecutando el comando ssh-keygen, por defecto usando seguridad 2048-bit RSA (y SHA256) la cual de acuerdo a ssh-keygen(1) es "considerada generalmente suficiente" y debe ser compatible con virtualmente todos los servidores y clientes:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<username>/.ssh/id_rsa):   ### Ubicación de las llaves
Enter passphrase (empty for no passphrase):                           ### Contraseña de la llave
Enter same passphrase again:                                          ### Repetir la contraseña
Your identification has been saved in /home/<username>/.ssh/id_rsa.   ### Nombre llave privada
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub.   ### Nombre llave publica
The key fingerprint is:
SHA256:gGJtSsV8BM+7w018d39Ji57F8iO6c0N2GZq3/RY2NhI username@hostname
The key's randomart image is:
+---[RSA 2048]----+
|   ooo.          |
|   oo+.          |
|  + +.+          |
| o +   +     E . |
|  .   . S . . =.o|
|     . + . . B+@o|
|      + .   oo*=O|
|       .   ..+=o+|
|           o=ooo+|
+----[SHA256]-----+

La imagen de arte aleatorio fue introducida en OpenSSH 5.1 como una forma más simple de identificar la huella de la llave.

También es posible agregar un comentario opcional a la llave publica con el parámetro -C, para identificar la llave más fácilmente en lugares como ~/.ssh/known_hosts, ~/.ssh/authorized_keys y ssh-add -L. Por ejemplo:

$ ssh-keygen -C "$(whoami)@$(hostname)-$(date -I)"    ### usuario@nombredemaquina-fecha

Creara un comentario diciendo el usuario que creo la llave, en que maquina y la fecha.

El parámetro -o, puede ser usado para guardar la llave privada en el nuevo formato de OpenSSH, el cual ha incrementado la resistencia a ataques de fuerza bruta, pero no es soportado por versiones de OpenSSH anteriores a 6.5 lanzamiento 2014-01-29. Use el parámetro -a para especificar el numero de rondas de KDF. De acuerdo a ssh-keygen(1), llaves de Ed25519 siempre usan el nuevo formato de llave privada.

Seleccionar el tipo autenticación de la llave

OpenSSH soporta varios algoritmos (para llaves de autenticacion), los cuales se pueden dividir en dos grupos dependiendo en las propiedades matemáticas que se usan:

  1. DSA y RSA, que dependen en la dificultad práctica de factorizar el producto de dos números primos largos.
  2. ECDSA y Ed25519, que dependen del problema de curva eliptica del logaritmo discreto.

Criptografía de curva elíptica (ECC) es una adición relativamente reciente al ecosistema de llaves publicas criptográficas. Una de sus ventajas más importantes es la habilidad de proveer el mismo nivel de seguridad con llaves más cortas, lo cual se transforma en menos recursos usados al crear, cifrar o descifrar mensajes y reduce los costos de transmisión y guardado.

OpenSSH 7.0 hizo llaves de tipo DSA obsoletas debido a vulnerabilidades descubiertas, así que las únicas opciones en el sistema criptográfico son RSA o alguno de los dos tipos de ECC.

Llaves de #RSA proveerán mayor portabilidad, mientras que #Ed25519 le proveeran la mejor seguridad requiriendo versiones recientes de servidor y cliente. #Ed25519 es probablemente más compatible que Ed25519 (aunque menos que RSA), pero sospechas sobre su seguridad existen (ver abajo).

Nota: Estas llaves son usadas al autenticar un usuario, seleccionar una llave más segura no quiere decir que más recursos de CPU se usaran cuando se transfieren datos por SSH.

RSA

ssh-keygen usa por defecto RSA, así que no hay necesidad de especificarlo con el parámetro -t. Este provee la mejor compatibilidad de todos los algoritmos, pero requiere que la llave sea más larga para proveer suficiente seguridad.

El tamaño mínimo de la llave es 1024 bits,por defecto es 2048 (vea ssh-keygen(1)), el máximo es 16384.

Si se desea generar un par de llaves RSA más seguro, simplemente use el parámetro -b con el valor bit deseado:

$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/<username>/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/<username>/.ssh/id_rsa.
Your public key has been saved in /home/<username>/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:+Pqo84NC+vAQQ9lUV0z+/zPHsyCe8oZpy6hLkIa7qfk <username>@<hostname>
The key's randomart image is:
+---[RSA 4096]----+
|   ... .+o       |
|  +   . ..       |
| o .     .       |
|. . .  .  .      |
|o. +  . S  .     |
| o+ .  .    .    |
|o+   o  . o. o . |
|.=+ + .oo=..o o+o|
|+=E..**+oo=+   o*|
+----[SHA256]-----+

Es importante tener en cuenta que existen desventajas en llaves más largas.[1][2] Las preguntas frecuentes del proyecto GnuPG dice: "Si se desea más seguridad que RSA-2048, la mejor opción es usar curvas elípticas en lugar de seguir usando RSA".[3]

En contraste, en un reporte de sistema Criptográfico de la NSA se sugiere una llave mínima de 3072-bit para RSA mientras "[se prepara] la transición al algoritmo resistente a computadores cuanticos".[4]

ECDSA

El algoritmo de firmado de curva elíptica (ECDSA, siglas en ingles), fue introducido como el algoritmo recomendado de autenticación en OpenSSH 5.7. Algunos vendedores deshabilitaron la implementación requerida debido a potenciales brechas de patentes.

Hay dos fuentes de preocupación con este algoritmo:

  1. Preocupación política, la confianza de productos producidos por NIST es cuestionada después de revelaciones que la NSA insertan backdoors en software, hardware y estándares publicados. Criptografos conocidos expresaron dudas
  2. sobre las curvas fabricadas por NIST, y como voluntariamente en el pasado las ha hecho más susceptibles.
  3. Preocupación técnica, sobre la dificultad de implementar el estándar adecuadamente y la lentitud y fallas de diseño que reducen la seguridad en implementaciones insuficientemente precavidas.

Estas preocupaciones están mejor resumidas en libssh curve25519 introduction (en ingles). Aunque las preocupaciones políticas todavía son debatidas, hay un consenso que #Ed25519 es técnicamente superior y debería ser preferida.

Ed25519

Ed25519 fue introducida en OpenSSH 6.5 en Enero de 2014: "Ed25519 es un esquema de firmado con curva elíptica que ofrece mejor seguridad que ECDSA y rendimiento como DSA". Sus mejores ventajas son su velocidad, resistencia a ataques de canal de lado y la ausencia de constantes embebidas en el codigo.[5] Vea también este blog por un desarrollador de Mozilla explicando como funciona.

Esta implementado en varias aplicaciones y librerías y es el algoritmo por defecto (lo cual diferente a firmado de llaves) en OpenSSH.

Un par de llaves SSH de tipo Ed25519 se pueden generar ejecutando:

$ ssh-keygen -t ed25519

No hay necesidad de elegir el tamaño de la llave, ya que todas las llaves Ed25519 tienen 256 bits. Estas también dependen del nuevo formato de llaves el cual "usa derivation de llaves basada en la función de bcrypt, lo cual hace que ataques de fuerza bruta en contra de llaves robadas sean mucho más lentos".

Por esas razones, compatibilidad con versiones antiguas de OpenSSH o con otros servidores y clientes SSH puede ser complicada.

Selección de ubicación y contraseña

Al ejecutar el comando ssh-keygen, se le preguntara por la ubicación deseada de su llave privada. Por defecto, las llaves son guardadas en la carpeta ~/.ssh/ y se les nombra de acuerdo y tipo de encriptado usado. Se recomiendo aceptar la ubicación y nombre por defecto para que los ejemplos en de este articulo funcionen sin problemas.

Cuando se le pregunte por una contraseña, seleccione algo que no sea fácil de adivinar. Una contraseña aleatoria y larga es generalmente mucho más difícil de descifrar si cae en manos equivocadas.

También es posible crear su llave privada sin contraseña. Mientras que esto es conveniente, es necesario que entienda los riesgos asociados. Sin una contraseña, su llave privada va a ser guardada en el disco de manera no encriptada. Todos aquellos que ganen acceso al archivo de su llave privada podrán asumir su identidad en un servidor SSH. Además, sin contraseña, también debe confiar en el usuario root, que puede pasar permisos de archivos y puede acceder a su llave en cualquier momento.

Cambiar la contraseña de la llave privada sin cambiar la llave

Si la contraseña seleccionada originalmente ya no se desea o debe ser cambiada, se puede ejecutar el comando ssh-keygen para cambiar la contraseña sin cambiar el contenido de la llave.

Para cambiar la contraseña de una llave privada RSA, ejecute:

$ ssh-keygen -f ~/.ssh/id_rsa -p

Manejo de llaves múltiples

Es posible —aunque no se considera buena práctica— usar la misma llave de SSH para múltiples servidores.

Claro que es relativamente fácil mantener diferentes llaves para diferente servidores usando la directiva IdentityFile en su archivo de configuración de OpenSSH:

~/.ssh/config
Host SERVIDOR1
   IdentitiesOnly yes
   IdentityFile ~/.ssh/id_rsa_SERVIDOR1

Host SERVIDOR2
   IdentitiesOnly yes
   IdentityFile ~/.ssh/id_ed25519_SERVIDOR2

Vea ssh_config(5) para una descripción completa de estas opciones.

Copiar llaves a un servidor remoto

Una vez se generen un par de llaves, es necesario copiar la llave pública al servidor remoto para que se pueda usar autenticación vía SSH. La llave publica lleva el mismo nombre que la llave privada excepto que tiene una extensión .pub. Nótese que la llave privada no se comparte y permanece en la maquina local.

Método simple

Nota: Este método puede que falle si el servidor usa una shell diferente a sh, por ejemplo tcsh y usa OpenSSH mas antiguo que 6.6.1p1. Vea este reporte de bug.

Si la llave publica esta en ~/.ssh/id_rsa.pub, simplemente ejecute el siguiente comando:

$ ssh-copy-id servidor-remoto.org

Si el usuario difiere en la maquina remota, asegúrese de prefijar el usuario seguido por @ al nombre del servidor.

$ ssh-copy-id nombreusuarion@servidor-remoto.org

Si el nombre del archivo de la llave publica es diferente a ~/.ssh/id_rsa.pub, obtendrá un error diciendo /usr/bin/ssh-copy-id: ERROR: No identities found (Identidad no encontrada). En este caso, se debe proveer la ubicación del archivo de la llave publica explícitamente.

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub nombreusuarion@servidor-remoto.org

Si el servidor esta esperando una conexión en un puerto diferente al 22 (por defecto), necesita incluirlo en el comando.

$ ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 221 nombreusuarion@servidor-remoto.org

Método manual

Por defecto, para OpenSSH, la llave publica necesita ser agregada en el archivo ~/.ssh/authorized_keys. Se inicia copiando la llave publica al servidor remoto.

$ scp ~/.ssh/id_ed25519.pub nombreusuarion@servidor-remoto.org:

Esto copiara la llave publica (id_ed25519.pub) en el directorio raíz del usuario en el servidor remoto vía scp (nótese los : al final de la dirección del servidor).

En el servidor remoto, sera necesario crear el directorio ~/.ssh en caso de no existir, y agregar la llave al archivo authorized_keys:

$ ssh nombreusuarion@servidor-remoto.org
nombreusuarion@servidor-remoto.org's password:
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys
$ rm ~/id_ed25519.pub
$ chmod 600 ~/.ssh/authorized_keys

Los últimos dos comando eliminan la llave publica del servidor ( la cual ya no se necesita), y otorgan los permisos correctos al archivo authorized_keys.

Agentes de SSH

Si la llave privada esta encriptada con una contraseña, esta debe ser introducida cada vez que se intente conectar a un servidor. Cada ejecución individual de programas como ssh o scp necesitaran la contraseña para descifrar la llave privada antes de autentificar y proceder.

Un Agente de SSH es un programa el cual guarda su llave descifrada y la provee a los diferentes clientes de SSH en su nombre. En este caso, la contraseña solo es proporcionada una vez, al agregar la llave al cache del Agente de SSH. Esto es muy conveniente al hacer conexiones de SSH frecuentes.

Un Agente esta típicamente configurado a ejecutarse automáticamente cuando se inicie la sesión y persistirá hasta el cierre de la misma. Una variedad de Agentes, GUIs y configuraciones están disponibles para lograr este objetivo. Esta sección proveerá una reseña de un numero de diferentes soluciones que se pueden adaptar a las necesidades especificas.

ssh-agent

ssh-agent es el agente por defecto incluido en OpenSSH. Puede ser usado directamente o puede ser usado como back-end de algún otro programa, algunos ejemplos serán discutidos en la parte inferior.

Cuando se ejecuta ssh-agent, se mostrará en pantalla las variables de entorno que serán usadas, y una tarea de fondo sera creada.

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2148; export SSH_AGENT_PID;
echo Agent pid 2148;

Para hacer uso de estas variables, ejecute eval.

$ eval `ssh-agent`
Agent pid 2157

Ahora que ssh-agent se esta ejecutando, es necesario agregar la llave privada.

$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /home/user/.ssh/id_ed25519:
Identity added: /home/user/.ssh/id_ed25519 (/home/user/.ssh/id_ed25519)

Si la llave esta encriptada, ssh-add preguntara por la contraseña. Una vez que la llave privada ha sido añadida satisfactoriamente al agente, sera posible hacer conexiones de SSH sin necesidad de ingresar la contraseña.

Sugerencia: Para hacer que todos los clientes de ssh, incluyendo git guarden la llave en el agente en el primer uso, agregue la configuración AddKeysToAgent yes al archivo ~/.ssh/config. Otros valores posibles son confirm, ask y no (por defecto).

Para iniciar el agente automáticamente y asegurarse que solamente un proceso de ssh-agent se esta ejecutando, agregue lo siguiente al archivo ~/.bashrc:

if ! pgrep -u "$USER" ssh-agent > /dev/null; then
    ssh-agent > ~/.ssh-agent-thing
fi
if [[ "$SSH_AGENT_PID" == "" ]]; then
    eval "$(<~/.ssh-agent-thing)"
fi

Esto ejecutara un proceso de ssh-agent si no existe alguno. Si hay un proceso ejecutándose, se tomara el resultado de ssh-agent y se evaluara para configurar las variables de entorno necesarias.

También existen GUIs para ssh-agent y agentes alternativos descritos posteriormente que evitan este problema.

Iniciar ssh-agent con systemd/user

Es posible usar systemd/user lo cual facilita el inicio del agente.

~/.config/systemd/user/ssh-agent.service
[Unit]
Description=SSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Agregue SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket" al archivo ~/.pam_environment. Después active o active inicio automatico de la unidad.

Nota: SI esta usando GNOME, esta variable de entorno es sobre escrita por defecto. Vea GNOME/Keyring#Disable keyring daemon components.

Agente GnuPG

El gpg-agent tiene emulación de OpenSSH. Vea GnuPG#SSH agent para la configuracion necesaria.

Keychain

Keychain administra una o mas llaves privadas, que se le hayan especificado. Cuando se inicializa, preguntara por la frase-de-paso para la clave privada, y la guardara. De esta manera sus llaves privadas estarán protegidas por password, pero no deberá ingresar su password una y otra vez.

Instale el paquete keychain, disponible en los repositorios oficiales

Cree el siguiente archivo y hágalo ejecutable:

/etc/profile.d/keychain.sh
eval `keychain --eval --nogui -Q -q id_rsa`

o

/etc/profile.d/keychain.sh
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_dsa
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh

o

anexe

eval `keychain --eval --agents ssh id_dsa`

a su .bashrc o .bash_profile.

Tip: Si quiere mayor seguridad reemplace -Q con --clear pero es menos conveniente.

Si es necesario, reemplace ~/.ssh/id_dsa con ~/.ssh/id_rsa. Para aquellos que usan una shell que no es Bash, veankeychain --help o keychain(1) para detalles en otras Shells.


Cierre su shell y vuélvala a abrir, Keychain deberá aparecer y si es la primera vez que corre, le preguntara por la frase-de-paso de la llave privada especificada.

x11-show-askpass

Necesita iniciar ssh-agent cada vez que inicia una nueva sesión de X. El ssh-agent se cerrara cuando al sesión de X termine

Se puede instalar una variante de x11-ssh-askpass la cual le pedirá su frase-de-paso cada vez que abra una nueva sesión de X. También puede usar el x11-ssh-askpass original de AUR o ksshkpass (usa kdelibs):

# pacman -S ksshaskpass

o openssh-askpass (usa qt):

# pacman -S openssh-askpass

Luego de instalarlo, cierre su sesión de X y recarguela a partir de ahora se le preguntara su frase-de-paso en el inicio de la sesión X.

GNOME Keyring (llavero)

Si usa el escritorio GNOME, la herramienta Gnome Keyring puede ser usada como un agente de SSH. Visite el articulo Gnome Keyring.

Resolución de problemas

Si cree que el servidor SSH esta ignorando sus claves, asegúrese de que tiene los permisos adecuados sobre los archivos relevantes.

Para la maquina local:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa

Para la maquina remota:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Si no fuera eso, ejecute el servidor ssh en modo de depuración y monitoree la salida mientras se hace la conexión:

# /usr/sbin/sshd -d

Links Utiles / Informacion (en ingles)