Tiempo de espera de solicitud SSH cada vez

Estoy tratando de acceder a un espacio de almacenamiento que tenemos en el trabajo a través de ssh, pero obtengo un tiempo de espera cada vez ( Mac OS 10.7.5 - Terminal ).

Revisé los firewalls, la configuración, incluso apagué Little Snitch, y el puerto 22 no está bloqueado en ninguna parte. Hacer exactamente la misma solicitud en una máquina Windows con un cliente SSH funciona de maravilla.

Solicitud:

ssh login_name@server_address

Respuesta:

ssh: connect to host server_address port 22: Operation timed out

El problema parece provenir de la configuración de vpn/proxy de mi empresa. Se actualizará si encuentro una forma de evitarlo.

¿Funciona si cierras tu firewall? Sé que revisó la configuración, pero no dice si lo hizo con el firewall desactivado
Sí, perdón por no ser claro, ¡también verifiqué con el firewall apagado!
Estoy pensando en un problema de enrutamiento... ¿Es posible configurar su Mac para usar la dirección IP de la computadora con Windows e intentarlo sshdesde su Mac? ¿La dirección IP está configurada con DHCP? ¿Podría agregar el resultado de netstat -rna su pregunta (es posible que no desee hacer públicas todas las direcciones IP aquí en AskDifferent, en ese caso, reemplácelas a.b.c.dpero sea coherente para que la misma dirección IP siempre obtenga el mismo a.b.c.dreemplazo)? ¿Está su Mac en la misma red que su dispositivo de almacenamiento?
¿Finalmente entendiste y arreglaste este sshbloqueo?
@Anas: escribiste en un comentario que el problema era el mismo en la computadora portátil de tu colega. ¿Estaba esto mal? ¿Cuál es la diferencia entre su cliente Mac y Windows? ¿Qué da un básico pingsobre los 2?
@danielAzuelos Sí, lo hice, pero también era una computadora portátil Mac. Funcionó en las PC de otros colegas.
Entendí. Agregue a su pregunta original el resultado de un básico pingsobre máquinas comparadas.
Agregue a su OQ (pregunta original) cómo están conectados físicamente la Mac y la PC.
@danielAzuelos Esto fue hace más de 3 años :) Todo lo que puedo recordar es que el problema terminó siendo que el proxy de la empresa nos bloqueó, o algo similar, como dije en uno de mis comentarios. ¡Ojalá pudiera agregar más información!
Lo entendí, pero hoy en día todavía hay muchos colegas que miran esta pregunta porque tienen el mismo tipo de problema que solucionar. Esta pregunta no irá a la papelera hoy :).

Respuestas (3)

3 comandos pueden ayudarlo a rastrear esta falla de protocolo:

ping server_address
traceroute server_address
ssh -v login_name@server_address

Verifique que se esté conectando a su servidor de destino con la interfaz de red correcta. Si está utilizando la Automaticubicación infame, es posible que se esté conectando de forma incorrecta (por ejemplo, a través del wi-Fi gratuito del vecino cuando pensaba que estaba usando la VPN de su empresa).

Si sospecha un filtrado legítimo o accidental, podrá diagnosticarlo con:

nmap -Pn -p22 server_address
Hola daniel, muchas gracias por tu respuesta. Desafortunadamente, me acabo de dar cuenta de que podría ser un problema con la configuración del servidor y los proxies de mi empresa, ya que tampoco funciona en la computadora portátil de mi colega. ¡Te avisaré si no es así! Gracias !
De otro comentario, esta computadora portátil también es una Mac.
@daniel Azuelos ¿Es necesario -Pn para nmap? ¿Qué diferencia haría?
zsh: comando no encontrado: nmap
@JamieHutber, ¿qué versión de MacOS X? echo ${PATH}? [regresar] De hecho, creo que deberías hacer una pregunta sobre tu problema que no es ssh timeoutuno.
Estoy enfrentando el mismo problema después de la última actualización de Mac, los tres comandos que probé están funcionando, pero cuando se prueba nmap, ¿muestra el estado como 'filtrado'? Puedo conectar el mismo servidor con la misma red desde Windows. Alguien puede ayudarme porfavor
¿Qué computadora actualizaste? ¿Es este el sshcliente o el servidor o ambos? ¿Qué tipo de equipo tenéis entre el cliente y el servidor?

Esto me ocurrió inmediatamente después de instalar una versión actualizada de OS X. Antes de profundizar demasiado en cambiar la configuración de red, sugiero hacer un reinicio adicional. Esto me corrigió el problema.

Pude solucionar esto cambiando mi configuración de DNS de la proporcionada por el ISP predeterminado a otras diferentes (en este caso, 1.1.1.1, 1.0.0.1)

¿Cómo cambiar un servidor DNS público a otro servidor DNS público soluciona un problema que está localizado ("aquí en el trabajo", según el OP) en una red interna?
Exactamente lo que me pregunto yo también. Pero no se cambiaron otras variables, por lo que es extraño.
Mi ISP hace algunas cosas muy incompletas y restrictivas cuando se trata de enrutar mi tráfico.