Envía el password de SSH en la misma línea con el paquete sshpass

Para aquellos que usamos en nuestro día a día el SSH, o sea, los que necesitamos acceder a ordenadores o servidores remotos de forma constante en nuestro día a día llegamos al punto de hartarnos de teclear contraseñas, sería:

  1. Teclar en una terminal: ssh usuario@servidor
  2. Esperar unos segundos
  3. Nos pedirá el password el servidor a donde deseamos conectarnos
  4. Una vez ponemos el password y presionamos [Enter] entonces es que accederemos al servidor remoto

Y ahora mi pregunta, ¿no es más simple teclear solamente?:

sshpass -p «PASSWORD» ssh root@servidor

Por ejemplo, supongamos que el usuario es root, el servidor es: dev.desdelinux.net y el password es xunil … entonces la línea sería:

sshpass -p xunil ssh root@dev.desdelinux.net

Para lograr esto simplemente debemos instalar el paquete sshpass, en Debian/Ubuntu o derivados sería con sudo apt-get install sshpass mientras que en ArchLinux o derivados bastaría con sudo pacman -S sshpass

Si deseamos especificar el puerto (pues el SSH no se encuentra en el puerto 22) añadimos -p «PUERTO» … o sea, suponiendo que sea el puerto 9122:

sshpass -p xunil ssh root@dev.desdelinux.net -p 9122

Para simplificar todo esto aún más podemos crear alias, por ejemplo que al ejecutar server1 se ejecute toda la línea para conectarnos por SSH al server1 (sshpass -p password usuario@server1) o algo similar, así nos ahorramos también poner una línea demasiado extensa 

En fin, espero que esto les haya sido de utilidad.

Por cierto, otra forma de evitar tener que escribir el password cuando accedemos por SSH es mediante el uso de llaves públicas y privadas.

