Ubuntu установка настройка SSH сервера. Установка и настройка SSH - Ubuntu Удаление ssh ubuntu

В этой статье вы узнаете как установить, включить и настроить SSH в Ubuntu Linux.

OpenSSH – это свободно доступная версия семейства протоколов Secure Shell (SSH) для удаленного управления или передачи файлов между компьютерами.

Традиционные инструменты, используемые для выполнения таких функций, как telnet или rcp, небезопасны и передают пароль пользователя в текстовом формате при его использовании. OpenSSH предоставляет серверный демон и клиентские инструменты для обеспечения безопасного, зашифрованного дистанционного управления и операций передачи файлов, эффективно заменяя устаревшие инструменты.

Серверный компонент OpenSSH, sshd, постоянно прослушивает клиентские соединения с любого из клиентских инструментов. Когда возникает запрос на соединение, sshd устанавливает правильное соединение в зависимости от типа подключения клиентского инструмента. Например, если удаленный компьютер подключается к клиентскому приложению ssh, сервер OpenSSH устанавливает сеанс удаленного управления после аутентификации. Если удаленный пользователь подключается к серверу OpenSSH с помощью scp, демон сервера OpenSSH инициирует безопасную копию файлов между сервером и клиентом после аутентификации. OpenSSH может использовать множество методов проверки подлинности, включая простой пароль и открытый ключ.

Как установить OpenSSH

Чтобы установить OpenSSH, откройте терминал и введите следующие команды

Sudo apt-get update sudo apt-get install openssh-server -y

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

Sudo systemctl status ssh

Вы должны увидеть что-то вроде Active: active (running): Это означает, что SSH установлен и запущен в вашей системе Ubuntu.

Конфигурация

Можно изменить конфигурацию поведения сервера OpenSSH по умолчанию, отредактировав файл /etc/ssh/sshd_config.

Но перед редактированием файла конфигурации вы должны сделать копию исходного файла и защитить его от записи, чтобы у вас были исходные настройки в качестве ссылки чтобы можно было повторно использовать этот файл при необходимости.

Скопируйте файл /etc/ssh/sshd_config и защитите его от записи с помощью следующих команд:

Sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original sudo chmod a-w /etc/ssh/sshd_config.original

А теперь откройте файл для редактирования

Sudo apt-get install nano -y sudo nano /etc/ssh/sshd_config

Для получения информации о директивах конфигурации, используемых в этом файле, вы можете просмотреть соответствующую страницу руководства с помощью следующей команды:

Man sshd_config

Ниже приведены примеры директив конфигурации, которые вы можете изменить:

Чтобы настроить OpenSSH на прослушивание например через порт 2222 вместо стандартного TCP-порта 22, измените директиву порт на: Port 2222

Чтобы sshd разрешал учетные данные для входа на основе открытого ключа, просто добавьте или измените строку: PubkeyAuthentication yes – Если строка уже присутствует, убедитесь, что она не закомментирована.

Чтобы ваш сервер OpenSSH отображал содержимое файла /etc/issue.net в качестве баннера перед входом в систему, просто добавьте или измените строку: Banner /etc/issue.net . В файле /etc/ssh/sshd_config.

После внесения изменений в файл /etc/ssh/sshd_config сохраните файл и перезапустите приложение-сервер sshd, чтобы выполнить изменения, используйте следующую команду в терминале:

Sudo systemctl restart sshd.service

Набор OpenSSH состоит из следующих инструментов:

  • Удаленные операции выполняются с использованием ssh, scp и sftp.
  • Управление ключами – ssh-add, ssh-keysign, ssh-keyscan и ssh-keygen.
  • Службы состоят из sshd, sftp-server и ssh-agent.

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

Ssh user@serverip

Эта команда соединяет вас с вашим сервером, который имеет свой IP адрес serverip и имя пользователя user .

Вам предложат ввести пароль, после ввода которого, вы успешно подключены к вашему серверу.


Для установки ssh-сервера выполните в терминале:

Ubuntu/Debian/Linux Mint

Затем отредактируйте настройки ssh-сервера в файле /etc/ssh/sshd_config
Для этого в терминале выполните:


Также для того чтобы OpenSSH слушал только определенные ip адресса, допустим 192.168.0.50, 192.168.0.51 на порту 777, то просто добавьте следующие строчки:

Ограничить доступ через SSH для пользователей: test test2 test3

OpenSSH сервер может использовать протокол Rlogin для авторизации и может имитировать поведение устаревшей комманды rsh, по этому отключите чтение пользовательских файлов ~/.rhosts и ~/.shosts:

Включите предупреждающий баннер отредактировав следующую строку и создания соотв. файла:

Сохраняйте логи, удостоверьтесь что директива LogLevel имеет значение INFO или DEBUG

Чтобы перезапустить OpenSSH на CentOS, Fedora или RHEL:

В некоторых случаях, запустить сервер можно только таким способом:


Для проверки статуса сервера используем следующую команду


Теперь на компьютер с установленным OpenSSH-server можно зайти так:

Ssh [-p port]

Например:

CentOS / RHEL / Fedora Linux - отключить или удалить OpenSSH можно так:

$ chkconfig sshd off
$ yum erase openssh-server

Основные файлы и папки SSH:
~/.ssh/ - пользовательские конфигурационные директории
~/.ssh/authorized_keys и ~/.ssh/authorized_keys2 - списки публичных ключей (RSA или DSA), которые могут быть использованы для авторизации в пользовательский аккаунт
~/.ssh/known_hosts - ключи серверов
/etc/ssh/sshd_config - конфигурационный файл сервера OpenSSH
/etc/ssh/ssh_config - конфигурационный файл клиента OpenSSH
/etc/nologin - если этот файл существует, то система будет отказываться пускать кого-либо кроме root-пользователя. Лучше удалить и не использовать.
/etc/hosts.allow и /etc/hosts.deny - списки контроля доступа (ACL)

Когда стали широко использоваться алгоритмы шифрования при передаче данных в сети, одной из первых задач стала организация безопасной оболочки.

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

  • данные, передаваемые через сеть, никак не шифруются, включая пароли;
  • жанные, передаваемые через сеть, могут быть без проблем получены либо модифицированы третьей стороной;
  • злоумышленник мог спокойно подменить IP клиента и, использовав полученный ранее хеш пароля, пройти аутентификацию на сервере со всеми вытекающими последствиями.

