Puerto diferente a 22 en SSH desde el arranque de debian

17 envíos / 0 nuevos
Último envío
#1 Vie, 28/12/2018 - 06:20
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Puerto diferente a 22 en SSH desde el arranque de debian

Estado: 
[SOLUCIONADO]

Buenos días,

No he encontrado la solución ni en este foro ni en internet, nada me funciona. Soy incapaz de que el puerto de ssh se quede en uno diferente al 22. Cambio el archivo de configuración por el puerto 22230 reinicio el servicio de ssh. Luego actualizo el demonio para que arranque así pero no se lo que hago mal, al reiniciar el servidor vuelve a tener el puerto 22 y no el 22230. No tengo ni idea de que puedo hacer mal.

El servidor tiene debian 9 y está actualizado. Uso openssh.

¿Alguien podría indicarme que debería hacer para que se quede el puerto 22230 al reiniciar el servidor?

Muchas gracias

Un saludo

Vie, 28/12/2018 - 09:16
luquitas
Imagen de luquitas
Desconectado/a
se unió: 18/11/16

¡Hola!

¿Podrías mostrarnos la configuración que usas para SSH? Normalmente está en el archivo /etc/ssh/sshd_config ..

¡Saludos!

Vie, 28/12/2018 - 18:03
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Buenas noches Luquitas,

Gracias por intentar ayudarme, te paso la config que me pides:

#    $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

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

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

# 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 override the
# default value.

Port 22230
#AddressFamily any
ListenAddress 192.168.1.230
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile    .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# 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

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# 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 and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

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

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server

 

Muchas gracias

Un saludo

Vie, 28/12/2018 - 19:28
caliban
Imagen de caliban
Desconectado/a
moderador
se unió: 14/01/16

¿Como reinicias el servidor ? 

¿tenes alguna regla de iptables para ssh ?

¿Como comprobas en que puerto esta escuchando sshd ? (netstat,  ss , lsof  ? ) 

Sáb, 29/12/2018 - 06:25
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Muchas gracias por la ayuda,

trato de responder ya que soy novato y estoy intentando aprender a marchas forzadas.

Reinicio el servidor con el comando reboot desde root o apagando e iniciando o cuando se va la luz y vuelve

la verdad no se que son las ip tables, creo que no he cambiado nada de eso,al menos de forma consciente

es fácil, una vez rearranco el servicio ssh me vuelvo a intentar conectar por el 22 y no me deja, uso el 22230 y me deja. Después reinicio y el 22230no funciona pero sí el 22.

al principio el servidor ssh no arrancaba después de un reinicio y metí el siguiente comando y ya funcionaba después de reiniciar:

update-rc.d ssh defaults

ahora el problema que tengo es que mi router impide el puerto 22,sí o sí necesito un puerto diferente para conectarme desde fuera.

muchas gracias por la ayuda y el interés 

 

Sáb, 29/12/2018 - 11:58
caliban
Imagen de caliban
Desconectado/a
moderador
se unió: 14/01/16

Bien para que el cambio de configuración del servidor sshd ,tenga efecto tenes que reiniciarlo por ejemplo:

systemctl restart sshd.service

En cuanto a la apertura y redirección de puertos  de tu router, ya es otro tema y deberías crear uno nuevo.

Aunque queda algo confuso el asunto ,si vos cambiaste el puerto de escucha de tu servidor hacia otro, ¿para que queres que el router permita el puerto 22 ? 

Buscate en internet ,marca y modelo de tu router, y te descargas el manual , ahí encontraras redireccion de puertos,

o sea ,en tu router vos tenes que abrir el puerto que queres que escuche ,y luego redireccionarlo hacia el host (la ip )donde esta alojado tu servidor sshd.

Por ultimo ,comandos como  netstat,  te permiten entre otras cosas ,comprobar que servicios estan escuchando ,en cuales puertos,en tu sistema .que es una forma de comprobar si un servidor esta funcionando ,y ecucha en un puerto determinado.. ,por ejemplo te mostrara algo asi :

 netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/init              
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      792/vsftpd          
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1076/sshd           
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      745/cupsd           
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1114/exim4          
tcp        0      0 127.0.0.1:9050          0.0.0.0:*               LISTEN      1100/tor            
tcp6       0      0 :::111                  :::*                    LISTEN      1/init              
tcp6       0      0 :::22                   :::*                    LISTEN      1076/sshd  

 

Sáb, 29/12/2018 - 19:38
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Buenas noches,

