CentOS: no puedo usar SSH

CentOS: no puedo usar SSH

Recientemente intenté conectar SSH a mi servidor (un nodo de radioaficionado con conexión a Internet) y acabo de volver al aire.

escribí ssh[correo electrónico protegido]cuál es la dirección de mi computadora confirmada por ifconfig eth0

Por supuesto, aparece Conexión rechazada.

Tuve este problema antes, lo solucioné encontrando la IP CORRECTA ejecutando ifconfig. Lo ejecuté ahora y tenía la IP de LAN correcta.

Aquí están los pasos de lo que hice.

•Configuré la IP en la dirección MAC de la computadora en la configuración de mi enrutador, en mi caso 10.0.1.9.

•Ejecuté ifconfig eth0 y apareció como 10.0.1.9 en la pantalla.

•Reenvié todos los puertos (aunque eso no es necesario para la comunicación LAN)

•Lo cambié de 222 a 22 en /etc/ssh/sshd_config

•Reinicié la computadora varias veces.

•SSHobrasal revés, así que si escribo SSH puedo iniciar sesión en mi propia computadora desde la computadora del servidor CentOS

Adjunto capturas de pantalla de la configuración de mi enrutador.

ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí

ps auxiliar |grep sshd

regresó

root 2923 0.0 0.0 4032 692 tty1        S+ 07:15 0:00 grep sshd

MI ARCHIVO SSHD:::

i#  $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk 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

# Accept locale-related environment variables
AcceptEnv LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL
#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
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner /some/path

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

ACTUALIZACIÓN Ejecuté el inicio del servicio SSHD y obtuve un error

Iniciando sshd: /etc/ssh/sshd_config: línea 1: opción de configuración incorrecta: i / etc/ssh/sshd_config: terminando, 1 opciones de configuración incorrectas [FALLADO]

Respuesta1

Tonto, encontré el problema. Tenía un carácter justo antes del primer comentario en SSHD_Config, una "i", como se puede ver en mi archivo de configuración.

ingrese la descripción de la imagen aquí

Jajaja funciona

Respuesta2

¡Hoy (27/01/2016), me enfrenté al mismo problema! Quería enviar ssh a un host como root, pero me lo negaron. Busqué en la web y probé muchas sugerencias allí, sin éxito. Luego creé un nuevo usuario "xyz" e intenté utilizar ssh como "xyz" ¡y pude! Eso me hizo darme cuenta de que sshd no era el problema, puede que el root SÓLO tenga este problema. Por lo tanto, verifiqué mi archivo /etc/ssh/sshd_config y noté que "PermitRootLogin" estaba configurado en "no". Lo comenté y reinicié "sshd".

[root@yav-031 ~]# cat /etc/ssh/sshd_config|grep -i permit
#PermitRootLogin yes
#PermitEmptyPasswords no
# the setting of "PermitRootLogin without-password".
#PermitUserEnvironment no
#PermitTunnel no
#PermitRootLogin no <----------In my case this was NOT commented out 
[root@yav-031 ~]# 
# service sshd restart 

Luego volví a intentar iniciar sesión como root y pude iniciar sesión correctamente. Este sitio me ayudó a pensar en la "dirección correcta" y por eso pensé en compartirlo con ustedes y por eso esta nota. Saludos, -Deb

Respuesta3

Hay más que solo la configuración del puerto en /etc/ssh/sshd_config.

Por ejemplo, el campo AllowUserspodría limitar el uso de sshd.

Lea la página de manual de sshd_config:

man sshd_config

Si aún no puedes entenderlo, publica todo tu/etc/ssh/sshd_config

Respuesta4

Según ps, ssh ni siquiera se está ejecutando, lo que provocaría errores de conexión rechazada.

Si inicia el demonio ssh, service sshd startdebería iniciarse y debería poder conectarse mediante ssh a su servidor.

información relacionada