Поэтому сейчас rsh применяется в чрезвычайно редких случаях, например, при переносе данных между двумя попарно соединенными машинами (мне так пришлось работать с двумя машинами в разных комнатах). В основном стандартом де-факто стал ssh. Первая буква «s» означает безопасный (secure), что означает, что все данные, предаваемые через ssh шифруются, а значит, защищены от просмотра. Существует несколько версий протокола ssh, различающиеся используемыми алгоритмами шифрования и общими схемами работы. В настоящее время повсеместно используется протокол ssh версии два. Протокол младших версий является по современным меркам небезопасным (там есть несколько очень опасных дыр). Вообще-то сейчас ssh является коммерческим продуктом (что само по себе противоречит требованиям безопасности - всем должен быть известен исходный код системы защиты информации, чтобы убедиться в отсутствии всяких backdoors), но тем не менее доступна свободная реализация ssh - OpenSSH, которая может быть найдена на www.openssh.com. Наилучшим документом по ssh является, по-моему, банальный man ssh, поэтому в некоторых местах я не постесняюсь его просто переводить.

Итак, начнем, как обычно, с теории. SSH предоставляет 3 способа аутентификации клиента: по ip адресу клиента (небезопасно), по публичному ключу клиента и стандартный парольный метод. Вот как работает ssh версии 2: при запросе клиента сервер сообщает ему, какие методы аутентификации он поддерживает (это определяется в опции PreferredAuthentications sshd.conf) и клиент по очереди пытается проверить их. По умолчанию клиент вначале пытается аутентифицироваться своим адресом, затем публичным ключом и, если ничего не сработало, передает пароль, введенный с клавиатуры (при этом пароль шифруется асимметрическим шифрованием). После прохождения аутентификации одним из методов из имеющихся у клиента и сервера пар ключей генерируется ключ симметрического шифрования, который, как я описывал во введении, генерируется на основании своего секретного и удаленного публичного ключей. После чего все последующие данные, передаваемые через ssh, шифруются данным ключом (обычно используется алгоритм aes с длиной ключа 128 бит). Отмечу, что протокол ssh версии 1 имел некоторые баги в шифрации передаваемого трафика и являлся по сути методом безопасной аутентификации, поэтому по современным меркам данный протокол считается небезопасным. Протокол версии 2 поддерживает более современные методы шифрования тарфика, также вместе с данными посылаются контрольные суммы формата sha или md5, что исключает подмену или иную модификацию передаваемого трафика (чего не было у ssh версии 1).

Теперь пару слов о способах аутентификации пользователей через ssh:

  1. По адресу клиента. При данном способе аутентификации происходит следующее: каждый клиент и сервер имеют свои пары ключей RSA, которые называются ключи хоста. При этом существует несколько методов проверки адреса клиента. Сервер смотрит файлы $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv или /etc/ssh/shosts.equiv, если же сервер настроен на проверку ключей клиентов (а это нужно в соображениях безопасности, т.к. иначе злоумышленник может подменить ip клиента на свой), то он дополнительно проверяет /etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts. Естественно, что файлы, расположенные в домашних каталогах сервера, действуют на пользователя, в чьем каталоге они размещены, а файлы, расположенные в /etc имеют глобальный эффект.

    Для начала расскажу о синтаксисе вышеперечисленных файлов: - .rhosts - определяет адрес машины и имя пользователя, с которой данному пользователю открыт доступ (файл расположен в домашнем каталоге пользователя); - .shosts* - аналогичен.rhosts, но предназначен исключительно для ssh, поэтому использовать лучше именно данный файл; - /etc/hosts.equiv - также содержит пары имя машины/имя пользователя, но имеет эффект на всех пользователей; - /etc/shosts.equiv** - аналог hosts.equiv, но применяется только ssh, что также более предпочтительно. - /etc/ssh/ssh_known_hosts и $HOME/.ssh/known_hosts*** - данные файлы содержат список адресов и соответствующих им публичных ключей. При запросе клиента сервер генерирует рандомную строку и шифрует ее публичным ключом удаленного хоста. Клиент, получив данную строку, расшифровывает ее своим секретным ключом (который имеется только у него) и зашифровывает полученную строку ключом сервера. Сервер получает зашифрованное сообщение, расшифровывает своим секретным ключом и сравнивает с исходной. Если строки совпали, то клиент имеет валидный секретный ключ, что дает ему право захода на данный сервер. Но для начала клиент должен иметь правильный адрес, которому соответствует публичный ключ на сервере в файле ssh_known_hosts. Файл состоит из 3-х полей: адрес (или адреса, разделенные запятой), публичный ключ для него одной (!) строкой и дополнительное поле комментариев(необязательно);

    * Пример.shhosts:

    User1.test.ru user1 userstend.test.ru user1 null.test.ru user1

    ** Пример файла /etc/shhosts.equiv:

    User1.test.ru user1 - server.test.ru xakep Знак «+» означает разрешение пользователю работать с сервером с данного адреса, знак «-» запрещает подобное действие.

    *** Пример файла known_hosts: user1.test.ru {SOME_VERY_LONG_PUBLIC_KEY} Адрес клиента должен быть в полном формате (name.domain), иначе могут быть проблемы. Кроме этого, в адресе можно использовать шаблоны * и?. Публичные ключи вставляются в данный файл самим администратором из генерированных клиентом ssh(identity.pub) публичных ключей. Вообще создание ssh_known_hosts - это прерогатива администратора (aka root).

    И еще добавлю: при аутентификации по хосту лучше использовать ssh_known_hosts, т.к. этот метод достаточно безопасен, если публичные ключи клиентов были получены из доверенного источника. Другие методы аутентификации не исключают подмену адреса, и потому считаются небезопасными.

  2. Аутентификация пользователя по его публичному ключу.

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

    Для генерации пары ключей используйте программу ssh-keygen. Для указания типа ключа укажите ssh-keygen -t {RSA DSA}, например, ssh-keygen -t rsa создаст пару ключей RSA длиной 1024 бита. Для указания файла, в котором следует сохранить ключи, можно использовать опцию -f (традиционно используются файлы $HOME/.ssh/id_rsa и $HOME/.ssh/id_dsa для ключей rsa и dsa соответственно), для указания длины ключа в битах используйте опцию -b:

    Ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/id_rsa

    В результате работы программа запросит ввод пароля для шифрования секретного ключа, чтобы исключить использование его при попадании к посторонним лицам, не знающим пароля (пароль желательно выбирать не короче 10-и символов). После этого вам будет необходимо вводить данный пароль каждый раз при использовании секретного ключа (далее я расскажу, как избежать этого при помощи программы ssh-agent). После работы ssh-keygen создается пара ключей: один секретный (зашифрованный введенным паролем), а другой публичный с расширением.pub (id_rsa.pub). Публичный ключ вам необходимо будет скопировать в домашнюю директорию сервера $HOME/.ssh/authorized_keys. После этого сервер будет знать ключ данного пользователя и сможет аутентифицировать вас без пароля. Файл authorized_keys может содержать несколько публичных ключей, допустимых для данного пользователя: просто поместите их в данный файл по порядку. После этих операций вы сможете входить, имея секретный ключ, на сервер, где размещен ваш публичный ключ, причем под тем пользователем, в чьем домашнем каталоге данный ключ находится. Пароля удаленного пользователя не требуется, необходимо только знать пароль расшифровки секретного ключа. Для переноса своего публичного ключа на сервер надо использовать только безопасные источники, иначе ваш ключ могут подменить. Для переноса публичного ключа клиента служит программа ssh-copy-id. Для начала необходимо сделать следующее:

    # ssh-copy-id -i public_key_file user@machine

    После соединения с севером machine и передачей имени пользователя user (необходимо указывать, если удаленное имя отличается от локального) происходит парольная аутентификация заданного пользователя(или текущего) на удаленной машине, затем происходит копирование ключа public_key_file (или $HOME/.ssh/identity.pub, если имя файла не указано) на сервер в $HOME/.ssh/authorized_keys. После этого можно входить на сервер, не используя пароль пользователя. При выполнении данной операции учтите, что вы должны скопировать на удаленную машину ПУБЛИЧНЫЙ ключ, иначе все будет очень печально (думаю, ясно, почему).

  3. Обычная парольная аутентификация.

    Тут можно отметить только одно: в любом случае вначале идет обмен асимметрическими ключами, и хеш пароля передается в зашифрованном виде. Парольная аутентификация используется наиболее часто, но, честно говоря, ssh предлагает более удобные методы аутентификации, и пользоваться ими IMHO можно, если к ssh есть все заплатки. И, конечно же, протокол версии 1 необходимо вырубить вообще. Итак, начинаем настройку… Я заметил, что большинство администраторов просто оставляет конфиги клиента и сервера по умолчанию, чтобы руки не марать. Но это неправильно: в разных системах эти конфиги различаются очень существенно, и это приводит к неразберихе и непониманию работы сервера, что создает дополнительную угрозу безопасности (свой сервак - потемки). Для этого я решил описать файлы конфигурации ssh на примерах ssh_config и sshd.conf для клиента и сервера соответственно. Для конфигурации клиента используется файл $HOME/.ssh/config или /etc/ssh/ssh_config (для всей системы). Файл имеет следующий формат: определение адреса хоста и параметры для него. В адресе можно использовать обычные шаблоны * и?, все имена параметров и их значения должны быть набраны в том же регистре, что и в примере (иначе параметр воспринят не будет). Вот пример ssh_config, который содержит наиболее полезные опции (на самом деле описывать некоторые параметры конфигурации ssh не имеет смысла, т.к. употребляются они очень редко):

    # Определение хоста, в данном случае включает все хосты домена test.ru, можно # использовать одиночный символ * чтобы указать параметры доступа к любому хосту Host *.test.ru # Эта опция определяет, будет ли ssh использовать передачу данных от удаленного # X сервера через свой безопасный канал. Далее будет описано, каким образом # организуются безопасные туннели через ssh. Данная возможность позволяет # защищать по идее небезопасные протоколы(X, pop, smtp, ftp) шифрованием ssh. По # умолчанию данная опция no ForwardX11 yes # Список предпочтительных методов аутентификации через ssh версии 2. Первым # стоит самый предпочтительный протокол, думаю, значения данного параметра ясны PreferredAuthentications hostbased,publickey,keyboard-interactive # Этот параметр определяет, будет ли производится стандартная парольная проверка # По умолчанию yes PasswordAuthentication yes # Число попыток ввода пароля перед тем, как клиент отсоединяется от сервера. По # умолчанию пароль можно вводить трижды NumberOfPasswordPrompts 3 # Список допустимых пользователей для данного сервера. Можно применять два # формата: список пользователей, разделенных пробелом, и список пользователей и # хостов, разделенных пробелом(USER@HOST - разрешает данному пользователю доступ # только с данного адреса). Можно использовать выражения * и?. Подобное же # назначение имеют опции AllowGroups, DenyUsers и DenyGroups(для групп нельзя # указывать адрес клиента) AllowUsers *@*.test.ru DenyUsers xakep lamer DenyGroups x* # Использование ssh(2 версия) аутентификации через rhosts и RSA ключи. По # умолчанию no. HostbasedAuthentication yes # Будет ли клиент пытаться работать по rsh, если ssh недоступен или по каким-то # причинам работает неправильно. По умолчанию no FallBackToRsh no # Используем ли rsh. По умолчанию no UseRsh no # Режим скрипта, когда не спрашиваются пароли с терминала. По умолчанию no BatchMode no # Дополнительно проверяется ключ хоста удаленной машины в # known_hosts, что исключает подмену ip. По умолчанию yes. CheckHostIP yes # Данный параметр означает, будет ли клиент доверять полученным от серверов # ключам. Параметр может принимать следующие значения: yes - ключи никогда # автоматически не помещаются в known_hosts, ask - ключ может быть помещен в # known_hosts только после подтверждения пользователя, no - все ключи # автоматически размещаются в known_hosts(небезопасно). По умолчанию ask. StrictHostKeyChecking ask # Следующие параметры определяют секретные ключи ssh различных форматов: # rsa и dsa IdentityFile $HOME/.ssh/id_rsa IdentityFile $HOME/.ssh/id_dsa # Порт, на удаленной машине используемый ssh. По умолчанию 22 Port 22 # Версии протоколов, используемые клиентом в порядке убывания приоритета. Protocol 2 # Протокол шифрования для версии 1 протокола ssh Cipher 3des # Возможные протоколы шифрования в порядке убывания приоритета для протокола # версии 2 Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # Значение escape-символа, сигнализирующего, что идущие за ним символы # необходимо воспринимать специальным образом(например ~. вызовет немедленное # отключение клиента от сервера) при передаче двоичных данных необходимо # установить этот параметр в none, что выключает escape последовательности. По # умолчанию ~ EscapeChar ~ # Управление работой компрессии зашифрованнного трафика. Полезный параметр для # медленных сетей, т.к. зашифрованные данные обычно увеличиваются в размере за # счет фиксированной длины ключа. Компрессия позволяет уменьшить количество # данных, передаваемых через сеть, но увеличит время работы самого протокола. # Так что включать этот параметр желательно на медленных соединениях. По # умолчанию no. Compression yes # Управляет посылкой сообщений о доступности клиента серверу, что позволяет # нормально разорвать соединение, если произошла неполадка в сети или иная, # приведшая к разрыва соединения. Если связь плохая, то лучше эту опцию # отключить, чтобы дисконнект не происходил после каждой ошибки сети. По # умолчанию yes. KeepAlive yes Я думаю, что в данном примере все объяснено достаточно подробно и скажу только вот что: в большинстве случаев опции по умолчанию работают неплохо, необходимо только отключить поддержку ssh версии 1 и настроить необходимые методы аутентификации (кроме парольной) и указать пути доступа к ключам. На этом закончим с настройкой клиента и настроим сервер. Файл конфигурации сервера sshd находится в /etc/ssh/sshd_config, и многие его параметры совпадают с аналогичными в ssh_config, но здесь нет определений хостов, как это было в ssh_config. Я все же приведу пример sshd_config, чтобы далее не возникало вопросов: # Номер порта и версия протокола Port 22 Protocol 2
    # Адреса, на которых слушает сервер, можно также указывать # порт (server.test.ru:2022), но назначение ssh нестандартного порта # нецелесообразно, т.к. заинтересует потенциальных взломщиков("А чего это там # они прячут?") ListenAddress server.test.ru
    # Ключ сервера для протокола версии 1 HostKey /etc/ssh/ssh_host_key # Ключи rsa и dsa для ssh версии 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key
    # Данные значения определяют длину ключа сервера и его время жизни для # использования ssh версии 1(данный ключ будет заново генерироваться через # заданное время) #KeyRegenerationInterval 3600 #ServerKeyBits 768
    # Далее определяем методы аутентификации для данного сервера и ее параметры
    # Сервер отсоединяется по происшествии данного времени в секундах, если клиент # не проходит аутентификацию LoginGraceTime 600 # Разрешаем заходить по ssh руту. Долгое время эта тема обсуждалась на форуме, # но я думаю все же, что со внутренней сети рут может заходить и по ssh (для # этого надо настроить должным образом iptables). Также можно запретить руту # входить по паролю: without-password, разрешая вход только по публичному ключу PermitRootLogin yes # Проверка sshd прав доступа и владельцев домашних каталогов. Полезно для тех # пользователей, что дают права всему 0777. Хотя таких болванов лучше держать на # расстоянии от сервера(лучше всего это делать бревном, подвешенным в серверной # к потолку, чтобы придать нежеланному гостю должное ускорение, и не забудьте # оббить конец бревна какой-нибудь железкой, иначе бревна придется менять # слишком часто;) StrictModes yes
    # Аутентификация через RSA (версия 1) RSAAuthentication yes # Аутентификация пользователя по ключу (версия 2) PubkeyAuthentication yes # Определяет публичный ключ пользователя для аутентификации по ключу. Можно # применять шаблоны: %u - имя пользователя, %h - домашний каталог пользователя. AuthorizedKeysFile .ssh/authorized_keys
    # Не используем аутентификацию rhosts RhostsAuthentication no # Можно также игнорировать rhosts и shosts при hostbased autentification, # используя только known_hosts файл. #IgnoreRhosts yes # Используем ли аутентификацию через known_hosts совместно с.rhosts или # .shosts. Опция действительна только для протокола версии 1. RhostsRSAAuthentication no # То же самое, что и предыдущее только для версии 2 HostbasedAuthentication yes # Если нет доверия к known_hosts, то их можно не использовать при hostbased # autentification. По умолчанию no IgnoreUserKnownHosts no
    # Чтобы запретить посылку хешей паролей через туннель ssh задайте значение # данной опции no. По умолчанию аутентификация по паролю разрешена PasswordAuthentication yes # Можно также разрешить пустые пароли, но это полный отстой, т.к. это огромная # дыра на сервере, через которую можно наделать много гадостей! Поэтому должно # быть no (по умолчанию) PermitEmptyPasswords no
    # Аутентификация через механизм PAM. PAMAuthenticationViaKbdInt no
    # Передача протокола иксов через туннель ssh X11Forwarding yes # Используем в качестве x-сервера данный, т.е. клиент, запуская у себя x-клиента # будет фактически использовать наш сервер, но все данные от сервера к клиенту # будут шифроваться, что есть хорошо! X11UseLocalhost yes # При логине пользователя выводим /etc/motd: в некоторых системах это отменено в # целях безопасности PrintMotd yes # Сообщаем пользователю время и место последнего логина, ситуация, аналогичная # предыдущей PrintLastLog yes # Посылать клиенту сообщения о доступности KeepAlive yes # Максимальное число возможных соединений, где не произошло аутентификации. Если # клиентов, не прошедших аутентификацию больше, то новые соединения не будут # обрабатываться MaxStartups 10 # Путь к файлу, который будет отображаться при входе клиента ДО аутентификации Banner /etc/ssh_message # Проверка соответствия ip адреса клиента и его символического имени в backzone, # затем снова сравнение имени с ip адресом. Таким образом (извращенным) # проверяется подлинность ip, но метод этот достаточно тормозной и по умолчанию # он отключен VerifyReverseMapping no
    # Новые системы, работающие через ssh. В данном примере определяется # "безопасный" ftp сервер - sftp, аналогичный доступ пользователя, но с # возможностью передачи файлов(т.е. пользователь получает доступ ко всем своим # файлам и нет возможности настройки разрешений и виртуальных пользователей, # как, например в proftpd). По сути дела подсистемы ssh могут обеспечивать # прохождение других протоколов по сети, но под "крылышком" ssh. Например, для # sftp сервера есть одноименный sftp клиент. Его интерфейс полностью идентичен # оригинальному ftp, но с одним отличием: происходит та же самая аутентификация # пользователя на удаленном сервере(методами ssh), но вместо оболочки с # пользователем взаимодействует подсистема, в данном случае sftp. Subsystem sftp /usr/lib/ssh/sftp-server

    Ну вот, вроде бы все настроено! Теперь я бы хотел поговорить о некоторых фичах, работающих в ssh. Для начала я бы хотел рассказать о туннелях. SSH имеет встроенную возможность передавать данные с локального порта на удаленный, используя сетевой туннель, причем данные, передаваемые через данный туннель будут шифроваться. То есть происходит аутентификация на удаленной системе, а затем начинается перенаправление трафика через туннель. Таким образом, можно перенаправлять любой трафик, а протокол иксов может работать в интерактивном режиме, для этого необходимо включить соответствующие опции в файлах конфигурации сервера и клиента(это было описано ранее). Для других же портов необходимо вызывать ssh с параметром -L{LOCAL_PORT}:{LOCAL_ADDRESS}:{REMOTE_PORT}:

    # ssh -L10101:localhost:101 server.test.ru

    Такой туннель довольно быстро умирает, т.к. сервер автоматически убивает «ленивых» клиентов. Поэтому можно применить метод, который позволяет устанавливать произвольное время удержания туннеля: выполнить sleep на удаленном сервере:

    # ssh -f -L10101:loclahost:101 server.test.ru sleep 100

    Данная команда держит туннель 100 секунд, чего достаточно для любого соединения. И еще одна вещь: когда по туннелю передаются данные, то он не уничтожается, что хорошо для реализации безопасного ftp-, smtp- и pop3-протоколов (впрочем, sftp-сервер имеется уже и в поставке openssh, применение его не должно вызвать затруднений sftp hostname, т.к. фактически это особая реализация ssh протокола и механизм работы sftp абсолютно идентичен механизму ssh). Чтобы отключить перенаправление портов, необходимо установить опцию sshd AllowTcpForwarding в no. Использование длительной задержки ssh-туннеля несколько уменьшает безопасность, т.к. во время ожидания злоумышленник имеет больше шансов на атаку (но механизм ssh версии 2 позволяет избежать подобной ситуации подписыванием передаваемых сообщений).

    Вот что сделал бы я для безопасного ssh. Для начала создал бы rsa-ключ длиной 4096 бит:

    # ssh-keygen -t rsa -b 4096

    Затем скопировал бы данный ключ с помощью флешки или ssh-copy-id на удаленный сервер(а):

    # ssh-copy-id -i $HOME/.ssh/id_rsa remote_host

    После этого запретил бы парольную и всякую host-based аутентификацию в sshd_config:

    IgnoreHosts yes RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication yes HostbasedAutentification no PasswordAuthentication no PermitEmptyPasswords no UseLogin no PermitRootLogin without-password

    И отключим потокол версии 1 (по умолчанию Protocol 2,1 и сервер падает к ssh 1, при неудаче ssh 2):

    Protocol 2 Ну, вот, теперь, чтобы зайти на сервак по ssh надо ввести нехилый (а он должен быть нехилый!) пароль секретного ключа. Немножко неудобно, не правда ли? Можно хранить пароль для секретного ключа в памяти на протяжении работы некоторой программы (например, bash) и при запросе его ssh клиентом доставать из памяти. Для этой цели служит программа ssh-agent (агент аутентификации ssh). Агент запускает необходимую программу и ждет добавления новых секретных ключей (ssh-agent хранит расшифрованные секретные ключи). Для этой цели есть другая программа - ssh-add, которая добавляет в агент ключи $HOME/.ssh/id_rsa, id_dsa, identity. Если необходимо добавить другие ключи, то надо запустить ssh-add с именем файла: ssh-add filename. Учтите, что при добавлении ключа в агент ssh-add вам все равно необходимо ввести пароль для его расшифровки, но пока агент находится в памяти (пока вызванная им программа не завершилась), вводить пароль секретного ключа не надо: ключ берется из ssh-agent. Причем контакт с ssh-agent может устанавливать только программа, запущенная им (и все ее дочерние процессы), т.к. устанавливаются переменные окружения. Обычный метод запуска ssh-agent: # ssh-agent bash # ssh-add Enter passphrase for ".ssh/id_rsa": Enter passphrase for ".ssh/id_dsa": .ssh/identity: No such file or directory

    После завершения работы оболочки ssh-agent завершается, а ключи удаляются из памяти. Ну, и наконец можно разрешить доступ определенных пользователей с определенных машин. Это делается полем AllowUsers в sshd_config или правилами iptables. Думаю, этого достаточно для нормальной и безопасной работы на удаленном сервере через ssh. Особо мнительные могут запретить доступ рута по ssh (PermitRootLogin no) и делегировать часть его прав с помощью sudo. Ну, и использовать протокол версии 2 (такие плюсы, как алгоритм вычисления симметрического ключа на основании пары асимметрических, и подписывание сообщений, передаваемых по сети, а также 2 версия протокола ssh быстрее первой). Существует множество клиентов ssh, работающих на разных ОС. Для Windows выделю

S ecure Sh ell, т. е. SSH – протокол, обеспечивающий защищённые соединения и передачу данных между двумя удалёнными компьютерами. Изначально создавался на замену таким системам как rlogin и rcp. Как понятно из полного названия протокола, система SSH позволяет соединяться и управлять удалённым узлом (компьютером, маршрутизатором и т. д.), при этом защищая весь передаваемый трафик с помощью высоконадёжного шифрования.
SSH широко применяется администраторами серверов для их настройки и управления, да и обычные продвинутые пользователи - владельцы, например, сайтов или виртуальных серверов активно используют SSH для подключения к своей учётной записи на хостинге и использования командной оболочки сервера.
Сразу после окончания разработки система SSH стала активно трансформироваться в закрытый коммерческий продукт в виде версии SSH2. Но благодаря сообществу GNU версии протокола SSH1 и SSH2 были реализованы в виде открытого и свободно распространяемого ПО openSSH. В Linux-системах используется именно этот метапакет.
Метапакет SSH базово включает в себя сервер SSH (sshd) в качестве програмы-демона, а также несколько утилит: ssh – удаленная регистрация и выполнение команд, scp – передача файлов и ssh-keygen – для генерации пар SSH-ключей.

Установка пакетов SSH

Как уже говорилось система ssh в Linux-системах распространяется в виде составного метапакета, поэтому для установки всех требуемых утилит ssh нужно выполнить всего одну команду:
В Ubuntu

