web-dev-qa-db-fra.com

Connexion SSH refusée depuis un emplacement spécifique uniquement

Ma copine et moi partageons un serveur Ubuntu que j'ai configuré pour différentes choses. Récemment cependant, elle a connu un problème qui la rend confuse et confuse.

Chaque fois qu'elle est au travail en utilisant le WiFi de son travail, elle se connecte à l'aide de PuTTY, mais obtient simplement une erreur "Connexion réseau inattendue du serveur". On ne lui demande jamais de mot de passe avant l'erreur. Si elle configure son téléphone comme point d'accès auquel elle connecte son ordinateur portable, elle peut se connecter avec succès. Si elle est chez moi ou chez moi, elle peut également se connecter à l'aide du même ordinateur portable (sans point d'accès). Elle peut également se connecter à l'aide de son téléphone lorsque ce dernier est connecté au WiFi de son travail.

Dans le auth.log sur le serveur, je vois sa tentative de connexion entrer, mais le seul post est celui qui est fait est celui qui indique

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

Il n'y a plus d'informations dans ce journal.

Trucs nous avons essayé jusqu'à présent (y compris "je doute sérieusement que cela fonctionnera, mais pourquoi pas" - tentatives):

  • Supprimez les entrées de registre PuTTY pour réinitialiser les clés de session sur son ordinateur.
  • Supprimer et ajouter son utilisateur du serveur à partir de zéro.
  • Exécutez ssh-keygen -A pour mettre à jour les jeux de clés, avec le redémarrage ssh du service Sudo pour mettre à jour les modifications.
  • Essayez de vous connecter en utilisant uniquement l'adresse IP et non l'adresse Web.
  • Essayez de vous connecter en utilisant le formulaire [nom d'utilisateur] @ [adresse_serveur] ainsi que simplement [adresse_serveur].

  • Ajouter un addon SecureShell dans Chrome pour remplacer PuTTY (même résultat, mais avec une erreur légèrement différente:

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

Avez-vous d'autres idées sur ce qui pourrait se passer ici?

EDIT:

Le contenu de/etc/ssh/sshd_config et le résultat si iptables -L a été demandé:

# 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

Également; la sortie d'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:

Je ne peux pas en être sûr, bien sûr, mais je ne pense pas qu'il soit très probable que son travail bloque le trafic sortant sur le port 22 pour plusieurs raisons:

  1. Cela a bien fonctionné jusqu'à il y a quelques jours.
  2. Elle travaille pour une organisation qui est essentiellement un institut de recherche qui effectue des recherches en informatique. La plupart des gens là-bas utilisent Linux presque à dessein, et je pense qu'une grande majorité d'entre eux seraient très en colère s'ils ne pouvaient pas utiliser les connexions SSH.
  3. Le responsable informatique, qui est titulaire d’un doctorat en informatique, a examiné le problème pendant 5 minutes et a également été surpris. Je pense qu’il devrait savoir, parmi toutes les personnes présentes, si la politique de l’entreprise était de bloquer le port 22.
  4. Mon serveur enregistre une demande de connexion entrante et la refuse activement. Si le port 22 était bloqué, cela n'empêcherait-il pas la mise à jour du fichier auth.log?
14.04serverssh
6
Geir K.H.
refused connect from [IP-ADDRESS] ([IP-ADDRESS])

Ce message particulier est émis par le bibliothèque de wrappers TCP lorsqu'il décide de refuser une connexion. La version sshd de Ubuntu est conçue pour utiliser les wrappers TCP.

Vérifiez les deux fichiers "/etc/hosts.allow" et "/etc/hosts.deny" sur le serveur ssh. Vous avez une entrée dans l'un de ces fichiers qui provoque le rejet des connexions SSH à partir de cette adresse. Voir la page de manuel Ubuntu pour ces fichiers .

14
Kenster

En fin de compte, il est probable que l'administrateur du réseau de travail bloque TCP port 22 sortant et le port UDP 22 sortant pour bloquer l'accès SSH. Ceci est effectué pour un problème de sécurité lié au transfert de données du réseau interne vers un serveur non contrôlé par l'organisation. Ceci est également fait en tant que question de politique de lieu de travail.

En tant que professionnel de la sécurité informatique, il est de mon devoir de ne PAS fournir de réponses qui compromettraient la sécurité du serveur partagé ou celle du lieu de travail, , mais je vous propose trois options et ceux que je recommande dans les sections ci-dessous. L'un enfreint la politique du lieu de travail pour la petite amie probable, et porte également atteinte à la sécurité de votre serveur, les deux autres sont des options potentielles.

Option 1: essayez d’exécuter un client Shell Web ou définissez sshd pour utiliser le port 80.

NON RECOMMANDÉ

La seule solution dans ce cas consiste à exécuter un client Shell Web, mais vous aurez probablement besoin d'un serveur Web. L’autre solution, proposée par Nitin J Mutkawoa de mettre votre serveur SSH sur le port 80, est une autre option. Ces deux options vous exposent à plusieurs risques de sécurité, notamment les suivants:

  • Le fait de mettre SSH sur un port HTTP signifie que BEAUCOUP de serveurs peuvent essayer d’accéder à une page Web sur l’adresse IP, mais doivent plutôt toucher une connexion SSH, ce qui constitue un risque pour la sécurité, comme le voient les scanners de services.
  • Mettre ce qui devrait être considéré comme un service "sécurisé" sur un port Web vous ouvrira la voie à des attaques Web contre le port
  • Mettre SSH sur le système Web vous ouvrira la voie à de nombreux vecteurs d’attaque brutale.
  • La mise en place d’un client Shell Web orienté Web vous ouvrira également la voie aux tentatives brutales.
  • Mettre en place un client Shell basé sur le Web et ouvert sur le Web vous ouvrira la porte aux vecteurs d'attaque, quel que soit le nom du client (Java, PHP, etc.), qui peuvent inclure, sans toutefois s'y limiter:
    • Vulnérabilités d'exécution de code à distance
    • Vulnérabilités d'escalade de privilèges
    • Vulnérabilités de déni de service.

Ceci ouvre également votre petite amie à des violations des politiques sur le lieu de travail en faisant quelque chose que la politique sur le lieu de travail a décidé de refuser. Elle peut être passible de mesures disciplinaires pouvant aller jusqu'à mis à la porte. Pour cette raison, ainsi que pour les raisons de sécurité ci-dessus, vous ne devez pas implémenter cette option.

Option 2: Ne pas essayer de contourner la stratégie informatique du lieu de travail

CONSEILLÉ

En tant que professionnel de la sécurité informatique moi-même, qui a dû mettre fin à l'accès au réseau en raison de violations des règles d'autres personnes sur un lieu de travail, ma recommandation est que votre petite amie n'essaie pas et SSH de votre serveur partagé depuis un environnement/réseau de travail . Si des audits sont effectués sur le réseau, ceux-ci peuvent indiquer que quelqu'un tente de passer à SSH sur un serveur non sécurisé et non configuré. Bien que vous-même ou votre petite amie puissiez individuellement n'avoir aucune intention malveillante, la plupart des "Règles d'utilisation acceptable du réseau/de l'ordinateur" sur le lieu de travail incluront le fait que vous ne ferez pas d'objets personnels sur le réseau sans autorisation ou nécessité absolue. Une autre chose est susceptible de dire "Vous ne devez pas utiliser certains services tels que: [liste]".

Je vous recommanderais de revoir la politique d'utilisation acceptable pour le lieu de travail de votre petite amie et de déterminer si elle enfreindrait cette politique suffisamment pour qu'elle puisse faire l'objet de mesures disciplinaires, telles que la suppression de l'accès au réseau, de l'accès à l'ordinateur ou d'un renvoi éventuel. . N'essayez pas de contourner la stratégie car votre petite amie pourrait être licenciée en la contournant.

Option 3: si le SSH est nécessaire pour des tâches liées au travail, contactez les superviseurs/la direction pour voir si des exemptions de restriction peuvent être accordées à la petite amie.

AUSSI RECOMMANDÉ

Si l'accès à votre serveur SSH partagé est une nécessité pour le lieu de travail , votre copine doit Parler à son superviseur pour déterminer s'il y a violation de la politique en autorisant l'accès en tant que tel. La direction devrait ensuite déterminer si elle peut ou non autoriser l'accès, puis, à partir de là, elle déterminera s'il est sûr/sain ou non d'autoriser l'accès via le réseau.

C'est probablement la deuxième option la plus sûre

3
Thomas Ward

quelque chose ou quelqu'un a probablement installé sur le serveur un logiciel qui semblait modifier certaines valeurs par défaut du système de réseau linux. Avez-vous un journal de tous les logiciels installés depuis le début de l'incident? Oui, et avant de désinstaller le suspect, voyez ce qu'il a changé lors de son installation sur votre système.

0
MIchael Odumosu