Локальный пользователь CentOS, который не в состоянии просмотреть каталоги/файлы через вход в систему FTP

Особенный (и AFAICT) немного под - зарегистрированное поведение в iputils ping: Вы проверяете с помощью ping-запросов себя.

Если Вы ping 0 это - то, что происходит (в большой степени отредактированный и прокомментированный для ясности):

if (inet_aton(target, &whereto.sin_addr)) == 1) {
    // convert string to binary in_addr
}
// inet_aton returns 1 (success) and leaves the `in_addr` contents all zero.

if (source.sin_addr.s_addr == 0) {    
    // determine IP address of src interface, via UDP connect(), getsockname()
}

// special case for 0 dst address
if (whereto.sin_addr.s_addr == 0)
        whereto.sin_addr.s_addr = source.sin_addr.s_addr;

inet_aton() не POSIX, но я предполагаю, что он копирует поведение inet_addr() когда меньше чем 4 точечных десятичных числа преобразовываются. В случае точечного меньше единственного числа это просто хранится в двоичный сетевой адрес, и 0x00000000 эквивалентно точечной форме 0.0.0.0.

Вы видите это если Вы strace (как корень):

# strace -e trace=network ping  0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025), 
    sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(58056),   
    sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
...
PING 0 (127.0.0.1) 56(84) bytes of data.

Можно также видеть изменение, если Вы связываете с определенным интерфейсом вместо этого:

# strace -e trace=network ping -I eth0  0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
setsockopt(4, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0", 5) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(1025), 
    sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(58408),    
    sin_addr=inet_addr("192.168.0.123")}, [16]) = 0
setsockopt(3, SOL_RAW, ICMP_FILTER,  ...)
[...]
PING 0 (192.168.0.123) from 192.168.0.123 eth0: 56(84) bytes of data.

В то время как 0 может рассматриваться как 0.0.0.0 и широковещательный адрес во многих случаях, это ясно не, что делает ping. Это особые случаи это для значения "основного IP рассматриваемого интерфейса" (с некоторой дополнительной обработкой для случаев многоадресной передачи/широковещательной передачи).

RFC 1122 §3.2.1.3 объясняет поведение: и 0.0.0.0 и IP-адрес с сетью, замаскированной прочь ("номер узла", например, 0.0.0.1 в случае обратной петли), означают "этот хост в этой сети".

       (a)  { 0, 0 }

            This host on this network.  MUST NOT be sent, except as
            a source address as part of an initialization procedure
            by which the host learns its own IP address.

            See also Section 3.3.6 for a non-standard use of {0,0}.

       (b)  { 0,  }

            Specified host on this network.  It MUST NOT be sent,
            except as a source address as part of an initialization
            procedure by which the host learns its full IP address.

По крайней мере, в случае 0 или 0.0.0.0, именно так iputils ping ведет себя, другие ping и другое OSs могут вести себя по-другому. Например, FreeBSD проверяет с помощью ping-запросов 0.0.0.0 через маршрут по умолчанию (который я не думаю, "корректное" поведение).

ping 1 или 0.0.0.1 не вполне работайте, как надеялся хотя (не для меня так или иначе, iputils-sss20101006).