Guía de OpenSSH




Luciano Bello - luciano (arr@ba) sistemas.frba.utn.edu.ar
Ver. 0.4 - 22 de Enero de 2004
La última versión está disponible en http://www.lucianobello.com.ar/openssh/
Tablero de cambios 0.1 10-Ene-04 Partes incompletas o no revisadas, explicación de forwarding.
0.2 13-Ene-04 Correcciones ortográficas, de formato. Se completa parte del Apéndice I.
0.3 15-Ene-04 Menos errores de tipeo (thx Fedex!). Arreglo de links rotos. Validación W3Consortium para HTML 4.01 Transitional. Optimización de los png (thx Sismo!).
0.4(current) 22-Ene-04 Se hacen las pruebas de seguridad del forwarding. Se agregan los créditos de Dia y de Gimp. Se agregan subsecciones en "(In)Seguridad en el forwarding". Se completan las capturas de pantalla incompletas.


Copyright © 2004 Luciano Bello. Se permite la copia, distribución y/o modificación de este documento bajo los términos de la GNU Free Documentation License, Versión 1.1 o cualquier otra versión publicada por la Free Software Foundation; con la Sección Invariante siendo "Prefacio", con el Texto de Portada siendo "Guía de OpenSSH", y sin Textos al respaldo de la página de título. Una copia de la licencia se puede encontrar aquí.

a Machu
--------------------------------------------------------------------------------
Índice
Índice
Prefacio
Sobre este documento
Convenciones
Introducción a SSH
Introducción a OpenSSH
Tuneleando conexiones (Port Forwarding)
¿Porque tunelear conexiones?
A forwardear se a dicho
Forwarding Local simple
Forwarding Local a un servidor protegido/nateado
Forwarding Local de una red (Gateway al túnel)
Forwarding Remoto
Forwarding del X
¿Y que hago con el shell?(completar)
(In)Seguridad en el forwarding
Deshabilitar el forwarding
Tramos no encriptados
Multiusers en un forwardeo de localhost
GatewayPorts en todas las interfaces
Resumen de Referencia
T.U.P.E.R. (Tips Útiles, Pequeños, Estúpidos y/o Rápidos)
Loguear conexiones entrantes y salientes (check!)
Proteger el acceso de root
Abrir X remotamente desde una sesión ssh (check!)
Ejecutar un comando remotamente
Apéndice I (PuTTY)
Creando túneles
Port Forwarding
Caso de Estudio

--------------------------------------------------------------------------------
Prefacio
Sobre este documento
El autor no se hace responsable de los daños o perdida de datos producidos por la libre aplicación de la información contenida en este documento. De hecho, nadie se hace responsable. Que a mi me haya funcionado no significa que respondo por los resultados.
Para un mejor seguimiento de cambios de este documento sugiero que quien lo modifique me avise, así toda la comunidad puede hacer uso de ellos. Los créditos de los cambios serán respetados, como también los créditos originales del autor. Si quiere hacer referencia a este documento o si quiere tener una copia en su página ruego también se me avise.
El autor suele castellanizar palabras del inglés como "tunelear" (por "tunneling"), espero esto sea útil y no moleste a nadie, pero hay palabras anglosajonas que no tienen su equivalente en el español. Tal vez, con el tiempo, haga un pequeño glosario para los no argentinos.
Los dibujos están hecho en Dia y retocados con TheGimp se pueden agrandar haciendo un click sobre ellos.

Este documento intenta ser una humilde guía práctica de OpenSSH, así como también un manual de referencia para consultas rápidas. Críticas, preguntas o mejoras son bienvenidas y agradecidas.
Convenciones
Si el segundo número de la versión es distinto a 0 es porque hay cosas no probadas, porque se hace referencia a secciones que todavía no se escribieron o porque hay secciones incompletas. Cuando se agregen nuevas secciones del nivel más alto, el primer número aumentará. Para detalles sobre los cambios en las versiones puede seguir el "Tablero de cambios", en la parte superior de este documento
La jerarquía de títulos es la correspondiente a la etiqueta del código HTML.
Los nombres de host se escriben en italic. Por ejemplo: imap.utn.edu.ar. Los nombres de los archivos en courier. Por ejemplo: /etc/ssh/sshd_config. Los comandos y salidas de terminales se expresan con letras gruesas blancas sobre fondo negro, y sus comentarios con letras finas. En bold irán las palabras claves o los conceptos que merezcan ser resaltados. Los canales seguros (o sea, encriptados por la sesión SSH) se representan con una flecha de color gruesa. Los números de puertos a los que se hace referencia son todos TCP, a menos que se aclare lo contrario.
--------------------------------------------------------------------------------
Introducción a SSH Secure Shell es una solución basada en software que mantiene seguros los datos de la red. Muchos usuarios de telnet, rlogin, ftp y otros programas parecidos, no se dan cuenta que sus contraseñas se están transmitiendo sin cifrar a través de la red. SSH cifra todo el tráfico (incluidas las contraseñas) para eliminar de un modo efectivo las "escuchas", los secuestros de las conexiones y otros ataques a nivel de red. Además, SSH ofrece amplias posibilidades para la creación de túneles seguros, aparte de una variedad de métodos de autenticación. Parece cosa de locos, pero Secure Shell no es un shell. No es un interprete, historial de comandos, ni demás.
Pero sí hace cosas muy útiles por la seguridad de un sistema en entornos poco confiables. Algunas "features":
Protocolo criptográfico en un modelo cliente/servidor
Autenticación de las más variadas formas:
por contraseña
por host
por sistema de llaves
Integración con sistemas de autenticación como:
Kerberos
SecurID
PGP
TIS Gauntlet
PAM
Seguriza los protocolos de aplicación de manera (casi) transparente Implementación sobre la mayoría de los sistemas operativos y plataformas
--------------------------------------------------------------------------------
Introducción a OpenSSH
De la página de OpenSSH: «OpenSSH es una versión LIBRE del paquete de herramientas de comunicación segura del protocolo SSH/SecSH para redes, una solución de seguridad que está ganando la confianza de un número cada vez mayor de usuarios de Internet.[...] Está desarrollado principalmente por el Proyecto OpenBSD, y su primera integración en un sistema operativo fue en OpenBSD 2.6. Estos programas se desarrollan fuera de los EE.UU., usando código desarrollado en unos 10 países distintos. Este código es de libre utilización bajo la licencia BSD.
La gestión de la distribución de OpenSSH está dividida entre dos equipos. Un equipo sólo lleva a cabo el desarrollo basado en OpenBSD, y su objetivo es el de producir un código que sea tan limpio, simple y seguro como sea posible. Estamos convencidos de que el sacrificio de la portabilidad en favor de la simplicidad permite un mejor control de calidad y facilita la revisión del código. El otro equipo toma la versión "pura" y la convierte en una versión portable, para que pueda funcionar en muchos otros sistemas operativos (estas versiones se conocen como "versiones p", y se distinguen por nombre como OpenSSH 3.7p1). Esta es la lista de Sistemas Operativos donde OpenSSH está portado:
AIX
HP-UX
Irix
Linux
NeXT
SCO
SNI/Reliant Unix
Solaris
Digital Unix/Tru64/OSF
Mac OS X
Cygwin
... y más que van siendo añadidos continuamente.»
Esta guía se basará en OpenSSH por ser LIBRE y por que muchos sistemas operativos y productos lo tienen integrado al sistema base. Aunque la mayoría de los conceptos son igual de aplicables a las implementaciones propietarias.
--------------------------------------------------------------------------------
Tuneleando conexiones (Port Forwarding)
¿Porque tunelear conexiones?
SSH no solo provee un login remoto de manera segura. También permite generar conexiones de servicios inseguros (como ser http, imap, pop entre otros) sobre sesiones de SSH de manera (casi) transparente para ellos. Esto es lo que se llama "Port Forwarding".

Pero... ¿por qué forwardear conexiones?


Porque necesito acceder a servicios TCP internos de una LAN con direcciones privadas
Porque no quiero que pasar mi clave en texto plano de FTP (canal de control y comandos), Telnet, POP3, IMAP, SMTP o NNTP
Porque necesito atravesar un firewall donde solo servicio de SSH está permitido
Porque el relay del SMTP de mi ISP solo está abierto para las direcciones asignadas por él y quiero usarlo para mandar mis mail
s Porque quiero servicios X a través de una red insegura

A forwardear se a dicho
Antes de poner en práctica el forwarding de puertos sugiero leer las implicancias de seguridad que las distintas técnicas conllevan.

Si los conceptos ya se conocen la sección "Resumen de Referencia" puede ser útil como ayuda memoria.

Cuando se genera una sesión SSH se puede hacer que ciertas aplicaciones pasen por el túnel encriptado que se generó. Para las aplicaciones superiores es (casi) transparente y segurizar de esta manera es mucho menos engorroso que levantar una VPN. Pero solo permite que aplicaciones TCP pasen por el túnel, ya que son orientadas a conexión. UDP no maneja sesiones, por lo que este sistema no funciona para servicios como DHCP, NFS, NetBIOS y TFTP entre otros. Tampoco se pueden forwardear protocolos no basados en IP, como AppleTalk o IPX. Para resumir, solo TCP/IP está permitido, como ser: Telnet, HTTP, SMTP, HTTPS (HTTP con encriptación SSL), POP, IMAP, ciertas características de DNS, SSH en sí mismo y FTP, este último con algunas consideraciones /*que explicaré luego(ref!)*/.

Como ejemplo de forwarding voy a usar el servicio de IMAP. La situación es la siguiente: tengo, tras un firewall, un servidor (que llamaremos "imap.utn.edu.ar") de IMAP (corriendo en el puerto 143/tcp) y de OpenSSH (en el 22/tcp). En otra punta de InterNet (atravesando redes inseguras) está mi computadora (que llamaremos home, con conexión y los cliente correspondientes de ambos servicios.


Si yo me conecto directamente tanto el nombre de usuario como la contraseña se transmiten en texto plano. Pero al usar port forwarding la comunicación en su totalidad será encriptada. Cabe aclarar que esto no me dará seguridad para la conexión extremo a extremo de los correos, ya que antes de llegar a mi servidor atravesaron otros servidores, de los cuales desconfío (¿no seré demasiado paranoico?). Si quiero seguridad desde el remitente necesito usar algún sistema como GPG (la implementación GNU de PGP) o algún otra encriptación aplicada desde la generación del correo mismo.

Forwarding Local simple
Este método es el más sencillo de entender en un principio. Y es cuando el servidor y el cliente de la aplicación a forwardear son también los extremos de la sesión SSH, como en nuestro caso.
Volviendo al ejemplo, en home tendré que tipear el siguiente comando:
home:~$ ssh -L 10143:localhost:143 imap.utn.edu.ar
Analicemos los modificadores (para ver como guardar los parámetros de una sesión consultar "configuración del cliente"(ref: todavía no escrita):
-L significa que es un forwarding local (que quedará mucho más claro en contraposición al remoto)
10143 es un puerto que esté libre elegido arbitrariamente entre el 1024 y el 65535. Yo suelo usar a partir del 10000 y dependiendo del servicio, así es una manera sencilla de referirme al puerto 143 usando el 10143. Una cosa a tener en cuenta, un usuario no root no puede usar puertos por debajo del 1024 por cuestiones de seguridad, salvo deshonrosas excepciones (MacOS y MS Windows, puaj!). localhost es el servidor IMAP destino, que en este caso es el mismo que el servidor SSH. También se podría haber sustituido por imap.utn.edu.ar, pero en ciertos entornos puede traer (ref!?)algunas complicaciones(ref!?).
143 es el puerto donde está escuchando el servicio de IMAP, el objetivo final. Así, cuando dé "intro", tendré un login en el servidor SSH donde habré de autenticarme. Una vez que me identifique, un shell estará a mi disposición. Ahora tengo que reapuntar mi cliente IMAP hacia la entrada del túnel (es decir, localhost:10143 y no imap.utn.edu.ar:143). Cuando dé la orden de sincronizar mis correos el paquete se dirigirá al puerto 10143 de home, ahí el cliente SSH lo encriptará y lo enviará al servidor SSH en donde los desencriptará y lo mandará a localhost (o sea él mismo) en el puerto 143. De esta manera la comunicación viajará segura.

Veamos algunas pruebas de lo que acabó de pasar (la salida se modificó levemente para facilitar el ejemplo). Estos son lo puertos que se generaron en home:
home:~$ netstat -na | awk '{ if (/22/ || /10143/ ) print $0; }'
tcp 0 0 127.0.0.1:10143 0.0.0.0:* LISTEN
tcp 0 0 home: imap.utn.edu.ar:22 ESTABLISHED

Nótese el puerto 10143 que escucha en localhost y la conexión al 22 de imap.utn.edu.ar. Por otro lado, en el shell que generamos en imap.utn.edu.ar se puede ver que el servidor IMAP y SSH están a la escucha, además de la conexión establecida con home:
imap:~$ netstat -an | awk '{ if ( /22/ || /143/ ) print $0; }'
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 imap.utn.edu.ar:22 home: ESTABLISHED
Las siguientes linea solo se ven mientras se sincronizan los correos
tcp 0 0 127.0.0.1: 127.0.0.1:143 ESTABLISHED
tcp 0 0 127.0.0.1:143 127.0.0.1: ESTABLISHED

Las dos últimas lineas son la conexión final del servidor a sí mismo.
Algo raro: Si hacemos el túnel con Putty e intentamos realizar la experiencia de estos netstat antes de que nuestro cliente IMAP sincronice los correo no veremos nada, no así cuando el cliente es OpenSSH, que levanta el puerto junto con la sesión SSH.

Forwarding Local a un servidor protegido/nateado
Vayamos complicando el ejemplo. Este es el nuevo escenario: El servidor IMAP no tiene servicio de SSH por alguna razón. Pero puede pasar que el firewall o que alguna otra máquina dentro de mi DMZ tenga servidor de SSH. Así, si mi servicio de IMAP está solo disponible para la red interna puedo usarlo igual, ya que será el una máquina interna quien realice la conexión.

Esta situación sería parecida si lo que quiero es usar el servidor SMTP de mi empresa, cuyo relay está abierto solo a la red interna


A fines prácticos es lo mismo si el servidor SSH está en el firewall o en un host interno. En nuestro ejemplo llamaremos bastion.utn.edu.ar a quien corra el demonio SSH en el puerto 22/tcp. Este sería el comando a correr en home:
home:~$ ssh -L 10143:imap.utn.edu.ar:143 bastion.utn.edu.ar

Lo que genera un esquema de conexiones así:


Los primeros pasos de la conexión son muy semejantes a los del caso anterior. El cliente IMAP de home se conecta a localhost:10143 ahí se encripta sobre la sesión SSH hasta bastion.utn.edu.ar. Hasta acá igual, pero esta vez bastion.utn.edu.ar se conecta a imap.utn.edu.ar:143. Este último tramo no será encriptado, por lo que un sniffer en nuestra DMZ verá pasar nuestra clave en texto plano.

Forwarding Local de una red (Gateway al túnel)
Ahora se empieza a poner más lindo. Esto es lo que se conoce como "off-host port forwarding". En mi casa, home es el gateway de una pequeña red hogareña. Tengo dos máquinas más, espiralito y tuxboy. Estas dos máquinas tienen clientes IMAP.


Con mirar el siguiente dibujo se pueden dilucidar algunos evidentes problemas de seguridad. El más obvio es que dos de las tres conexiones son no encriptadas. Pero hay más, la sección "(In)Seguridad en el forwarding" trata estos temas.


Para correr la siguiente linea se debe estar consiente de la implicancias de seguridad, pero (bien usada) puede ser MUY útil. home:~$ ssh -g -L 10143:imap.utn.edu.ar:143 bastion.utn.edu.ar
El modificador -g permite que tanto tuxboy como espiralito redireccionen sus clientes a home:10143 para entrar en el túnel. Esto también puede hacerse agregando la linea en el archivo de configuración del cliente (el default es "no"):
~/ssh/ssh_config
GatewayPorts yes


Forwarding Remoto
En todos nuestros casos en modificador que usamos fue -L para Forwarding Local. Pero existe otro tipo de forwarding, menos usado: Forwarding Remoto. Sería algo parecido a lo que es el Call-Back en un servidor dial-up.
El Forwarding Remoto es igual al Local, pero al revés. El servidor de la aplicación es quien inicia la sesión SSH hacia el cliente de la aplicación. Veamos el esquema de nuestro ejemplo:


Si estubieramos logueados en imap.utn.edu.ar, y home fuese "resolvible" (que se puede resolver a una IP, sino hay que poner la IP) por él, se puede generar el túnel inverso así:
imap:~$ ssh -R 10143:localhost:143 home
Las opciones tienen una interpretación levemente diferente:
-R especifica el forwarding como remoto. El puerto 10143 es que home usará para conectarse al túnel. Desde el punto de vista de imap.utn.edu.ar es ahora el puerto remoto. localhost, porque quien inicia la sesión es el mismo servidor de IMAP. 143 es el puerto a forwardear, donde el demonio de la aplicación está escuchando.
Si el servidor es OpenSSH (debería ;-)) soporta la opción GatewayPorts y se aplica globalmente a todos los forwarding remotos establecidos por él.(check!)
Al principio puede ser algo confuso, o simplemente no entender en que situación usar cual. Esta puede ser una buena regla práctica:
En el forwarding local la aplicación cliente a forwardear está del mismo lado que el cliente SSH.
En el forwarding remoto la situación es inversa: La aplicación servidor tiene un cliente SSH y es desde donde se inicia la sesión.
De entrada el forwarding remoto puede parecer inútil, pero hay casos en donde puede sacarnos las papas del fuego. En el Apéndice I se puede leer acerca de un caso de estudio puntual con MS Windows, pero es cuestión de imaginación para crear nuevos escenarios útiles.


Forwarding del X
El forwardeo de sistemas X es todo un tema aparte. Por el momento espero sirva esto:
ssh -X @


¿Y que hago con el shell?(check)
Si me deslogueo de la sesión que generó el túnel! guarda con ventanas cortas.
(como http adif de SSH)
Para generar un túnel TCP/IP sobre la sesión SSH primero hay que abrir la sesión. Después de la autenticación el cliente nos dará un shell para correr comandos en el host remoto. La opción -f

(In)Seguridad en el forwarding Me cansé de decirlo: El forwarding puede ser inseguro, por eso se debe estar consiente de que se provoca cuando se levanta un túnel y como solucionar estos problemas según el entorno donde se lo aplicó. Incluso si en un entorno no se usa Forwarding es bueno leer esta sección, sobre todo el primer punto. A continuación se enumerarán los casos y consejos, si leyendo se te ocurren otro podes mandármelos para agregarlos a la lista

Deshabilitar el forwarding
Primero lo primero, puede que como sysadmins no queramos que se haga forwarding en los servidores de nuestra DMZ. Deshabilitar el forwarding si no se usa debería ser lo segundo después de prohibir el acceso de root por SSH. Por otro parte, si solo usas tu servidor SSH para correr shells, te recomiendo que también lo deshabilites, ya que si alguna cuenta de usuario está comprometida pueden utilizarte de trampolín para otros ataques a tu red o a otra.
~/ssh/sshd_config
AllowTcpForwarding no


Tramos no encriptados
En casos de forwarding off-host se hizo referencia a la inseguridad en ciertos tramos de la conexión end-to-end. Si no se confía en las redes internas de las puntas y el servidor o cliente final no tienen SSH, entonces el túnel puede no dar toda la seguridad que se pretende. En este caso hay dos opciones:
Se instala un servidor alguno de los extremos (cliente siempre hay).
Se utiliza criptografía en la aplicación. Por ejemplo SSL/POP para el POP.
De cualquier manera que siempre será más seguro usar forwarding que no usarlo, pero estar consiente de los tramos no encriptados nos ayudará a evitar una falsa sensación de seguridad.


Multiusers en un host con puertos forwardeados
Cuando abrimos un túnel se abre un puerto en localhost. Este puerto puede ser accedido por cualquier usuario con cuenta en el equipo. En la mayoría de los casos esto no es un problema, o porque la aplicación forwardeada tiene su propio sistema de autenticación o porque los usuarios del sistema suelen ser una cantidad manejable.

GatewayPorts en todas las interfaces ¡Este es un problema terrible para el forwarding off-host! Cuando habilitamos la opción GatewayPorts (o su equivalente -g) estamos levantando un nuevo puerto en nuestro host. Veamos este netstat de home.utn.edu.ar, cliente de la sesión SSH iniciada con -g:

home:~$ netstat -an | grep 10143
tcp 0 0 *.10143 *.* LISTEN

Importantísimo recalcar el asterisco (*), ya que significa que está escuchando en todas las interfaces.Es decir cualquiera puede usar este puerto para conectarse al servidor imap.utn.edu.ar conectándose a la IP de home en su puerto 10143. Basca con imaginarse que, por ejemplo, se esté forwardeando smtp. ¡Se dejaría un relay abierto para el mundo!
La solución es un filtro de puertos en home, lo que sería más que lógico teniendo en cuenta que es un host en el borde de nuestra red. En las reglas hay que poner que no se permiten conexiones desde InterNet a los puertos altos.
Resumen
Resumen del uso del forwarding. (a completar)

--------------------------------------------------------------------------------

T.U.P.E.R. (Tips Útiles, Pequeños, Estúpidos y/o Rápidos)
Loguear conexiones entrantes y salientes (check!)
~/ssh/sshd_config
SyslogFacility AUTH
LogLevel INFO


Protegiendo el acceso de root
Para que root no pueda loguarse a través de una sesión SSH hay que deshabilitar esta opción, así los usuarios tendrán que hacer su para ejecutar comandos con privilegio.:

~/ssh/sshd_config
PermitRootLogin no


X en una sesión ssh (check!) En host_destino hay que permitir X Forwarding

ssh -X


Ejecutar un comando remotamente
Cuando solo se quiere ejecutar un comando sin necesidad de un shell interactivo.
ssh @

--------------------------------------------------------------------------------

Apéndice I - Putty
PuTTY es un cliente de SSH/Telnet para plataformas MS Windows de 32 bits, creado por Simon Tatham de Gran Bretaña. Es bastante intuitivo de usar y, además, es libre (licencia MIT, similar a la BSD).

Esta sección no intenta llegarle ni a los talones a la documentación oficial pero sí intenta ser una referencia para casos puntuales. Los screenshots son de la versión 0.53b, la última a la fecha de escritura de esta sección.

Creando tuneles
En la sección "Tuneleando conexiones" se explico la teoría de su funcionamiento y su uso en el cliente de OpenSSH. Con PuTTY se puede hacer forwardeo de puertos TCP/IP y de X desde la opción Connection -> SSH -> Tunnels. Este panel se divide en dos: "X11 forwarding" y "Port forwarding".

Los números rojos son para luego hacer referencia a esas partes de la pantalla durante la explicación, poniendolo [entre corchetes]. Por ejemplo: [1] para referirse al checkbox de "Enable X11 forwarding".
Port Forwarding
Veamos como hacer forwarding de secciones TCP/IP, cuya teoría se explicó aquí. Se aplicará el mismo ejemplo del servicio IMAP que se usó anteriormente, con la única diferencia que ahora home es un Win32, cosa que nunca pasará ;-).
Para un forwarding local hay que seleccionar la opción [10] (para forwarding remoto la opción es la [11]), colocar el puerto donde el tunel empieza en [7] (donde hay que redirigir el cliente IMAP, para nuestro ejemplo) y en [9] el servidor de imap seguido de dos puntos y el puerto. Queda algo así:

