Debian/Ubuntu: sudo: unable to resolve host — как исправить hostname, /etc/hostname и /etc/hosts

Сообщение sudo: unable to resolve host в Debian или Ubuntu выглядит неприятно, но обычно не означает поломку самого sudo. В большинстве случаев причина прозаична: текущее имя хоста не совпадает с локальной конфигурацией разрешения имён.

Чаще всего проблема появляется после ручного переименования сервера, клонирования шаблона, восстановления из снапшота или автоматических изменений через cloud-init и систему конфигурации. На новых облачных инстансах и VDS это особенно частый сценарий.

Хорошая новость в том, что исправление обычно занимает несколько минут. Плохая — если поправить только один файл, ошибка часто возвращается после перезагрузки. Поэтому ниже разберём не только быстрый фикс, но и нормальный алгоритм проверки.

Важно понимать: предупреждение не всегда мешает выполнению команды. Нередко sudo продолжает работать, но каждый запуск сопровождается лишним сообщением. Игнорировать это не стоит, потому что путаница с hostname потом всплывает в логах, мониторинге и автоматизации.

Ниже покажу, как проверить текущее имя хоста, как связаны /etc/hostname и /etc/hosts, когда нужен hostnamectl и что делать, если изменения откатывает cloud-init.

Почему возникает ошибка sudo: unable to resolve host

Когда вы запускаете sudo, система пытается сопоставить текущее имя узла с локальными источниками имён. Если hostname не удаётся корректно разрешить, появляется предупреждение вида:

sudo: unable to resolve host myserver: Name or service not known

Обычно это означает, что имя хоста существует, но в локальной конфигурации нет корректной записи, которая с ним совпадает. Во многих случаях DNS здесь вообще ни при чём: достаточно исправить локальный файл /etc/hosts.

Типовые причины такие:

• в /etc/hostname указано одно имя, а в /etc/hosts осталось другое;
• hostname изменили через hostnamectl, но локальную запись не обновили;
• поправили /etc/hosts, но активное имя системы осталось старым;
• после перезагрузки старое имя вернул cloud-init;
• сервер клонировали из шаблона с уже зашитым чужим hostname.

Если коротко: проблема не в самом sudo, а в том, что текущее имя хоста и локальное разрешение имени перестали совпадать.

Что проверить в первую очередь

Перед правкой полезно увидеть текущее состояние системы: какое имя хоста активно сейчас, что лежит в файлах и может ли система разрешить это имя локально.

Для быстрой диагностики достаточно такого набора:

hostname
hostnamectl status
cat /etc/hostname
cat /etc/hosts
getent hosts $(hostname)

На что смотреть:

• hostname показывает текущее короткое имя;
• hostnamectl status помогает увидеть static и transient hostname;
• в /etc/hostname должна быть одна строка с корректным именем;
• в /etc/hosts должна быть строка, где присутствует текущее hostname;
• getent hosts $(hostname) должен вернуть результат, а не пустой вывод.

Если последняя команда ничего не возвращает, проблема почти наверняка в локальной привязке имени. Это и есть основной источник предупреждения sudo: unable to resolve host.

Быстрый способ исправить проблему

Если hostname менять не нужно, задача сводится к одному: текущее имя хоста должно присутствовать в /etc/hosts.

Допустим, ваш сервер должен называться web-01. Сначала проверьте содержимое /etc/hostname:

cat /etc/hostname

В файле должно быть ровно это значение:

web-01

Затем проверьте /etc/hosts. На практике чаще встречается один из двух вариантов.

127.0.0.1 localhost
127.0.1.1 web-01

::1 localhost ip6-localhost ip6-loopback

Или так:

127.0.0.1 localhost web-01
::1 localhost ip6-localhost ip6-loopback

Для Debian и Ubuntu особенно типична схема с отдельной строкой 127.0.1.1. Главное не сам адрес, а то, чтобы текущее имя хоста реально разрешалось через локальную конфигурацию.

После правки сразу проверьте результат:

getent hosts $(hostname)
sudo -v

Если предупреждение исчезло, проблема решена.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как правильно поменять hostname

Если вы не просто чините рассинхронизацию, а действительно переименовываете сервер, лучше использовать hostnamectl. На современных Debian и Ubuntu это основной и самый предсказуемый способ.

sudo hostnamectl set-hostname db-prod-01

После этого проверьте, что система приняла новое имя:

hostname
hostnamectl status
cat /etc/hostname

Но на этом работа не заканчивается. Новое имя нужно внести и в /etc/hosts, иначе получите классическую ситуацию: hostnamectl показывает уже новое значение, а sudo продолжает ругаться.

127.0.0.1 localhost
127.0.1.1 db-prod-01

::1 localhost ip6-localhost ip6-loopback

На старых или минимальных системах иногда используют ручной вариант с правкой /etc/hostname и временным применением имени через hostname, но для современных установок лучше опираться именно на hostnamectl.

Нужна ли перезагрузка

Обычно нет. Если вы исправили /etc/hosts и при необходимости задали имя через hostnamectl, результат можно проверить сразу. Перезагрузка полезна только как дополнительная проверка, если есть подозрение, что настройки кто-то перезаписывает.

Типичные ошибки при исправлении

Первая частая ошибка — администратор смотрит только в один файл. Например, меняет /etc/hostname, но не проверяет активное имя системы через hostname и не обновляет /etc/hosts.

Вторая ошибка — лишние символы в /etc/hostname. В этом файле не нужны комментарии, лишние пробелы и несколько строк. Самый безопасный вариант — одно имя в одной строке.

