Est-il possible d'accéder SSH à un serveur avec un sous-réseau mal configuré?

Nous avons un serveur où l'un de nos ingénieurs a mal configuré le sous-réseau et maintenant nous sommes verrouillés sur ce serveur et le seul accès que je sache fonctionnerait est une console série d'IDC (cela signifie demander à un ingénieur IDC de nous aider avec cela) .

Ce qui a été mal configuré:

address 192.168.1.9 # Original address there was
netmask 255.255.255.254 # Misconfigured, originally should've been .240

Par curiosité - existe-t-il un moyen d'éviter d'appeler IDC et de se connecter en quelque sorte à cet hôte via SSH (alors nous pouvons corriger la configuration)?

Vous devez pouvoir vous connecter sur un autre hôte sur le même segment de réseau. Certaines des façons d'obtenir l'accès à l'hôte mal configuré nécessitent le root sur l'hôte intermédiaire, mais il existe également un moyen facile d'obtenir l'accès sans avoir besoin du root sur l'hôte intermédiaire.

Le moyen facile d'accéder à l'hôte à l'aide d'IPv6

ssh -o ProxyCommand='ssh -W [fe80::42:ff:fe:42%%eth0]:%p user@intermediate-host' root@target-server

Les valeurs exemple suivant dans le besoin de commande ci - dessus pour remplacer par les valeurs correctes pour votre cas d'utilisation: fe80::42:ff:fe:42, eth0, user, intermediate-hostet target-server.

Explication détaillée de son fonctionnement

ProxyCommandest une fonctionnalité ssh à utiliser lorsque vous ne pouvez pas ouvrir une connexion TCP directement à l'hôte cible. L'argument de ProxyCommandest une commande dont stdin / stdout à utiliser à la place d'une connexion TCP.

-West utilisé pour ouvrir un transfert de port unique et le connecter à stdin / stdout. Cela correspond bien avec ProxyCommand.

fe80::42:ff:fe:42%%eth0est l'adresse de liaison locale de l'hôte cible. Notez qu'en raison de l' ProxyCommandutilisation %comme caractère d'échappement, la commande typée ssh doit être utilisée %%à cet emplacement. Vous pouvez trouver toutes les adresses de lien local sur le segment en exécutant ssh user@intermediate-host ping6 -nc2 ff02::1%eth0.

L'utilisation des adresses de liaison locale IPv6 à cette fin est généralement la manière la plus simple car elle est activée par défaut sur tous les systèmes modernes, et les adresses de liaison locale continuent de fonctionner même si les piles IPv4 et IPv6 sont gravement mal configurées.

Revenir à IPv4

Si IPv6 est complètement désactivé sur l'hôte mal configuré (absolument déconseillé), vous devrez peut-être recourir à IPv4. Étant donné qu'IPv4 n'a pas d'adresses de liaison locale, la façon dont IPv6 accède à l'hôte mal configuré à l'aide d'IPv4 devient plus compliquée et nécessite un accès root sur l'hôte intermédiaire.

Si l'hôte mal configuré était toujours en mesure d'utiliser sa passerelle par défaut, vous seriez en mesure d'y accéder de l'extérieur. Il est possible que le masque de réseau mal configuré ait également cassé la passerelle par défaut en raison du refus de la pile d'utiliser une passerelle en dehors du préfixe couvert par le masque de réseau. Si c'est effectivement le cas, l'hôte mal configuré ne pourra communiquer qu'avec 192.168.1.8 car c'est la seule autre adresse IP du sous-réseau actuellement accessible à cet hôte mal configuré.

Si vous avez une connexion sur 192.168.1.8, vous pourrez peut-être simplement passer de ssh à 192.168.1.9. Si 192.168.1.8 n'est actuellement pas affecté, vous pouvez l'attribuer temporairement à n'importe quel hôte du segment sur lequel vous avez un accès root.

kasperda publié une excellente réponse suffisamment détaillée pour que j'apprenne comment je peux me remettre de la situation dans la question. Cette réponse est exactement comment je l'ai fait étape par étape.

1. SSH vers le serveur sur le même réseau physique
2. En utilisant arp -aou ip neighbor listen roottrouver l'adresse MAC du serveur mal configuré.
3. Utilisation de MAC pour convertir un lien local en lien local pour un serveur mal configuré
4. Maintenant, SSH peut servir de serveur à tout utilisateur via ssh user@link-local%devoù:
   • utilisateur - nom d'utilisateur pour lequel nous sommes autorisés à SSH
   • link-local - adresse IPv6 auto-attribuée récupérée à l'étape 3
   • dev est l'interface physique à partir de laquelle ce serveur est accessible (par exemple eth0)

Vous devez charger une adresse IP dans le sous-réseau configuré de votre cible, pas seulement dans la plage que vous souhaitez réellement.

Si vous envoyez un paquet à 10.0.0.2 avec le sous-réseau 255.255.255.248 de, par exemple, 10.0.0.220, 10.0.0.2 examinera son masque de sous-réseau pour comprendre comment répondre. Étant donné que .220 est hors du sous-réseau 255.255.255.248, .2 doit plutôt envoyer la réponse à la passerelle par défaut.

Donc, si vous pouvez charger une adresse IP dans le même sous-réseau que .2, par exemple. 10.0.0.3, alors cela fonctionnera.

Dans votre cas spécifique, pour 10.0.0.9, le sous-réseau 255.255.255.254 n'a qu'une seule adresse IP supplémentaire , à savoir 10.0.0.8. Donc, si vous pouvez charger cette adresse IP, vous devriez pouvoir SSH.