Fix: SSH Error ‘could not resolve hostname server’

You’ll sometimes see an error telling you that ssh couldn’t resolve a hostname when you attempt to use it. If you’re getting this error, then you should first make sure that you’re connected to the network. Users of any type of wireless networking will also want to make sure that they’re getting enough of a signal to complete the request. A lack of connectivity is the most common cause of these errors according to many developers. It’s even more common than typos.

If you’re sure that you have a solid connection, then you should next check for any typographical errors. You may have mistyped an IP address or some sort of resource locator line. While it might seem picky about the way information gets presented to it, the ssh software wants to make sure you’re always connecting to the right resource. In addition, your hosts file might also ultimately point ssh in the wrong direction as to the resource you’re attempting to connect to.

Method 1: Resolving Malformed Hostname Commands

Assuming you didn’t make a mistake like typing s sh or ss h instead of ssh, then you might have malformed the hostname command. The software expects commands given as ssh user@NAME instead of some other format. Open up a terminal with the appropriate privileges for your command. You’ll generally be able to operate as a regular user when using ssh and you won’t need superuser powers.

You may want to open a terminal by holding down Ctrl, Alt and T at the same time. Some Xfce4 users can hold down the Windows or Super key and push T. You can start a prompt from the Dash, Applications, KDE or Whisker menu by heading to search and typing Terminal or instead by selecting it from system tools. Users of Ubuntu Server or versions of Red Hat Enterprise Linux and Scientific Linux that don’t have a graphical user interface should hold down Ctrl, Alt and F1-F6 to access a virtual console. You’ll need to log in before proceeding.

Once you’re at a prompt, issue your ssh code and make sure it’s in the previous format. For instance, you could try ssh root@myPlace if you had a hostname connected on your network as such. The command ssh root@##.#.#.##, having replaced the octothorpe symbols with numbers, is a good idea if you’re connecting directly to an IP address.

You may find you were writing root@server or something else similar, which would spit out this following error:

ssh: Could not resolve hostname server: Name or service not known

Some users make a habit of reminding themselves that ssh user@server is the way you always need to write this command out.

Method 2: Correcting the  File

Any sort of damage to the  file can also cause hostname problems, and ssh will sometimes offer the same warnings for these types of errors that it would offer for anything else. You’ll need root access to open the hosts file. If you’re working on one of the terminals from above, then you can type sudo nano  or
 to open the file for editing. The sudo prompt will request your password.

If you’re working from inside of a desktop environment, then you’ll want to open an application line. You can do so by holding down the Windows or Super key and R, pushing Alt and F2 or clicking on the Dash depending on which desktop environment you’re using. When you have a line, type depending on whether you’re using GTK+ or KDE Qt based applications. You may want to use gvim, leafpad or mousepad instead of gedit or kate.

You’ll have loaded the hosts file in any case. Make sure you have read and write access then take a look at the top of the file. You’ll need the following two lines for it work correctly:

127.0.0.1    localhost

127.0.1.1    YourHostName

YourHostName should feature your machine’s actual hostname. You may need these as well if you’re working with an IPv6 network:

::1     ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

If you’re on some sort of network that only uses IPv4 technology, then you will only need to correctly set the first two in a majority of situations. Modern Internet connectivity is quickly migrating toward the IPv6 standard, however, so the days of setting these alone are quickly vanishing. Your Linux distribution should have configured these settings for you, but sometimes an errant package or simply user errors can corrupt the hosts file and point connections in the wrong location.

If you’re using a graphical text editor that reads <hosts> in the title bar, then you can’t actually save it and didn’t use gksu or kdesu correctly. You may alternatively find you have other lines after ff02::2 ip6-allrouters, which you don’t need to touch unless they have anything to do with any of these other codes. These are parts of other assignments, and you may have quite a few of them if you’re on a system where the hosts file was used to block users from accessing any particular site. You will need to comment out duplicate lines, however, which can be done by adding the # symbol to the start of them. Each of the previous lines should only occur once, and you don’t want to have multiple assignments for any of the given names. That would force ssh and all other networking programs to simply take the last assignment, which might be wrong.

Save the file once you’re done editing it and make sure to close it immediately afterward. You don’t want to make any unnecessary changes to the hosts file if you can avoid it, which is why exiting here is so imperative. Try your ssh command once you’re done, making sure that you’ve properly formed it with the steps laid out in the first method. If you’re still having problems, then you’ll want to restart the machine. Otherwise, you should have no further issues with ssh.