Ich kann bei mir zu Hause keine Verbindung per SSH oder Gitlab herstellen

Ich kann bei mir zu Hause keine Verbindung per SSH oder Gitlab herstellen

Ich habe einige Probleme beim Verbinden mit SSH und anderen Diensten wie Gitlab. Das passiert nur, wenn ich mich zu Hause über WLAN verbinde, da ich damit arbeiten kann, wenn ich mit einem anderen verbunden bin oder meine mobilen Daten verwende. Es sollte also an meinem Router liegen. Dieser Internetdienst ist ein neuer Vertrag mit meinem Anbieter, daher konnte ich ihn vorher nie nutzen.

Ich habe meinen ISP angerufen und er hat mir gesagt, dass ich bereits aus dem CG-Nat raus bin und die Ports öffnen kann (ich dachte, es wäre aus diesem Grund) und die Nummer 22 zu meiner Liste der geöffneten Ports hinzufügen kann, aber bei Verwendung von SSH trotzdem keine Verbindung herstellt.

Mein Routermodell ist ein Sercomm FG824CD und ich habe den Port 22 mit diesen Parametern geöffnet:

  • Gerät: MeinGerätename
  • IP LAN: 192.168.1.** (die IP meines Gerätes
  • Protokoll: TCP
  • Öffentlicher Hafen: 22
  • Hafen LAN: 22

Das einzige, was ich nicht verstehe, ist, dass der Router mir sagt: „Port 22 wird noch verwendet, wählen Sie einen anderen Port“, wenn ich versuche, die IP-Adresse meines Mobiltelefons hinzuzufügen, um auch von diesem Telefon aus SSH zu verwenden. Aber ich verstehe den Sinn nicht ... was ist, wenn ich diesen Port für mein Telefon öffnen möchte? Kann ich das nicht?

Entschuldigen Sie meine Unwissenheit und danke. Ich hoffe, Sie können mir helfen

[BEARBEITET]

Mir ist aufgefallen, dass mein MacBook eine SSH-Verbindung über WLAN herstellen kann (mit meinem Linux-Laptop geht das nicht), also liegt es vielleicht nicht am Router … Ich habe versucht, eine SSH-Verbindung mit meinem Manjaro-Laptop und meinem Mobiltelefon herzustellen, das über eine benutzerdefinierte Android-Version (/e/project) verfügt, aber ohne Erfolg.

Rückkehr von SSH beim Verbindungsversuchper WLAN:

ssh -v admin@*****.com
OpenSSH_8.6p1, OpenSSL 1.1.1k 25 Mar 2021
debug1: Reading configuration data /data/data/com.termux/files/usr/etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to *****.com [123.456.789.10] port 22.
debug1: connect to address 123.456.789.10 port 22: Connection timed out
ssh: connect to host *****.com port 22: Connection timed out

Rückkehr von SSH beim Verbindungsversuchüber mobile Daten: (Das funktioniert, da es nicht über WLAN läuft)

OpenSSH_8.6p1, OpenSSL 1.1.1k 25 Mar 2021
debug1: Reading configuration data /data/data/com.termux/files/usr/etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to u-u.monster [185.253.155.236] port 22.
debug1: Connection established.
debug1: identity file /data/data/com.termux/files/home/.ssh/id_rsa type 0
debug1: identity file /data/data/com.termux/files/home/.ssh/id_rsa-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_dsa type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_dsa-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa_sk type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519 type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519_sk type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_xmss type -1
debug1: identity file /data/data/com.termux/files/home/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: compat_banner: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to domain.com:22 as ‘admin’
debug1: load_hostkeys: fopen /data/data/com.termux/files/home/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /data/data/com.termux/files/usr/etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /data/data/com.termux/files/usr/etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: compression: none
debug1: kex: client->server cipher: [email protected] MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:+UsoRJPg7pqOz0Ed7THprLgHSaOftnLZx9K+RK4er9k
debug1: load_hostkeys: fopen /data/data/com.termux/files/home/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /data/data/com.termux/files/usr/etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /data/data/com.termux/files/usr/etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host ‘domain.com’ is known and matches the ED25519 host key.
debug1: Found key in /data/data/com.termux/files/home/.ssh/known_hosts:4
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_rsa RSA SHA256:gkbJVeuPG13A8SrcRGhVQjJyRXqHhwMkgj0PWdgoA0Q
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_dsa
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ecdsa
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ecdsa_sk
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ed25519
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_ed25519_sk
debug1: Will attempt key: /data/data/com.termux/files/home/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /data/data/com.termux/files/home/.ssh/id_rsa RSA SHA256:
aBhj25nfhTWHMOwh9 t3o23t7mhew9eto23y0weimasu
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_dsa
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ecdsa
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ecdsa_sk
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ed25519
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_ed25519_sk
debug1: Trying private key: /data/data/com.termux/files/home/.ssh/id_xmss
debug1: Next authentication method: password
admin@*****.com’s password:

Beim Verbindungsversuchlocalhost mit WLAN verbundenes gibt zurück:

ssh -v u0_a153@localhost

OpenSSH_8.6p1, OpenSSL 1.1.1k 25 Mar 2021
debug1: Reading configuration data /data/data/com.termux/files/usr/etc/ssh/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: connect to address 127.0.0.1 port 22: Connection refused
ssh: connect to host localhost port 22: Connection refused

Antwort1

Ich hatte genau das gleiche Problem mit dem Sercomm FG824CD-Router von MasMovil. Er konnte sich mit SSH von Windows aus verbinden, aber nicht von Mac. Nach genauerer Betrachtung des SSH -vvvvv sah ich, dass Mac SSH „debug3: set_sock_tos: set socket 3 IP_TOS 0x10“ ausgab, Windows SSH jedoch nicht.

Es sieht also so aus, als ob dem Sercomm-Router die aktivierten Flags bei TCP ToS nicht gefallen, sie werden gefiltert oder so etwas.

Um dies zu beheben, müssen Sie SSH so konfigurieren, dass ToS nicht verwendet wird. Dies können Sie durch Festlegen der Option tun ssh -o IPQoS=none hostoder diese Option in Ihrer ~/.ssh/config hinzufügen.

verwandte Informationen