nc (netcat) в Mac OS X 10.8.4 зависает

Я столкнулся с небольшой проблемой при использовании утилиты nc в Mac OS X, утилиты, которую я часто использую в качестве быстрого и грязного решения, чтобы проверить, открыт ли порт и какая версия запущена демоном.

На днях мы развернули новый набор компьютеров, и я хотел проверить, какая версия sshd на них работает, не вставая со стула.

Это команда, которую я выполнил, и результат:

$ for i in {183..200}; do echo "hello" | nc -n -w 2 -v 10.120.113.$i 22; done
Connection to 10.120.113.183 22 port [tcp/*] succeeded!
SSH-2.0-OpenSSH_5.9
Protocol mismatch.
nc: connect to 10.120.113.184 port 22 (tcp) failed: Connection refused
^C
$

Он находит первую машину на 183 и возвращает версию демона, это не похоже на то, что sshd работает на 184, но когда он достигает 185, он просто останавливается, и я должен убить его с помощью Ctrl + C.

Как я понял, справочная страница для nc должна истечь по времени при использовании переключателя «-w», но это не так. Такая же проблема с нескольких машин.

Это просто случай, когда я неправильно понимаю справочную страницу? Есть ли другой способ сделать nc тайм-аутом через X секунд, если вы не получили никакого ответа? Есть ли другой способ сделать это с помощью встроенных инструментов Mac OS X?

Я также пытался запустить nc только с ключом '-z' с теми же результатами. Машины размещены в нашем производстве, поэтому мне не разрешено устанавливать какие-либо сторонние приложения, такие как nmap.

Platform: Mac OS X 10.8.4
Executable: /usr/bin/nc

Извините, если на этот вопрос уже был дан ответ, я искал, но не нашел решения.


person ZombieNinjaPirate    schedule 02.09.2013    source источник
comment
Я думаю, что это ошибка в nc на Mac. У меня есть Йосемити. Когда я сравниваю одну и ту же команду в Linux для проксирования DNS, Linux возвращает ответ снова и снова, как и должно быть. На Mac он возвращает первый ответ, а затем застревает, потому что я предполагаю, что он не видит конца передачи. Убедитесь сами с помощью mkfifo /tmp/fifo; nc -lu 127.0.0.1 53 < /tmp/fifo | nc -u 8.8.4.4 53 > /tmp/fifo, а затем в другом окне терминала выполните nslookup example.com 127.0.0.1 более одного раза.   -  person Volomike    schedule 31.08.2015


Ответы (2)


Я полагаю, что вы ищете вариант -G. Из справочных страниц:

-G conntimeout Время ожидания соединения TCP в секундах.

-w используется для установки времени ожидания после соединения. Параметр -G используется для установки времени ожидания перед подключением. Это должно дать вам то, что вы хотите

nc -n -G 2 -v xxx.xxx.xxx.xxx 22
person Kevin Burdett    schedule 01.02.2016

Я попробовал это на своем Mac под управлением 10.8.4, и примерно через 6 минут это выглядело так:

andys-MacBook-Pro:EquipDB uw$ for i in {183..200}; do echo "hello" | nc -n -w 2 -v 10.120.113.$i 22; done
nc: connect to 10.120.113.183 port 22 (tcp) failed: Operation timed out
nc: connect to 10.120.113.184 port 22 (tcp) failed: Operation timed out
nc: connect to 10.120.113.185 port 22 (tcp) failed: Operation timed out
nc: connect to 10.120.113.185 port 22 (tcp) failed: Operation timed out

Так что у меня истекает время, но это занимает довольно много времени.

Хммм... думал, что мой тест будет бессмысленным, потому что я никогда не буду подключаться к чему-либо, так как я не в вашей сети. Но я видел это:

-w # =› Тайм-аут через # секунд

Обратите внимание, что -w также устанавливает тайм-аут бездействия сети. Это не имеет никакого эффекта, пока стандартный ввод не закроется, но затем, если в течение следующих секунд из сети больше ничего не поступит, netcat попытается прочесть сеть еще раз для верности, а затем закроется и выйдет. В настоящее время существует множество сетевых служб, которые принимают небольшое количество входных данных и возвращают большое количество выходных данных, таких как Gopher и веб-серверы, что является основной причиной, по которой netcat был написан так, чтобы «блокировать» сеть, оставаясь открытой, а не чем стандартный ввод. Такая обработка тайм-аута дает единообразное поведение сетевых серверов, которые не закрываются сами по себе, пока об этом не будет сообщено.

Это работает для окончательного сетевого чтения, но не для соединений.

Если я правильно понимаю, время ожидания истекает только после подключения, поскольку мой никогда не подключается, у него просто есть встроенный тайм-аут, который не имеет ничего общего с -w? нашел здесь, полезно?

person Beartech    schedule 02.09.2013
comment
Спасибо за ответ. Я заметил то же самое, кажется, что nc истекает по тайм-ауту примерно через ок. 90сек. Я предполагаю, что теперь вопрос заключается в том, есть ли способ заставить nc истечь меньше времени, чем это. - person ZombieNinjaPirate; 02.09.2013
comment
Решил написать небольшой скрипт, который обновляет кеш arp на моем клиенте перед проверкой открытых портов/версий сервисов, это предоставит мне список используемых IP-адресов. В дополнение к этому я выпущу обновленную версию пользовательского сценария запуска, который не позволит пользователям отключать sshd через Системные настройки. Это должно предотвратить подключение nc к несуществующим IP-адресам и клиентам с отключенным sshd. Я знаю, что на самом деле это не решит проблему, но я очень ценю ваши отзывы, спасибо Beartech! - person ZombieNinjaPirate; 03.09.2013