FreeBSD 8: Configurando ssh con llaves publicas

ssh tiene muchas opciones para hacerlo aun mas seguro, cuando tienes abierto el puerto atraves de tu firewall y lo tienes configurado por default, esta abierta la opcion: usuario+passwd.

Esto hace que en los logs de tu firewall aparezcan varios intentos de acceso tratando con diccionarios y esto le quita CPU a tu firewall como servidor.

Por ello es mas conveniente crear tu llaves y autentificarse con ellas, asi ya puedes deshabilitar el usuario+password.

Para ello tienes que tener configurado el sshd_config asi:

# $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $
# $FreeBSD: src/crypto/openssh/sshd_config,v 1.49.2.1.2.1 2009/10/25 01:1

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

#VersionAddendum FreeBSD-20090522

#Port 22
#Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable PAM authentication
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

#2010-03-04
AllowUsers root@192.168.50.120 root@192.168.50.100 root@192.168.50.3

La ultima linea marcado en bold, no viene en la configuracion original, con esto aun puedes darle mas seguridad a tu ssh, por que aqui solo le estas permitiendo a el usuario root poder accesar pero solo de las ip's ahi indicadas y puedes tambien hacerlo de la forma:

root@example.com

Si tienes un dns funcional.

Todo lo marcado en bold es lo que hago para tener un ssh mas seguro. Linux por default tiene habilitado el usuario root pero en FreeBSD no, es a veces un poco incomodo tener que estar haciendo el su o usar el sudo por ello yo prefiero tener el root abierto.

En el sistema donde estoy haciendo esto, necesito darle las llaves de los clientes que tienen permitido accesar.

Esos clientes tienen que tener ya listas sus llaves publicas, si no las tienen solo ejecutan este comando en cada uno de ellos(hablando de Linux/Unix):

ssh-keygen

Si gustan le dan una frase, pero luego se las va a estar solicitando, aqui solo denle enter hasta que termine la operacion, luego ya vamos a tener tiempo para investigar mas este parte.

Su sistema les va a poner las llevas en el home del usuario con el que las generaron, si fue root en /root/.ssh/

1; id_rsa
2; id_rsa.pub

2) es la llave publica la otra es la llave privada, esa se queda en su cliente a nadie se la tienen que dar, es su seguro.

En windows pueden hacer todo bajando el paquete completo de putty, ahi viene un modulo que se llama: PuTTYgen con el hacen todo graficamente.

Bien de lado del equipo que deseamos accesar debemos darle las llaves, estas se guardan en la misma ruta donde se guardan las llaves de cada usuario, en el archivo de nombre:

authorized_keys

es un archivo de texto, aqui vas las llaves asi:

ssh-rsa
7asdf87sdaf978dsa90f7s9da0f790ds7fdsaf980dsfn9sd87f09sd809sad8a78d709s7f9asd7f09sad7f9IUU=(=)(=)(JMN=(=)(=)MN==?=
%%$·"%khbyiubyUYBIUYyiy&786IUbuiinOYT0= pepito@example.com

es mi llave publica, es un listado grande que debe de ir en una sola linea de este archivo, aqui podemos poner cuantas llaves quieran, cada una es para cada usuario.

Y con esto listo, solo arrancamos el servicio y prueban.

/etc/rc.d/ssh start

Abren su cliente ssh y adentro, saludos!!!