Después, con el botón [8], se lo agrega en la lista de puertos a forwardear [6]. Se lo pueden agregar múltiples puertos para forwardear en una sesión. Incluso algunos pueden ser locales y otros remotos. Si queremos borrar alguno se lo selecciona de la lista [6] y con el botón [5] se lo borra. Cuando esten todos por puertos (y si completamos la opción "Session" con los datos del servidor SSH) se puede dar la opción "Open" y el túnel quedará formado. Todas estas opciones pueden guardarse en "Session".

Caso de Estudio
Resulta que por esas vueltas del destino tengo un Internet Information Server en una red privada con un desarrollo web para un cliente de la empresa a la cual trabajo. Este servidor es de pruebas y no está público en InterNet, pero necesito mostrarle las versiones beta del desarrollo al cliente en cuestión, quien es inteligente y tiene un Unix-like (en este caso es un FreeBSD) en su red. ¿Cómo puede ayudarme el forwarding del PuTTY?
Si en mi servidor web pongo el PuTTY (no necesita instalación ni privilegios de administrador) puedo generar un forwarding remoto contra el servidor de SSH que tiene el cliente. De esta manera él se conecta a su servidor en el puerto forwardeado y entra en el tunel que da a mi puerto 80. Sin VPN ni ambientes complejos, todos gracias a un programita de menos de 350 K.