$ sudo apt-get install ssh

$ yum -y install openssh-server openssh-clients

После чего начнется процесс установки

Как видно, менеджер пакетов сам распознает все зависимые и связанные пакеты и установит их. Также, по завершению установки, автоматически будет запущен SSH-сервер в режиме демона. Это можно проверить командой:
$ systemctl status sshd
или:
$ service sshd status даст тот же вывод. Теперь сервер работает с базовыми настройками по-умолчанию.

Настройка SSH

Режим работы SSH-сервера с настройками по-умолчанию хоть и является вполне работоспособным для небольших частных сетей, всё же нуждается в задании некоторых важных параметров для использования на высоконадёжных публичных серверах. Настройки демона хранятся в файле /etc/ssh/sshd_config. Посмотреть его можно командой

Cat /etc/ssh/sshd_config

В первую очередь следует обратить внимание на следующие параметры: Port, AddressFamily, ListenAddress . Первый глобально задаёт номер порта, через который будет работать соединение и если оставить его стандартным, т. е. 22, то велика вероятность, что он будет слишком часто сканироваться роботами.
Примечание: для задания активации параметра необходимо раскомментировать соответствующую строку - убрать символ «#» в её начале.
Второй параметр задаёт семейство используемых IP-адресов - IPv4 и IPv6. Если, к примеру, используются только адреса IPv4, то очень рекомендуется установить для параметра

AddressFamily значение inet: AddressFamily inet

