SSH falla con frecuencia cuando se contacta con VM desde una máquina remota

SSH falla con frecuencia cuando se contacta con VM desde una máquina remota

Tengo un Host Windows 8.1 en el que instalé el servidor Ubuntu 15.05 en una máquina virtual. Configuré un servidor SSH en el invitado (ubuntu) y luego creo una regla de reenvío desde el puerto del host 2222 al puerto invitado 22.

Si intento realizar ssh desde el Host, ssh -p 2222 username@localhostpuedo conectarme sin problemas a la máquina virtual.

Si intento conectarme desde una máquina remota (una con OS X) en la misma red local, la mayoría de las veces aparece un error de tiempo de espera. Cuando logro establecer una conexión, después de un tiempo se congela hasta que aparece el error.ssh -p 2222 [email protected]Error de escritura: tubería rota.

He desactivado el firewall de mi antivirus (Bitdefender) y creado reglas en el firewall de Windows para permitir el tráfico desde los puertos 22 y 2222. El problema persiste incluso después de desactivar ambos firewalls (en realidad, el de Bitdefender siempre está desactivado).

También lo inscribí UseDNS noen el expediente del huésped sshd_config. No hay ningún firewall instalado en el Guest (ubuntu).

Veo que el problema ocurre tanto con vmware workstation 11 como con VirtuaBox.

Respuesta1

El problema parece ser que no se puede acceder a la red VM desde fuera de la máquina con Windows 8.1. Puede ver que funciona cuando realiza ssh a localhost:2222 y eso puede deberse a la configuración de la red (probablemente esté configurada como NAT, la opción predeterminada)

Cuando utilice VirtualBox, debe configurar la red de la VM que se va a conectar y eso debería funcionar. Puede obtener más información dehttps://superuser.com/questions/810097/vmware-player-bridged-networking-no-longer-works-host-win8-1-guest-mint-17-l

Respuesta2

Tuve un problema similar en el host de Windows 7 con WMware Workstation 12.5.9. La única solución que realmente me ayudó: https://communities.vmware.com/thread/590825

Establecer indicadores de QoS alternativos parece solucionar el problema, por ejemplossh -o IPQoS=throughput ...

información relacionada