Вопросы Теги

SSH основанная на ключе аутентификация в сервере Perl

Windows использует символ вставки (^) как ее символ продолжения строки, не обратная косая черта. При замене обратных косых черт в конце каждой строки с каре она будет работать как одна команда.

1
задан 27 February 2012 в 14:02
4 ответа

Вы хотите использовать SSH-туннель. Это зашифрует ваше общение и аутентифицируется с помощью ключей SSH.

Если вы хотите, чтобы клиент был написан на Perl, используйте что-то вроде модуля Net :: SSH :: Perl: http: //search.cpan. org / ~ turntep / Net-SSH-Perl-1.34 / lib / Net / SSH / Perl.pm

Не зная больше о вашей настройке, я действительно не могу помочь вам полностью реализовать туннель SSH.

3
ответ дан 3 December 2019 в 16:50

SSH использует ключи, тогда как SSL, как правило, использует сертификаты X.509 (кстати, SSH не основан на SSL).

Сертификат (открытый ключ) - это больше, чем просто открытый ключ: это связь между открытым ключом, идентификатором (например, Subject DN) и другими атрибутами, все подписывается (эмитентом для сертификатов X.509).

Например, при использовании RSA можно извлечь материал открытого ключа (модуль и открытый показатель степени) и превратить его в сертификат. В этой модели отсутствует то, что ключи SSH - это просто ключи, они не «подписаны» или «выпущены», как сертификаты X.509. Вам будет не хватать аспекта PKI, который часто используется в SSL в вашей модели. Легкий способ обойти это - создать самоподписанный сертификат.

1
ответ дан 3 December 2019 в 16:50

Помимо простого туннелирования соединения через SSH, как Крис Тинг указывает :

Вы можете реализовать подсистему SSH, которая позволит вашей программе легко интегрироваться с SSH. Для пользователя это будет выглядеть так, как будто ваша программа просто использует ключи SSH и шифрование (что на самом деле связано с фактическим использованием SSH). Процесс не так хорошо документирован, хотя клиент и сервер OpenSSH SFTP в некоторой степени самодокументируются.

Это потребует значительного количества переписывания, в зависимости от того, как клиенты подключаются и синтаксиса протокола. Очевидным преимуществом является то, что тогда он будет легко интегрирован в конфигурацию SSH пользователя.

1
ответ дан 3 December 2019 в 16:50

Некоторое время назад я написал подобное серверное / клиентское приложение. Базовая конструкция:

  • сервер не поддерживает работу в сети, это простой скрипт, который взаимодействует с потоками stdin / stdout (например, демоны, выполняемые inetd);
  • все сетевые и аутентификационные данные выполняются ssh / sshd, клиент использует ssh с авторизация на основе ключа, сервер имеет файл authorized_keys с опцией command = "" - этот ключ всегда запускает мой сервер и не может использоваться для доступа к оболочке или другим программам;

Пример .ssh / authorized_keys файл: 

no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding,from="10.0.0.1",command="/usr/local/bin/fsdumps-receiver" ssh-rsa AAAA.... key_comment

Обратите внимание на параметр from = "" - доступ в этом примере ограничен только одним IP.

Код сервера имеет доступ к некоторым полезным переменным среды. Например:

  • $ ENV {'SSH_ORIGINAL_COMMAND'} - «команда» (не совсем), переданная как ssh server_ip that_command
  • $ ENV {' SSH_CLIENT '} - IP-адрес клиента

Вы можете использовать SSH_ORIGINAL_COMMAND для выбора задачи управления на вашем сервере. Клиентский код может порождать ssh (или использовать Net :: SSH :: Perl) с этим именем задачи в качестве аргумента, а затем отправлять / получать данные на / с сервера.

1
ответ дан 3 December 2019 в 16:50

Теги

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