OpenSSH

Esta es una pequeña introduccion de la instalacion y configuracion del OpenSSH
en Debian lenny.
Empezamos con la instalacion de los dos paquetes necesarios para nuestra configuracion.
Como esta es una version de Debian muy nueva les voy a colocar una linea de repositorio que me ha funcionado muy bien deb http://ftp.de.debian.org/debian lenny main.

En la imagen anterior se muestra la linea que utilizamos para instalar nuestro servidor SSH; seguida de la imagen con la cual montamos el cliente SSH.

Como ya hemos instalado los paquetes vamos a crear una llave la cual vamos a enviar al servidor ssh; para conectarnos sin que solicite password de root, si no de nuestra llave.Cabe recordar que nosotros somos clientes y servidores. En algun momento alguien nos enviara su llave para poderse conectar de la misma forma con nosotros.

En el momento de la creacion de la llave el sistema te va a preguntar por una frase o password; Coloca una que te sea facil de recordar.

Ya creada la llave vamos a crear el archivo en donde vamos a introducir las llaves de los usuarios de nuestro servidor, esta ruta esta ubicada en el archivo #> etc/ssh/sshd_config en el viene en la configuracion del SSH, cuando vean el archivo, encontraran una ruta que es la que especifica donde tiene que leer para encontrar la llave de las autorizaciones #> root/.ssh/authorize_keys, este archivo no existe entonces lo creamos como se ve en la imagen de abajo.

Ahora nos vamos a configurar nuestro servidor.

Ahora dejo una pequeña muestra de como se configura el ssh, con una breve explicacion de algunas lineas.
Siginificado de algunas lineas del ssh/sshd_config
RECUERDEN ESTA ES UNA CONFIGURACION PERSONALIZADA. PARA TU NECESIDADES PUEDES TENER OTRA, ESTA ES UNA BASE DE LO QUE SIGNIFICAN ALGUNAS LINEAS.
# Definimos el puerto por el que escuchamos las peticiones de conexión del los clientes
Port 22
# Especificamos por qué direcciones locales escucharemos.
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
# Especificamos las versiones del protocolo que aceptaremos
Protocol 2,1
# Archivos que contienen las llaves privadas de host a usar (solo permisos rw- para root)
# HostKeys 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
# Cada cuantos segundos el servidor regenera las claves, para así evitar el que se puedan
# descifrar sesiones caputaradas y luego usarse. Nunca es guardada en disco.
KeyRegenerationInterval 3600
# Espeficia el nº de bits para la clave del servidor del protocolo v1
ServerKeyBits 768
# Tipo de logeo de actividades -> AUTH=>/var/log/auth.log También disponible DAEMON, USER...
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
# El servidor desconecta al cliente si no se ha logueado correctamente en 600 segs.
LoginGraceTime 600
# Permitimos o no el login del usuario root => poner a no!
PermitRootLogin no
# SSH comprobará que los archivos tienen los permisos correctos, para evitar tener archivos con todos
# los permisos a todos los usuarios
StrictModes yes
# Permitimos la autentificación por RSA (solo para v1)
RSAAuthentication yes
# Permitimos la autentificación por clave pública (solo para v2)
PubkeyAuthentication yes
# Contiene el archivo que contiene las claves para la autentificación
#AuthorizedKeysFile %h/.ssh/authorized_keys
# NO usaremos el método de autentificación por rhost (.rhost)
# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# No usamos el protocolo de autentificación por host
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
# HAbilitamos la autentificación "normal" si todo falla
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user
PAMAuthenticationViaKbdInt yes
# Opciones para servidor Kerberos
# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes
# En un principio, no permitimos exportar las X
X11Forwarding no
# Espeficicamos el primer nº de pantalla disponible para exportar
X11DisplayOffset 10
# Si queremos que al hacer login, al usuario le salga /etc/motd
PrintMotd no
# Por defecto, enseñaremos los datos del último login
#PrintLastLog no
# Para que el servidor pueda "enterarse" de que el cliente ha caido por ej
KeepAlive yes
#
#UseLogin no
#MaxStartups 10:30:60
# Si queremos enviar un banner cuando un cliente se conecte
#Banner /etc/issue.net
#ReverseMappingCheck yes
# Servidor ftp por ssh
Subsystem sftp /usr/lib/sftp-server
Luego de haber organizado nuestra configuracion, procedemos a enviar nuestra llave que se encuentra en la ruta #> root/.ssh/id_rsa.pub, en la imagen a continuacion se mustra el archivo en el Deskto, por que yo lo habia copiado en esa ruta.
Ahora voy a enviar mi llave a otro servidor.

De igual forma con el mismo comando sea desde un equipo linux o windows nos pueden enviar la llave.

Bibliografia
http://www.e-ghost.deusto.es/docs/TutorialOpenSSH.html

Maurio Ortiz Morales
Tutor Admon de Redes de Computadores
Centro de Servicios SENA Medellin.

Esquema PKI

El acrónimo PKI deriva de "Public Key Infrastructure" (Infraestructura de Clave Pública) y es la forma común de referirse a un sistema complejo necesario para la gestión de certificados digitales y aplicaciones de la Firma Digital.
Una PKI bien construida debe tener una arquitectura proporcionar a:
• Autenticidad. La firma digital tendrá la misma validez que la manuscrita.
• Confidencialidad, de la información transmitida entre las partes.
• Integridad. Debe asegurarse la capacidad de detectar si un documento
firmado ha sido manipulado.
• No Repudio, de un documento firmado digitalmente.

Su arquitectura seria:
1. La infraestructura de llave publica o PKI
2. El modelo PKIX, o modelo de las entidades que gestionan la infraestructura de llave publica, degsinando funciones y protocolos.
3. Las politicas y praticas de certificacion CPS y CP.
La arquitectura PKI se encuentra: Internet Certificate and CRL Profile RFC 3280
> Especificada Internet Engineering Task Forge. http://ietf.org
El Modelo PKIX
En la imagen que veran a continuacion, el usuario va a acceder a una pagina de una entidad bancaria, con la cual requiere tener un canal de comunicacion seguro.
Primero abre su browser o navegador y digita la direccion web del banco, la cual hace una serie de peticiones para enviar el certificado al usuario firmado por una autoridad de certificadora ya reconocida y dar tranquilidad sobre la autenticidad de la identidad del banco.

Contiene 5 componentes
1. Entidades Finales: Quien solicita la llave o se pretende identificar
2. Autoridad de Certificacion: La que emite los certificados y es la parte de la credibilidad de la llave publica. Firma los certificados con su llave privada, dando fe de que es en la verificacion de las llaves asignadas son a quien corresponde.
3. Autoridad de Registro: Realiza el proceso de registro de las entidades finales, validad los atributos, genera los secretos compartidos que permiten el proceso de inicializacion y certificacion.
4. Repositorios: Metodo que permite guardar la informacion de PKI "Certificados y CRL", viendo tambien el status de revocacion de los certificados.
5. Emisores CRLs "Certificate Revocation List Issuer":Son listas de certificados que han dejado de ser validos.


Contenido del Certificado.
Es necesario poder vincular la clave pública de un usuario con su identidad y para esto surge el concepto de "Certificado Digital", que contiene la siguiente información:
•Identidad del usuario (Nombre, NIF, etc...).
•Clave Pública del usuario.
•Periodo de Validez del Certificado.
•Identidad de la Autoridad Certificadora (entidad que emite el certificado).
•Firma digital del certificado (los datos anteriores más otras posibles extensiones personalizables, p.e. la dirección de correo electrónico), generada por la Autoridad Certificadora.
Esta información se encapsula en un formato estándar, definido por la norma ISO X.509 versión 3. Generalmente existirá un repositorio (p.e. directorio LDAP) en el que se publican todos los certificados gestionados por la PKI y puede ser consultado por otros usuarios de la PKI que quieran enviar información cifrada o verificar firmas digitales.

Tipos de Certicados
Certificados Clase 1: Son emitidos unica/ a individuos, donde no se verifica la identidad, por lo tanto no permite autenticarla.
Certificados Clase 2: Son emitidos unicamente a individuos que confirman la informacion proporcionada por el suscriptor.Son datos fiables.
Certificados Clase 2 (no reconocidos):Usados para transaciones de bajo riesgo.
Certificados clase 2 (reconocidos): Pueden usarse como soporte de firmas electronicas legal/ reconocidas.
Certificados Clase 3: Son los que requieren evidencias probatorias de la identidad del sujeto o de una URL.


Bibliografia.
http://www.eurologic.es/soluciones/que-es-pki.htm
www.microsoft.com/.../images/04fig4-2_big.gif
Mauricio Ortiz Morales
Docente Admon de Redes de Computadores
Centro de Servicios SENA Medellin.