Третья ошибка — неаккуратная правка /etc/hosts. Особенно часто встречаются такие случаи:

• удалили строку с localhost;
• оставили одновременно старое и новое имя без понимания, какое реально используется;
• привязали hostname к неподходящему адресу;
• исказили формат файла при ручном редактировании.

Четвёртая ошибка — всё исправили, но после перезагрузки конфигурация вернулась назад. Тогда нужно искать внешний источник изменений: cloud-init, шаблон образа, оркестрацию или CM-систему. Если вы регулярно разворачиваете серверы из подготовленных шаблонов, полезно держать под рукой и разбор по golden image с cloud-init.

Особый случай: cloud-init перезаписывает hostname

На облачных инстансах и готовых образах очень часто активен cloud-init. Он может выставлять hostname при первом старте и иногда повторно применять его позже, в зависимости от конфигурации.

Из-за этого возможна неприятная ситуация: вы вручную исправили hostname и /etc/hosts, всё заработало, но после reboot предупреждение вернулось.

Сначала проверьте, установлен ли cloud-init:

dpkg -l | grep cloud-init

Затем проверьте, не управляет ли он именем хоста:

grep -R "preserve_hostname" /etc/cloud /usr/lib/cloud 2>/dev/null
cloud-init status

Если hostname должен сохраняться вручную, обычно помогает явная настройка:

sudo sh -c 'printf "preserve_hostname: true\n" > /etc/cloud/cloud.cfg.d/99-preserve-hostname.cfg'

После этого задайте нужное имя через hostnamectl, ещё раз проверьте /etc/hosts и выполните контрольную перезагрузку в удобное окно обслуживания.

Если hostname откатывается после reboot, проблема уже не только в /etc/hosts. Нужно искать систему, которая считает себя источником правды для имени узла.

Пошаговая диагностика на рабочем сервере

На продакшене лучше действовать по простому и безопасному сценарию:

1. Проверьте текущее имя через hostname и hostnamectl status.
2. Сравните его с содержимым /etc/hostname.
3. Убедитесь, что это имя есть в /etc/hosts.
4. Проверьте локальное разрешение через getent hosts $(hostname).
5. Если имя недавно меняли, убедитесь, что мониторинг и автоматизация тоже знают о новом hostname.
6. Если после reboot проблема возвращается, проверяйте cloud-init и внешние шаблоны.

Такой порядок помогает не просто убрать предупреждение у sudo, а действительно навести порядок в идентификации узла.

Эталонная минимальная конфигурация

Для большинства одиночных Debian/Ubuntu-серверов достаточно очень простой схемы.

Файл /etc/hostname:

app-01

Файл /etc/hosts:

127.0.0.1 localhost
127.0.1.1 app-01

::1 localhost ip6-localhost ip6-loopback

Проверка:

hostname
getent hosts app-01
sudo -v

Этого обычно достаточно, чтобы предупреждение исчезло и локальный резолвинг стал предсказуемым.

Если вы используете FQDN, например app-01.example.internal, делайте это единообразно во всей инфраструктуре. Для маленького одиночного сервера без собственной DNS-зоны усложнять схему часто не нужно.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Когда проблема не в /etc/hosts

Хотя чаще всего виноват именно /etc/hosts, бывают и менее типичные причины. Например, нестандартный порядок источников в /etc/nsswitch.conf, особенности контейнера или автоматически генерируемый файл hosts.

Базовая проверка выглядит так:

grep '^hosts:' /etc/nsswitch.conf

Обычно ожидается что-то вроде:

hosts: files dns

Это означает, что система сначала смотрит локальные файлы, а уже потом DNS. Для разбираемой ошибки именно такое поведение обычно и требуется.

Если вы работаете не с полноценной VM, а с контейнерами или шаблонами образов, полезно помнить, что hostname и /etc/hosts там часто генерируются автоматически. В таких случаях ручная правка внутри окружения не всегда переживает перезапуск. Для массовых развёртываний лучше сразу выстраивать корректный pipeline сборки образов и инициализации.

Как не допустить повторения ошибки

Лучший способ избежать этой проблемы — не допускать рассинхронизации между hostname и локальными файлами. Для команды администраторов стоит зафиксировать простой регламент.

• Меняйте hostname через hostnamectl или через утверждённую автоматизацию.
• После смены имени сразу проверяйте /etc/hosts.
• Всегда выполняйте getent hosts $(hostname) как финальную проверку.
• На cloud-образах заранее определите, кто управляет hostname: администратор или cloud-init.
• После клонирования шаблона проверяйте hostname до ввода сервера в эксплуатацию.

Если вы регулярно поднимаете сайты и приложения, где важна предсказуемая базовая конфигурация Linux, иногда проще вынести такие проверки в bootstrap и стандартные роли, а для самих проектов использовать либо виртуальный хостинг, либо отдельные серверы под нужный стек в зависимости от задач.

Краткий итог

Предупреждение sudo: unable to resolve host в Debian и Ubuntu почти всегда связано с тем, что текущее имя хоста не совпадает с записью в /etc/hosts или было изменено не до конца. Главные точки проверки — /etc/hostname, /etc/hosts, вывод hostname и результат getent.

Практически всегда рабочая схема такая: выясняете текущее имя, приводите его к нужному виду, добавляете корректную локальную запись и проверяете результат через getent hosts $(hostname) и sudo -v. Если проблема возвращается после перезагрузки, ищите внешнее управление hostname.

Это как раз тот случай, где лучше потратить пять минут на аккуратную диагностику, чем потом разбираться, почему в системе снова всплывает странное предупреждение и расходятся имена узлов в автоматизации.