Nu se poate conecta la ssh prin rețea (Administrarea sistemului, Ssh)

maffo a intrebat.
a intrebat.

Prezentare generală

Nu mă pot conecta la o gazdă prin ssh. am 2 mac-uri, ambele pe același wifi. Mac A se poate conecta la un VPN și poate intra prin ssh în mașini prin wifi. Mac B se poate conecta la VPN, dar nu poate face ssh.

Ambele mașini au același .pem fișier, în aceeași locație, permisiunea este setată la chmod 400 (-r--------). De asemenea, ambele mașini au același ~/.ssh/config fișiere.

Din cercetările pe care le-am făcut, nu pare a fi o problemă de server și cred că este o problemă cu mac B și cu setările sale de rețea.

Mașina de lucru — Mac A

OpenSSH_7.2p2, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /Users/matthewlowe/.ssh/config
debug1: /Users/matthewlowe/.ssh/config line 8: Applying options for *
debug1: /Users/matthewlowe/.ssh/config line 21: Applying options for *.internal
debug2: add_identity_file: ignoring duplicate key ~/.ssh/innometrics.pem
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug2: resolving "ip-10-0-4-139.eu-west-1.compute.internal" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to ip-10-0-4-139.eu-west-1.compute.internal [10.0.4.139] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established. 

Mașina care nu funcționează — Mac B

Când rulează ssh -vvv ipaddress.eu-west-1.compute.internal Primesc următoarele:

OpenSSH_7.2p2, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 8: Applying options for *
debug1: /Users/username/.ssh/config line 21: Applying options for *.internal
debug2: add_identity_file: ignoring duplicate key ~/.ssh/username.pem
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug2: resolving "ipaddress.eu-west-1.compute.internal" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to ipaddress.eu-west-1.compute.internal [xx.x.x.xxx] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address xx.x.x.xxx port 22: Operation timed out
ssh: connect to host ipaddress.eu-west-1.compute.internal port 22: Operation timed out

Ce înseamnă fd 3 setting O_NONBLOCK face? Am înțeles că fd 3 caută un descriptor de fișier nr. 3 și am găsit acel director pe calculatorul meu. De ce ar trebui să se blocheze aici?

Aceasta nu pare a fi o problemă DNS, deoarece numele DNS pe care îl furnizez este apoi rezolvat la IP-ul AWS corect.

Detalii suplimentare

Firewall: Off

Setări Wifi

Using DHCP
DNS Servers: 192.168.1.1
NetBIOS Name: IP-192-168-1-63 (IP-192-168-1-63 is currently being used)
Hardware configured automatically, MTU 1500

De la /etc/ssh/ssh_config Singura parte activă:

 Host *
   SendEnv LANG LC_*
   HashKnownHosts yes
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials no

Și același lucru din /etc/ssh/sshd_config

UseDNS no
UsePrivilegeSeparation sandbox
AuthorizedKeysFile  .ssh/authorized_keys

Mașina de lucru are și ea XAuthLocation /opt/X11/bin/xauth deși nu știu dacă acest lucru este relevant sau nu.

Am încercat o conexiune prin cablu și nici asta nu funcționează.

Pot posta informații suplimentare dacă este nevoie.

Papa să fie binecuvântat.

UPDATE #1

Am reinstalat openssh și open ssl. /usr/local/bin/ arată linkul sym corect la versiunile instalate. Nu folosesc o versiune mai veche din greșeală.

Am rulat ifconfig pentru a compara interfețele de rețea wifi. De asemenea, am rulat /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I en1 pentru a aprofunda un pic mai mult. Totul pare totuși normal.

Actualizare #2

Se rulează route -n get dnsnamehere pe A:

17:36 $ route -n get ip-10-0-2-121.eu-west-1.compute.internal
  route to: xx.x.x.xxx
destination: xx.x.x.xxx
 interface: ppp0
     flags: <UP,HOST,DONE,WASCLONED,IFSCOPE,IFREF>
recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
      0         0         0        52         2         0      1444         0

Rulează la fel pe B:

17:31 $ route -n get ip-10-0-2-121.eu-west-1.compute.internal
   route to: xx.x.x.xxx
destination: xx.x.x.xxx
    gateway: 192.168.1.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1453         0

De asemenea, avem și o mașină C care arată similar cu rezultatele din A. Se pare că aparatul rău este direcționat prin wifi en0 mai degrabă decât prin VPN (ppp0)? Dacă acesta este cazul, cum pot rezolva problema?

Comentarii

  • Chiar dacă vă îndoiți că problema este legată de server, ar putea fi, deoarece conexiunea VPN funcționează pe mașina B. Aveți alte servere cu care puteți testa? Ați verificat firewall-ul serverului pentru a vedea dacă a blocat ceva? –  > Por Julie Pelletier.
  • Mulțumesc că mi-ați răspuns @JuliePelletier. VPN-ul este utilizat pentru a accesa toate instanțele noastre AWS. Nu pot intra prin ssh în niciuna dintre instanțele de pe mac B. Se blochează pe debug2: fd 3 setting O_NONBLOCK. –  > Por maffo.
  • Dacă verifici conexiunea care funcționează, ar trebui să observi aceeași linie, deci este irelevantă pentru problema ta. Din moment ce problema este aparent pe Mac B, este posibil ca acesta să direcționeze tot traficul către interfața sa locală în loc de VPN. Comparați tabelele de rutare de pe ambele mașini atunci când VPN-ul este activat pentru a verifica acest lucru. –  > Por Julie Pelletier.
  • Mi-am actualizat întrebarea cu rezultatul de la mac A, deoarece ar putea fi utilă. Pot adăuga că atunci când executați traceroute pe A se obține punctul final corect, pe B sunteți aruncat în jurul valorii de 6 sau cam așa ceva și nu ajungeți niciodată la punctul final real. –  > Por maffo.
  • Faceți ambele traceroutes trec prin aceeași cale? (probabil că nu) După cum am spus, comparați tabelele de rutare de pe ambele mașini atunci când VPN-ul este activat: route -n. –  > Por Julie Pelletier.
1 răspunsuri
maffo

Mai întâi curățați tabelele de rutare de toate intrările de gateway:

sudo route flush

Apoi direcționați tot traficul care se încadrează în 10/16 către ppp0:

sudo route add -host 10.0.0.0 -netmask 255.255.0.0 -interface ppp0

Tags: