Vejledninger

Fix: SSH-fejl 'kunne ikke løse værtsnavneserver'

Du vil undertiden se en fejl, der fortæller dig, at ssh ikke kunne løse et værtsnavn, når du forsøger at bruge det. Hvis du får denne fejl, skal du først sikre dig, at du har forbindelse til netværket. Brugere af enhver form for trådløst netværk vil også gerne sikre sig, at de får nok af et signal til at gennemføre anmodningen. Manglende forbindelse er den mest almindelige årsag til disse fejl ifølge mange udviklere. Det er endnu mere almindeligt end skrivefejl.

Hvis du er sikker på, at du har en solid forbindelse, skal du derefter kontrollere for eventuelle typografiske fejl. Du har muligvis fejlagtigt indtastet en IP-adresse eller en slags ressourcelokaliseringslinje. Selvom det kan virke kræsen om den måde, information bliver præsenteret for, vil ssh-softwaren sikre, at du altid opretter forbindelse til den rigtige ressource. Derudover kan din værtsfil muligvis også i sidste ende pege ssh i den forkerte retning med hensyn til den ressource, du forsøger at oprette forbindelse til.

Metode 1: Løsning af misdannede værtsnavnskommandoer

Forudsat at du ikke lavede en fejl som at skrive s sh eller ss h i stedet for ssh, har du muligvis misdannet værtsnavnskommandoen. Softwaren forventer kommandoer givet som ssh-bruger @ NAME i stedet for et andet format. Åbn en terminal med de rette privilegier til din kommando. Du vil generelt være i stand til at fungere som en almindelig bruger, når du bruger ssh, og du har ikke brug for superbrugerbeføjelser.

Det kan være en god idé at åbne en terminal ved at holde Ctrl, Alt og T nede samtidig. Nogle Xfce4-brugere kan holde Windows- eller Super-tasten nede og trykke på T. Du kan starte en prompt fra menuen Dash, Applications, KDE eller Whisker ved at gå til søgning og skrive Terminal eller i stedet ved at vælge den fra systemværktøjer. Brugere af Ubuntu Server eller versioner af Red Hat Enterprise Linux og Scientific Linux, der ikke har en grafisk brugergrænseflade, skal holde Ctrl, Alt og F1-F6 nede for at få adgang til en virtuel konsol. Du skal logge på, før du fortsætter.

Når du er hurtig, skal du udstede din ssh-kode og sørge for, at den er i det tidligere format. For eksempel kan du prøve ssh root @ myPlace, hvis du havde et værtsnavn tilsluttet på dit netværk som sådan. Kommandoen ssh root@##.#.#.##, efter at have erstattet octothorpe-symbolerne med tal, er en god ide, hvis du opretter forbindelse direkte til en IP-adresse.

Du kan finde ud af, at du skrev root @ server eller noget andet lignende, hvilket ville spytte denne følgende fejl:

ssh: Kunne ikke løse værtsnavneserver: Navn eller service ukendt

Nogle brugere har en vane med at minde sig selv om, at ssh user @ server er den måde, du altid har brug for at skrive denne kommando ud.

Metode 2: Korrigering af Fil

Enhver form for skade på filen kan også forårsage problemer med værtsnavnet, og ssh vil undertiden tilbyde de samme advarsler for disse typer fejl, som den ville tilbyde for noget andet. Du skal bruge rootadgang for at åbne værtsfilen. Hvis du arbejder på en af ​​terminalerne ovenfra, kan du skrive sudo nano eller

for at åbne filen til redigering. Sudo-prompten beder om din adgangskode.

Hvis du arbejder indefra i et skrivebordsmiljø, skal du åbne en applikationslinje. Du kan gøre det ved at holde Windows eller Super-tasten og R nede, trykke på Alt og F2 eller klikke på Dash afhængigt af hvilket skrivebordsmiljø du bruger. Når du har en linje, skal du skrive afhængigt af om du bruger GTK + eller KDE Qt-baserede applikationer. Det kan være en god idé at bruge gvim, leafpad eller mousepad i stedet for gedit eller kate.

Du har under alle omstændigheder indlæst værtsfilen. Sørg for, at du har læsning og skriveadgang, og kig derefter øverst i filen. Du skal bruge følgende to linjer for at det fungerer korrekt:

127.0.0.1 lokal vært

127.0.1.1 YourHostName

YourHostName skal indeholde din maskines faktiske værtsnavn. Du har muligvis også brug for disse, hvis du arbejder med et IPv6-netværk:

:: 1 ip6-localhost ip6-loopback

fe00 :: 0 ip6-localnet

ff00 :: 0 ip6-mcastprefix

ff02 :: 1 ip6-allnoder

ff02 :: 2 ip6-allrouters

Hvis du er på et slags netværk, der kun bruger IPv4-teknologi, skal du kun indstille de to første korrekt i de fleste situationer. Moderne internetforbindelse migrerer hurtigt mod IPv6-standarden, men dagene med at indstille disse alene forsvinder hurtigt. Din Linux-distribution skulle have konfigureret disse indstillinger for dig, men nogle gange kan en fejlagtig pakke eller simpelthen brugerfejl ødelægge værtsfilen og pege forbindelser på den forkerte placering.

Hvis du bruger en grafisk teksteditor, der læser i titellinjen, kan du faktisk ikke gemme den og ikke bruge gksu eller kdesu korrekt. Du kan alternativt finde ud af, at du har andre linjer efter ff02 :: 2 ip6-allrouters, som du ikke behøver at røre ved, medmindre de har noget at gøre med nogen af ​​disse andre koder. Dette er dele af andre opgaver, og du kan have en hel del af dem, hvis du er på et system, hvor værtsfilen blev brugt til at blokere brugere for at få adgang til et bestemt websted. Du bliver dog nødt til at kommentere duplikatlinjer, hvilket kan gøres ved at tilføje symbolet # til starten af ​​dem. Hver af de foregående linjer skal kun forekomme en gang, og du vil ikke have flere opgaver for nogen af ​​de givne navne. Det ville tvinge ssh og alle andre netværksprogrammer til simpelthen at tage den sidste opgave, hvilket kan være forkert.

Gem filen, når du er færdig med at redigere den, og sørg for at lukke den umiddelbart derefter. Du vil ikke foretage unødvendige ændringer i værtsfilen, hvis du kan undgå den, hvorfor det er så vigtigt at afslutte her. Prøv din ssh-kommando, når du er færdig, og sørg for, at du har dannet den korrekt med de trin, der er beskrevet i den første metode. Hvis du stadig har problemer, skal du genstarte maskinen. Ellers skal du ikke have yderligere problemer med ssh.

$config[zx-auto] not found$config[zx-overlay] not found