Вопросы Теги

Тестирование подключения к удаленному хосту с помощью telnet

Независимо от того, является ли параметр глобальным или локальным, является свойством параметра, а не тем, что вы можете контролировать . В документации есть два отдельных списка опций: первый - это список глобальных опций, второй - список локальных опций. Глобальные параметры включают такие параметры, как asis , accept_color и т. Д. И влияют на общее поведение редактора ( например , поддержка цвета вашим терминалом не зависит от файл, который вы редактируете). Локальные параметры включают автоотступ , кодировку и т. Д. И могут быть установлены автоматически в зависимости от расширения файла.

Я не вижу способа применить локальный параметр ко всем файлам в командной строке, кроме использования расширения оболочки.

1
15.03.2017, 17:39
3 ответа

С помощью telnet вы можете проверить, открыт ли порт и прослушивается ли он. Но не выполнять команды на удаленном хосте. telnet очень небезопасен, и во всех современных системах он отключен. Это также причина, по которой ваше соединение с портом 23 не работает: система не должна принимать соединения tenet, и порт закрыт. Connection refused означает, что соединение было заблокировано брандмауэром или закрытым портом.

2
27.01.2020, 23:16

Telnet , используемый таким образом, просто устанавливает несколько необработанное TCP-соединение. nc или netcat - лучший инструмент для тестирования подключения к IP-сети из командной строки.

Сначала вы подключились к прослушивающему sshd на порту 22 и получили первую часть подтверждения SSH - строку версии сервера.

Во втором случае вы подключились к порту 23, который традиционно прослушивает telnetd . Однако, поскольку telnet менее безопасен, чем ssh , он обычно не включен по умолчанию в современных системах. Вы не можете подключиться, потому что telnetd не прослушивает .

Вы не устанавливаете удаленный сеанс оболочки при использовании telnet таким образом, поэтому вы не можете выполнять команды оболочки в удаленной системе, такие как ping ] или дата . Вы устанавливаете сетевое соединение, которое позволяет вам вручную вводить то, что обычно отправляется по сети для соответствующего протокола. С SSH вы в значительной степени застряли после обмена начальной версией, поскольку после этого момента обмен данными шифруется.

Более типичным использованием было бы тестирование сервера, на котором работает протокол, основанный на тексте, такой как HTTP, IMAP или SMTP, например. 

$ telnet <remote_host_ipaddr> 80
> GET /index.html HTTP/1.0
>
...
$
3
27.01.2020, 23:16

Для более специализированного тестирования вы можете использовать наш инструмент тестирования dda -serverpec(https://github.com/DomainDrivenArchitecture/dda-serverspec-crate)для таких задач. Вы можете определить свои ожидания 

{:netcat [{:host "mywebserver.com" :port "443"}
          {:host "telnet mywebserver.com" :port "80"}
          {:host "telnet mywebserver.com" :port "8443"}]}

и проверьте эти ожидания либо на локальном хосте, либо на удаленных хостах (, подключающихся по ssh ). Для удаленных тестов вы должны определить цели:

{:existing [{:node-name "test-vm1"
             :node-ip "35.157.19.218"}
            {:node-name "test-vm2"
             :node-ip "18.194.113.138"}]
 :provisioning-user {:login "ubuntu"}}

Вы можете запустить тест сjava -jar dda-serverspec.jar --targets targets.edn serverspec.edn

Под капотом мы используем netcat с некоторыми специальными настройками тайм-аута или минимизации трафика...

0
27.01.2020, 23:16

Теги

Похожие вопросы