My usecase is that I manage remote computers using reverse SSH tunneling. This works great as our customer enable the tunnel and I can then log on using it.
However, on one machine the tunneling stopped working.
ssh -fN -R 9999:localhost:22 user@host
After a lot of troubleshooting it turned out that using 127.0.0.1 instead of localhost did still work.
ssh -fN -R 9999:127.0.0.1:22 user@host
So, when connected to the target machine I noticed that eve more things did not work with localhost. For example ping.
ping -v localhost
ping: socket: Permission denied, attempting raw socket...
ping: socket: Permission denied, attempting raw socket...
ping: localhost: System error
While using 127.0.0.1 does work
ping -v 127.0.0.1
ping: socket: Permission denied, attempting raw socket...
ping: socket: Permission denied, attempting raw socket...
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.022 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.017 ms
sshd gave me equally useless error messages
error: connect_to localhost: unknown host (Bad file descriptor)
error: connect_to localhost: unknown host (Bad file descriptor)
error: connect_to localhost: unknown host (System error)
error: connect_to localhost: unknown host (System error)
Naturally I looked to the /etc/hosts file. But it looks ok to me.
cat /etc/hosts
#
# /etc/hosts: static lookup table for host names
#
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost
# End of file
Also, the lookup in the hosts file does work to some degree at least. Because trying for example ping localhostq gives me the usual "unknown host" reply.
Running arch linux on target machine. Up to date as of 2016-06-23 (also another similar computer with the exact same arch version does not have this problem).
EDIT (2016-06-23 15:30):
Iptables (very relaxed atm)
sudo iptables -L
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
Not using nftables at all.
Hosts from /etc/nsswitch.conf:
cat /etc/nsswitch.conf | grep hosts
hosts: = files mdns4_minimal [NOTFOUND=return] dns mdns4
[РЕДАКТИРОВАТЬ: 2016-06-23 15:45] На самом деле, на машине, которая действительно работает, у меня есть следующее:
cat /etc/nsswitch.conf | grep hosts
hosts: files dns myhostname
Очень удивлен, увидев, что строки различаются, так как этот файл я не изменял. Я также не знаю, что это означает:)
Оказалось, что это файл / etc / nsswitch
Видите проблему?
cat /etc/nsswitch.conf | grep hosts
hosts: = files mdns4_minimal [NOTFOUND=return] dns mdns4
Знак '=' в скрипте неверен. Это было сделано в нашем специальном пакете (написанном не мной, виноват распределение FTW!). который просто не был установлен на тот, который работал, но был установлен на тот, который не работал.
Теперь я могу исправить пакет (используемый для автоматической настройки avahi), и все должно вернуться в нормальное состояние.
Многие Большое спасибо всем, кто задавал дополнительные вопросы. Особенно @ 7171u, который правильно спросил :)