it-swarm.com.de

Die SSH-Verbindung wurde nur von einem bestimmten Standort aus abgelehnt

Meine Freundin und ich teilen uns einen Ubuntu-Server, den ich für verschiedene Dinge eingerichtet habe. In letzter Zeit hat sie jedoch ein Problem, das mich, sie und unsere beiden Kollegen verwirrt und verwirrt hat.

Immer wenn sie mit dem WLAN ihres Jobs auf der Arbeit ist, stellt sie mit PuTTY eine Verbindung her, erhält jedoch den Fehler "Server unerwartet geschlossene Netzwerkverbindung". Sie wird vor dem Fehler nie zur Eingabe eines Kennworts aufgefordert. Wenn sie ihr Telefon als Hotspot einrichtet, mit dem sie ihren Laptop verbindet, kann sie sich erfolgreich anmelden. Wenn sie zu Hause oder bei mir ist, kann sie sich auch mit demselben Laptop anmelden (ohne Hotspot). Sie kann sich auch mit ihrem Telefon anmelden, während das Telefon mit dem WiFi ihres Jobs verbunden ist.

In dem auth.log auf dem Server sehe ich, wie ihr Verbindungsversuch hereinkommt, aber der einzige Beitrag, der gemacht wird, ist der, der angibt

refused connect from [IP-ADDRESS] ([IP-ADDRESS])

In diesem Protokoll sind keine weiteren Informationen enthalten.

