Cómo SSH en WSL

30

Lector desde hace mucho tiempo, preguntador por primera vez.

Seguí las instrucciones en esta respuesta:

¿Cómo puedo SSH en "Bash en Ubuntu en Windows 10"?

Estoy intentando SSH desde PuTTY en Windows en la misma máquina. Usando el puerto 22, que coincide con mi archivo de configuración. Intenté 127.0.0.1 y 127.0.1.1. Sin embargo, todavía recibo "acceso denegado":

ingrese la descripción de la imagen aquí

En última instancia, espero configurar una compilación remota de Visual Studio, pero hasta ahora no he podido acceder de forma remota. ¿Qué próximos pasos debo tomar?

Process Hacker muestra esto para el puerto 22 (no estoy seguro de lo que esto significa):

ingrese la descripción de la imagen aquí

Aquí están los contenidos de / etc / ssh / sshd_config:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation no

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
AllowUsers basel
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

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

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

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

Subsystem sftp /usr/lib/openssh/sftp-server

# 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
windows-10 bash ssh windows-subsystem-for-linux Alghanem de Basilea
fuente
Un "Acceso denegado" significa que está proporcionando una contraseña incorrecta a la cuentabase1
Ramhound
1
Definitivamente no estoy proporcionando la contraseña incorrecta. Lo cambié y volví a intentarlo varias veces solo para asegurarme.
Basel Alghanem
¿Intentaste mirar alrededor ?
Matt Clark el
1
Absolutamente intenté mirar alrededor, durante un par de horas esta mañana. Lamentablemente, en general, no sé nada en esta área. Traté de comentar la línea como se sugirió en una respuesta, y eso no ayudó. ¿Crees que intentar la autenticación basada en claves podría funcionar?
Basel Alghanem
1
Cambió al puerto 2200 (línea 5 en sshd_config) y pudo iniciar sesión con éxito en WSL. Supongo que Windows estaba usando el puerto 22, ¿entonces Linux no pudo? Además, sshd apareció en Process Hacker como escuchando el puerto 2200, donde antes no aparecía en absoluto. ¿Presento esto como respuesta a mi pregunta?
Basel Alghanem

Respuestas:

25

Cambie el puerto 22 a otro, como 2222, en el archivo /etc/ssh/sshd_config, luego reinicie el servicio ssh mediante el commond sudo service ssh --full-restart, iniciará sesión correctamente, pero no sé el motivo.

También trato de usarlo como un servidor gdb remoto para visual studio de VisualGDB, no funciona bien. VisualGDB lo admitirá en la próxima versión como muestra el sitio web oficial. El enlace es https://sysprogs.com/w/forums/topic/visualgdb-with-windows-10-anniversary-update-linux-support/#post- 9274

nul lun
fuente
Ahora, VisualGDB lo admite, más detalles en visualgdb.com/tutorials/linux/win10
nul lun
44
Esto se debe a que Windows podría ejecutar SSH Server Broker en el puerto 22. A menos que sepa con certeza que lo necesita, se puede deshabilitar de manera segura. Se utiliza para algunos procedimientos durante el desarrollo.
UnclickableCharacter
3
No olvides abrir el puerto en el Firewall de Windows.
dthor
3
Probablemente, también necesitarás cambiar la autenticación. Por defecto requiere claves ssh para el cliente. Si desea el inicio de sesión clásico de usuario / contraseña, configure esta configuración en /etc/ssh/sshd_config:PubkeyAuthentication no PasswordAuthentication yes
Tonatio
1
Tuve que habilitar la regla de firewall como @dthor mencionó y habilitar la autenticación de contraseña como mencionó Tonatio y luego funcionó.
sdkks
10

El puerto 22 no funciona porque Windows viene con un servidor SSH incorporado.

Windows 10 viene con un servidor SSH, y será necesario deshabilitarlo o se deberá cambiar el puerto que se usará para SSH en WSL. Elegí hacer esto último y usar el puerto 2200 para WSL SSH.

Fuente: https://virtualizationreview.com/articles/2017/02/08/graphical-programs-on-windows-subsystem-on-linux.aspx

ayao1337
fuente
Esta es en realidad la única respuesta correcta a esta pregunta, incluso la respuesta aceptada, insinúa que esta es la razón por la que se tuvo que cambiar el puerto. Le otorgaré una recompensa a esta respuesta en 24 horas.
Ramhound
2

Cuando inicie sesión, use su contraseña de cuenta de Microsoft Windows, no su contraseña de usuario WSL Linux. Iniciará sesión en su directorio de inicio de Windows ejecutando cmd.exe. Ingrese el comando /windows/system32/bash.exe ~ --loginpara iniciar sesión en su directorio de inicio de WSL y ejecutar su .profile.

rhmccullough
fuente
1

WSL: también busque 'UsePrivilegeSeparation no'. De lo contrario, la ejecución del servidor en la consola (/ usr / sbin / sshd -Dddde) fallará con PrivilegeSeparation no implementado ...

revólver
fuente
1
UsePrivilegeSeparation está en desuso
mFeinstein
0

Lo que hice fue sudo ssh-keygen en lugar de ssh-keygen se topó con algunos problemas anteriores con archivos que no se escriben correctamente y esto me lo solucionó

META
fuente