Для адресов семейства IPv6 используется значение inet6.
Параметр ListenAddress позволяет задавать порты для отдельных сетевых интерфейсов:

ListenAddress 10.24.205.75:2123 ListenAddress 10.24.205.76:2124

Поскольку реализация openSSH позволяет работать с протоколами SSH1 и SSH2, то разумно отключить использование SSH1, т. к. эта версия является устаревшей. Работа по SSH1 крайне не рекомендуется: Protocol 2
Очень полезным является параметр, позволяющий проводить авторизацию и шифрование трафика с помощью специальных SSH-ключей:

PubkeyAuthentication yes

Следует заметить, что в таком случае серверу необходимо явно указывать, где хранятся открытые ключи пользователей. Это может быть как один общий файл для хранения ключей всех пользователей (обычно это файл etc/.ssh/authorized_keys), так и отдельные для каждого пользователя ключи. Второй вариант предпочтительнее в силу удобства администрирования и повышения безопасности:
AuthorizedKeysFile etc/ssh/authorized_keys # Для общего файла
AuthorizedKeysFile %h/.ssh/authorized_keys # Файл -> пользователь
Во втором варианте благодаря шаблону автоподстановки с маской «%h» будет использоваться домашний каталог пользователя.
Важно также отключать парольный доступ:

PasswordAuthentication no

Или же, в случае, если всё-таки необходимо использовать доступ по паролю, то обязательно нужно отключать авторизацию по пустому паролю:

PermitEmptyPasswords no

Для указания разрешённых или запрещённых пользователей и групп служат директивы DenyUsers, AllowUsers, DenyGroups, и AllowGroups. Значениями для них являются списки имён, разделяемых пробелами, например:

DenyUsers fred john AllowGroups root clients administrators

Следует также отключать root-доступ:

PermitRootLogin no

Иногда, когда следует задавать мультисерверную конфигурацию, очень удобно использовать алиасы (Aliases), что позволяет настроить сразу несколько режимов доступа (с разными хостами, портами и т. д.) и использовать их, указывая при этом конкретный алиас:

$ ssh alias_name

Настройки для алиасов хранятся либо глобально в /etc/ssh/ssh_config, либо раздельно для пользователей в ~/.ssh/config. Здесь нужно не спутать с ssh_config! Пример:

Host your_alias Port your_ssh_port HostName 0.0.0.0 # IP или имя хоста User your_user_name

Для применения сделанных настроек необходим перезапуск SSH-сервера:

$ systemctl restart sshd

$ service sshd restart

Настройка и использование клиента SSH
Для подключения по к серверу используется команда:

$ ssh user_name@host_name

где user_name – имя пользователя в системе, host_name – имя узла, к которому производится подключение, например:

$ ssh fred@fredwebserver

При этом утилита ssh запросит (в зависимости от настроек сервера) логин, пароль или парольную фразу для разблокировки приватного ключа пользователя.
В случае авторизации по ключу, должна быть предварительно сгенерирована пара SSH-ключей - открытый, который хранится на стороне сервера, обычно в файле.ssh/authorized_keys в домашнем каталоге пользователя, и закрытый - используется для авторизации клиента и хранится, как правило, в каталоге.ssh/ домашней директории пользователя. Открытый ключ представляет собой «цифровой слепок» закрытого ключа благодаря которому сервер «знает», кто «свой», а кто «чужой».
Для генерации ключей используется утилита ssh-keygen:

$ ssh-keygen

Утилита предложит выбрать расположение ключей (лучше всё оставить по-умолчанию), обычно это каталог ~/.ssh/, ввести парольную фразу для закрытого ключа. После чего будут сгенерированы открытый ключ id_rsa.pub и закрытый - id_rsa. Теперь нужно скопировать открытый ключ, т. е. «слепок» закрытого на сервер. Проще всего этого можно добиться командой:

Ssh-copy-id -i ~/.ssh/id_rsa.pub user_name@host_name

Теперь можно выполнить подключение командой ssh и запустить защищённый сеанс удалённого управления.
Важно заметить, что использование сгенерированных openSSH-ключей несовместимо с PPK-форматом, используемым по-умолчанию в таких комплексах как PuTTY. Поэтому необходимо конвертировать имеющиеся openSSH-ключи в формат PPK. Удобнее всего это делать с помощью утилиты PuTTY – puttygen.exe.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

Что такое и для чего нужен SSH

Безопасный шелл (SSH) - это сетевой протокол, обеспечивающий функции шелла на удалённой машине через безопасный канал. SSH несёт в себе различные улучшения безопасности, среди них аутентификация пользователя/хоста, шифрование данных и целостность данных, благодаря чему невозможны популярные атаки вроде подслушивания (eavesdropping), DNS/IP spoofing, подделка данных (data forgery), перехват соединения (connection hijacking) и т. д. Пользователям ftp, telnet или rlogin, которые используют протокол, передающий данные в виде открытого текста, крайне рекомендуется переключиться на SSH.

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

OpenSSH серверные/клиентские пакеты поставляются со следующими утилитами:

  • OpenSSH сервер: sshd (SSH daemon)
  • OpenSSH клиент: scp (безопасное удалённое копирование), sftp (безопасная передача файлов), slogin/ssh (безопасный удалённый вход), ssh-add (дополнение закрытого ключа), ssh-agent (агент аутентификации), ssh-keygen (управление ключами аутентификации).
Установка сервера и клиента OpenSSH на Linux

Если вы хотите установить сервер/клиент OpenSSH и настроить автоматический запуск сервера OpenSSH, следуйте следующим инструкциям, которые различаются в зависимости от дистрибутива.

Debian, Ubuntu или Linux Mint

$ sudo apt-get install openssh-server openssh-client

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

$ sudo update-rc.d ssh defaults

Fedora или CentOS/RHEL 7

$ sudo yum -y install openssh-server openssh-clients $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service

CentOS/RHEL 6

$ sudo yum -y install openssh-server openssh-clients $ sudo service sshd start $ sudo chkconfig sshd on

Arch Linux

$ sudo pacman -Sy openssh $ sudo systemctl start sshd service $ sudo systemctl enable sshd.service

Настройка сервера OpenSSH

Если вы хотите настроить сервер OpenSSH, вы можете редактировать общесистемный файл конфигурации размещённый в /etc/ssh/sshd_config.

Есть пара опций OpenSSH, которые могут заинтересовать:
По умолчанию, sshd прослушивает порт 22 и ожидает входящие соединения ssh. Изменив порт по умолчанию для ssh, вы можете предотвратить различные автоматизированные атаки хакеров.
Если ваша машина имеет более чем один физический сетевой интерфейс, возможно вы заходите уточнить, какой из них связан с sshd, для этого вы можете использовать опцию ListenAddress. Эта опция помогает улучшить безопасность посредством ограничения входящих SSH только через особый интерфейс.