--------------------------------------------------------------------------------
Ver. 0.4 Luciano Bello luciano (arr@ba) sistemas.frba.utn.edu.ar
La última versión está disponible en http://www.lucianobello.com.ar/openssh/
Fuente:
http://www.lucianobello.com.ar/openssh/


Otras artículos de interés:

Fish, la terminal con esteroides
Desde el blog del amigo @sinfallas encontré este post bastante interesante sobre Fish (desde uso Fish, ha sido más rápido trabajar con la terminal). A...
Instalar NTP en CentOS 6
Desde la consola: Instalamos: yum install ntp ntpdate Activamos el servicio: chkconfig ntpd on Iniciamos el servicio servicio ntpd start ...
Scam (fraude) en el mundo de las criptomonedas
Desde que se ha popularizado los bitcoins se han generados miles de sitios web para engañar y/o estafar a las personas con ansias de hacer dinero fácil. Esos sitios algunos basados en el sistema ponzi, otros sencillamente con solicitud de gananc...
Bio Criptoanalisis
...
El problema del Spyware
Articulo Bastante interesante: Spyware es software o hardware instalado en un ordenador, generalmente sin el conocimiento del usuario, que recoge información de dicho usuario para más tarde enviarla por Internet a un servidor. Por Marcos Rico (*) ...
Habilitar acceso remoto a MySQL
Nota: En acceso remoto podría ser consecuencia de una vulnerabilidad, si antes poseías una regla que cerraba el puerto 3306 al eliminarla podrías ser vulnerable. Sí despues de leer la nota aún quieres habilitar el acceso remoto:...
Fonts para Xanadu Linux - Debian y Derivados
Hemos creado un paquete que contiene las siguientes Fonts (Tipos de Letras) para la Distribución Xanadu Linux, aunque funcionan para cualquier Distribución basada en Debian Los usuarios de Ubuntu, Linux Mint, Canaima, pueden usarla sin...
Instalando Ubuntu desde Windows
A todos mis compañeros y amigos desde hace algún tiempo le he sugerido que usen a Linux como su sistema operativo y que dejen a un lado el lado seguir usando el Micsoft Windows aunque sea crakeado. Esta solución bastante sencilla ...
Ataques Cross-Site-Scripting
Modos de Ataque I Al referirnos al Cross-Site-Scripting podemos encontrar bastante material didáctico acerca del tema, algunos de ellos describen los modos de ataques como directos e indirectos, pero realmente creo que podemos simpl...
Liberar memoria RAM Debian - Ubuntu y derivados
En equipo de poca memoria RAM es necesario que la memoria que no estemos usando sea liberada de inmediato, afortunadamente Linux permite hacer eso de una forma sencilla. Solo debemos teclear lo siguiente en consola. free -m ...

Brindanos
un o una


Redes Sociales

Publicidad


Gana Bitcoins desde tu casa

Categorías


Planeta Vaslibre

Blog Roll




Nube de tags

  • anonimato
  • anonimo
  • antivirus
  • apache
  • blog
  • bsd
  • bug
  • centos
  • chrome
  • cifrado
  • computer
  • debian
  • exploits
  • fedora
  • fice
  • firefox
  • forense
  • freebsd
  • gentoo
  • github
  • gnome
  • gnu
  • gpl
  • gtk
  • guia
  • hack
  • hacking
  • hosting
  • informatica
  • internet
  • isos
  • libre
  • licencias
  • linux
  • linuxmint
  • lxde
  • micros
  • mint
  • mit
  • mozilla
  • mysql
  • noticia
  • opensource
  • openssh
  • pgp
  • php
  • sabayon
  • seguridad
  • system
  • tecnologia
  • thunar
  • thunderbird
  • tor
  • troyanos
  • tware
  • ubuntu
  • underground
  • vaslibre
  • virus
  • viserproject
  • vivaldi
  • vulnerabilidades
  • web
  • website
  • windows
  • xanadu
  • xfce
  • xombra