Configurar SSH por otro puerto y NO por el 22
SSH 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 Debian, Ubuntu, SolusOS, Mint. Si usan Arch 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.

Y supongo que debes ir con cuidado en no usar un puerto que no sea utilizado por otro programa.¿no?
Pues si…..no debe coincidir con un puerto ya en uso por otro servicio…..
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á
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.
De hecho elav pondrá mañana (espero) un post sobre cómo usar SOCKS5 para burlar la seguridad de servidores proxys
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?
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
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.
Muy buena puntualización !!
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 !!!