Sachen, die wir bisher versucht haben (einschließlich "Ich bezweifle ernsthaft, dass dies funktionieren wird, aber warum nicht" -Versuche):

  • Löschen Sie die PuTTY-Registrierungseingaben, um die Sitzungsschlüssel auf ihrem Computer zurückzusetzen.
  • Löschen Sie den Serverbenutzer und fügen Sie ihn von Grund auf neu hinzu.
  • Führen Sie ssh-keygen -A aus, um die Schlüsselsätze zu aktualisieren, und starten Sie den Sudo-Dienst ssh neu, um die Änderungen zu aktualisieren.
  • Versuchen Sie, sich nur mit der IP-Adresse und nicht mit der Webadresse anzumelden.
  • Versuchen Sie, sich sowohl mit dem Formular [Benutzername] @ [Serveradresse] als auch nur mit [Serveradresse] anzumelden.
  • Hinzufügen eines SecureShell-Addons in Chrome, um PuTTY zu ersetzen (gleiches Ergebnis, jedoch mit einem etwas anderen Fehler:

    ssh_exchange_identification: Connection closed by remote Host NaCl plugin exited with status code 255
    

Irgendwelche anderen Ideen, was hier los sein könnte?

EDIT:

Der Inhalt von/etc/ssh/sshd_config und die Ausgabe, wenn iptables -L angefordert wurde:

# 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 yes

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

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
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

Ebenfalls; das outout von iptables -L:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

EDIT2:

Ich kann mich natürlich nicht sicher sein, aber ich glaube nicht, dass es sehr wahrscheinlich ist, dass ihr Job aus mehreren Gründen ausgehenden Datenverkehr auf Port 22 blockiert:

  1. Bis vor ein paar Tagen hat es geklappt.
  2. Sie arbeitet für eine Organisation, die im Grunde genommen ein Forschungsinstitut ist, das sich mit IT befasst. Die meisten Leute dort benutzen Linux fast religiös, und ich glaube, eine große Mehrheit der Leute dort wäre ziemlich wütend, wenn sie keine SSH-Verbindungen benutzen könnten.
  3. Der dortige IT-Leiter, der im Fach Informatik promoviert hat, hat sich das Problem 5 Minuten lang angeschaut und war auch ratlos. Ich denke, ausgerechnet er sollte wissen, ob es eine Firmenrichtlinie war, Port 22 zu blockieren.
  4. Mein Server registriert eine eingehende Verbindungsanforderung und lehnt sie aktiv ab. Wenn Port 22 blockiert wäre, würde dies nicht dazu führen, dass in auth.log überhaupt keine Updates vorhanden sind?
6
Geir K.H.
refused connect from [IP-ADDRESS] ([IP-ADDRESS])

Diese spezielle Nachricht wird von der TCP-Wrapper-Bibliothek ausgegeben, wenn entschieden wird, eine Verbindung abzulehnen. Ubuntus sshd verwendet TCP Wrapper.

Überprüfen Sie die beiden Dateien "/etc/hosts.allow" und "/etc/hosts.deny" auf dem SSH-Server. Sie haben einen Eintrag in einer dieser Dateien, wodurch ssh-Verbindungen von dieser Adresse abgelehnt werden. Siehe die Ubuntu-Manpage für diese Dateien .

15
Kenster

Es ist wahrscheinlich, dass der Netzwerkadministrator für sein Arbeitsnetzwerk TCP ausgehenden Port 22 und UDP-Port 22 ausgehenden Port 22 blockiert, um den SSH-Zugriff zu blockieren. Dies geschieht aus Sicherheitsgründen, wenn Daten vom internen Netzwerk auf einen Server 'hochgeladen' werden, der nicht von der Organisation kontrolliert wird. Dies ist auch eine Frage der Arbeitsplatzpolitik.

Als IT-Sicherheitsexperte ist es meine Pflicht, KEINE Antworten zu liefern, die die Sicherheit des gemeinsam genutzten Servers oder des Arbeitsplatzes gefährden würden. Aber ich gebe Ihnen hier drei Optionen und identifiziere welche diejenigen, die ich in den folgenden Abschnitten empfehle. Einer verstößt wahrscheinlich gegen die Richtlinien des Arbeitsplatzes für die Freundin und beeinträchtigt auch die Sicherheit Ihres Servers, die anderen beiden sind mögliche andere Optionen.


Option 1: Versuchen Sie, einen mit dem Web verbundenen Shell-Client auszuführen, oder legen Sie sshd fest, um Port 80 zu verwenden.

NICHT EMPFOHLEN

Die einzige Lösung in diesem Fall besteht darin, einen webbasierten Shell-Client auszuführen. Wahrscheinlich benötigen Sie jedoch einen Webserver. Die andere von Nitin J Mutkawoa vorgeschlagene Lösung, Ihren SSH-Server auf Port 80 zu setzen, ist eine weitere Option. Mit beiden Optionen sind Sie verschiedenen Sicherheitsrisiken ausgesetzt, unter anderem:

  • Wenn Sie SSH auf einen HTTP-Port setzen, versuchen MANY-Server möglicherweise, auf eine Webseite mit der IP-Adresse zuzugreifen. Stattdessen wird eine SSH-Verbindung hergestellt, was ein Sicherheitsrisiko darstellt, da Service-Scanner dies erkennen.
  • Wenn Sie einem Web-Port einen "sicheren" Dienst hinzufügen, können Sie webbasierte Angriffe auf den Port ausführen
  • Wenn Sie SSH in das Web-System einbinden, können Sie viele Bruteforce-Angriffsmethoden anwenden.
  • Wenn Sie einen webbasierten Shell-Client für das Web einrichten, können Sie auch Bruteforce-Versuche starten
  • Wenn Sie einen webbasierten Shell-Client mit Web-Oberfläche einrichten, können Sie Vektoren von jedem beliebigen "Client" (Java, PHP usw.) aus angreifen, einschließlich, aber nicht beschränkt auf:
    • Sicherheitslücken in der Remotecodeausführung
    • Sicherheitsanfälligkeiten durch Rechteerweiterung
    • Denial-of-Service-Schwachstellen.

Dies öffnet Ihrer Freundin auch die Möglichkeit, am Arbeitsplatz gegen Richtlinien zu verstoßen, indem sie etwas unternimmt, das die Richtlinien am Arbeitsplatz verweigern. Sie könnte mit Disziplinarmaßnahmen bis hin zur Entlassung konfrontiert werden. Aus diesem Grund sowie aus den oben genannten Sicherheitsgründen sollten Sie diese Option nicht implementieren.


Option 2: Versuchen Sie nicht , die IT-Richtlinien am Arbeitsplatz zu umgehen

EMPFOHLEN

Als IT-Sicherheitsexperte selbst, der in der Vergangenheit den Netzwerkzugriff aufgrund von Richtlinienverstößen anderer Personen an einem Arbeitsplatz beenden musste, empfehle ich, dass Ihre Freundin nicht versucht, SSH auf Ihren gemeinsam genutzten Server zu übertragen eine Arbeitsumgebung/Netzwerk . Wenn im Netzwerk Überwachungstypen ausgeführt werden, zeigt die Netzwerküberwachung möglicherweise, dass jemand versucht, eine SSH-Verbindung zu einem unsicheren, nicht überprüften Server herzustellen. Auch wenn Sie oder Ihre Freundin möglicherweise keine böswillige Absicht haben, enthalten die meisten Richtlinien für die Nutzung des Netzwerks/Computers am Arbeitsplatz, dass Sie keine persönlichen Dinge im Netzwerk tun, die weder autorisiert noch unbedingt erforderlich sind. In einer anderen Meldung wird wahrscheinlich angegeben, dass Sie bestimmte Dienste nicht nutzen dürfen, z. B .: [Liste].

Ich würde empfehlen, dass Sie die Richtlinie zur akzeptablen Nutzung für den Arbeitsplatz der Freundin überprüfen und feststellen, ob sie gegen diese Richtlinie verstößt, sodass sie Disziplinarmaßnahmen wie das Entfernen des Netzwerkzugriffs, das Entfernen des Computerzugriffs oder eine mögliche Entlassung ausgesetzt ist . Versuchen Sie nicht, die Richtlinie zu umgehen, da Ihre Freundin durch Umgehen entlassen werden könnte.


Option 3: Wenn der SSH für arbeitsbezogene Aufgaben benötigt wird, wenden Sie sich an die Vorgesetzten/das Management, um zu erfahren, ob der Freundin Einschränkungen gewährt werden können.

AUCH EMPFOHLEN

Wenn der Zugriff auf Ihren gemeinsam genutzten SSH-Server für den Arbeitsplatz erforderlich ist , muss Ihre Freundin mit ihrem Vorgesetzten sprechen, um festzustellen, ob dies der Fall ist ob ein Verstoß gegen die Richtlinie vorliegt, indem der Zugriff als solcher zugelassen wird. Es müsste dann vom Management besprochen werden, ob sie Zugriff gewähren können oder nicht, und von dort aus wird bestimmt, ob es sicher ist, den Zugriff über das Netzwerk zuzulassen oder nicht.

Dies ist wahrscheinlich die zweit sicherste Option

3
Thomas Ward

etwas oder jemand hat wahrscheinlich Software auf dem Server installiert, die einige Standardeinstellungen im Linux-Netzwerksystem zu ändern schien. Haben Sie ein Protokoll aller installierten Software seit dem Beginn des Vorfalls? Bevor Sie den Verdächtigen deinstallieren, überprüfen Sie, welche Änderungen der Verdächtige vorgenommen hat, als er auf Ihrem System installiert wurde

0
MIchael Odumosu