Ssh как открыть доступ для всех

Могу ли я включить или отключить доступ по SSH для определенного пользователя или группы?

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

В файле конфигурации openSSH по умолчанию есть две директивы для включения и отключения доступа по SSH для определенных пользователей. или группы. Во-первых, давайте посмотрим, как включить или отключить доступ по SSH для пользователя и группы. Все приведенные ниже команды должны выполняться от имени пользователя root или sudo.

1. Разрешить доступ по SSH пользователю или группе

Чтобы разрешить доступ по SSH определенному пользователю, например sk , отредактируйте файл sshd_config. :

Нажмите «i», чтобы войти в режим вставки, и добавьте или измените следующую строку:

Замените «sk» своим именем пользователя. Обратите внимание на отступ между «AllowUsers» и «sk». Вы должны использовать Tab вместо пробела. Значение: добавьте слово «Включить пользователя» и нажмите Tab, затем введите имя пользователя.

Вы также можете ввести более одного пользователя, как показано ниже.

Если вы хотите разрешить Для всей группы, например root, добавьте/отредактируйте следующую строку:

Эта опция позволит всем членам «корневой» группы подключаться к серверу Linux через ssh.

Нажмите ESC, чтобы выйти из режима вставки, и введите: wq, чтобы сохранить и выйти из файла конфигурации SSH. Перезапустите службу SSH, чтобы изменения вступили в силу.

Пользователь sk и все члены группы «root» теперь могут подключаться к вашему серверу Linux через ssh. Другие пользователи (кроме sk и членов группы «root») не могут получить доступ к системе по ssh.

Чтобы убедиться в этом, попробуйте войти на сервер Linux под любым из отключенных пользователей:

Появится следующее сообщение об ошибке:

2. Запретить доступ по SSH пользователю или группе

Чтобы отключить или запретить доступ по SSH пользователю или group вам необходимо добавить/изменить следующие директивы в файле sshd_config вашего удаленного сервера.

Чтобы отключить доступ по SSH для определенного пользователя с именем «sk», отредактируйте sshd_config:

Добавить/изменить следующую строку в sshd_config.

Убедитесь, что отступ правильный. Не используйте пробел. Нажмите Tab, чтобы добавить имя пользователя.

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

Аналогичным образом, чтобы запретить доступ по SSH для всей группы, например root, добавьте:

Сохраните и закройте файл конфигурации ssh. Перезапустите службу ssh, чтобы изменения вступили в силу.

Теперь попробуйте подключиться к вашей машине Linux по ssh из заблокированной учетной записи пользователя, например sk:

Вы получите следующее сообщение:

3. Отключить вход через SSH-root

Ssh root-доступ считается плохой практикой безопасности. Поэтому мы настоятельно рекомендуем отключить вход root ssh для защиты вашей системы.

Чтобы отключить вход root ssh, отредактируйте sshd_config:

Найдите следующую строку, удалите ее и установите значение no .

Перезапустите службу SSH, чтобы изменения вступили в силу немедленно:

Теперь вы знаете, как предоставлять и ограничивать доступ по SSH для определенных пользователей или групп в Linux. Вы также узнали, как предотвратить или отключить вход в систему SSH root в Linux. Это одна из рекомендуемых мер безопасности, которую должен использовать каждый администратор Linux при настройке сервера Linux.

Источник

Напоминания для пользователей ssh

резюме: В этой статье описываются расширенные функции OpenSSH, которые значительно облегчают жизнь системным администраторам и программистам, которые не любят оболочки. В отличие от большинства руководств, в которых описываются только переключатели и опции -L/D/R, я попытался собрать все интересные функции и удобства, которые дает ssh.

Предупреждение: сообщение очень громоздко, но для удобства решил не крошить.

Таблица:

  • управление ключами
  • копирование файлов по ssh
  • Перенаправление потока ввода-вывода
  • Удаленное подключение к ФС через ssh
  • Удаленное выполнение кода
  • Псевдонимы и параметры подключения в .ssh/config
  • Параметры по умолчанию
  • Переадресация X-сервера
  • ssh as Socks Proxy
  • Переадресация портов: вперед и назад
  • Обратный средний прокси
  • Туннелирование трафика L2/L3
  • Агент переадресации авторизации
  • Туннелирование ssh через ssh через недоверенный сервер ( вероятно, не знает )

Управление ключами

Кратко о теории: ssh можно войти не паролем а ключом. Ключ состоит из открытой части и закрытой части. Открытый находится в домашнем каталоге пользователя, «переключающегося» на сервер, закрытый — в домашнем каталоге пользователя, переключающегося на удаленный сервер. Половинки сравнивают (утрируя) и если все в порядке, то разрешают. Важно: Авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (т.е. сервер имеет свой ключ). Основная особенность ключа по сравнению с паролем заключается в том, что его нельзя «украсть» путем взлома сервера: ключ не передается от клиента к серверу, а клиент при авторизации доказывает серверу, что ключ у него есть ( та же криптографическая магия).

Генерация ключей

Вы можете сгенерировать свой собственный ключ с помощью команд ssh-keygen. Если не задать параметры, то сохранит все как надо.

Ключ можно заблокировать паролем. Этот пароль (в обычных графических интерфейсах) запрашивается один раз и хранится в течение определенного периода времени. Если пароль пуст, он не потребуется во время использования. Забытый пароль восстановить невозможно.

Вы можете изменить пароль ключа с помощью команды ssh-keygen -p .

Читайте также:  Prx как открыть файл

Структура ключа

/.ssh/id_rsa.pub общедоступен ключ. Он копирует себя на серверы, к которым ему нужен доступ.

/.ssh/id_rsa — закрытый ключ. Вы не можете показать это никому. Если вы копируете и вставляете его в письмо/чат вместо паба, вам нужно сгенерировать новый ключ. (Я не шучу, около 10% людей, которых вы спрашиваете о ключе id_rsa ssh, и 100% из этих 10% — мужчины.)

Копировать ключ на сервер

/ .ssh/authorized_keys и поместите туда публичный ключ, вы сможете войти без пароля. Обратите внимание, что права доступа к файлу не должны позволять неавторизованным пользователям записывать в этот файл, иначе ssh не примет его. Последнее поле ключа — uživatel@stroj. Это не имеет никакого отношения к авторизации и просто облегчает определение того, где находится ключ. Обратите внимание, что это поле можно изменить (или даже удалить) без нарушения структуры ключа.

Если вы знаете пароль пользователя, процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ без ручного редактирования файлов.

Примечание. В старых руководствах по ssh упоминается author_keys2. Причина: это была первая версия ssh, потом она стала второй (актуальной), для нее сделали свой набор конфигураций, это всех очень утомляло, а вторая версия долгое время переходила на версии без «2 » некоторое время назад. Это означает, что всегда следует использовать authorize_keys и не думать о разных версиях.

Если вы используете ssh на нестандартном порту, ssh-copy-id требует особого приема: ssh-copy-id ‘- p 443 user@server’ (следите за кавычками).

Ключ сервера

/.ssh/known_hosts. Невозможно определить, где какой ключ (потому что это небезопасно).

Если ключ сервера изменился (например, сервер был переустановлен), ssh кричит, что ключ был подделан. Учтите, что если вы не трогали сервер и он кричит ssh, то вы заходите не на тот сервер (например, в сети появился еще один компьютер с таким же IP, все локальные сети с 192.168.1.1, которых в сети несколько миллионов мира, страдают от этого в особенности). Сценарий «злой человек посередине» маловероятен, чаще это просто ошибка с айпи, хотя если «все хорошо» и поменялся ключ, то это повод поднять уровень паранойи на несколько ступеней ( и если у вас есть авторизация ключа и сервер вдруг запрашивает у вас пароль, то паранойя может включиться 100% и вы не вводите пароль).

Известный ключ сервера можно удалить с помощью ssh-keygen -R server При этом следует также удалить IP ключа (они хранятся отдельно): ssh-keygen -R 127.0.0.1 .

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub Они могут быть:
а) скопированы со старого сервера на новый новый.
б) сгенерировать с помощью ssh-keygen. В этом случае вам не нужно устанавливать пароль (т.е. пустой). Сервер ssh не сможет использовать ключ с паролем.

Обратите внимание, что если вы клонируете серверы (например, на виртуальных машинах), вам необходимо восстановить ключи ssh сервера.

Это лучше удалить старые ключи из know_hosts, иначе ssh будет жаловаться на дубликат ключа.

Копировать файлы

Переносить файлы в сервер может иногда утомлять. Помимо возни с sftp и другими странными вещами, ssh дает нам команду scp , которая копирует файл в сеанс ssh.

path scp/myfile user@8.8.8.8:/full/ path/to/ new/location/

Возможна и обратная процедура:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here

Примечание от Fish: Несмотря на то, что mc может подключаться через ssh, копирование больших файлов будет очень болезненным, потому что fish (модуль mc для работы с ssh в качестве виртуальной fs) очень медленный. 100-200кб это предел, так что начинается испытание терпения. (Вспомнил свою раннюю молодость, когда, не зная про scp, копировал

5 Гб через fish в mc, по FastEthernet это заняло чуть более 12 часов.)

Возможность копирования у него отличная. Но я хочу «сохранить как» и сразу на сервер. И копировать в графическом режиме не из специальной программы, а из любой известной.

sshfs

Теория: модуль fuse позволяет «экспортировать» запросы файловой системы из ядра обратно в соответствующую программу. Это упрощает реализацию «псевдофайловых систем». Например, мы можем предоставить доступ к удаленной файловой системе по ssh, чтобы все локальные приложения (за редким исключением) ничего не подозревали.

Собственно, исключение: O_DIRECT, к сожалению, не поддерживается (это не проблема sshfs , это вообще проблема с фьюзами).

Использование: Установить пакет sshfs (загрузить фьюз).

На самом деле пример моей последовательности команд, которые подключаю desunote.ru (находится у меня на домашнем компе; картинки представлены в этой статье) на моем ноуте:

создаем файл +x, вызываем его, заходим в любое приложение, говорим сохранить и вы увидите:

Параметры Sshfs, которые могут быть важны: -o reconnect (говорит попробовать переподключиться, а не сбой).

Если вы много работаете с корневыми данными , то вы можете (вы должны) выполнить idmap:

-o idmap=user . Это работает следующим образом: если мы подключаемся как пользователь pupkin@server и работаем локально как пользователь vasiliy, то мы говорим «предположим, что файлы pupkin являются файлами vasiliy». или «root», если мы подключаемся как root.

В моем случае idmap не нужен, потому что имена пользователей (локальные и удаленные) одинаковы.

Обратите внимание, что это удобно, только если мы иметь ключ ssh (см. начало статьи), иначе авторизация по паролю надоедает 2-3 подключения.

Выключаешь опять командой fusermount -u /path , но если соединение зависло (например, нет сети), вы можете/должны сделать это от имени пользователя root: sudo umount -f /path.

Удаленное выполнение кода

ssh может работать на удаленном сервере и немедленно прервите соединение. Самый простой пример:

ssh user@server ls /etc/

Отображает содержимое /etc/ на сервере, пока у нас есть локальная командная строка.

Некоторые приложения хотят иметь терминал и управлять им. Их следует запускать с параметром -t:
ssh user@server -t remove_command

Кстати, мы можем сделать что-то вроде этого:
ssh user@server cat /some /remote server file , где cd их игнорирует (не читает стандартный ввод), а tar читает и распаковывает их. Scp для бедных, так сказать.

Читайте также:  Дарья тайна карибского моря как открыть замок

Неймы

Честно говоря, я не знал о нем и не использовал его до недавнего времени. Они оказались очень удобными.

В более-менее крупной компании часто бывает, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. Это означает, что вы должны войти в систему следующим образом: ssh ivanov_i@spb-MX-i3.extrt.int.company.net. Вы не устанете от туннельного синдрома каждый раз, когда будете печатать. В небольших компаниях проблема обратная: про DNS никто не думает, а обращение к серверу выглядит так: ssh root@192.168.1.4. Короче, но все равно неприятно. Еще драматичнее, если у нас нестандартный порт и например первая версия ssh (привет Cisco). Итак, все выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. утопиться Я даже не хочу говорить о драме scp.

Можно установить системные псевдонимы для IP-адресов (/etc/hosts), но это искаженный вывод (а user и options все равно должны печататься). Есть более короткий путь.

/.ssh/config позволяет настроить параметры подключения, в том числе специфичные для серверов и, что более важно, у каждого сервера свои. Вот пример конфигурации:

Все доступные параметры можно увидеть в man ssh_config (не путать с sshd_config).

Параметры по умолчанию

По запросу ПОЛЬЗОВАТЕЛЯ: Вы можете указать параметры подключения по умолчанию, используя конструкция Host *, т.е. например:

То же самое можно сделать в /etc/ssh/ssh_config (не путать с /etc/ssh/ssh d _config), но для этого требуются привилегии суперпользователя и применяются ко всем пользователям.

Переадресация сервера X

На самом деле я немного испортил эту часть в приведенном выше примере конфигурации. ForwardX11 — это именно то, что нужно.

Теория: графические приложения Unix обычно используют X-сервер (wayland уже в пути, но еще не готов). Это означает, что приложение запустится и подключится к X-серверу для рисования. Другими словами, если у вас есть простой сервер без графического интерфейса и у вас есть локальный x-сервер (на котором вы работаете), вы можете отрисовывать серверные приложения на рабочем столе. В общем, подключение к удаленному X-серверу не самое безопасное и тривиальное. SSH позволяет упростить этот процесс и сделать его полностью безопасным. А возможность сбора трафика также позволяет обойтись меньшим трафиком (т.е. уменьшить использование канала, т.е. уменьшить пинг (точнее, латентность), т.е. уменьшить задержку).

Переключатели: -X — переадресация X на сервер. -Y прохождение авторизации.

Только запомните комбинацию ssh -XYC user@SERVER .
В приведенном выше примере (названия компаний вымышлены) я подключаюсь к ооо-рогам-и-копытам.рф по одной причине, а для доступа к серверу Windows. Мы все знаем о сетевой безопасности Microsoft, поэтому раздражает показывать голый RDP внешнему миру. Вместо этого мы подключаемся к серверу по ssh и затем запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900×1200

и чудо, окно входа в Windows на нашем рабочем столе. Осторожно, тщательно зашифрован и неотличим от обычного ssh-трафика.

Socks-proxy

Когда я оказываюсь в соседнем отеле (кофе, конференция), местный вайфай обычно ужасен: порты закрыты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа особого нет (это не паранойя, я вполне наблюдал, как удаляются пароли и куки с помощью банального ноута, который раздает всем 3G с названием соседнего кафе (и пишет интересные вещи)).

Особую проблему представляют закрытые порты. Накроется Jabber, потом IMAP, потом еще что-то.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает, проход просто не разрешен. Опытным путем известно, что порт 443 чаще всего оставляют и в режиме CONNECT, т.е. пропускают «как есть» (обычный http еще можно прозрачно завернуть в октопус).

Решение — socks-proxy режим работы ssh. Его принцип таков: клиент ssh подключается к серверу и слушает локально. Получив запрос, отправляет его (по открытому соединению) на сервер, сервер устанавливает соединение по запросу и передает все данные ssh-клиенту. И ответь звонящему. Вам нужно указать приложениям «использовать socks-прокси», чтобы это работало. И введите IP-адрес прокси. В случае ssh это обычно локальный хост (чтобы не отдавать свой канал посторонним).

Соединение sock-proxy выглядит так:

Потому что другие народный вайфай есть часто не только дрянной, но и медленный, может быть хорошей идеей включить опцию -C (сжимать трафик). Получается, что работает почти турбо (только изображение не нажимает). При реальном браузинге по http покажет примерно в 2-3 раза (читай: если не повезло с 64кбит, то мегабайтные страницы будет открывать не две минуты, а 40 секунд. Да, но даже лучше). Но самое главное: никаких украденных куков и сеансов подслушивания

Я не зря упомянул закрытые порты. Порт 22 закрывается точно так же, как и порт 22. Джаббер «избыточный» порт. Решение — повесить сервер на 443 порт. Не стоит стрелять с 22, иногда бывают системы с DPI (глубокая проверка пакетов), которые не пускает ваш «псевдо-ssl».

См. моя конфигурация для этого:

/etc/ssh/sshd_config:
(фрагмент)
порт 22
порт 443

/.ssh/config вашего ноутбука опишите vpn

(Обратите внимание, что ленивая форма localhost — 127.1, это совершенно законный способ записи 127.0.0.1)

Перенаправление портов

Перейдем к крайне сложному часть функциональности SSH, позволяющая выполнять операции логического TCP-туннелирования «с сервера» и «на сервер».

Для понимания ситуации все приведенные ниже примеры относятся к этой схеме:

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая представляет собой «шлюз», т.е. сервер с белым интерфейсом и серым интерфейсом, обращенными друг к другу. собственная частная сеть. В следующих рассуждениях мы предполагаем, что «наш» ноутбук — это A, а «сервер» — это B.

Задача : У нас есть приложение, работающее локально, нам нужно разрешить другому пользователю (за пределами нашей сети), а именно

Решение: Перенаправить локальный порт (127.0.0.1:80) на общедоступный адрес. Допустим, наш «общедоступный» Б занял 80-й порт чем-то полезным, поэтому мы перенаправляем на нестандартный порт (8080). localhost.

Читайте также:  Доказательство отваги вов как получить

ssh -R 127.1 :80:8.8.8.8:8080 user@8.8.8.8

Параметр -R позволяет перенаправить порт с удаленного сервера ( R emote ) на свой собственный (локальный) сервер.
Важно: Если мы хотим использовать адрес 8.8.8.8, нам нужно включить GatewayPorts в конфигурации сервера B.
Задача . Некий демон (скажем, сервер sql) прослушивает сервер «B». Наше приложение не поддерживается сервером (разная разрядность, операционная система, плохой админ, бан и лимит и т.д.). Мы хотим получить локальный доступ к удаленному локальному хосту.

Окончательная конфигурация: запросы к локальному хосту: 3333 на «А» должны обслуживаться демоном на локальном хосте: 3128 «Б».

ssh -L 127.1 : 3333: 127.1:3128 user@8.8.8.8

Параметр -L позволяет направлять локальные ( L локальные) запросы на удаленный server.

Задача : Определенная служба прослушивает сервер «B» в сером интерфейсе, и мы хотим разрешить коллеге (192.168.0.3) просматривать это приложение.

Окончательная конфигурация: Требования для нашего серого IP-адреса (192.168.0.2) идут на серый интерфейс сервера B.

ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8 . 8,8

Вложенные туннели

Конечно, туннели могут быть перенаправлены.

Давайте усложним задачу: Теперь мы хотим показать коллеге приложение, работающее на локальном хосте на сервер с адресом 10.1.1.2 (на порту 80).

Комплексное решение:
ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999: 127.1:80 user2@10.1.1.2

Что происходит? Мы скажем ssh перенаправить локальные запросы с нашего адреса на локальный хост сервера B и сразу после подключения запустить ssh (т.е. ssh-клиент) на сервере B с возможностью прослушивания на локальном хосте и пересылки запросов. запросы к серверу 10.1.1.2 (куда должен подключаться клиент). Порт 9999 выбран произвольно, главное, чтобы он совпадал при первом и втором вызовах.

Обратное означает прокси

Если приведенный выше пример показался простым и очевидным, попробуйте догадаться, что это за пример будет делать :
ssh -D 8080 -R 127.1:8080:127.1:8080 uživatel@8.8.8.8 ssh -R 127.1: 8080:127.1 :8080 uživatel@10.1.1.2

