Secure Shell (SSH) is a tool we usually use to manage remote systems. In this guide, we’ll look into a common error message: “ssh: Could not resolve hostname [name]: No such host is known” or “Name or service not known”. This message can show up when trying to connect to a SSH server.
This error isn’t just for Linux users; it happens in Windows too, like in Windows 11 or 10. This could happen when you use SSH clients like PuTTY or the Windows Subsystem for Linux (WSL or WSL2). There are several reasons why you might see this error, and how to fix it depends on your system and setup.
What does the error actually mean?
The error “ssh: Could not resolve hostname [name]: No such host is known” or “Name or service not known” shows up when your SSH client on Windows can’t turn the hostname into a network address. It’s like trying to call someone who isn’t in your phonebook.
This issue often starts with a problem in the Domain Name System (DNS) resolution, where the system fails to connect the easy-to-remember hostname (like “server.example.com“) to its IP address. This could happen for many different reasons, like a typo in the hostname or other bigger network problems (like the server is simply down).
How to correctly connect to an SSH server
Double-check to make sure the hostname is correct
It might sound simple, but typos are a common issue. Make sure the hostname you are trying to connect to is spelled right and is the one you mean to use.
SSH command syntax
Check that your SSH command is set up right. It should look something like ssh username@hostname. A mistake in how you write this command can cause issues, including problems with hostname resolution.
These might seem like simple steps, but they can save you a lot of time if the error is just because of some small human mistakes.
Check the DNS resolution
Use nslookup or ping
You can use tools like nslookup [hostname] or ping [hostname] to check if the hostname turns into an IP address correctly. Just type these in the Command Prompt. If these tools show an IP address, then DNS is working fine for that hostname. If not, you have a DNS problem.
What does DNS do?
DNS is like a phonebook for the internet, turning friendly hostnames into IP addresses. If DNS can’t find the hostname, your SSH client won’t know where to connect.
Check the DNS configuration
Make sure the DNS settings on your computer are set up right. Sometimes, changing to a different DNS server, like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1, can fix these issues.
These checks often help find out if the problem is with DNS resolution, which is a usual suspect behind the “ssh: Could not resolve hostname” error.
Pro tip: DNS Servers to Unblock Websites and Possibly Everything
Check your network connectivity
Also, check your network connection to see if it is the problem that is causing the SSH issues.
- Make sure your devices are actually online. Try opening a website or use
ping 8.8.8.8in Command Prompt to check your connection. - Sometimes, problems come from wrong settings. Check that your network adapter is set up right and there are no IP conflicts or incorrect gateway settings that might be messing up your connection.
- If you’re using a VPN or proxy, it might be messing with your SSH connections. Try turning these off for a while to see if that fixes the problem.
- Try to do a quick restart for your modem, router, or any network switches.
Look at the “hosts” file in Windows
The Windows hosts file can skip DNS and directly link hostnames to IP addresses. A wrong entry (although rare) in this file could be why you’re seeing the “Could not resolve hostname” error in SSH.
- The hosts file is usually at
C:\Windows\System32\drivers\etc\hosts. You’ll need to be an administrator to change this file. - Open the hosts file using a text editor like Notepad, run as an administrator. Check for any lines that have the hostname you’re trying to connect to. If you see a wrong or old IP address linked to this hostname, that might be your problem.
- If there’s a bad entry, you can change it to the right IP address or delete the entry to let DNS handle the hostname normally. Don’t forget to save the file after you make changes.
- Try your SSH connection again after you edit the hosts file to see if that fixed the issue.
Check your firewall and security app
Windows Firewall or other security programs can sometimes block SSH connections and cause the “ssh: Could not resolve hostname: Name or service not known” or “No such host is known” error when you try to connect to a SSH server.
Try to check your Windows Firewall settings. Search for and open “Windows Defender Firewall with Advanced Security” from the Start menu. In the firewall settings, look for any rules that might be blocking outbound SSH connections (typically on port 22). If you find such rules, you can turn them off to test the connection.
If you’re using third-party antivirus or security software, it might have its own firewall or network protection rules. These can also interfere with SSH connections. You can try turning these features off temporarily to see they are the problem. Like with the Windows Firewall, make sure to turn these protections back on after testing.
In both cases, if turning off the firewall fixes the problem, consider adding an exception rule for your SSH connections instead of keeping the firewall turned off.
Related resource: Using PowerShell to Test Port Connection Without Telnet
Use IP addresses directly
Bypassing hostname resolution by using the server’s IP address directly in your SSH command is a simple way to check if DNS resolution is the main problem. Instead of relying on DNS to turn the hostname into an IP, you put the IP address right into your SSH command. This method can quickly show if the problem is with DNS or other parts of the SSH connection process.
To do this, instead of using ssh username@hostname, use ssh username@IP_Address, where IP_Address is the actual IP address of the server you’re trying to connect to. If this works and you get connected, it’s clear that the issue is with DNS resolution for the hostname, not with the SSH server or your client setup.
Might be useful: Using FTP via Command Line (CMD) on Windows 11
Check the SSH client configuration and logs
When you get the “ssh: Could not resolve hostname” error, try to have a look at your SSH client’s settings and logs. These can give you clues on whether the problem is due to wrong settings or other underlying issues.
In Windows, if you’re using a third-party SSH client, make sure it’s set up according to the guide. For the built-in Windows SSH client, check the environment variables and any config files that might affect how it works.
Next, check the SSH client logs. The way to do this can vary depending on the SSH client you’re using. For the built-in Windows client, you can make the output more detailed by adding the -vvv flag to your SSH command, like ssh -vvv username@hostname. This command will show a lot of debug information, which is very helpful for figuring out where the connection process is going wrong.
Example: If the logs show a problem at the point of hostname resolution, this might tell you that it’s likely a DNS issue. If they show a different issue, like a problem with authentication or a timeout, then the main problem lies elsewhere.
It might just be a server-side issue
While we’ve focused on the client side, sometimes you also need to think about the server side, especially if you haven’t solved the problem after trying a lot of things.
- Make sure the SSH server you want to connect to is running and reachable. If you can get to the server some other way, check that the SSH service is active.
- Like on the client side, the server’s firewall can stop incoming SSH connections. Check that the server’s firewall lets connections through on the SSH port (default is 22).
- If the server recently changed its IP address, it might take some time for the new address to spread through the DNS system. This can cause mismatches and connection issues.
- On the server, make sure your user account has the right permissions and that the server is set up to recognize your client correctly, whether through a password or an SSH key.
Looking at these server-side things can help you rule out outside factors that might be causing the “Could not resolve hostname” error.
Version
Microsoft Windows [Version 10.0.19044.1889]
WSL Version
- WSL 2
- WSL 1
Kernel Version
5.10.102.1-microsoft-standard-WSL2
Distro Version
Ubuntu 22.04.1
Other Software
No response
Repro Steps
When I start Terminal I have WSL Ubuntu as default shell, and it autostarts sshd (/etc/init.d/ssh).
I then get an error message complaining about not being able to resolve hostname.
It completes the start and works just fine, but it’s annoying to get an error message on every start and restart of WSL.
The error message only occurs on boot of WSL. Not when restarting sshd when WSL is already running.
If this had been when trying to connect to the sshd, I have found other people suggesting there’s an incorrect — somewhere on the command line, but I am only starting the daemon. I have also gone through all files I can find that are related to sshd, and there are no broken characters what I can see.
Expected Behavior
sshd should just start without the error message.
Actual Behavior
Starting SSH server:
ssh: Could not resolve hostname \342\200\223v: Name or service not known
- Stopping OpenBSD Secure Shell server sshd [ OK ]
- Starting OpenBSD Secure Shell server sshd [ OK ]
$ sudo service ssh status
[sudo] password for MyUser:
- sshd is running
Connecting to it works fine.
$ ssh MyUser@127.0.0.1 -p 22
Welcome to Ubuntu 22.04.1 LTS (GNU/Linux 5.10.102.1-microsoft-standard-WSL2 x86_64)
Diagnostic Logs
No response
SSH stands for secure shell, and it is a security protocol that provides end-to-end encryption of data. SSH could not resolve hostname is an error message that occurs when the host system fails to resolve the IP address of the remote host provided with the ssh command. Ssh protocol is widely used to provide secure remote shell access.
The ssh command is used to connect to a remote host. The ssh command requires a hostname to connect to, which is then inquired from a DNS(Domain Name System) server that sends the IP address of the remote host the user is trying to login to. If, for some reason, if the hostname is not resolved, then the ssh could not resolve the hostname error message is displayed.
Understanding SSH
Secure Shell is an intermediate protocol that is implemented between the application layer and the transport layer of the Internet protocol stack. It works on top of the TCP protocol, ensuring reliable delivery and data integrity. To connect to a remote shell, use the ssh command and provide the username and the hostname of the remote host you are trying to connect. Public key cryptography is used to authenticate the user. The private key is stored in the user’s host, which provides authentication. The ssh could not resolve hostname is one of the common errors faced while using ssh.
SSH hostname resolution and DNS
The hostname provided in the ssh command has to be resolved to an IP address, i.e., the address of the remote host in computer-readable form. The hostname can be provided in the IP address form example, 192.168.43.89, or a name can be used instead of example.com, for example. A DNS server is used to resolve the hostname to an IP address. The string of characters provided as the hostname in the command is sent to the DNS server, which then, in turn, returns the IP address of the host.
If the host is unable to contact the DNS server or the DNS server doesn’t return a valid IP address in return then, ssh could not resolve the hostname error that occurs. The ssh could not resolve hostname can also happen due to the cached DNS data stored in the system. Frequently used Domain name addresses are stored in cache storage in the host system so that the system doesn’t need to enquire the DNS server every time it makes a request. If the cache data is outdated or the host’s IP has been charged, the cached data becomes useless and can cause problems like ssh could not resolve the hostname.
If you are receiving the ssh could not resolve the hostname error, then a few steps can be employed to resolve and avoid this error message. Consider the given steps to fix the ssh could not resolve the hostname error.
Check the hostname
Most of the basic and simple measures to avoid the ssh could not resolve hostname is to check whether the hostname you are using with the ssh command is correct or not. Using the wrong hostname or domain address might result in a Wrong DNS response or no valid response at all. Check your hostname address for typos and syntax errors of the command. If everything is correct but still getting the hostname does not resolve the error, then employ the following measures.
Clearing DNS Cache
Clearing the DNS cache might also help resolve the ssh could not fix the hostname error. After the DNS cached data is deleted, a new fresh DNS inquiry is sent to the DNS server for each request, which would be beneficial if the IP address of the host is changed. Follow the given steps to clear the DNS cache in Windows.
- Press Windows + R.
- Enter cmd in the serach box and hit enter.
- In the shell Enter the command ipconfig /flushdns.
- The DNS cache is not cleared.
- Try running the ssh command again.
For Ubuntu users, Enter the following command in the terminal to clear the DNS cache manually.
Editing the /etc/hosts file
If you are trying to connect to a remote host using ssh for the first time and getting a hostname error not resolved error in return, try editing the ssh hosts file and entering the username and hostname in the file. Employing the given steps to edit the hosts’ file and fix the ssh could not resolve the hostname error.
- Open the terminal emulator.
- Enter sudo nano /etc/hosts.
- Enter your root password.
- Now in the file, enter the IP address and hostname of your remote host.
- Press ctrl + O to save the file.
- Press ctrl + X to exit nano.
- Run the ssh command again.
SSh could not resolve hostname github.com
The ssh could not resolve hostname error can also show up while using the git version management program. The git uses the ssh while cloning a repository or pushing a remote repository. The issue can be fixed with the following steps.
- Try to ping the github.com using the ping github.com command. If the server responds then try to run the git command again after rebooting the system, it might be a normal network issue.
- If the issue persists, follow the steps mentioned above, such as clearing the DNS cache.
- Run the following command to restart the network manager in linux, which might help resolve the issue.
sudo service network-manager restartSSH could not resolve hostname Gitlab
Gitlab is another popular open-source platform that is widely used in DevOps operations. “ssh: Could not resolve hostname gitlab.example.com: Temporary failure in name resolution” is the error message that is displayed while logging into the GitLab server. As the message itself suggests, this is a temporary failure in the name resolution, and chances would be resolved automatically after some time. But if the problem persists, follow the steps suggested above to make it work. You could also try adding ssh:// before the git URL to resolve the hostname issue.
git clone ssh://[email protected]:username/This_is_a_demo.gitSSH could not resolve hostname Gitbucket.org
Bitbucket is another open platform used to host git repositories online. The same hostname resolution problem can be encountered with gitbucket.org as with github.com. To resolve this issue, use the suggested methods and configure your .git config file. Open the config file in the .git folder for your project’s main directory. Change the remote directory listing as mentioned below (remove the ssh:// in the config file) and rerun the command.
url = ssh://[email protected]
//before
url = [email protected]
//afterFAQs on SSH Could Not Resolve Hostname
What is TCP?
It stands for Transfer Control Protocol. It is a transport layer protocol that ensures the reliable hosts-to-host delivery of the data packets.
What is the difference between git and GitHub?
Git is a version management program that keeps track of the changes in a project, While GitHub is an online platform where people can share their git repositories.
What is the Linux equivalent of ipconfig?
The Linux equivalent of the ipconfig command is ifconfig.
Conclusion
The ssh could not resolve hostname is a common error that any user can face. It is not that big of an issue. It simply happens when the ssh command fails to resolve the IP address of the provided hostname. In such situations clearing the DNS cache or editing the /etc/host file can help. This article provided you with the necessary measure and solutions to fix this error. In the end, we also mentioned what to do if you are receiving this error while using the git CLI.
Trending Now
-
The Best Popup Builders in 2025: Boost Engagement and Conversions
●February 22, 2025
-
Fixing Xtools XToolkit Installation Error
by Dharam Nath Jha●March 3, 2023
-
Troubleshoot DeepMotion Preview Not Working: Tips and Tricks
by Dharam Nath Jha●March 3, 2023
-
Getting Virtwifi has No Internet Access? Here’s What to Do!
by Dharam Nath Jha●February 16, 2023
25 мая, 2017 11:40 дп
93 893 views
| Комментариев нет
Linux, SSH
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:
- Ошибки протокола: в этой статье вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
- Ошибки аутентификации: поможет устранить проблемы с парольной аутентификацией или сбросом SSH-ключей.
- Ошибки оболочки: это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.
Для взаимодействия SSH-клиента с SSH-сервером необходимо установить базовое сетевое подключение. Это руководство поможет определить некоторые общие ошибки подключения, исправить их и предотвратить их возникновение в будущем.
Требования
- Убедитесь, что можете подключиться к виртуальному серверу через консоль.
- Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.
Основные ошибки
Разрешение имени хоста
Большинство ошибок подключения возникает тогда, когда ссылка на хост SSH не может быть сопоставлена с сетевым адресом. Это почти всегда связано с DNS, но первопричина часто бывает не связана с DNS.
На клиенте OpenSSH эта команда:
ssh user@example.com
может выдать ошибку:
ssh: Could not resolve hostname example.com: Name or service not known
В PuTTY может появиться такая ошибка:
Unable to open connection to example.com Host does not exist
Чтобы устранить эту ошибку, можно попробовать следующее:
- Проверьте правильность написания имени хоста.
- Убедитесь, что вы можете разрешить имя хоста на клиентской машине с помощью команды ping. Обратитесь к сторонним сайтам (WhatsMyDns.net, например), чтобы подтвердить результаты.
Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:
ssh user@111.111.111.111
# вместо
ssh user@example.com.
Истечение времени соединения
Эта ошибка значит, что клиент попытался установить соединение с SSH-сервером, но сервер не смог ответить в течение заданного периода ожидания.
На клиенте OpenSSH следующая команда:
ssh user@111.111.111.111
выдаст такую ошибку:
ssh: connect to host 111.111.111.111 port 22: Connection timed out
В PuTTY ошибка выглядит так:
Network error: Connection timed out
Чтобы исправить ошибку:
- Убедитесь, что IP-адрес хоста указан правильно.
- Убедитесь, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт. Это поможет вам определить, не связана ли проблема с самим сервером.
- Проверьте правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP.
Отказ в соединении
Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.
На клиенте OpenSSH следующая команда выдаст ошибку:
ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused
В PuTTY ошибка появится в диалоговом окне:
Network error: Connection refused
Эта ошибка имеет общие с ошибкой Connection Timeout причины. Чтобы исправить её, можно сделать следующее:
- Убедиться, что IP-адрес хоста указан правильно.
- Убедиться, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт.
- Проверить правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP, и что брандмауэр не блокирует этот порт.
- Убедиться, что сервис запущен и привязан к требуемому порту.
Рекомендации по исправлению ошибок подключения
Брандмауэр
Иногда проблемы с подключением возникают из-за брандмауэра. Он может блокировать отдельные порты или сервисы.
Читайте также: Что такое брандмауэр и как он работает?
В разных дистрибутивах используются разные брандмауэры. Вы должны научиться изменять правила и политики своего брандмауэра. В Ubuntu обычно используется UFW, в CentOS – FirewallD. Брандмауэр iptables используется независимо от системы.
Читайте также:
- Основы UFW: общие правила и команды фаервола
- Настройка брандмауэра FirewallD в CentOS 7
- Основы Iptables: общие правила и команды брандмауэра
Чтобы настроить брандмауэр, нужно знать порт сервиса SSH. По умолчанию это порт 22.
Чтобы запросить список правил iptables, введите:
iptables -nL
Такой вывод сообщает, что правил, блокирующих SSH, нет:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Если в выводе вы видите правило или политику по умолчанию REJECT или DROP, убедитесь, что цепочка INPUT разрешает доступ к порту SSH.
Чтобы запросить список правил FirewallD, введите:
firewall-cmd --list-services
Список, появившийся на экране, содержит все сервисы, которые поддерживаются брандмауэром. В списке должно быть правило:
dhcpv6-client http ssh
Если вы настроили пользовательский порт SSH, используйте опцию –list-ports. Если вы создали пользовательское определение сервиса, добавьте опцию –list-services, чтобы найти SSH.
Чтобы проверить состояние UFW, введите:
ufw status
Команда вернёт доступные порты:
Status: active
To Action From
-- ------ ----
22 LIMIT Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
Anywhere ALLOW 192.168.0.0
22 (v6) LIMIT Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
В списке должен быть порт SSH.
Проверка состояния сервиса SSH
Если вы не можете подключиться к серверу по SSH, убедитесь, что сервис SSH запущен. Способ сделать это зависит от операционной системы сервера. В более старых версиях дистрибутивов (Ubuntu 14.04, CentOS 6, Debian 
используется команда service. Современные дистрибутивы на основе Systemd используют команду systemctl.
Метод проверки состояния сервиса может варьироваться от системы к системе. В более старых версиях (Ubuntu 14 и ниже, CentOS 6, Debian 6) используется команда service, поддерживаемая системой инициализации Upstart, а в более современных дистрибутивах для управления сервисом используется команда systemctl.
Примечание: В дистрибутивах Red Hat (CentOS и Fedora) сервис называется sshd, а в Debian и Ubuntu – ssh.
В более старых версия используйте команду:
service ssh status
Если процесс работает должным образом, вы увидите вывод, который содержит PID:
ssh start/running, process 1262
Если сервис не работает, вы увидите:
ssh stop/waiting
В системах на основе SystemD используйте:
systemctl status sshd
В выводе должна быть строка active:
sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Mon 2017-03-20 11:00:22 EDT; 1 months 1 days ago
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (sshd)
CGroup: /system.slice/sshd.service
├─ 906 /usr/sbin/sshd -D
├─26941 sshd: [accepted]
└─26942 sshd: [net]
Если сервис не работает, вы увидите в выводе inactive:
sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: inactive (dead) since Fri 2017-04-21 08:36:13 EDT; 2s ago
Process: 906 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 906 (code=exited, status=0/SUCCESS)
Чтобы перезапустить сервис, введите соответственно:
service ssh start
systemctl start sshd
Проверка порта SSH
Существует два основных способа проверить порт SSH: проверить конфигурационный файл SSH или просмотреть запущенный процесс.
Как правило, конфигурационный файл SSH хранится в /etc/ssh/sshd_config. Стандартный порт 22 может переопределяться любой строкой в этом файле, определяющей директиву Port.
Запустите поиск по файлу с помощью команды:
grep Port /etc/ssh/sshd_config
Читайте также: Использование Grep и регулярных выражений для поиска текстовых шаблонов в Linux
Команда вернёт:
Port 22
Если вы уже убедились, что сервис работает, теперь вы можете узнать, работает ли он на требуемом порте. Для этого используйте команду ss. Команда netstat –plnt выдаст аналогичный результат, но команду ss рекомендуется использовать для запроса информации сокета из ядра.
ss -plnt
В выводе должно быть указано имя программы и порт, который она прослушивает. Например, следующий вывод сообщает, что сервис SSH прослушивает все интерфейсы и порт 22.
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:22 *:* users:(("sshd",pid=1493,fd=3))
LISTEN 0 128 :::22 :::* users:(("sshd",pid=1493,fd=4))
Символ * и 0.0.0.0 указывает, что все интерфейсы сервера прослушиваются. Строка 127.0.0.1 значит, что сервис не является общедоступным. В sshd_config директива ListenAddress должна быть закомментирована, чтобы прослушивать все интерфейсы, или должна содержать внешний IP-адрес сервера.
Если у вас не получается самостоятельно настроить соединение SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
Tags: firewalld, Iptables, OpenSSH, PuTTY, SSH, UFW
If you’ve been getting the error message “ssh: Could not resolve hostname Name or service not known,” don’t worry, you’re not alone.
The error message “ssh: Could not resolve hostname [name]: Name or service not known” indicates that the SSH client is unable to resolve the hostname of the remote server you are trying to connect to. This can happen for several reasons:
- Typo in the hostname: Double-check that you have entered the correct hostname or IP address. A simple typo in the hostname can lead to this error.
- DNS resolution issue: If the hostname is not in your local DNS cache or not present in the DNS server you are using, the resolution may fail. Ensure that the hostname can be resolved using DNS.
- Network connectivity issue: If you are trying to connect to a remote server, there might be a network connectivity problem preventing the DNS resolution. Check your internet connection and ensure that the remote server is accessible.
- Firewall or security restrictions: Firewall rules or security settings on your system or network may be blocking the DNS resolution or SSH connection.
- SSH configuration: Incorrect settings in your SSH client configuration file (usually located at ~/.ssh/config) could also cause this error.
In this blog post, we will discuss five ways to fix the ssh error message.
Get Your Free Linux training!
Join our free Linux training and discover the power of open-source technology. Enhance your skills and boost your career!
Start Learning Linux today — Free!
We will also provide instructions on how to troubleshoot this problem if it persists.
Table of Contents
How to fix ssh: Could not resolve hostname Name or service not known
- Check your ssh command syntax and make sure you type your command correctly.
- Check your hostname exists in DNS and make sure the hostname can be resolved to the correct IP address.
- Update your /etc/hosts file with an entry mapping the IP address of the server if necessary
Check your ssh command syntax
ssh is a secure shell client command used to connect to remote servers. The most basic syntax for the ssh command is:
ssh [options] user@server_hostname
or
ssh [options] user@ip_address
The user name is the name of the user you are logging in as, and the server name is the hostname or IP address of the remote server.
For example,
if the server hostname is “example.com” and your user name on the server is “admin”, you would enter:
ssh [email protected]
If you use the following command, you will get an error.
ssh admin@server example.com
ssh: Could not resolve hostname server: Name or service not known
ssh command also supports different options. These options allow you to set up the connection in different ways.
For example, if you’re trying to establish an SSH connection from a Windows machine, then you could use the -p option to specify the port number for the server.
For example:
ssh -p 33 [email protected]
If you need to use a private key in the ssh command, then use the -i option to specify the path to your private key.
For example:
ssh -i /path/to/private_key [email protected]
You can also mix these options like StrictHostKeyChecking together like the following example. Make sure you use the correct ssh command.
ssh -i bastion_dev.pem -o StrictHostKeyChecking=no -o ServerAliveInterval=30 [email protected]
Check your hostname and DNS record
If your syntax is correct, we need to check to make sure that the DNS record for your hostname is set up correctly, and if necessary try using the IP address of the server instead of its hostname.
We can use some commands like ping, dig, or nslookup to check the hostname and make sure that your hostname can be resolved by the DNS server.
For example, to check the hostname with the ping command:
ping example.com
If we get a response from this command, it means the DNS server is able to resolve the hostname, and your problem may be related to other factors.
We can also use nslookup or dig command to get more detailed information.
For example:
nslookup example.com
or
dig example.com
If these commands return errors related to the DNS server, then you may need to contact your ISP or hosting provider to help solve the problem.
Check Network connectivity
Here are some steps you can take to check and troubleshoot network connectivity issues:
- Verify Physical Connections:
- Check if all network cables are properly connected and secure.
- Ensure network devices like routers, switches, and modems are powered on and functioning.
- Check Network Interface Status:
- Use the ifconfig or ip addr show command to view the status of network interfaces.
- Ensure the network interface is UP and has an assigned IP address.
- Test DNS Resolution:
- Use the ping command to test DNS resolution (e.g., ping google.com).
- If DNS resolution fails, check the DNS server configuration in /etc/resolv.conf.
- Test Connectivity to Gateway:
- Use the ping command to check if you can reach the default gateway (e.g., ping 192.168.1.1).
- If the gateway is unreachable, there might be an issue with your local network setup.
Update your /etc/hosts file
If the hostname still can’t be resolved, you can try adding an entry in your local machine’s /etc/hosts file mapping the IP address of the server to its hostname.
For example, if the IP address of the server is 192.168.1.100, you would add the following line to your /etc/hosts file:
192.168 .1 .100 example.com
Save the file and try connecting again with ssh command. If it works then you know that the problem is related to your DNS server.
Check your ssh configuration file
Here are some potential issues in the SSH client configuration file that can trigger the error:
- Typo in Hostname: Double-check that the hostname specified in the configuration file is correct and matches the actual remote server’s hostname or IP address.
- Incorrect Host Alias: If you have defined a host alias in the configuration file, ensure it is accurately specified and corresponds to the intended server.
- Inconsistent Hostname: Make sure there are no duplicate entries for the same hostname in the configuration file. This could lead to ambiguity and result in connection problems.
- Invalid Configuration Syntax: Review the entire configuration file for any syntax errors, missing or extra characters, and ensure each option is properly formatted.
To troubleshoot SSH client configuration issues:
- Open the SSH client configuration file in a text editor (e.g., nano ~/.ssh/config).
- Check for any mistakes, typos, or inconsistencies in the configuration.
- Comment out any suspicious lines or host entries to see if the error persists.
- Use the SSH command without relying on the configuration file (e.g., ssh user@hostname) to see if the issue is related to the configuration.
- If the issue is resolved, gradually reintroduce entries from the configuration file, verifying each addition to identify the problematic entry.
If you are still having trouble, check any firewalls or proxy servers that may be blocking access to the server and make sure they are configured correctly. If all else fails, contact the server’s administrator for assistance.