Check host file linux

Is it possible to find out the hosts in the known_hosts file?

I would like to see what hosts are in my known_hosts file but it doesn’t appear to be human readable. Is it possible to read it? More specifically there is a host that I can connect to via several names and I want to find out what the fingerprint I expect for it from my known hosts file. Update: I’m using OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009 A line from my known_hosts file looks something like this,

|1|guO7PbLLb5FWIpxNZHF03ESTTKg=|r002DA8L2JUYRVykUh7jcVUHeYE= ssh-rsa AAAAB3NzaC1yc2EAAFADAQABAAABAQDWp73ulfigmbbzif051okmDMh5yZt/DlZnsx3DEOYHu3Nu/+THJnUAfkfEc1XkOFiFgbUyK/08Ty0K6ExUaffb1ERfXXyyp63rpCTHOPonSrnK7adl7YoPDd4BcIUZd1Dk7HtuShMmuk4l83X623cr9exbfm+DRaeyFNMFSEkMzztBYIkhpA2DWlDkd90OfVAvyoOrJPxztmIZR82qu/5t2z58sJ6Jm2xdp2ckySgXulq6S4k+hnnGuz2p1klviYCWGJMZfyAB+V+MTjGGD/cj0SkL5v/sa/Fie1zcv1SLs466x3H0kMllz6gAk0/FMi7eULspwnIp65g45qUAL3Oj 

5 Answers 5

You’ve got HashKnownHosts set to » yes » in your ssh_config file, so the hostnames aren’t available in plaintext.

If you know the hostname you’re looking for ahead of time, you can search for it with:

ssh-keygen -H -F hostname # Or, if SSH runs on port other than 22. Use literal brackets []. ssh-keygen -H -F '[hostname]:2222' 

Here’s the relevant section from the ssh-keygen(1) man page:

-F hostname

Search for the specified hostname in a known_hosts file, listing any occurrences found. This option is useful to find hashed host names or addresses and may also be used in conjunction with the -H option to print found keys in a hashed format.

Does hash known hosts essentially mean it’s not possible? i.e. I need to know the name of the host in order to look at it’s info?

@ColinNewell That’s right, you need to know the hostname(s). It’s a security measure to keep an attacker from harvesting hostnames/IP addresses of other boxes you frequent if your machine is compromised.

@pdo — your command does not always work. If the host has SSH on port other than 22 , then the format in known_hosts is different. Then you have to use the following command: ssh-keygen -H -F [host.example.com]:2222

I wanted to find the rsa key for a specific host, so I ran this: ssh-keygen -l -f ~/.ssh/known_hosts -F

For future searchers, this article (non-disclaimer: I’m not affilated) has a relatively simple Perl script to brute-force hashed IPs and hostnames in known_hosts .

It allows starting from a particular IP address. It could also easily be modified to use a dictionary.

Also, in June 2014, the John the Ripper project added support for known_hosts cracking, which can take advantage of multiple CPU cores, GPUs, dictionary mangling, etc.

Overall, it’s an exercise similar to password cracking, with a somewhat more predictable (or at least constrained) target space.

For private IPs, you can use this nmap snippet to generate a dictionary of all RFC1918 IP addresses to use as a dictionary:

nmap -sL -Pn -n 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 |\ grep '^Nmap scan report for' | cut -d\ -f5 >ips.list 

If public IPs are included, it may be more efficient to use rules. This hashcat ruleset may need additional work to adapt to work with JtR, but does most of the heavy lifting and should give you a starting point.

Hostnames are more idiosyncratic to the user and environment, but there are trends in host naming. Fully qualified hostnames can be correlated in DNS, /etc/hosts, shell history, etc. with any discovered IP addresses. Since destination systems can be entirely unrelated to the host system, public dumps of common domains and hostnames can be acquired from the DNS data from various Internet-wide scanning efforts (such as Censys).

Using John the Ripper is likely to be more efficient and scale better than the native SSH solution in the accepted answer for all but the most simple cases.

Источник

Audit your /etc/hosts file

The /etc/hosts file is one of the few files you will always find on a Linux system. It stores the ‘hosts’ database, and can be used to resolve between IP addresses and hostnames. Although the file is very simple structured, it is still common to see minor issues with name resolving on systems. Guess what, your /etc/hosts file might be causing more trouble than you think. A regular check up won’t hurt.

Order matters in name resolving

Linux systems have a library called Name Service Switch. It defines the databases for resolving between identities and names. Not just between hostnames and IP addresses, but also your user accounts. Knowing a little bit more about this library is good to know, especially when working both IPv4 and IPv6 addresses and the combination of local files and DNS.