He metido el comando que me has pasado y ha hecho efecto, el puerto era el 22230 pero luego he hecho un reboot y ya no conecta, imagino que ha vuelto a ponerse el 22 y por eso ya no tengo acceso. El día 2 podré confirmarlo, ahora mismo estoy fuera y no tengo acceso físico para poder comprobarlo.

El tema del router lo controlo bien, no hay problema, lo que pasa es que los puertos del los capa el operador para tener seguridad, solo abren el 80 y alguno adicional hasta el 1024, de ahí hacia arriba puedo usar cualquiera. El router es malo y no permite redireccionar el puerto 22 interno a otro diferente fuera, cualquier puerto interno tiene que ser mayor de 1024 para poder "sacarlo a internet".

Cuando he usado el netstat antes de hacer el reboot tenía el 22230 abierto así que el único problema es que la configuración se pierde al reiniciar el servidor.

Muchas gracias

Un saludo

Sáb, 29/12/2018 - 19:55
caliban
Imagen de caliban
Desconectado/a
moderador
se unió: 14/01/16

Intenta luego de configurar con :

service ssh restart 

Bien a estas alturas, tendrías que extender tu explicación ,por que para mi es confusa 

El servidor esta en una maquina tras el router y vos intentas acceder desde el exterior ? (internet) 

Cuando reconfiguras el servidor ¿lo haces teniendo acceso físico a la maquina con el servidor ,o  desde internet? 

En definitiva intenta relatar con mas detalle todo esto para comprender  como esta implementado todo y como intentas administrarlo.

Por otra parte, lo que vos necesitas es abrir un puerto por encima del 1024, en el router, y luego redirigirlo a la maquina con tus servidor , o sea el router escuchara peticiones de servicio en cualquier puerto (configurado), y las encaminara hacia el puerto/maquina,  que vos le configures dentro de la red que esta detrás de dicho router .No importa a cual puerto interno .

Sáb, 29/12/2018 - 21:38
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

Creo que para empezar, deberías desactivar, mediante rc.d, el servicio de ssh, comprobar que está parado, repasar la configuración, y luego iniciar el servicio con el comando

~# systemctl start ssh.service

y luego habilitarlo para que inicie automáticamente con

~# systemctl enable ssh.service

y comprobar su estado con

~$ systemctl status ssh.service

 

Debian 9 usa por defecto systemd como sistema de inicio en lugar de sysv-rc. y openssh tiene soporte para ambos sistemas de inicio. Pero, en algunos casos los servicios no funcionan exactamente igual si se usa update-rc o systemctl (de hecho, se puede tener un servicio desactivado si se inicia con sysv-rc pero desactivado si se inicia con systemd) y aquí puede (o no estar tu problema).

Deberías comprobar que tu servicio  no usa la activación por socket con el comando

~$ systemctl status ssh.socket

si te dice que está activo, entonces es la razón por la que vuelves a tener configurado el puerto 22, en este caso, mi recomendación es que desactives el servicio ssh usando rc.d, repases la configuración, iniicies y actives el servicio con los comandos systemctl start y systemctl enable y compruebes que funciona correctamente. Si aun así al reiniciar el sistema o el servicio vuelve al puerto 22, te queda la opción de editar el archivo /lib/systemd/system/ssh.socket y configures en la línea ListenStream= el puerto que quieres utilizar y reinicies el servicio. Todo debería funcionar correctamente.

 

P.D.: Usando Debian 9, no es conveniente gestionar los servicios usando sysv-rc, provoca conflictos con algunos, como posiblemente te esté pasando ya que, como he dicho, algunos servicios pueden  estar desactivados para sysb-rc y activados para systemd y viceversa. Acostumbrate a usar systemd para la gestión de servicios así evitarás dichos conflictos.

  No hay bar que por bien no venga....
Dom, 30/12/2018 - 05:22
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Gracias a los dos,

Panko, imagino que todo va por donde tu me dices. Lo probaré a partir del día 2.

Caliban, el proceso es el siguiente:

Instalo open-ssh con el puerto 22 (por defecto), funciona, reinicio y no funciona, introduzco el siguiente comando:

update-rc.d ssh defaults

ya funciona cuando reinicio siempre

ahora trato de salir a internet, y al intentar abrir los puertos, el 22, me doy cuenta de que no puedo usar puertos menores del 1024 ya que el router los capa todos (dentro de la red puedo usar cualquiera que funciona, pero salir hacia afuera los puertos de las máquinas de dentro de la red como los que redirecciono tienen que ser superiores a 1024), por ello no puedo usar (para conectarme desde internet) ningún puerto en la máquina inferior a 1025 ya que el router no me redirecciona. Entonces decido al azar poner el puerto 22230 para salir a internet, usándolo en la máquina para la intranet y para internet el mismo.

