SSH Secure Shell

SSH es un protocolo y el nombre del programa que lo implementa, que sirve para acceder de forma segura a máquinas remotas a través de una red, permitíendonos ejecutar comandos en la máquina remota e inclusive correr programas gráficos a través del Servidor X.

En este artículo veremos como SSH permite además de la conexión a otras máquinas, copiar datos de forma segura (tanto archivos como simular sesiones FTP seguras), gestionar claves RSA para no escribir claves al conectar a las máquinas y pasar los datos de cualquier otra aplicación por un canal seguro mediante SSH.

Entendiendo SSH

Anteriormente se utilizaba Telnet para accesar máquinas remotas en una red, el problema de esto es que Telnet no ofrece ningún tipo de seguridad, ya que envía toda la información en texto plano y es visible por cualquiera con acceso en la red, lo cual como es de suponerse es un gran riesgo de seguridad es por esto que NUNCA SE DEBE UTILIZAR TELNET PARA ACCEDER A UNA MAQUINA REMOTA y es recomendable deshabilitar este servicio, ya quitado esto del camino vamos a hablar de SSH.

SSH utiliza una arquitectura de Cliente-Servidor por tiene que estar corriendo el daemon de SSH en la máquina donde nos queremos conectar, la versión más popular de SSH es el OpenSSH el cual ya viene instalado por defecto en las mayorías de las distribuciones de linux actuales.

Si estamos en Debian o en Ubuntu (recordando colocar en el caso de Ubuntu al principio del comando) podemos correr el daemon de SSH ejecutando la siguiente línea de código:

/etc/init.d/ssh start

El puerto por defecto que usa SSH es 22, así que si tenemos un firewall activado tenemos que permitir este puerto si queremos permitir conexiones remotas a través de SSH.

Bueno ahora que tenemos SSH corriendo en la máquina remota y tenemos el cliente SSH en la máquina desde la cual nos queremos conectar solo queda correr el siguiente comando desde la consola:

ssh usuario1@servidor_remoto

Donde usuario1 es el nombre de usuario con el cual tenemos creada una cuenta en el servidor remoto y servidor_remoto es el nombre de dominio o la dirección IP de la máquina donde nos queremos conectar.

Cuando ejecutamos este comando nos debería preguntar nuestro password, introducimos el password y ya estamos conectados a la otra máquina, puedes ejecutar cualquier comando para los cuales tengas privilegios en la otra computadora.

Una buena medida de seguridad es no permitir el acceso como root via SSH para esto primero hacemos un backup o respaldo del archivo de configuración de SSH en el servidor remoto:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Luego usando tu editor de texto favorito abrimos el archvio /etc/ssh/sshd_config y buscamos la lína de texto que dice ‘#PermitRootLogin yes‘ y la cambiamos por ‘ #PermitRootLogin no ‘ guardamos el archivo y reiniciamos SSH con el siguiente comando:

/etc/init.d/sshd restart

Si necesitas tener privilegios de root en el servidor remoto puedes crear un usuario que pueda ejecutar su para tener privilegios de root en la máquina remota.

SCP – Copia segura de archivos (Secure File Copying)

SCP es una parte integral del paquete de OpenSSH. Es un simple comando que nos permite copiar cualquier archivo o carpeta desde o hacia una máquina remota usando el protocolo SSH, y es un gran reemplazo para el protocolo FTP el cual es utilizamo ampliamente por los usuarios de Internet pero no están concientes que todos los passwords enviados por este protocolo están en texto simple, es decir, que pueden ser vistos por cualquiera que intercepte la transmisión entre ambos computadores. SCP es una alternativa mucho más confiable ya que manda encriptada toda la información através de SSH.

El ejemplo más simple de SCP es el siguiente:

scp archivo.txt usuario1@servidor_remoto:~/

Este comando copiará el archivo local archivo.txt a el servidor_remoto y lo colocará en el directorio home del usuario1. Se puede utilizar cuaquier directorio al que tenga acceso el usuario1 como por ejemplo /tmp/, /home/publico/, etc.

Ahora si queremos copiar un archivo desde el servidor remoto hacia nuestra máquina local ejecutamos el siguiente comando:

scp usuario1@servidor_remoto:~/archivo.txt

Este comando copiará el archivo.txt que se encuentra en la carpeta /home/ del usuario1 en el servidor_remoto a nuestra máquina local.

Algunas opciones útiles de scp son:

  • -r : para copiar archivos recursivamente (incluyendo subcarpetas)
  • -P port : donde cambiamos port por el número de puerto no estandar (que es el 22) en caso de que tengamos configurado el SSH en un puerto distinto al estándar. Si colocamos el servidor de SSH al puerto 443 que se utiliza para HTTPS podemos saltarnos restricciones existentes en un red corporativa.

Interfaces Gráficas para SSH y para SCP

Una interfaz muy utilizada en Windows para realizar SSH es Putty es un programa totalmente gratuito y muy versatil que normalmente viene acompañado con pscp que permite hacer SCP desde Windows, este programa también está disponible para Linux. Tambien existe otra buena aplicación de SCP llamada WinSCP desde MS Windows.

Tanto Nautilus como Konkeror son capaces de manejar SCP, para esto colocamos en la barra de direcciones ssh://usuariio1@servidor_remoto:~/ y realizamos las transferencias que queramos.

SSH sin passwords – Generando claves RSA

Antes de seguir este paso es de destacar que puede ser inseguro utilizar este método ya que degrada la seguridad del acceso a un servidor remoto utilicelo bajo su propio riesgo.

Puede ser molesto tener que colocar el password cada vez que se realiza una conexión via SSH y utilizar una conexión sin clave es un gran riesgo de seguridad por lo que para este caso tenemos como solución la autorización a través de un par de llave pública-privada.

Este par de llave generalmente es generado en el sistema remoto utilizando el comando ssh-keygen. A continuación vamos a ver un ejemplo de una generación de clave RSA:

$ ssh-keygen -t rsa
  Generating public/private rsa key pair.
  Enter file in which to save the key
