Configurar SSH por otro puerto y NO por el 22

es sin lugar a dudas el pan de cada día de los que administramos redes. Pues necesitamos controlar, administrar remotamente otros ordenadores y/o servidores, y usando SSH podemos hacer esto … podemos hacer tanto como nuestra imaginación nos permita 😀

Sucede que SSH usa por defecto el puerto 22, por lo que todos los intentos de hacking a SSH siempre irán por defecto al puerto 22. Una medida básica de seguridad es simplemente NO usar SSH en este puerto, configuraremos  por ejemplo SSH para que escuche (trabaje) en el puerto 9122.

Lograr esto es sumamente simple.

1. Debemos obviamente tener SSH instalado en nuestro servidor (paquete openssh-server)

2. Editemos el archivo /etc/ssh/sshd_config

Para esto en una terminal (como root) ponemos:

  • nano /etc/ssh/sshd_config

Ahí entre las primeras líneas vemos una que dice:

Port 22

Le cambiamos el 22 por otro número, que sería el nuevo puerto, en este ejemplo dijimos que usaríamos el 9122, por lo que la línea nos quedaría:

Port 9122

3. Ahora reiniciamos SSH para que lea la nueva configuración:

  • /etc/init.d/ssh restart

Esto en caso que usen . Si usan sería:

  • /etc/rc.d/ssh restart

Y listo, ya tendrán SSH por otro puerto (9122 según el ejemplo que hemos usado acá)

Bueno creo que no hay nada más que agregar.

Cualquier duda que tengan, me dejan saber 😉

Saludos

PD: Recuerden, todo esto tienen que hacerlo con privilegios administrativos… bien sea como root, o usando sudo.


17 comentarios

  1.   rogertux dijo

    Y supongo que debes ir con cuidado en no usar un puerto que no sea utilizado por otro programa.¿no?

    1.    elMor3no dijo

      Pues si…..no debe coincidir con un puerto ya en uso por otro servicio…..

    2.    KZKG^Gaara dijo

      Sí sí claro, en efecto. Si ponemos para que SSH use el puerto 80 (por ejemplo) y tenemos Apache (Nginx, etc) funcionando en ese mismo puerto, habrá conflicto y SSH no funcionará 😉

  2.   Giskard dijo

    Yo tuve que hacer eso hace como un año para crear un canal con alguien en Miami. Al parecer el hotel donde estaba tenía un firewall de esos fastidiosos. Enrutamos todo por el puerto 80 y el firewall creyó que era todo web.

    1.    KZKG^Gaara dijo

      De hecho elav pondrá mañana (espero) un post sobre cómo usar SOCKS5 para burlar la seguridad de servidores proxys 😉

      1.    ElBananeroSoyIo dijo

        Interesante, esperaremos la nota.
        Mientras tanto estimado KZKG^Gaara, te cuento que vi tu incursion en el foro de Mint, para cuando una review del Unofficial LMDE KDE SC?

        1.    KZKG^Gaara dijo

          No soy el más adecuado para hacer reviews jajaja, pero intentaré hacer uno de este.
          Puse a bajar el ISO para el VPS nuestro mayormente para hacer seed, para ayudar a difundir 😉

  3.   daniel dijo

    yo agregaría que para hacerlo mas seguro, en el mismo archivo de configuración buscar la linea PermitRootLogin yes (si mal no recuerdo yes esta por defecto) y cambiar a no, con esto evitamos un posible ataque de fuerza bruta al superusuario ya que no permite logearse como tal, y para realizar una tarea que requiera privilegios root, nos logeamos con nuestro usuario y usamos un simple su.

    1.    educhip dijo

      Muy buena puntualización !!

  4.   Percaff_TI99 dijo

    Hola KZKG^Gaara tengo algunas dudas espero me puedas ayudar.
    Lo primero es donde es conveniente crear las claves rsa en el servidor o en el cliente.
    Acabo de instalar netbsd en Virtualbox y utilicé el siguiente comando:
    ssh-keygen -t rsa -f /etc/ssh/ssh_host_key -N “” hay otra forma de hacerlo como un simple ssh-keygen -t rsa pero lo guarda en otro directorio, esto me crea un poco de confusión, el tema redes no es mi fuerte, estoy tratando de crear un cluster con 2 o mas maquinas virtuales como clientes y el host como servidor, solamente para aprender la metodología del armado y las comunicaciones entre ellos mediante ssh ya que tengo una sola Pc.
    Me gustaría sí podes hacer un post sobre las conexiones host (servidor) Virtualbox (cliente) o al revéz mediante ssh arrancando desde la creación de claves rsa. Yo he podido comunicarme mediante ssh scp a netbsd (VM) y viceversa pero hice un lío bárbaro creando las claves tanto en el host como en netbsd (Virtualbox) me e quedado con mas dudas que certezas.

    Un saludo !!!

  5.   Francisco dijo

    Gracias, nunca había caído en eso, hace que sea bastante más seguro y encima es sencillo de hacer.

  6.   gabriel dijo

    sudo service ssh restart en los nuevos ubuntu.

    1.    Cris dijo

      Gracias, no se me había refrescado aún.

  7.   Thomas BL dijo

    ¡¡gracias por compartir el conocimiento!!

  8.   Mauricio dijo

    buenas tardes, tengo el siguiente problema a ver si alguien me puede ayudar.
    tenia una base de datos colgada en una direccion erp.”””””””””, y resulta que desde ayer no puedo acceder me dice : Firefox no puede establecer una conexión con el servidor en erp.*************.es. la empresa que me la creo desaparecio, y estoy sin poder trabajar, tengo todos los datos de acceso, pero no se que hacer, cuando intento entrar con la misma direccion pero con :8585 al final me pone:
    It works!

    This is the default web page for this server.

    The web server software is running but no content has been added, yet.

    alguien puede darme algun consejo o algo, le estaria muy agradecido , desde ayer no puedo trabajar
    muchas gracias

    me acaban de decir que parece que tiene algun tipo de firewall o algo que impide al acceder al puerto 80, tenia el 22 y lo he cambiado como tu has explicado pero sigue igual

  9.   Ripnet dijo

    Hola amigo, sabes que seguí todos los pasos, reinicié SSH, luego, fui a la configuración de mi firewall para abrir los puertos, pero no pasa nada, sigue con el mismo, uso CSF firewall en centos 6.5. Si alguien sabe , favor ayuda!

    Un saludo!!

  10.   Cris dijo

    Gracias por la guía

Deja un 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.