A partir de aquí sucede lo que os he dicho. Pongo el puerto 22230 en la máquina y funciona dentro de la red y hacia internet perfectamente, ahora bien, una vez que se reinicia el servidor la configuración se vuelve a quedar establecida en el puerto 22.

Ahora mismo como estoy fuera físicamente y accedo al servidor desde internet (por el 22230 ya que no había reiniciado y funcionaba hasta apagarlo), al hacer ayer el cambio y reiniciar el servidor (al no surtir efecto) ahora ya no tengo acceso desde internet. Así que no me queda más remedio que el día que vuelva, el día 2, ir físicamente al servidor para seguir probando.

Probaré todo esto que me comentáis,

Muchas gracias por la ayuda

Feliz entrada de año 2019!

Mié, 02/01/2019 - 19:02
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Buenas noches,

Efectivamente el problema estaba ahí Panko. Tenía que haber usado systemctl. Entonces estaba arrancando con dos configuraciones diferentes.

Lo que he hecho es desinstalar ssh y volver a instalarlo y configurarlo desde 0, y he recordado porqué usé rc.d, era la única forma de que el servidor iniciara ssh al inicio.

Ahora no hay forma de que se inicie el servicio ssh automaticamente, ahora bien, creo que cuando lo hace siempre lo hace con el puerto correcto, pero lo tengo que arrancar manualmente.

¿no entiendo por qué no arranca ssh al iniciar?? Esto me sale al inicio:

[FAILED] Failed to start OpenBSD Secure Shell Server

See 'systemctl status ssh.service' for details

La única forma de que conseguí que arrancara desde el incio la anterior vez fue usando rc.d...

¿Qué estoy haciendo mal? ¿Cómo evito usar rc.d?

Muchas gracias

Un saludo

Mié, 02/01/2019 - 20:56
caliban
Imagen de caliban
Desconectado/a
moderador
se unió: 14/01/16

¿Habilitaste el servicio ssh para que cargue al inicio ? 

systemctl enable ssh.service

Y en todo caso  si falla al iniciar , puede ser un error en la configuracion , intenta 

sshd -T 

Modo test 

Jue, 03/01/2019 - 17:34
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Buenas noches,

Gracias Caliban, la verdad que no funcionó... Hoy se me ha roto la placa base del servidor... He encontrado otra y espero poder ponerlo en marcha mañana. A ver con que problemas me encuentro. Ya os contaré.

Muchas gracias por la ayuda

Vie, 04/01/2019 - 11:00
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Buenas tardes,

Ya tengo todo en marcha con la nueva placa. El servidor ssh funciona correctamente al instalarlo de 0, imagino que al no tener conflictos con rc.d.

Ahora ya únicamente tengo un problema. Mi router es una basura y no acepta servidores ddns. Tengo una cuenta con un servidor en no-ip.com y he instalado en el servidor un programa de no-ip que actualiza automáticamente la dirección ip pública para poder entrar desde fuera. Lo he hecho siguiendo la guía de https://www.figueroaiglesias.com/index.php/linux/11-instalar-cliente-no-ip-en-linux-e-iniciar-en-el-arranque:

Los comandos que he introducido os los resumo:

apt-get install build-essential gcc
cd /usr/local/src
wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz
tar xzf noip-duc-linux.tar.gz
cd noip-2.1.9-1
make
make install
/usr/local/bin/noip2 -C
/usr/local/bin/noip2
nano /etc/init.d/noip2

he pegado esto en el archivo

DAEMON=/usr/local/bin/noip2
NAME=noip2

test -x $DAEMON || exit 0

case "$1" in
    start)
    echo -n "Starting dynamic address update: "
    start-stop-daemon --start --exec $DAEMON
    echo "noip2."
    ;;
    stop)
    echo -n "Shutting down dynamic address update:"
    start-stop-daemon --stop --oknodo --retry 30 --exec $DAEMON
    echo "noip2."
    ;;

    restart)
    echo -n "Restarting dynamic address update: "
    start-stop-daemon --stop --oknodo --retry 30 --exec $DAEMON
    start-stop-daemon --start --exec $DAEMON
    echo "noip2."
    ;;

    *)
    echo "Usage: $0 {start|stop|restart}"
    exit 1
esac
exit 0

y he introducido los siguientes comandos:

chmod +x /etc/init.d/noip2
update-rc.d noip2 defaults

El programa actualiza la ip pública correctamente pero como me pasó con ssh no inicia al hacer un reboot. Luego después de haber metido todos estos comandos me paro a pensar y veo que la he vuelto a liar con el rc.d. Debo ser medio gilipoll... Bueno intento arrancar el servicio con:

 systemctl start noip2.service

y me dice lo siguiente:

Job for noip2.service failed because the control process exited with error code.
See "systemctl status noip2.service" and "journalctl -xe" for details.

 

hago un status:

● noip2.service
   Loaded: loaded (/etc/init.d/noip2; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2019-01-04 14:50:54 CET; 48s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3756 ExecStart=/etc/init.d/noip2 start (code=exited, status=203/EXEC)

ene 04 14:50:54 truck-server systemd[1]: Starting noip2.service...
ene 04 14:50:54 truck-server systemd[3756]: noip2.service: Failed at step EXEC spawning /etc
/init.d/noip2: Exec format error
ene 04 14:50:54 truck-server systemd[1]: noip2.service: Control process exited, code=exited
status=203
ene 04 14:50:54 truck-server systemd[1]: Failed to start noip2.service.
ene 04 14:50:54 truck-server systemd[1]: noip2.service: Unit entered failed state.
ene 04 14:50:54 truck-server systemd[1]: noip2.service: Failed with result 'exit-code'.

 

y mirando el log:

ene 04 14:17:39 truck-server systemd[1]: Starting noip2.service...
-- Subject: Unit noip2.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit noip2.service has begun starting up.
ene 04 14:17:39 truck-server systemd[3725]: noip2.service: Failed at step EXE
C spawning /etc/init.d/noip2: Exec format error
-- Subject: Process /etc/init.d/noip2 could not be executed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The process /etc/init.d/noip2 could not be executed and failed.
--
-- The error number returned by this process is 8.
ene 04 14:17:39 truck-server systemd[1]: noip2.service: Control process exite
d, code=exited status=203
ene 04 14:17:39 truck-server systemd[1]: Failed to start noip2.service.
-- Subject: Unit noip2.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit noip2.service has failed.
--
-- The result is failed.

 

¿la he vuelto a liar? No acabo de entender cómo se hace que un programa arranque desde el inicio automáticamente.

Si creéis que debo abrir otro hilo por favor decídmelo, la línea principal de éste está solucionada.

Muchas gracias por la ayuda foreros

Un saludo

 

Vie, 04/01/2019 - 11:12
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

el error diría que no tiene nada que ver con el servicio o lo que hayas hecho con rc.d, parece ser que el ejecutable está mal.

De todas formas, desinstala todo  lo relativo y vuelve a hacerlo desde el principio, o prueba con el paquete dyndns, que está en repos y me suena que soporta noip.

Además, como estamos hablando de un probema diferente, es recomendable que abras un  hilo nuevo para tratar este problema y no alargar ni  desvirtuar este.

  No hay bar que por bien no venga....
Vie, 04/01/2019 - 12:47
caliban
Imagen de caliban
Desconectado/a
moderador
se unió: 14/01/16

Bien uso no ip desde hace unos años, lo que yo he hecho es poner una entrada en el crontab de mi usuario para que ejecute el script en cada inicio/reinicio 

@reboot sleep 15 ; sudo noip2

El sudo es por que he  permitido a mi usuario ejecutar dicho script,  vale lo mismo que directamente pongas una entrada en el crontab de root , el  sleep 15 , que es una demora antes de ejecutar, no recuerdo ( ha pasado mucho tiempo ) por que la inclui , pero de todos modos no te afecta , ( quince segundos de demora ,,un minuto de demora,,cinco minutos de demora no harán gran diferencia en todo caso )

Y para comprobar el estado del demonio en funcionamiento ,ejecuto ( como root ) 

noip2 -S

Y claro , también podes comprobar si esta como un proceso en ejecución 

ps -A |grep noip2

Lo que te refiero lo he hecho hace mucho y el método puede variar , por ejemplo crear un service con systemd que se encargue de iniciar el demonio cada  vez , mira el enlace , respecto a como crear un  un  .service.

Por cierto, lo que ha dicho panko,  si vamos a continuar con este tema, crea uno asi no mezclamos los tantos .

Dom, 06/01/2019 - 16:38
franzps
Imagen de franzps
Desconectado/a
se unió: 28/12/18

Gracias muchachos,

Seguro que me veis mucho más por aquí porque seguiré teniendo problemas.

El tema inicial del foro lo doy por solucionado, muchas gracias a todos por la ayuda.

En cuanto al otro tema lo voy a gestionar con la ayuda que me habéis proporcionado y si no lo soluciono abro un nuevo hilo.

Muchas gracias

Un saludo