Cannot resolve hostname как исправить

You may get an error message when connecting to a machine that says ssh: Could not resolve hostname server: Name or service unknown. This might happen if you cannot connect wirelessly or don’t have enough signal strength for your device, but it can also occur because of typos in the command line prompt.

In this article, we’ll discuss how to fix it so you can reaccess your machine.

What is SSH?

Secure Shell (SSH) is an intermediate protocol between the application and transport layers of the Internet protocol stack. To create a connection to a remote shell, use the ssh command providing the username and hostname of the remote server.

Authentication uses public key cryptography, storing a private key in the user’s host. The error ssh: Could not resolve hostname is one of the most common errors encountered when using SSH.

How Does SSH Resolution With DNS?

To initiate a secure connection via SSH, a hostname must be resolved to an IP address. This can be done by providing the remote system’s IP address (e.g., 74.6.11.164) or its domain name (e.g., techcolleague.com).

A DNS server is used to translate the hostname into an IP address, and if this process fails, an error that reads “ssh could not resolve the hostname” may occur.

Additionally, systems will often store frequently-used domain names in their cache storage, so they don’t have to query a DNS server every time they attempt a request – but if this data is outdated or incorrect, it can lead to similar errors with SSH resolution.

Solution 1: Ping the Host

If you’re having difficulty connecting to a host via SSH, you should try pinging it using the ping command. If the host does not respond, it may be due to an issue on the server side.

If the host responds, there might be a network issue. Check if you can SSH to other hosts.

Solution 2: Check the Hostname

When trying to SSH to a server, verify your full command. You may be typing a command that the ssh program does not understand.

Here is an example of a command you may have run:

As you can see, the error is about not resolving the hostname myserver.

When you use the ssh program, the command you will use should be the following:

ssh [email protected]
ssh root@74.6.11.164

In the previous example, the user is root and hostname is myserver which is not a valid hostname. The correct example is shown you provide user as root and hostname as 74.6.11.164.

Solution 3: Fix the Hosts File

Hostname problems can also arise due to damage to the hosts file (i.e., /etc/hosts). Sometimes, ssh can give the same warnings for such errors as other issues. To edit the hosts file, root access is required.

Type the following command to open the file for editing:

sudo nano /etc/hosts

If you’re familiar with the vi program, you can also edit the file using vi by typing:

sudo vi /etc/hosts

The sudo prompt will ask for your password.

Make sure you have read and write access to the hosts file and look at the top of the file. You will need the following two lines for it to work correctly:

127.0.0.1 localhost
127.0.1.1 myhostname

Replace “myhostname” with your machine’s actual hostname. If you are working with an IPv6 network, you may also need these lines:

::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

In most cases, correctly setting the first two lines is sufficient for networks that use only IPv4 technology. However, modern Internet connectivity is quickly moving towards the IPv6 standard, so you may need to set these additional lines in the future.

Your Linux distribution should have configured these settings for you, but errors can occur due to an errant package or user mistakes that corrupt the hosts file and direct connections to the wrong location.

Solution 4: Add an Entry in /etc/hosts

You may have a scenario where you want to specify myserver as your hostname because you don’t want to type the IP address 74.6.11.164. In this case, you need to add an entry in /etc/hosts.

To make this change, open the /etc/hosts file and add myserver line to the end of the file such as the following example:

Once this entry has been saved in /etc/hosts, you can ssh to the server by typing:

ssh [email protected]

You should not be able to connect to your specified server.

Solution 5: Check the Hosts Directive

If the previous solution didn’t fix your issue, it may be the ordering of the hosts directive in your /etc/nsswitch.conf file.

Take a look at your /etc/nsswitch.conf. It should have this line:

hosts: files dns

With the above line, your Linux system will look at files first, which is /etc/hosts to resolve DNS. If it finds nothing there, it will query DNS in /etc/resolv.conf.

If your /etc/resolv.conf shows a different entry than the above, you may consider updating it and then connect to your server again.