The first step is knowing how the system determines where to look when it wants to do some name resolving. We use the /etc/nsswitch.conf file for this.

This file shows for each database type what order it will use and what specific query mechanism. For our hosts database we see it queries first the applicable files, then uses DNS. This is good to know, as we can leverage to overrule hardening with the /etc/hosts file.

Please note that some tools will not adhere to this order. Tools like host and dig are meant to query data via DNS. Querying the ‘hardening’ hostname, which is listed in /etc/hosts, will still result in an error:

Host hardening not found: 3(NXDOMAIN)

If you want to validate how resolving is performed by a tool, use the strace command:

Give it a go and see if you can find /etc/hosts in your output (we can’t).

The hosts database

The hosts database is formed by the /etc/hosts file. We can query it in two ways:

The first option is easy, as we can use the cat command for that.

The second command is less familiar, yet always available as well.

Both will query (or show) what is in the hosts database. While this might have the same goal, the output might surprisingly be different.

In this screenshot we see the last two lines missing from the getent command output. This is because they are not normal hosts. They can be compared to broadcast addresses in IPv4, with ip6-allnodes for all systems (including routers), the ip6-allrouters for just the routers in the network segment.

What can be wrong with /etc/hosts?

Although the /etc/hosts file is a simple structured file, there are a few things that should be checked. So next time you are on a system, become an IT auditor and check the following parts:

Your hosts file is not a DNS replacement

If you have added more than 10 systems to your /etc/hosts file you may consider moving that to a separate DNS zone. Even if it is for internal usage, name translation is perfectly performed by DNS. Add your internal zone to your name servers for optimal caching and easy of management. Even if you use configuration management tools like Ansible or Puppet, your host file should not be storing many entries.

Using your local hosts files may also have the risk of introducing unexpected behavior when some system name is reused for example. If you truly only use some entries for temporarily testing, then the hosts file can be a great option. From experience we can say that temporary often results in permanent (on purpose, but more often by accident). So try to be disciplined and avoid changing the hosts file and keep your systems tidy.

No FQDN provided

Still many Linux installations are not properly configured when it comes to the domain name. Even if you provided it during the installation process, it may not have been propagated to the /etc/hosts file. The so-called Fully Qualify Domain Name (FQDN) defines the hostname + domain.

You can easily check if your Linux system is properly configured by using the hostname command.

No output of this command means there is not hostname configured. In that case change your hosts file into this format

One typical error is that the last two are reversed. The longest match, which is the FQDN, should be at the front to get it working.

Localhost mapping

The localhost entry defines the local system. It should always map against 127.0.0.1 or ::1 (IPv6) to prevent issues. To check this, use the getent utility.

The other way around should be return at least localhost, with optional some aliases.

Conclusion

The /etc/hosts file is used on Linux to support local name resolving. The file itself should remain as small as possible, so the remaining entries can do their job. One of them is resolving the localhost entry back to 127.0.0.1 (IPv4) or ::1 (IPv6). The other purpose is to define the domain name of the system, to properly form the fully qualified domain name (FQDN).

Want to test these things automatically for all systems? Then check out Lynis, as it has built-in tests for that (and much more).

One more thing.

Keep learning

So you are interested in Linux security? Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become (or stay) a Linux security expert.

Security scanning with Lynis and Lynis Enterprise

Run automated security scans and increase your defenses. Lynis is an open source security tool to perform in-depth audits. It helps with system hardening, vulnerability discovery, and compliance.

Continue reading

Источник

How to test /etc/hosts

What’s the best way to confirm that your /etc/hosts file is mapping a hostname to the correct IP address? Using a tool like dig queries an external DNS directly, bypassing the hosts file.

@mdpc I edited it to reflect that. Basically the same question though, I was just looking for a way to verify the hosts file entry is working.

3 Answers 3

I tried this out and it seems to work as expected:

echo «1.2.3.4 facebook.com» >> /etc/hosts

$ getent ahosts facebook.com 1.2.3.4 STREAM facebook.com 1.2.3.4 DGRAM 1.2.3.4 RA 

looks good, thanks! I also found that ping works: ping facebook.com outputs: PING facebook.com (1.2.3.4) 56(84) bytes of data.

I found gethostip which accepts either hostname or IP and also has options suitable to print out exactly what you need.

$ gethostip -d facebook 1.2.3.4 

You can use the ‘ping’ command to check the values added in /etc/hosts are working fine or not.

echo "1.1.1.1 abc.com" >> /etc/hosts ping abc.com 

You must log in to answer this question.

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.14.43533

Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group.
This site is not affiliated with Linus Torvalds or The Open Group in any way.

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник