How to Fix sudo: unable to resolve host Error

1. Introduction

The Internet Protocol (IP) is the main network driver in many Linux systems. In most environments, we have three main choices for specifying hosts:

• IP address
• DNS name
• hostname

Since addresses are usually harder to remember for humans, names are often more appropriate. This applies to the system as well as any applications.

In this tutorial, we discuss the unable to resolve host (none) and sudo: unable to resolve host X: Name or service not known errors when using sudo. First, we talk about hosts in the sudo configuration files. Next, we go over how their resolution works when running the command. Finally, we explore some common troubleshooting steps to ensure the sudo command can resolve names correctly.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.

2. Hosts in sudo and sudoers

The sudo command rules can work for users or whole hosts. Further, the /etc/sudo.conf and /etc/sudoers configuration files can reference a host for two main reasons:

• specify effective privilege area
• refer to the localhost local host

Although most configurations use ALL by default, we can specify hosts in a comma-separated list comprising different formats:

• hostname
• DNS name
• IP address
• network and netmask
• netgroup

For brevity, we call all of these options hosts. Of course, we need a way to resolve the first two.

Using the ALL keyword alone for hosts, each one gets referenced as sudo executes. In fact, this applies to the local host as well.

3. sudo Host Name Resolution

Importantly, unlike some commands with similar functionality, sudo attempts to resolve hosts.

In particular, it first uses the sudo_gethostname() function to acquire the local hostname in sudoers_sethost().

/*
 * Set ctx->user.host. ctx->user.shost, ctx->runas.host and ctx->runas.shost
 * based on the local and remote host names.  If host is NULL, the local
 * host name is used.  If remhost is NULL, the same value as host is used.
 */
bool
sudoers_sethost(struct sudoers_context *ctx, const char *host,
    const char *remhost)
{
    char *cp;
    debug_decl(sudoers_sethost, SUDOERS_DEBUG_UTIL);

    if (ctx->user.shost != ctx->user.host)
	free(ctx->user.shost);
    free(ctx->user.host);
    ctx->user.host = NULL;
    ctx->user.shost = NULL;

    if (host == NULL)
	ctx->user.host = sudo_gethostname();
[...]
}

Of course, we can just read any specified hosts from the configuration files or fall back to the local host.

Later, we resolve each one with resolve_host():

/*
 * Look up the fully qualified domain name of host.
 * Use AI_FQDN if available since "canonical" is not always the same as fqdn.
 * Returns 0 on success, setting longp and shortp.
 * Returns non-zero on failure, longp and shortp are unchanged.
 * See gai_strerror() for the list of error return codes.
 */
static int
resolve_host(const char *host, char **longp, char **shortp)

This procedure doesn’t exist for simpler run-as versions of sudo, such as doas.

4. Correct sudo Name Resolution Issues

Considering the resolution steps, we can have hostname issues at a couple of points when using sudo.

4.1. Get Local Hostname

To ensure sudo is able to get and resolve it, we need to correctly configure the local hostname.

Let’s check the current one via both the /etc/hostname file and the hostname command:

$ cat /etc/hostname
xost
$ hostname
xost

Problems with sudo in this area can arise for several reasons:

• hostname isn’t set
• contents of /etc/hostname and output of hostname differ
• hostname changes aren’t applied

For example, we can set the hostname via hostname:

$ hostname x0st
$ hostname
x0st

However, this change doesn’t propagate or persist:

$ cat /etc/hostname
xost

So, let’s use the more robust hostnamectl:

$ hostnamectl status
   Static hostname: xost
[...]
$ cat /etc/hostname
xost
$ hostnamectl set-hostname x0st
$ cat /etc/hostname
x0st

At this point, we should have our local hostname correctly configured.

Still, sudo can respond with an error:

$ sudo true
sudo: unable to resolve host x0st: Name or service not known

Trying to run the true utility with sudo produces a problem with the resolution of our new hostname. Let’s try to address that.

4.2. System Host Resolution

Ensuring we can resolve a given name via the /etc/hosts file or the current DNS server is vital for the correct function of many applications that rely on any kind of network connectivity.

The sudo command is no exception. So, any hostnames that we specify in the sudo and sudoers configuration files need to be resolvable. Perhaps the simplest way to verify this is the case is to test our current setup with a given name:

$ getent ahosts xost
127.0.1.1       STREAM xost.local
127.0.1.1       DGRAM
127.0.1.1       RAW

Should the local or remote hostname not resolve, we can make modifications to /etc/hosts by any means:

$ cat /etc/hosts
127.0.1.1 xost.local
[...]
$ vi /etc/hosts
[...]
$ cat /etc/hosts
127.0.0.1 x0st
[...]

In this case, we use vi to change the local hostname in the hosts file. Importantly, the local hostname we set earlier should exactly match the one in /etc/hosts.

If we don’t find the results satisfying, we can also add a hosts entry:

$ printf '192.168.6.66\trem0st\n' >> /etc/hosts
$ cat /etc/hosts
[...]
192.168.6.66  rem0st

At this point, we have a new mapping for rem0st.

5. Summary

In this article, we talked about sudo name resolution and ways it can fail.

In conclusion, like other applications, the sudo command relies on the system host resolution and hostname configuration.