Frequently Asked Questions

Conclusion

This article explains the steps to resolve the error “ssh: Could not resolve hostname.” The error can be caused due to various reasons like incorrect hostname or command line prompt, missing entry in /etc/hosts, or incorrect ordering of the hosts directive in /etc/nsswitch.conf.

This article provides solutions to fix the issue. By following these steps, you can successfully connect to your machine.

Ahem… dynamically changing the server’s hostname will likely cause a great many of the system daemons to malfunction, and often in ways that are not immediately apparent. The O/S expects the hostname to be set when the system is installed and remain unchanged. hostname is almost always checked just once on process startup. There are other ways to switch versions on the fly however…

The easiest is to setup a level of indirection using symlinks…

You don’t need two servers for this. Instead, on the same directory level as the website’s «home» directory (i.e. /var/www, hosted/server/html, etc.) create a directory for each version of the site as in…

.../
.../v1.0
.../v1.1a
.../v1.1b
   :

The v1.1a and v1.1b will be your alternating «LIVE» and «TEST».

Here comes the indirection…

Creating symlinks is very fast so you can probably recreate them when you want to swap versions with the site under light load without too much disruption.

The hosting service I’m basing this on requires the website «home» directory to be «html» as in…

/home/group/subgroup/myuserid/html

So we rename the html directory the service gives us to a version directory like v1.1a and create a symlink to it named html.

With our symlinks set, the directory listing might look like…

.../
.../TEST -> v1.1b
.../html -> v1.1a
.../v1.0
.../v1.1a
.../v1.1b

Upon making changes to website files in the .../v1.1b directory, we run a script that removes (Ubuntu has a safer unlink command) and recreates the symlinks with «html» and «TEST» swapped as in…

.../
.../TEST -> v1.1a
.../html -> v1.1b
.../v1.0
.../v1.1a
.../v1.1b

Hope this helps.

2013-02-16 18:15:12 EST supplemental…

Today’s research reveals there’s a lot conflicting opinion about this it seems.

My own experience comes from spending a lot of time restoring Xwindows and Ubuntu «zeroconfig» functionality after changing the hostname, as a few of my notes from the incident indicate…

• Ubuntu-10.04

• Net

  • As of the May 2011 updates, network settings requirements have changed dramatically in order to support Zeroconf!

  • The main issue encountered has to do with the ‘hostname’ command.

    • The method Ubuntu uses to maintain the hostname, ip address, etc. has changed.
    • The /etc/hostname and /etc/hosts files are now the authority for all of these values
    • There can no longer be multiple aliases for a host in /etc/hosts
    • In /etc/hosts, the first name should be the Fully Qualified Domain Name (FQDN) — in other words, hostname.domainname.

    • SSH now sends the FQDN instead of just the host name, so /etc/hosts.allow must be changed from…

      ALL: LOCAL
      to..
      ALL: LOCAL *.DORIS

• Excerpt from http://www.oldapps.com/linux/ubuntu.php?old_ubuntu=35?changelog…

  • ‘Avahi will always start even if a .local domain is present. The avahi-daemon package, which implements the mDNS «zeroconf» standard, formerly included a check to avoid running when a conflicting .local DNS domain is present, as it was reported that some ISPs advertise such a .local domain on their networks, leaving Ubuntu hosts unable to see names advertised on the local network (327362). In Ubuntu 9.10, avahi-daemon is started regardless. It is possible that this may cause other problems. If your network is configured this way, you can disable mDNS using the following command:’

    sudo stop avahi-daemon
    sudo sed -e ‘/^start/,+1s/^/#/’ /etc/init/avahi-daemon.conf

A couple of relevent articles…

• Near the end of Linux Hostname Configuration is a discussion of
  Xwindow considerations

• This technote from IBM.com on the «Effect of changing the IP address
  or Hostname on ITM Component server» is a good example of the
  machinations often required to get everything back in sync after a
  hostname change.