(/home/usuario1/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in
/home/usuario1/.ssh/id_rsa.
  Your public key has been saved in
/home/usuario1/.ssh/id_rsa.pub.
 The key fingerprint is:
 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Cuando el programa pregunte por tu password de la llave (key password), debes presionar ENTER, de esta forma se crea una llave sin password. Recuerda que esto es siempre un hueco de seguridad así que hazlo bajo tu propio riesgo. La llave privada se guarda en /home/usuario1/.ssh/id_rsa y nunca se debe hacer pública. La llave pública es guardada en /home/usuario1/.ssh/id_rsa.pub y esta es la que podemos compartir con cualquiera.

Para accesar desde un sistema remoto desde nuestra computadora local sin ningún password (solamente usando llaves), debemos añadir la información de la llave pública en el archivo de llaves autorizadas (autorized_keys) que se encuentra en la carpeta home de nuestro usuario es decir, ~/.ssh. Esto se puede hacer con los siguientes comandos desde nuestro sistema local:

$ scp /home/user1/.ssh/id_rsa.pub 
 user1@remote_server:~/
$ ssh usuario1@servidor_remoto
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

El tercer comando obviamente va a ser ejecutado en el servidor remoto, luego de esto no se necesitará introducir la clave para realizar ningún comando en el servidor remoto lo cual hace las cosas mucho más rápidas.

Si necesitas tener acceso desde el servidor remoto hacia el sistema local tienes que generar un par de llaves en el sistema local y repetir el proceso, ya que las llaves sólo funcionan en un sentido.

Redireccionamiento de X11 – Corriendo aplicaciones gráficas remotamente

Otra funcionalidad de SSH es que permite ejecutar casi cualquier aplicación basada en el protocolo X (protocolo gráfico) remotamente, solo es necesario conectarse al servidor remoto usando la opción -X:

ssh -X usuario1@servidor_remoto

y se mostrará de ahora en adelante cualquier aplicación X que se corra en el sistema local. Podemos hacer que permanentemente se redireccione X11 editando el archivo de configuración de SSH ubicado normalmente en /etc/ssh/ssh_config y cambiando la linea de ForwardX11 de no a yes. Claro que se necesita que la opción de redireccionamiento también este presente en el servidor remoto pero casi siempre está habilitado por defecto.

Para ejecutar cualquier aplicación gráfica podemos utilizar la siguiente sintaxis de comando:

ssh -X usuario1@servidor_remoto 'firefox'

Esto ejecutará el navegador Firefox en el servidor remoto, redireccionando la pantalla a nuestro sistema local.Claro que la velocidad de la aplicación dependerá de la velocidad de nuestra conexión, en las redes locales funciona muy bien de hecho se pueden hasta ver películas, en caso de una conexión por Internet dependerá de que tan pesada sea la interfaz gráfica y la velocidad de conexión que poseas.

Ahora que sabemos conectarnos a un sistema remoto vía SSH, podemos ejecutar cualquier comando que normalmente ejecutaríamos en una máquina local. Esto es muy utíl sobre todo cuando tenemos un servidor web al que no tenemos acceso físicamente y la única forma de accesarlo es de forma remota. También aprendimos como copiar archivos y carpetas así como ejecutar interfaces gráficas remotamente.

En otro artículo veremos otras funcionalidades de SSH y aprenderemos otros trucos más.

Espero que les haya servido de algo y espero sus comentarios.

30 comentarios

  1. Hola ggalaz uno de los programas más utilizados para realizar conexiones SSH desde Windows es Putty, es un simple ejecutable que te permite conectarte via SSH, telnet y otros protocolos.

    Te lo puedes descargar desde:

    http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

    Al ejecutarlo te pedirá la dirección IP del PC al que te quieras conectar, colocas ahí la dirección IP de tu PC con Linux, y cuando se conecte te pedirá usuario y clave que son los del usuario Linux y listo tendrás un terminal via SSH.

    Espero que te sirva cualquier duda vuelve a escribir

    Saludos
    Olivers

  2. Hola, tengo este caso:
    Ya puedo hacer que se conecten sin claves 2 equipos linux, pero cuando trato de conectar el linux cliente a un servidor windows me sigue preguntando por la contraseña…hice el proceso desde cero y no funciono y tambien tome el archivo Authorized_keys2 del linux en el que si funciona y lo copie en el equipo Windows y nada! En el Windows no esta activo el firewall. Podrian ayudarme por favor?

  3. Hola Carlos, gracias por tu comentario, pronto tendré tutoriales de proxy, el de iptables puedes ver el tutorial de Shorewall aquí el cual sirve como una interfaz para iptables y es una herramienta muy poderosa.

    Registrate en los feed para que pueda llegarte la notificación de cuando salgan nuevos tutoriales.

    Saludos
    Olivers

  4. Hola dani, es indiferente si te conectas por putty o winscp por medio de ssh. Para restringir que ve y que puede o no hacer el usuario debes restringirle los permisos al usuario tan simple como eso.

    Esto lo puedes hacer de varias formas, se puede hacer por consola con comandos como chmod, chown y otros. Y tambien lo puedes hacer por alguna interfaz gráfica no me dices que distribución o que desktop.

    Además puedes crear un nuevo usuario con adduser y restringirlo todo lo que quieras. Para más información puedes utilizar:

    man adduser

    Cualquier otra duda puedes consultarla por aqui
    Saludos
    Olivers

  5. Muy bueno el tutorial. Solo una consulta: es posible dejar que un usuario realice un login por medio del Putty y bloquear que el mismo usuario no sea capaz de acceder por el winspc ?
    Mi intencion es hacer que un usuario se conecte y ejecute una aplicacion (por medio del putty) y no se capaz de acceder con el WinSCP para que pueda acceder a los archivos de la aplicacion.

    Desde ya muchas gracias

    Saludos
    Daniel

  6. Hola roque, recuerda que este método es sin password por lo que cuando te pide el passphrase no deberías colocar nada y solo presionar ENTER, este no es el método más seguro como lo menciono en el tutorial ni lo recomiendo pero hay casos donde es aplicable.

    Estas colocando un password? Revisa esto y déjanos saber.

    Saludos
    Olivers

  7. como para ver cual es el problema cuando hago esto :

    ssh -o PreferredAuthentications=publickey servidoremoto

    y me tira este error :
    Permission denied (publickey,gssapi-with-mic,password).

    este es mi sshd_config :

    # $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

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

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

    # 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.

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

    # 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 768

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

    # Authentication:

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

    #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

    # To disable tunneled clear text passwords, change to no here!
    #PasswordAuthentication yes
    #PermitEmptyPasswords no
    PasswordAuthentication yes

    # Change to no to disable s/key passwords
    #ChallengeResponseAuthentication yes
    ChallengeResponseAuthentication no

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

    # GSSAPI options
    #GSSAPIAuthentication no
    GSSAPIAuthentication yes
    #GSSAPICleanupCredentials yes
    GSSAPICleanupCredentials yes

    # Set this to ‘yes’ to enable PAM authentication, account processing,
    # and session processing. If this is enabled, PAM authentication will
    # be allowed through the ChallengeResponseAuthentication mechanism.
    # Depending on your PAM configuration, this may bypass the setting of
    # PasswordAuthentication, PermitEmptyPasswords, and
    # “PermitRootLogin without-password”. If you just want the PAM account and
    # session checks to run without PAM authentication, then enable this but set
    # ChallengeResponseAuthentication=no
    #UsePAM no
    UsePAM yes

    #AllowTcpForwarding yes
    #GatewayPorts no
    #X11Forwarding 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
    #ShowPatchLevel no

    # no default banner path
    #Banner /some/path

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

  8. esto es lo que hago no se que no anda

    ———————-

    paso 1 –

    ssh-keygen -t rsa

    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/saver6/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/saver6/.ssh/id_rsa.
    Your public key has been saved in /home/saver6/.ssh/id_rsa.pub.
    The key fingerprint is:
    d7:56:d8:f9:a5:9a:ce:a4:b0:78:74:40:8d:c6:d9:82 saver6@IRTY

    paso 2 –

    copio el pub al otro servidor

    scp /home/saver6/.ssh/id_rsa.pub saver6@10.158.6.45:/home/saver6

    The authenticity of host ‘10.158.6.45 (10.158.6.45)’ can’t be established.
    RSA key fingerprint is f2:03:a5:35:66:46:e4:77:a1:40:45:47:cf:25:e3:10.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added ‘10.158.6.45’ (RSA) to the list of known hosts.
    saver6@10.158.6.45‘s password:

    pongo el pass y se copia ,

    ahora en el servidor 10.158.6.45 hago el cat

    [saver6@srvd ~]$ cat id_rsa.pub >> ~/.ssh/authorized_keys

    y listo pero cuando me logueo me pide el pass , no se que estara pasando

  9. Hola Roque, recuerda que debes generar el par de claves (publica y privada) y que debes compartir tu clave pública con el sistema local o cliente.

    Revisa si hiciste esto, si colocaste la clave pública generada dentro de tus claves autorizadas en la carpeta correcta. Lo otro es que cuando generas el par de llaves y te pregunta por el pass deberías darle ENTER para que no tenga ningún password.

    Prueba y dinos como te fue, si sigues con el problema podemos buscar otra solución

    Saludos
    Olivers

  10. Hola Overflown, esto que comentas no es un fallo como tal de SSH, es un fallo de Windows si es tal el caso, lo que hay que hacer es tomar previsiones extras a la hora de utilizar Windows como siempre. Otro detalle es que lo que mencionas es cuando se accesa una computadora Windows con SSH no cuando accesas una computadora Linux desde Windows ya que en este caso no hay estos problemas.

    Hay forma de asegurar equipos con MS Windows instalado lo que pasa es que es mucho más tedioso y casi siempre no es 100% seguro.

    Por eso es que es mejor utilizar Linux 😉

    Saludos
    Olivers

  11. ssh combinado con linux es un sistema bastante seguro, pero si lo mezclas con windows ummm kreo ke no es una gran idea…ya que por ejemplo, si yo tuviera una carpeta protegida, c:/usuarios/t0023/… y usuarios es la carpeta protegida pero t0023 no esta protegida… gracias a un fallito de windows podria acceder sin ningun problema al contenido de t0023…aunque la carpeta usuarios estuviera protegida…en mi facultad de informatica usan sistema windows y ssh, y la verdad es que es muy facil asaltarlo jejeje un saludo y cuidense gente…

  12. Hola Miguel, no se a que comando te refieres, pero si puedes copiar archivos entre una PC con Windows y una con Linux fijate en la parte donde dice Interfaces Gráficas para SSH y para SCP ahi menciono un par de programas que puedes instalar en Windows.

    Saludos
    Olivers

  13. Hola tlcarlos, creo que por tu comentario estás compartiendo la clave publica con el servidor remoto y generaste la llave privada en el servidor local, tienes que generar el par de llaves en la computadora que te quieras conectar (en este caso me imagino que será el servidor unix) y sólo compartir la llave pública con el equipo local para poder conectarte.

    Vuelve a leer el paso a paso que está en el artículo y si sigues teniendo problemas vuelve a escribir y veremos como te ayudamos.

    Saludos
    Olivers

  14. Hola, buen manual, sencillo y práctico.

    Tan sólo una apreciación que creo útil para cerrar un poco más la seguridad de este protocolo. ¿No crees que sería bueno recomendar el cambio de puerto por defercto, el 22, a otro número diferente y más alto para evitar algunos scripts que ya cuentan con entrar por ahí? Quizá también limitar el número de intentos, editando /etc/ssh/sshd_config. Yo la sección Authentication la tengo así:

    # Authentication:
    LoginGraceTime 20
    PermitRootLogin no
    StrictModes yes
    MaxAuthTries 2

    Creo que serían útiles algunas recomendaciones de este tipo, centradas en la seguridad.

    Un saludo y gracias por el manual.

  15. Genere las llaves desde un servidor unix solaris y las comparto a el servidor Windows lo agrego en la ruta del home del usuario dentro de .ssh/authorized_keys y aun me sigue pidiendo la contraseña.

    Solo comparti la llave publica al servidor remoto pero cuando trato de firmame aun me solicita la contraseña. Como le hago ?

  16. Hola Carlos, la llave debe ser generada en el servidor remoto, y sólo debes copiar la llave pública al servidor cliente.

    Dices que la llave la generaste en el servidor cliente y ese puede ser tu problema.

    Revisa esto y si sigues con problemas no dudes en preguntar.

  17. Hola que tal
    Estoy tratando de usar la conexion a traves de ssh pero me sigue preguntando el password al accesar el servidor remoto, al cual ya le copie en el archivo authorized_keys la llave publica generada en el cliente, sabes que puede estar pasando? ya que requiero que no se pida el password

  18. Debes comprobar que si tienes instalado un firewall en la PC desde donde te estas conectando remotamente, estén habilitados los puertos de SSH (es el puerto 22).

    ¿Le puedes realizar ping desde la PC remota a tu servidor?

    Prueba hacer telnet desde la PC remota a tu servidor y ve si te funciona, si puedes entonces me avisas y estudiamos mejor el caso.

    También dime que tipo de PC es desde la que te estas conectando (Windows, Distribución de Linux) etc.

    Avisame como te fue

  19. Me funciona todo, pero cuando accedo remotamente no me va.
    Hay algún parámetro que deba activar en /etc/ssh/sshd_config?
    El router lo tengo bien configurado, porque de momento, mi pc está en DMZ y todos los puertos van directos a mi máquina.