что такое ssh key

Авторизация по ключу SSH

Как работают ключи SSH?

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

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

Как создать ключи SSH?

Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.

И так, генерация ключей ssh выполняется командой:

Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке

/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.

Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.

Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.

Загрузка ключа на сервер

Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.

При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл

/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.

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

/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:

Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль. Теперь вы можете использовать созданный ключ для аутентификации на сервере:

Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.

Отключение проверки пароля

Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:

sudo vi /etc/ssh/sshd_config

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

sudo service ssh restart

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

Выводы

В этой статье мы рассмотрели как выполняется авторизация по ключу ssh, настройка ключей ssh и добавить ssh ключ. Теперь вы можете войти на сервер без ввода пароля. Если у вас остались вопросы, спрашивайте в комментариях!

Источник

Подробные инструкции. Создание ключей SSH для аутентификации на виртуальной машине Linux в Azure и управление этими ключами

Применимо к: ✔️ виртуальные машины Linux ✔️ гибкие масштабируемые наборы

С помощью пары ключей Secure Shell (SSH) можно создать виртуальную машину Linux, использующую ключи SSH для проверки подлинности. В этой статье показано, как создать и использовать пару файлов открытого и закрытого ключей SSH RSA для клиентских соединений по SSH.

сведения о создании ключей ssh и их использовании для подключения к виртуальной машине Linux с Windows компьютера см. в статье использование ключей ssh с Windows в Azure. Вы также можете использовать портал Azure для создания ключей SSH и управления ими при создании виртуальных машин на портале.

Общие сведения о SSH и ключах

SSH — это протокол зашифрованного подключения, обеспечивающий безопасный вход в систему через незащищенные соединения. SSH — это протокол подключения по умолчанию для виртуальных машин Linux, размещенных в Azure. Хотя протокол SSH и обеспечивает зашифрованное подключение, использование паролей для соединений SSH все же сохраняет уязвимость виртуальной машины к атакам методом подбора. Мы рекомендуем подключаться к виртуальной машине по SSH с помощью пары «открытый ключ — закрытый ключ», также известных как ключи SSH.

Открытый ключ размещается на виртуальной машине с ОС Linux.

Закрытый ключ остается в локальной системе. Его нужно защищать и нельзя никому предоставлять.

При использовании клиента SSH для подключения к виртуальной машине Linux (с открытым ключом) удаленная виртуальная машина проверяет, имеется ли у клиента правильный закрытый ключ. Если у клиента есть закрытый ключ, он получает доступ к виртуальной машине.

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

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

Поддерживаемые форматы ключей SSH

В настоящее время платформа Azure поддерживает пары из открытого и закрытого ключей SSH-2 RSA длиной не менее 2048 битов. Другие форматы ключей, например ED25519 и ECDSA, не поддерживаются.

Использование ключей SSH и их преимущества

/.ssh/authorized_keys на виртуальной машине. Ключи SSH в

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

Создание ключей с помощью ssh-keygen

Ключи SSH по умолчанию хранятся в каталоге

Простой пример

Приведенная ниже команда ssh-keygen создает файлы 4096-разрядных открытого и закрытого ключей SSH RSA в каталоге

/.ssh по умолчанию. Если в текущем каталоге существует пара ключей SSH, они будут перезаписаны.

Подробный пример

В следующем примере показаны дополнительные параметры команды для создания пары ключей SSH RSA. Если в текущем каталоге существует пара ключей SSH, они будут перезаписаны.

Описание команды

ssh-keygen — программа, с помощью которой создаются ключи.

-m PEM — преобразование ключа в формат PEM.

-t rsa — тип создаваемого ключа; в данном случае создается ключ в формате RSA.

-b 4096 — количество битов в ключе; в данном случае ключ содержит 4096 битов.

-C «azureuser@myserver» — комментарий, который будет добавлен в конец файла открытого ключа для идентификации. Обычно в качестве комментария используется адрес электронной почты, но вы можете выбрать для своей инфраструктуры любой удобный метод идентификации.

-N mypassphrase — дополнительная парольная фраза, используемая для доступа к файлу закрытого ключа.

Пример с ssh-keygen

Сохраненные файлы ключей

Enter file in which to save the key (/home/azureuser/.ssh/id_rsa):

Список содержимого каталога

Парольная фраза ключа

Enter passphrase (empty for no passphrase):

Мы настоятельно рекомендуем добавить парольную фразу в закрытый ключ. Если не защитить файл ключа парольной фразой, любой пользователь, у которого есть этот файл, сможет использовать его, чтобы войти на любой из серверов, на котором используется соответствующий открытый ключ. Добавив парольную фразу, вы усилите защиту на случай, если другой пользователь получит доступ к файлу закрытого ключа. Это даст вам время, чтобы изменить ключи.

Автоматическое создание ключей во время развертывания

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

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

/.ssh/id_rsa.pub расположением файла собственного открытого ключа.

Выходные данные должны быть следующего вида (здесь показана исправленная версия).

Если вы копируете содержимое файла открытого ключа и вставляете его на портале Azure или в шаблон Resource Manager, в этом содержимом не должно быть дополнительных пробелов или символов разрыва строки. Например, при использовании macOS, чтобы скопировать содержимое файла открытого ключа (по умолчанию это

/.ssh/id_rsa.pub ), вы можете передать его в pbcopy (или другие аналогичные программы Linux, например xclip ).

Если вы предпочитаете использовать открытый ключ в многострочном формате, можно создать ключ в формате RFC4716 в контейнере pem открытого ключа, созданного ранее.

Чтобы создать ключ в формате RFC4716 из существующего открытого ключа SSH, выполните следующую команду:

Установление SSH-подключения к виртуальной машине с помощью клиента SSH

С помощью открытого ключа, развернутого на виртуальной машине Azure, и закрытого ключа в локальной системе установите SSH-подключение к виртуальной машине, используя ее IP-адрес или DNS-имя. Замените azureuser и myvm.westus.cloudapp.azure.com в приведенной команде, указав имя пользователя администратора и полное доменное имя (или IP-адрес).

Если при создании пары ключей вы указали парольную фразу, введите ее при появлении запроса во время входа в систему. (Сервер добавляется в папку

Если виртуальная машина использует политику доступа JIT, запросите доступ, прежде чем подключиться к виртуальной машине. Дополнительные сведения о политике JIT см. в статье Управление доступом к виртуальным машинам с помощью JIT-доступа.

Использование ssh-agent для хранения парольной фразы закрытого ключа

С помощью ssh-agent и ssh-add сообщите системе SSH о файлах ключей, чтобы вам не нужно было использовать парольную фразу в интерактивном режиме.

Копирование ключа на имеющуюся виртуальную машину с помощью ssh-copy-id

Если виртуальная машина Linux уже создана, вы можете добавить для нее новый открытый ключ SSH с помощью ssh-copy-id :

Создание и настройка файла конфигурации SSH

Чтобы ускорить процесс входа и оптимизировать поведение клиента SSH, можно создать и настроить файл конфигурации SSH

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

Изменение файла для добавления новой конфигурации SSH

Добавьте параметры конфигурации для виртуальной машины узла. В этом примере имя виртуальной машины — myvm, а имя учетной записи — azureuser.

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

Теперь, когда у вас есть пара ключей SSH и настроенный файл конфигурации SSH, вы можете быстро и безопасно входить на виртуальную машину Linux. При выполнении следующей команды служба SSH находит и загружает все параметры из блока Host myvm в файле конфигурации SSH.

При первом входе на сервер с использованием ключа SSH команда запрашивает парольную фразу для этого файла ключа.

Дальнейшие действия

Следующий шаг — создание виртуальных машин Linux Azure с помощью нового открытого ключа SSH. Виртуальные машины Azure, созданные с использованием открытого ключа SSH в качестве данных для входа, защищены лучше, чем виртуальные машины, созданные с помощью метода по умолчанию, предусматривающего использование паролей.

Источник

Как создать ключ для авторизации по SSH и добавить его на сервер?

SSH-ключи представляют собой пару — закрытый и открытый ключ. Закрытый должен храниться в закрытом доступе у клиента, открытый отправляется на сервер и размещается в файле authorized_keys.

Создание SSH-ключей в Linux на примере CentOS

На клиентской стороне должен быть установлен пакет ssh (openssh). На серверах FirstVDS с шаблонами по умолчанию необходимое ПО уже установлено.

На клиентском компьютере в командной строке выполните команду генерации ключей:

Пароль (passphrase) используется для ограничения доступа к закрытому ключу. Пароль усложнит использование ключа третьими лицами в случае утраты. Если не хотите использовать секретную фразу, нажмите Enter без заполнения строки.

Успешно сгенерировав пару ключей, вы увидите уведомление:

Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.

Создание SSH-ключей на Windows с PuTTYgen

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

Откройте файл authorized_keys через WinSCP и файл, в который вы сохранили открытый ключ (public), на локальном компьютере текстовым редактором. Скопируйте значение ключа, сохраните и закройте файл в WinSCP.

При запуске PuTTY укажите путь к закрытому ключу на локальном компьютере. Для этого во вкладке Connections → Auth выберите необходимый путь.

Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.

Отключение аутентификации по паролю

Подключитесь к серверу по SSH, используя пароль, и откройте файл sshd_config для редактирования.

Перезапустите службу sshd.

Источник

Рукопожатие SSH простыми словами

Secure Shell (SSH) — широко используемый протокол транспортного уровня для защиты соединений между клиентами и серверами. Это базовый протокол в нашей программе Teleport для защищённого доступа к инфраструктуре. Ниже относительно краткое описание рукопожатия, которое происходит перед установлением безопасного канала между клиентом и сервером и перед началом полного шифрования трафика.

Обмен версиями

Рукопожатие начинается с того, что обе стороны посылают друг другу строку с номером версии. В этой части рукопожатия не происходит ничего чрезвычайно захватывающего, но следует отметить, что большинство относительно современных клиентов и серверов поддерживают только SSH 2.0 из-за недостатков в дизайне версии 1.0.

Обмен ключами

Инициализация обмена ключами

Обмен ключами начинается с того, что обе стороны посылают друг другу сообщение SSH_MSG_KEX_INIT со списком поддерживаемых криптографических примитивов и их предпочтительным порядком.

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

Криптографические примитивы Teleport по умолчанию

Инициализация протокола Диффи — Хеллмана на эллиптических кривых

Стоит подчеркнуть, что эта ключевая пара эфемерна: она используется только для обмена ключами, а затем будет удалена. Это чрезвычайно затрудняет проведение класса атак, где злоумышленник пассивно записывает зашифрованный трафик с надеждой украсть закрытый ключ когда-нибудь в будущем (как предусматривает закон Яровой — прим. пер.). Очень трудно украсть то, чего больше не существует. Это свойство называется прямой секретностью (forward secrecy).

Рис. 1. Генерация сообщения инициализации обмена ключами

Ответ по протоколу Диффи — Хеллмана на эллиптических кривых

Затем сервер генерирует нечто, называемое хэшем обмена H, и подписывает его, генерируя подписанный хэш HS (подробнее на рис. 3). Хэш обмена и его подпись служат нескольким целям:

Рис. 2. Генерация хэша обмена H

Такое сообщение означает, что представленного ключа нет в вашей локальной базе данных известных хостов. Хороший способ избежать таких сообщений — использовать вместо ключей сертификаты SSH (что Teleport делает по умолчанию), которые позволяют вам просто хранить сертификат удостоверяющего центра в локальной базе известных хостов, а затем проверять все хосты, подписанные этим УЦ.

Рис. 3. Генерация ответа при обмене ключами ECDH

Новые ключи

Перед тем, как начать массовое шифрование данных, остался последний нюанс. Обе стороны должны создать шесть ключей: два для шифрования, два вектора инициализации (IV) и два для целостности. Вы можете спросить, зачем так много дополнительных ключей? Разве не достаточно общего секрета K? Нет, не достаточно.

Во-первых, почему нужны отдельные ключи для шифрования, целостности и IV. Одна из причин связана с историческим развитием протоколов, таких как TLS и SSH, а именно с согласованием криптографических примитивов. В некоторых выбранных криптографических примитивах повторное использование ключа не представляет проблемы. Но, как верно объясняет Хенрик Хеллстрём, при неправильном выборе примитивов (например, AES-256-CBC для шифрования и и AES-256-CBC-MAC для аутентификации) последствия могут быть катастрофическими. Следует отметить, что разработчики протоколов постепенно отказываются от такой гибкости, чтобы сделать протоколы более простыми и безопасными.

Далее, зачем используются ключи каждого типа.

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

Ключи целостности обычно используются с кодом проверки подлинности сообщения (MAC), чтобы гарантировать аутентичность шифротекста. В отсутствие проверки целостности злоумышленник может изменить шифротекст, который передаётся по открытым каналам, и вы расшифруете поддельное сообщение. Такая схема обычно называется Encrypt-then-MAC.

Следует отметить, что современные шифры AEAD (аутентифицированное шифрование с присоединёнными данными, когда часть сообщения шифруется, часть остаётся открытой, и всё сообщение целиком аутентифицировано) вроде aes128-gcm@openssh.com и chacha20-poly1305@openssh.com фактически не используют производный ключ целостности для MAC, а выполняют аутентификацию внутри своей конструкции.

Векторы инициализации (IV) обычно представляют собой случайные числа, используемые в качестве входных данных для симметричного шифра. Их цель состоит в том, чтобы гарантировать, что одно и то же сообщение, зашифрованное дважды, не приведёт к одному и тому же шифротексту. Необходимость такой процедуры отлично демонстрирует знаменитое изображение с пингвином Туксом, зашифрованное в режиме электронной кодовой книги (ECB).

Слева направо. (1) Открытый текст в виде изображения. (2) Криптограмма, полученная шифрованием в режиме ECB. (3) Криптограмма, полученная шифрованием в режиме, отличном от ECB. Изображение представляет собой псевдослучайную последовательность пикселей

Использование (и взлом) векторов IV — интересная тема сама по себе, о которой написал Филиппо Вальсорда.

Наконец, почему ключи идут в парах? Как отметил Томас Порнин, если используется только один ключ целостности, злоумышленник может воспроизвести клиенту отправленную ему запись, и он будет считать её действительной. Со спаренными ключами целостности (у сервера и клиента), клиент выполнит проверку целостности шифротекста и такой трюк не сработает.

Теперь с пониманием того, зачем нужны эти ключи, давайте посмотрим, как они генерируются, согласно RFC:

Здесь используется алгоритм хэширования SHA <256, 384 или 512>в зависимости от алгоритма обмена ключами, а символ || подразумевает конкатенацию, то есть сцепление.

Рис. 4:. Генерация начального вектора IV. Генерация для других ключей происходит по той же схеме, если заменить A и B на C, D, E и F, соответственно

Заключение

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

Вот как рукопожатие SSH устанавливает безопасное соединение между клиентами и серверами.

Источник

Памятка пользователям ssh

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

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

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

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

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

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

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

/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.

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

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

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

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

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

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

Ключ сервера

/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

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

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

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Копирование файлов

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

scp path/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 warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал

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

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

sshfs

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

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

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:

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

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

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

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

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

Удалённое исполнение кода

ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

ssh user@server ls /etc/

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

Это нас приводит следующей фиче:

Проброс stdin/out

Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

ssh user@8.8.8.8 command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — user@8.8.8.8:/path/remote_file

Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»

Есть и вот такой головоломный приём использования pipe’а (любезно подсказали в комментариях в жж):

Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.

Алиасы

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

Можно прописать общесистемные alias’ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.

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

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

Опции по умолчанию

По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.

Проброс X-сервера

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

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

Socks-proxy

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

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

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

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

Подключение в режиме sock-proxy выглядит так:

Вот так выглядит мой конфиг:

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

/.ssh/config с ноутбука, который описывает vpn

(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)

Проброс портов

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

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

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

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

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

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost’у.

Итоговая конфигурация: запросы на localhost:3333 на ‘A’ должны обслуживаться демоном на localhost:3128 ‘Б’.

Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

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

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

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

Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

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

Реверс-сокс-прокси

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

Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up 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, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

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

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

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

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

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

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

Эту клёвую настройку я не знал, и раскопал её redrampage.

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

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

Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.

Источник