Если вы офицер чья задача отключить использование Интернета на сервере 10.1.1.2, тогда вы можете начать рвать на себе волосы, потому что эта команда предоставит доступ в Интернет для сервера 10.1.1.2 через прокси-сервер sox, работающий на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. НО исходящий трафик с компьютера неотличим от обычного трафика компьютера А с точки зрения сети «192.168.0/24».

Туннели

Если на данный момент безопасность vagrant не лысая и ssh все еще не указан в качестве безопасности враг номер один, вот окончательный убийца всего: IP или даже туннелей Ethernet. В самых крайних случаях это допускает туннелирование dhcp, удаленную подмену arp, wake-on-lan и другие нарушения второго уровня.

(К сожалению, сам я этим не пользовался).

Нетрудно заметить, что при таких условиях никакой DPI (Deep Packet Inspection) не может отловить такие туннели — либо ssh включен (читай — делай что хочешь), либо ssh отключен (и можно смело). покинуть ту компанию идиотов, не чувствуя ни малейшего угрызения совести).

Прохождение Авторизации

Если вы думаете, что это оно, то… в отличие от автора, который еще не написал «снизу» , читатель заранее видит, что внизу много букв и интрига не работает.

OpenSSH позволяет серверам служить трамплином для подключения к другим серверам, даже если этим серверам нельзя доверять и ими можно злоупотреблять. каким-то образом.

Сначала поговорим о простом проходе авторизации.

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов к принимаем наш ключ.Но мы не хотим копировать его на 8.8.8.8 потому что там передний двор и половина людей имеют sudo и могут ковыряться в чужих директориях Компромисс Один из вариантов будет иметь «другой» ключ ssh что авторизует user@8.8.8.8 на 10.1.1.2 но если мы не хотим никого пускать с 8.8.8.8 на 10.1.1.2 то это не так (тем более что ключ можно не только использовать, но и копировать себе «для дождливого де n»).

ssh предлагает возможность переадресации агента ssh (служба, требующая пароль для ключа). Опция ssh -A отправляет авторизацию на удаленный сервер.

Вызов выглядит так:

ssh -A user@8.8.8.8 ssh user2@10.1. 1.2

Удаленный ssh-клиент (8.8.8.8) может доказать 10.1.1.2, что это мы, только если мы подключены к этому серверу и дали ssh-клиенту доступ к его агенту авторизации ( !, но не ключ!).

В большинстве случаев это работает.

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

Есть еще более мощный метод: он превращает ssh в простой пайп (в смысле «конвейер»), через который мы работаем впритык с удаленным сервером.

Основным преимуществом этого метода является полная независимость прокси от сервера-посредника. Вы можете использовать поддельный ssh-сервер, регистрировать каждый байт и каждое действие, захватывать любые данные и подделывать их, как хотите — взаимодействие происходит между «конечным» сервером и клиентом. Если серверные данные подделаны, подпись не будет совпадать. Если данные не поддельные, то сессия устанавливается в безопасном режиме, так что ничего не поймать.

Я не знал об этой прикольной настройке, поэтому откопал ее на redrampage.

Этот параметр связан с двумя параметрами ssh: параметром -W (который делает ssh «трубой») и параметром конфигурации ProxyCommand (похоже, нет параметра командной строки), который говорит «запустить программу и придерживаться на стандартный ввод/выход». Эти параметры появились совсем недавно, поэтому пользователи centos в замешательстве.

Выглядит это так (цифры на картинке выше):

Ну, подключение тривиально: ssh raep .

Повторим важный момент: сервер 8.8.8.8 не должен перехватывать или подделывать трафик, использовать агент авторизации пользователя или иным образом изменять трафик. Запрет да. Но если он включен, то он будет проходить сам без декодирования и редактирования. Для того, чтобы настройка работала, у вас должен быть свой публичный ключ в авторизованных ключах для user@8.8.8.8 и user2@10.1.1.2

Конечно, подключение может быть оснащено всеми дополнительными функциями: проброс портов, копирование файлов, прокси-серверы sox, туннели L2, туннели X-сервера и т. д.

Источник

Поделиться с друзьями
Решатор