Respuestas:
Para cada usuario: deben generar (en su máquina local) a su par de claves utilizando ssh-keygen -t rsa(la rsapueden reemplazado con dsao rsa1también, aunque no se recomiendan las opciones). Luego deben poner el contenido de su clave pública ( id_rsa.pub) en ~/.ssh/authorized_keysel servidor que está iniciando sesión.
De hecho, prefiero ssh-copy-id , un script que se encuentra en * nix de forma predeterminada (también se puede poner en Mac OS X con la suficiente facilidad) que automáticamente lo hace por usted. Desde la página del manual:
ssh-copy-id es un script que usa ssh para iniciar sesión en una máquina remota (presumiblemente usando una contraseña de inicio de sesión, por lo que la autenticación de contraseña debe estar habilitada, a menos que haya hecho un uso inteligente de múltiples identidades)
También cambia los permisos de inicio del usuario remoto, ~ / .ssh y ~ / .ssh / authorised_keys para eliminar la capacidad de escritura del grupo (lo que de otro modo le impediría iniciar sesión, si el sshd remoto tiene StrictModes establecido en su configuración).
Si se da la opción -i, se usa el archivo de identidad (predeterminado en ~ / .ssh / identity.pub), independientemente de si hay claves en su agente ssh.
Hum, no lo entiendas. Simplemente cree una clave y comience. :) CÓMO Además, puede prohibir el inicio de sesión mediante contraseña. En, por ejemplo, / etc / ssh / sshd_config:
PasswordAuthentication no
Esto es bastante sencillo de hacer - hay un tutorial simple para ser encontrado aquí .
Los puntos principales son:
ssh-keygenen tu máquina. Esto generará claves públicas y privadas para usted.~/.ssh/id_rsa.pub) en ~/.ssh/authorized_keysla máquina remota.Es importante recordar que esto le dará a cualquier persona que tenga acceso a la clave privada en su máquina el mismo acceso a la máquina remota, por lo que al generar el par de claves puede optar por ingresar una contraseña aquí para mayor seguridad.
Para que los usuarios de Windows configuren masilla
Para resumir lo que otros han dicho, configurar claves SSH es fácil e invaluable.
En la máquina que va a ser sshing de lo que necesita para generar su par de claves:
claudius:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/dinomite/.ssh/id_rsa): <ENTER>
Enter passphrase (empty for no passphrase): <PASSPHRASE>
Enter same passphrase again: <PASSPHRASE>
Your identification has been saved in /home/dinomite/.ssh/id_rsa.
Your public key has been saved in /home/dinomite/.ssh/id_rsa.pub.
The key fingerprint is:
a3:93:8c:27:15:67:fa:9f:5d:42:3a:bb:9d:db:93:db dinomite@claudius
Simplemente presione Intro donde se indique e ingrese una frase de contraseña cuando se le solicite; idealmente, esto es diferente de su contraseña de inicio de sesión habitual tanto en el host actual como en los que utilizará SSH.
A continuación, debe copiar la clave que acaba de generar al host que desea SSH a . La mayoría de las distribuciones de Linux tienen una herramienta ssh-copy-idpara hacer esto:
claudius:~$ ssh-copy-id caligula.dinomite.net
Now try logging into the machine, with "ssh 'caligula.dinomite.net'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Si su distribución no tiene eso, entonces debe copiar la clave al host de destino y agregarla al .ssh/authorized_keysarchivo (posiblemente existente) :
claudius:~$ scp .ssh/id_dsa.pub caligula.dinomite.net:
id_dsa.pub 100% 1119 1.1KB/s 00:00
claudius:~$ ssh caligula.dinomite.net
Last login: Sat May 9 10:32:30 2009 from claudius.csh.rit.edu
Caligula:~$ cat id_dsa.pub >> .ssh/authorized_keys
Finalmente, para obtener el máximo beneficio de las claves SSH, querrá ejecutar un agente SSH. Si usa un entorno de escritorio (Gnome, KDE, etc.), solo al cerrar sesión y volver a iniciarlo se iniciará un agente SSH para usted. Si no es así, se puede añadir lo siguiente a su shell archivo RC ( .bashrc, .profile, etc.):
SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi
Esto pretende ser una lista de verificación. Si se sigue punto por punto, se deben cubrir las trampas más comunes para los inicios de sesión sin contraseña. La mayoría de estos puntos se mencionan en otra parte; Esta es una agregación.
Debe haber un ~/.sshdirectorio chmod 700en cada máquina bajo la cuenta que originará o recibirá las conexiones.
La clave (privada) debe generarse sin una frase de contraseña, o puede iniciarse un agente que contendrá una versión descifrada de una clave que contenga una frase de contraseña para que los clientes la utilicen. Comience el agente con ssh-agent $SHELL. Es la $SHELLparte que me llevó un tiempo encontrar. Consulte la página de manual, ya que hay muchos detalles si desea utilizar un agente.
No olvide que, por defecto, las versiones recientes de sshd no aceptan claves débiles (DSA de <2048 bits).
Lo siguiente debe hacerse en la máquina del lado del cliente para originar una conexión.
Su clave privada debe colocarse en ~/.ssh/id_rsao ~/.ssh/id_dsasegún corresponda. Puede usar otro nombre, pero luego debe incluirse en una opción -i en el comando ssh en la máquina de origen para indicar explícitamente la clave privada.
Tu clave privada debe ser chmod 600.
Comprueba que tu carpeta de inicio es chmod 700.
Ahora por permitir que una máquina reciba una solicitud. Un modelo común es cuando un administrador le da acceso a una máquina que no es de su propiedad (como el alojamiento web compartido). Por lo tanto, la idea con ssh es que ofrezca su clave pública a quien le esté dando la cuenta. Es por eso que generalmente no coloca claves privadas en la máquina que recibe las solicitudes. Pero, si desea que esta máquina también haga ssh salientes, debe tratarla como una máquina de origen con los pasos anteriores.
~/.ssh/authorized_keysbajo la cuenta que recibirá las conexiones. Aquí también puede colocar otras claves que pueden conectarse a través de esta cuenta. Una cosa particularmente complicada si está en vi y pegando la clave en el archivo desde el búfer de pegado en PuTTY es esta: la clave comienza con un "ssh-". Si no está en modo de inserción, la primera "s" pondrá vi en modo de inserción y el resto de la clave se verá bien. Pero te perderás una "s" al comienzo de la clave. Me llevó días encontrar eso.chmod 600 ~/.ssh/authorized_keys. Debe ser al menos gw.Como han dicho otros, sus usuarios deben hacer pares de claves para ellos mismos en sus máquinas cliente con ssh-keygen y agregar su clave pública a ~ / .ssh / Authorizedkeys en la máquina en la que desean iniciar sesión.
Sin embargo, para obtener información más detallada, recomiendo SSH, The Secure Shell .
Aquí hay buenos consejos, así que no los repetiré. Una vez que configure un servidor para permitirle iniciar sesión con claves, puede configurar otros para que hagan lo mismo con este único revestimiento:
remote=server1 server2 server3 server4
for r in $remote; do echo connecting to $r; tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh $r "tar zxf -; chmod 700 .ssh" ; done
Simplemente cd a su directorio de inicio, defina la variable remota como uno o varios nombres de servidor y haga un montón a la vez. La contraseña que solicita será su contraseña ssh para el servidor remoto. Por supuesto, puede usar una versión simplificada sin el ciclo for:
tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh YOUR_SERVER_NAME_HERE "tar ztvf -; chmod 700 .ssh"
RECUERDE: solo copie sobre sus claves públicas. No desea que sus claves privadas se encuentren en algún servidor donde cualquier persona con sudo puede copiarlas y forzar su frase de contraseña.