HostKey /etc/ssh/ssh_host_key

Оция HostKey определяет гда размещён персональный хост ключ.

PermitRootLogin no

Оция PermitRootLogin – может ли root входить в систему посредством ssh.

AllowUsers alice bob

Используя опцию AllowUsers вы можете выборочно отключить службу ssh для определённых пользователей Linux. Можно задать множество пользователей, разделяя их пробелами.

После того, как был изменён /etc/ssh/sshd_config , убедитесь, что перезапустили службу ssh.

Для перезапуска OpenSSH на Debian, Ubuntu или Linux Mint:

$ sudo /etc/init.d/ssh restart

Для перезапуска OpenSSH на Fedora, CentOS/RHEL 7 или Arch Linux:

$ sudo systemctl restart sshd.service

Для перезапуска OpenSSH на CentOS/RHEL 6:

$ sudo service sshd restart

Как подключиться к SSH

Подключение к SSH из Linux

Пользователям Linux не нужно устанавливать дополнительных программ.

Подключение к SSH из Windows

Скрыто от гостей

.

Cygwin – это не просто клиент SSH. Это мощный комбайн, в котором поддерживаются многие команды Linux. Например, в Cygwin очень легко создавать SSL-сертификаты (точно также, как и в Linux). В Windows для создания самоподписанных сертификатов нужно поплясать с бубном. В Cygwin очень удобно пользоваться cURL (не нужно ничего устанавливать отдельно) и т. д. Те, кому не хватает на Windows командной строки и программ Linux, в лице Cygwin найдут себе отдушину.

Установка Cygwin проста. Переходим на

Скрыто от гостей

И скачиваем

Скрыто от гостей

Скрыто от гостей

Скачается крошечный файл - это установщик. Установщик графический. Хоть он и содержит большое количество опций, все они довольно простые и многие знакомы по другим графическим установщикам. Если что-то непонятно, просто нажимайте «Далее». Пожалуй, только следующее окно может привести в замешательство:

Здесь представленные все доступные для установки элементы. Нам не нужно прямо сейчас разбираться в них. Поскольку самые востребованные уже помечены для установки. А если чего-то в будущем будет не хватать, то легко можно доустановить нужное.

Соединение SSH (общее для Linux и Windows)

Пользователи Linux открывают консоль, пользователи Windows печатают в Cygwin.

SSH нужна следующая информация для подключения:

  • IP или имя хоста
  • номер порта
  • имя пользователя
  • пароль пользователя
Два из этих параметров SSH может предположить: имя пользователя и номер порта. Если порт не указан, то предполагается порт по умолчанию. Если не указан пользователь, то используется то же имя, что и в системе, из которой происходит подключение. Например, адрес хоста для подключения 192.168.1.36 . Если я наберу

Ssh 192.168.1.36

Я вижу следующее

Alex@MiAl-PC ~ $ ssh 192.168.1.36 The authenticity of host "192.168.1.36 (192.168.1.36)" can"t be established. ECDSA key fingerprint is SHA256:sIxZeSuiivoEQ00RXAQHxylxuEA8SC5r/YPhL8wfp8s. Are you sure you want to continue connecting (yes/no)?

Поскольку я подключаюсь к хосту первый раз, то это незнакомый хост. У меня спрашивают, хочу ли я продолжить. Я набираю yes :

Warning: Permanently added "192.168.1.36" (ECDSA) to the list of known hosts. [email protected]"s password:

Хорошо, хост 192.168.1.36 добавлен в список знакомых хостов. У меня запрашивается пароль для пользователя Alex. Поскольку на сервере с SSH нет такого пользователя, но я нажимаю Ctrl+C (для разрыва) и ввожу команду вместе с именем пользователя удалённой системы. Пользователь вводится перед адресом удалённой машины и отделяется от адреса символом @. Символ @ на английском читается как at и можно перевести как «в». Т.е. запись [email protected] можно истолковать как «пользователь mial в машине 192.168.1.36 ».

Ssh [email protected]

Приглашение Alex@MiAl-PC сменилось приглашением mial@mint . Это означает, что мы уже на удалённой машине, т. е. у нас уже произошло соединение. Если нужно указать порт (если он отличается от стандартного), то порт нужно указывать после ключа -p. Например так:

Ssh [email protected] -p 10456

После подключения нас встречает примерно такое приветствие:

Linux mint 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Jun 16 15:32:25 2015 from 192.168.1.35

Из него следует, что удалённая машина - это Linux Mint, с ядром 3.16, 64-битная версия. Также важная информация о времени последнего входа и IP адресе с которого произошло соединение. Если время и IP вам незнакомы, а вы являетесь единственным пользователем, то ваша система скомпрометирована и нужно принимать соответствующие меры.

Наберём несколько команд, чтобы убедиться где мы и кто мы: pwd, [B]uname -a и т. д.:

Чтобы закончить сессию (отключиться), наберите

Или нажмите Ctrl+D .

Вход в SSH без ввода пароля

Во-первых, это просто удобнее. Во-вторых, это безопаснее.

Во-первых, нам нужно создать rsa ключи. Если вы пользователь Linux, то у вас всё в порядке. Если вы пользователь Windows, но вы не послушали мой совет и выбрали PuTTY, то у вас проблема и думайте сами, как её решать. Если у вас Cygwin, то всё также в порядке.

Если вы успели залогиниться на удалённой системе, разлогинтесь. После этого наберите

Ssh-keygen -t rsa

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

Теперь на удалённой машине нам нужно создать каталог.ssh. Про выполнение команда на удалённой машине ещё будет рассказано ниже. Пока просто копируете команду, не забывая поменять IP адрес и имя пользователя на свои:

Ssh [email protected] mkdir .ssh

Теперь нам нужно скопировать содержимое файла id_rsa.pub на удалённую машину. Сделать это очень просто (не забываем менять данные на свои):

Cat .ssh/id_rsa.pub | ssh [email protected] "cat >> .ssh/authorized_keys"

Теперь просто логинимся и больше никакой пароль у нас не спрашивают. И так теперь будет всегда.

Выполнение команд на удалённом сервере без создания сессии шелла

Кроме открытия сессии шелла на удалённой системе, ssh также позволяет выполнять отдельные команды на удалённой системе. Например, для выполнения команды tree на удалённом хосте с именем remote-sys и отображением результатов на локальной системе, нужно сделать так:

Ssh remote-sys tree

Мой реальный пример:

Ssh [email protected] tree