Saludos


Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

      Linuxito dijo

    Mis disculpas pero esto es una terrible aberración de seguridad!! Te queda el password clavado en scripts, archivos de texto plano, bash history, etc.
    Para eso openssh soporta la autenticación mediante clave pública utilizando RSA.
    Gracias a este tipo de prácticas (implementadas por sujetos que se dicen «administradores») hay tanta inseguridad informática.
    Saludos.

         elav dijo

      A ver. Si, es un problema de seguridad pero no significa que «sujetos» que sean o no administradores tengan que usar este método. El método existe y se muestra por si se necesita usar en un ambiente donde la seguridad no sea un problema. En la tienda te venden el cuchillo, tu decides si lo usas para cortar verduras o matar a alguien.

           Linuxito dijo

        Entiendo tu postura, pero me da lástima que en un blog de semejante renombre fomenten este tipo de prácticas, es casi como una «apología a la pésima administración de sistemas» jeje.
        Un abrazo!!

             elav dijo

          Sigo sin entender cual es el problema 🙁

          Como mismo hemos hablado de «como obtener más seguridad» en varios aspectos, también podemos hablar de otros temas «menos seguros». Nuestro objetivo es ofrecer la información, queda de tu parte saber que hacer con ella. Además, el autor del post más paranoico con la seguridad no puede ser, créeme que a la hora de Administrar Sistemas, no hace este tipo de cosas.

          Saludos 😉

               Linuxito dijo

            Primero, cuando dije ‘implementadas por sujetos que se dicen “administradores”’, no me referí en ningún momento al autor del artículo, no entiendo por qué están tan susceptibles.

            El problema, desde mi punto de vista, es que esta herramienta va en contra de toda buena práctica de seguridad. Creo que desde la comunidad GNU/Linux debemos mantener nuestro preciado sistema operativo tan seguro como sea posible. Es decir, no me gustaría ver a GNU/Linux convertido en Windows (en lo que respecta a seguridad).

            Lamentablemente hay muchos administradores novicios que no saben cuál es la forma correcta de hacer las cosas, y terminan utilizando estas herramientas en sistemas críticos.

            Por supuesto que ustedes tienen derecho a publicar lo que quieran, pero te repito, me apena que desde este blog (uno de los más importantes de habla hispana) se les de lugar a herramientas que atentan contra la seguridad.

            Saludos!!

                 elav dijo

              Y dale Juana con la palangana. Precisamente, por ser un blog de referencia, nos gusta brindar todo tipo de información. Entiendo esto:

              Llega un usuario y pregunta: ¿Cómo puedo conectar a un servidor por SSH sin que me pida la contraseña?
              Le responden en un foro cualquiera: Noooo, eso es un problema de seguridad, eso nadie lo hace.

              Aún sabiendo, el usuario no le dice porque es un problema de seguridad. Mal, muy mal, es bueno que se sepa como hacer las cosas, por eso en Desdelinux:

              Llega un usuario y pregunta: ¿Cómo puedo conectar a un servidor por SSH sin que me pida la contraseña?
              Escribimos un post y decimos: Puedes usar este método, funciona de este modo pero NO ES SEGURO. Lo más seguro es usar este otro.

              ¿Cual crees que sea mejor?


                 Linuxito dijo

              Está bien, respeto tu postura. Saludos cordiales!!


                 KZKG^Gaara dijo

              SSHPass no atenta en realidad contra la seguridad, quien atenta contra la seguridad en todo caso es el usuario que le de un uso no adecuado.
              Por ejemplo, aquí hay un excelente ejemplo de que SSHPass no sirve solamente para lo que comento en el post, puede ser usado para (por ejemplo) cracking de OpenSSH-Server: http://paste.desdelinux.net/4810

              La aplicación no es más que eso, una aplicación, el uso que se le dé es lo que hará que hayan fallas que comprometan la seguridad o no.

              Referente a lo de nervioso o susceptibles, en lo absoluto, tal vez fue la forma en que lo dijiste (o que leer hace complicado entender correctamente) pero interpreté que el comentario iba dirigido a mí, si no fue así me disculpo.

              PD: Seguro habrán varios que encontrarán el script que puse interesante y hasta divertido LOL!


                 Linuxito dijo

              Ok, me alegro que hayamos llegado a un acuerdo. Saludos!!


         KZKG^Gaara dijo

      ¿En algún momento dije que este método es más seguro que usar llaves públicas y privadas?

      En otro artículo ya compartí cómo usarlas [1], ahora simplemente explico otra forma de lograr lo mismo u algo similar.

      Cada cual usa el que más le convenga, el que prefiera. Yo aquí simplemente expliqué uno de los usos que se le puede dar a sshpass, otro podría ser mediante un script Bash hacer cracking de SSH mediante el uso de un diccionario… pero vamos, este es solo otro uso.

      Repito, yo solo comparto mis conocimientos relacionados con GNU/Linux. SSHPass bien no puede ser la elección ideal para cualquier caso, pero tiene utilidad, eso no lo dudes.

      BTW, referente a: (implementadas por sujetos que se dicen “administradores”) … je..je..je.. prefiero no opinar, no tengo nada que demostrarle a nadie, sin mencionar que tú amigo mío, no tienes ni la más remota idea de quién soy, muchísimo menos de lo qué sé 😉

      [1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/

           Linuxito dijo

        No te pongas nervioso, sucede que en mi rubro conozco gente que basa su trabajo en Google y al momento de resolver problemas hace copy&paste de este tipo de cosas. Luego el administrador de seguridad es quien «pone palos en la rueda» cuando detecta este tipo de anomalías. Saludos!!

           msx dijo

        Relax man, no vale la pena 😉

      Xykyz dijo

    Claro, pero entonces te queda registrado el password en los comandos utilizados. Por cuestiones de seguridad no se debe hacer así…

         davidlg dijo

      eso mismo estaba pensando yo al leer el post

         KZKG^Gaara dijo

      Agregando esto en nuestro .bashrc no se guardarían los comandos relacionados con sshpass :
      HISTIGNORE='sshpass *'

      Haré un post sobre cómo ignorar comandos para que no se guarden en el historial de Bash en breve 😀

           angelblade dijo

        Otra forma para que los comandos no se guarden es poner siempre un espacio antes del comando. ^__^

      Ignacio dijo

    Creo que es más seguro utilizar claves para conectar por SSH sin tener que introducir la contraseña.

    Por otro lado, crear un alias de comando completo donde se guarda la contraseña puede ser un problema de seguridad.

      Saito dijo

    Si que me parece un falla a la seguridad informatica, pero vamos que haciendo que no se guarden en el historial del bash no es tanto el problema que nos hacemos(exceptuando por un alias que eso si seria garrafal), ademas como dice elav en la tienda nos venden el cuchillo nosotros somos los que veremos para que usarlo

      truko22 dijo

    Interesante, pero mejor uso lo de llave publica y privada que enseñaste en otra entrada.

      msx dijo

    @KZKG
    Creo que es más práctico – y seguro! – usar llaves RSA/ECDSA junto con un llavero (agente SSH) para la autenticación automática.
    En mi caso uso de llavero SSH a Keychain, desarrollado por la gente de Funtoo, que funciona muy bien, gasta poquísimos recursos y muy seguro:
    http://www.funtoo.org/Keychain

    Ejemplo:

    j:0 ~ > AliasSearch ssh
    # SSH management
    alias SSHCOPYIDecdsa='ssh-copy-id -i ~/.ssh/id_ecdsa.pub'
    alias SSHCOPYIDrsa='ssh-copy-id -i ~/.ssh/id_rsa.pub'
    alias SSHKEYGENecdsa='ssh-keygen -t ecdsa -b 521 -C "$(whoami)@$(hostname)-$(date -I)"'
    alias SSHKEYGENrsa='ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)-$(date -I)"'

    Forma de uso:
    SSHKEYGEN{ecdsa,rsa}
    SSHCOPYID{ecdsa,rsa} user@{servidor,ip}


    # SSH servers
    alias SERVER1mosh='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && mosh -p # usr1@server1'
    alias SERVER1='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@server1.local'
    alias SERVER101='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@[direc. ip].101'

    Donde:
    -p #: puerto
    usr1@server1: usuario@servidor AVAHI
    usr1@server1.local: usuario@servidor AVAHI (dependiendo cómo esté configurado el servidor en algunos sistemas hace falta agregar el sufijo .local)
    usr1@[direc. ip].101: dirección ip fija.

    /etc/ssh/sshd_config: http://paste.chakra-project.org/4974/
    ~/.ssh/config: http://paste.chakra-project.org/4975/
    OS: Arch Linux / Chakra

    Ojalá les sirva, saludos!

         KZKG^Gaara dijo

      De hecho yo uso llaves, no SSHPass para acceder a mis servidores … descubrí SSHPass cuando necesitaba una forma de hacer este script: http://paste.desdelinux.net/4810

      Pero … bueno, quise compartir SSHPass con todos, pero obviamente no podía poner acá un script que permita mediante un diccionario intentar vulnerar OpenSSH-Server HAHAHA!

           msx dijo

        «[…]no podía poner acá un script que permita mediante un diccionario intentar vulnerar OpenSSH-Server HAHAHA!»
        Pero por que no!!?
        Acaso el hacking & cracking no forma parte del aprendizaje de buenas prácticas de seguridad[0]!?
        Por favor hombre, adelante!!!

        [0] No es hermoso utilizar las palabras para que signifiquen exactamente lo contrario a lo que literalmente expresan!? Hack the linguistics!!! ;-D

           guzmanweb dijo

        Hola,me tira este error:

        Se está probando passwords a 192.168.20.11 en el puerto 22 con el usuario root
        cat: con-letras.txt: No such file or directory

        el archivo con-letras.txt las creo yo ?

        saludos

      Eduardo dijo

    Así no se hace, ya que la contraseña queda almacenada en bash_history como texto plano, aparte que se podría averiguar de otra forma. Para que ssh no te pida password la manera correcta es con “llaves públicas y privadas”.

      Oscar Meza dijo

    Yo utilizo RSA para conectarme a mis servidores de forma remota, aun asi creo que para conectarnos a algun equipo donde no requerimos seguridad tan fuerte es una buena herramienta, gracias por el tip!

      Nelson dijo

    Chiuuu

      nabucodonosor dijo

    Y porqué mejor no publico mi password para que esté al alcance de cualquiera?

      mario dijo

    Excelente que bien!!!!!! y en español.

      Gonzalo Jarjury dijo

    Excelente artículo, como siempre la gente se queja en vez de agradecer, si bien el método es inseguro es depende de dónde y cómo lo uses, muchas gracias 🙂