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.
fe80::42:ff:fe:42l'adresse de ...? mon serveur mal configuré je suppose?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.arp -aouip neighbor listenroottrouver l'adresse MAC du serveur mal configuré.ssh user@link-local%devoù:la source
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.
la source