Используя эту технику, можно делать интересные вещи, вроде такой, как выполнение команды ls на удалённой системе и перенаправление вывода в файл на локальной системе:

Ssh remote-sys "ls *" > dirlist.txt

Реальный пример:

Ssh [email protected] "ls *" > dirlist.txt cat dirlist.txt

Обратите внимание на одиночные кавычки в вышеприведённой команде. Это сделано потому, что мы не хотим, чтобы раскрытие пути было выполнено на локальной машине; поскольку нам нужно это выполнение на удалённой системе. Также если мы хотим стандартный вывод перенаправить в файл на удалённой машине, мы можем поместить оператор редиректа и имя файла внутри одиночных кавычек:

Ssh remote-sys "ls * > dirlist.txt"

Передача стандартного вывода с локальной машины на удалённую по ssh

Не менее интересный вариант выполнения команд приведён немного выше:

Cat .ssh/id_rsa.pub | ssh [email protected] "cat >> .ssh/authorized_keys"

  • Команда cat построчно считывает и отображает содержимое файла.ssh/id_rsa.pub , расположенного на локальной машине.
  • | (труба) передаёт то, что должно было бы появиться в стандартном выводе, другой команде.
  • Вместо команды, которая должна была бы обрабатывать передаваемые ей строки, происходит соединение к удалённой системе (ssh [email protected]).
  • На удалённую систему приходят строки, для которых предусмотрена команда cat >> .ssh/authorized_keys . Т.е. содержимое стандартного вывода построчно записывается в файл.ssh/authorized_keys, находящийся на удалённой машине.
Открытие графической программы, расположенной на удалённом компьютере

Для следующего фокуса нужно два компьютера с системой Linux. К сожалению, даже Cygwin с этим трюком не справляется. Причём оба Linux"а должны быть с графическим пользовательским интерфейсом.

Туннелирование с SSH

Среди всего прочего, что происходит когда устанавливается соединение с удалённым хостом через SSH, это создание зашифрованного туннеля, который образуется между локальной и удалённой системами. Обычно, этот туннель используется для того, чтобы набранные на локальной машине команды безопасно были переданы удалённой машине, а результат, также безопасно, прислан обратно.

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

Пожалуй самая часто используемая из этих функций - это возможность транслировать трафик систем X Window. На системе с запущенным X сервером (это машины, которые имеют графический пользовательский интерфейс) возможно запустить программу X клиента (графическое приложение) на удалённой системе и видеть результаты её работы на локальной системе. Сделать это просто. Например, я хочу подключиться к удалённому хосту remote-sys и на нём я хочу запустить программу xload. При этом видеть графический вывод этой программы я смогу на локальном компьютере. Делается это так:

Ssh -X remote-sys xload

Реальный пример:

Ssh -X [email protected] gedit

Т.е. SSH запускается с ключом -X. А затем просто запускается программа. Посмотрите на скриншот.

Я нахожусь в Kali Linux. Я успешно логинюсь к удалённому компьютеру по SSH. После этого я запустил программу gedit. Этой программы, может быть, даже нет на Kali Linux, но она точно есть в Linux Mint, к которой я и подключился. Результат работы этой программы я могу видеть на экране так, будто бы программа запущена локально. Но, повторюсь, я хочу, чтобы вы это поняли, запущенной программы gedit на локальном компьютере нет. Если я захочу сохранить результат работы gedit (или любой другой программы, открытой таким образом), то окажется, что она работает в окружении удалённого компьютера, видит его файловую систему и т. д. Это удобно, когда вы хотите настроить удалённый компьютер используя графический интерфейс.

О том, как передать изображение со всего рабочего стола вы узнаете в этой же статье далее, в секции «Как настроить VNC через SSH».

На некоторых системах для этого «фокуса» нужно использовать опцию “ -Y ” вместо опции “ -X ”.

Копирование с/на удалённый компьютер (scp и sftp)

scp

Пакет OpenSSH также включает две программы, которые использует зашифрованный туннель SSH для копирования файлов по сети. Первая программа – scp («безопасное копирование») – используется чаще, как и схожая с ней программа cp для копирования файлов. Наиболее заметная разница в том, что источником файла может быть удалённый хост после которого следует двоеточие и расположение файла. Например, если мы хотим скопировать документ, названный document.txt из нашей домашней директории на удалённую систему remote-sys в текущей рабочей директории на нашей локальной системе мы можем сделать так:

Scp remote-sys:document.txt . document.txt 100% 177 0.2KB/s 00:00

Реальный пример:

# удалим файл на локальной машине, если он есть rm dirlist.txt # создадим файл на удалённой машине ssh [email protected] "ls * > dirlist.txt" # проверим его наличие ssh [email protected] "ls -l" # скопируем его на локальную машину scp [email protected]:dirlist.txt . # проверим его содержимое cat dirlist.txt

  • [email protected] - имя пользователя и удалённый хост,
  • . (точка) означает, что файл нужно скопировать в текущую рабочую директорию на удалённом сервере, при этом имя файла останется прежним, т. е. nfile.txt
    • Памятка :

    Для копирования файла с B на A когда залогинены в B:
    scp /path/to/file username@a:/path/to/destination
    Копирование файла с B на A когда залогинены в A:
    scp username@b:/path/to/file /path/to/destination

    sftp

    Вторая программа для копирования файлов через SSH - это sftp . Как следует из её имени, она является безопасным заменителем ftp программ. sftp работает как и оригинальная ftp программа. Тем не менее, вместо отправки чистым текстом она использует зашифрованный туннель SSH. Важным преимуществом sftp перед ftp является то, что для неё не требуется запущенный FTP сервер на удалённом хосте. Для неё требуется только SSH сервер. Это означает, что любая удалённая машина, которая подключена через SSH клиент может также быть использована как FTP-подобный сервер. Вот пример сессии:

    Alex@MiAl-PC ~ $ sftp [email protected] Connected to 192.168.1.36. sftp> ls dirlist.txt newfile.txt nfile.txt temp Видео Документы Загрузки Изображения Музыка Общедоступные Рабочий стол Шаблоны sftp> lls dirlist.txt nfile.txt sftp> ls temp temp/TakeMeHome sftp> cd temp/ sftp> get TakeMeHome Fetching /home/mial/temp/TakeMeHome to TakeMeHome sftp> bye

    SFTP протокол поддерживается многими графическими файловыми менеджерами, которые можно найти в дистрибутивах Linux. Используя как Nautilus (GNOME), так и Konqueror (KDE), мы можем вводить URI (ссылки) начинающиеся на sftp:// в строку перехода и работать с файлами, расположенными на удалённой системе с запущенным SSH сервером.

     

    Возможно, будет полезно почитать: