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
SSH — защищенный протокол для удаленного доступа к компьютерам. Через SSH можно выполнять операции в командной строке компьютера, который физически находится в другом месте.
Иными словами, SSH — это дистанционная командная строка. Визуально вы работаете на своем компьютере, но в реальности — на другом.
Что значит «протокол»?
Протокол — это набор соглашений, правил, по которым разные программы могут обмениваться информацией. SSH — это набор правил, который известен и вашему компьютеру, и физически отдаленному компьютеру.
Пример: вы вводите команду удаления файла, и эта команда передается на другой компьютер и выполняется там. Ответ (или сообщение об ошибке) возвращается и показывается на вашем компьютере.
Что значит «защищенный»?
Вся информация передается в зашифрованном виде. Подобно тому, как некоторые сайты работают по HTTPS, шифруя информацию. Например, ваш онлайн-банкинг обязательно должен работать по защищенному соединению. В таком случае даже если всю информацию перехватывает злоумышленник, он не сможет расшифровать её.
Для чего нужен SSH?
Не всегда есть возможность физически находиться у компьютера, с которым нужно работать. Например, если вы хотите создать свой сайт, то он будет размещен на компьютере хостинг-провайдера. Этот компьютер может находиться на другом конце света. Вам нужен способ запускать команды на этом компьютере не выходя из своего дома.
Как подключаться по SSH?
Для подключения к удаленной машине по SSH нужен клиент — специальная программа. В *nix-подобных системах (Linux, macOS) клиент обычно установлен в системе по умолчанию, и достаточно открыть терминал. В Windows нужно скачать сторонний клиент, например, Putty.
Для подключения нужно указать адрес сервера и, опционально, имя пользователя и порт. Вот как выглядит команда при использовании консольного клиента (в терминале):
Например, для подключения к серверу 52.307.149.244 в аккаунт ivan нужно ввести:
В графическом клиенте вроде Putty нужно ввести ту же информацию в соответствующие поля:
Fingerprint
При первом подключении появится сообщение:
Введите yes в первый раз.
Это нужно для повышения безопасности. При настройке SSH-сервера создается уникальная комбинация символов — fingerprint («отпечатки пальцев»). Ваш компьютер запоминает эту комбинацию и сверяет ее при каждом новом соединении. Если кто-то переустановит SSH-сервер, или всю операционную систему, или вообще заменит удаленный компьютер, сохранив его адрес, то при следующем соединении вы узнаете об этом, потому что изменится fingerprint.
Если fingerprint не меняется, то такое сообщение не будет появляться.
Подключение по SSH по паролю
Простейший вариант — подключение по паролю. После ввода команды ssh система запросит пароль:
Пароль придется вводить каждый раз.
Подключение по SSH по ключу, без пароля
Для удобного подключения по SSH (и многим другим сервисам) без ввода пароля можно использовать ключи.
Нужно создать пару ключей: приватный (закрытый) ключ и публичный (открытый) ключ. Приватный ключ нужно хранить и никогда никому не показывать. Публичный ключ можно показывать всем и распространять свободно.
Эти ключи связаны друг с другом таким образом, что зашифровав информацию одним ключом, расшифровать ее можно только другим. Например, если ваш друг зашифрует письмо вашим публичным ключом, то прочитать его сможете только вы, потому что для этого нужен ваш приватный ключ. И наоборот: если вы зашифруете что-то своим приватным ключом, то расшифровать его можно только вашим публичным ключом. Так как публичный ключ доступен всем, любой может расшифровать это сообщение. Но он может быть уверен, что сообщение пришло именно от вас. В этом заключается идея цифровой подписи.
Генерация ключей
Создадим пару ключей:
Программа запустится и спросит, куда сохранять ключи:
Программа запросит passphrase. Это вроде пароля для ключа. Можно просто нажать Enter и пропустить этот шаг. Или ввести passphrase — тогда его нужно будет вводить каждый раз, когда используется ключ.
Теперь у вас есть два файла:
/.ssh/id_rsa — приватный ключ. Никогда никому и никуда не передавайте его!
/.ssh/id_rsa.pub — публичный ключ. Спокойно распространяйте его.
В Windows можно использовать ssh-gen в подсистеме Ubuntu for Windows или в командной строке Git for Windows. Или создавать ключи графической утилитой вроде PuTTYgen.
Загрузка публичного ключа на сервер
Нужно добавить публичный ключ на сервер в файл
Другой способ — подключиться по паролю, открыть в редакторе файл
/.ssh/authorized_keys и добавить в конец текст из вашего файла
После включения соединений по ключу рекомендуется отключить подключение по паролю.
ssh-agent
При работе с ключами возможны две неудобные ситуации:
ssh-agent решает эти проблемы. Этот агент аутентификации (authentication agent) работает на фоне в *nix-системах. В зависимости от системы, вам, возможно, придется установить и настроить его автозапуск самостоятельно.
Если добавить ключ к агенту, то:
ssh-add /home/demo/.ssh/id_rsa добавит ключ id_rsa в запущенный в системе агент. Если у него есть passphrase, то агент попросит ввести его.
Если запустить ssh-add без аргументов, то будут добавлены ключи
ssh-agent привязан к сессии. Поэтому, например, если перезагрузить компьютер, то ключи нужно будет добавлять в агент заново.
Форвардинг (проброс) ключей
Если вы подключились к удаленному серверу X, и с него хотите подключиться к другому серверу Y, например, чтобы сделать git pull с GitHub’а, то придется держать копию ваших ключей на сервере X.
Ключи, добавленные к агенту аутентификации (ssh-agent) станут доступными на удаленном сервере. При этом файлы-ключи физически не будут находиться на сервере.
Частые вопросы
Чем Telnet отличается от SSH?
Telnet это конкретная программа с графическим интерфейсом, с помощью которой можно соединяться по SSH. Обычно ей пользуются только Windows пользователи, в Linux и MacOS используют консольную утилиту ssh.
Защита с помощью SSH ключей
Это первая из серии статей, рассказывающих об особенностях использования SSH. Мы начнем с рассмотрения стандартных SSH ключей, изучив процесс верификации, чтобы гарантировать, что вы не стали объектом атаки. Обратите внимание, что эта статья применима к широко используемому приложению OpenSSH, которое присутствует в большинстве Unix-подобных операционных систем, а не к коммерческой версии SSH.
Это первая из серии статей, рассказывающих об особенностях использования SSH. Мы начнем с рассмотрения стандартных SSH ключей, изучив процесс верификации, чтобы гарантировать, что вы не стали объектом атаки. Обратите внимание, что эта статья применима к широко используемому приложению OpenSSH, которое присутствует в большинстве Unix-подобных операционных систем, а не к коммерческой версии SSH.
SSH ключи как защита от атак «человек посередине»
Проверка подлинности хоста это не уникальность SSH. В любом приличном защищенном протоколе есть набор способов верификации. Например, давайте рассмотрим HTTPS, зашифрованную SSL/TLS версию HTTP. Он также предоставляет возможность верификации хоста почти таким же способом, как и SSH. Проверка подлинности хоста средствами HTTP представляет собой следующее. Я возьму на себя смелость, говоря SSL подразумевать SSH, чтобы была ясность в сравнении ниже. [сноска 2]
SSH ключи в действии
Так как мы подключаемся к этой машине впервые, и SSH не работает по принципу третьего доверенного лица, такого как Certificate Authorities в мире SSL/TLS, вся работа, связанная с управлением ключами, лежит на вас. Ваш клиент показывает отпечаток ключа (key fingerprint), простую для чтения строку чисел, которую вы можете использовать для проверки ключа вручную, что мы и сделаем позже. Если вы отвечаете «Да, отпечаток правильный», ваш SSH клиент продолжит аутентификацию, дав вам возможность ввести ваш пароль и приступить к работе.
Каждая запись в known_hosts является большой строкой с тремя или больше пробелами, отделяющими поля следующим образом:
Подтверждение подлинности ключа
Лучший способ проверки подлинности ключа состоит в использовании нескольких различных методов. Например, владелец системы может разместить отпечаток ключа на своей защищенной SSL веб странице. В одном месте, где я работал, ключ главного сервера был напечатан на наших телефонных карточках, так, чтобы мы могли проверить его, всего лишь заглянув в бумажник, при посещении Интернет-кафе.
Если вышеописанный способ вам не доступен, проверить ключ системы, в которую вы вошли, можно следующим образом. Открытый ключ обычно доступен в директории /etc/ssh/, так что после входа в систему вы можете проверить отпечаток ключа (используя ssh-keygen), который вы приняли во время входа в систему. (ssh-keygen также используется для создания SSH ключей и Identities/PubKeys, которые мы обсудим позже.)
Вернемся к первому соединению, которое мы создали, и посмотрим, как мы можем проверить отпечаток ключа:
Выше мы видим, как пользователь принимает ключ, входит в систему, а затем проверяет ключ вручную с помощью ssh-keygen. Если отпечатки совпадают, вы можете с большой вероятностью быть уверены [сноска 4], что вы подключились к правильному серверу, даже при условии, что вы заранее не знали открытый ключ.
Проверка ключа
SSH имеет три способа реагирования на неопознанный или измененный ключ, основанных на значении переменной StrictHostKeyChecking: StrictHostKeyChecking=no Это самое небезопасное значение, разрешающее соединение с сервером вслепую. Если ключ сервера не присутствуют на локальном компьютере или ключ был изменен, он добавляется автоматически без каких-либо вопросов, всего лишь выдав предупреждение [сноска 5].
Ставить этот режим не очень хорошая идея.
StrictHostKeyChecking=ask Это параметр по умолчанию. Если у вас нет ключа сервера, вам будет показан отпечаток и запрошено подтверждение, как показано в примере выше. Если вы соединитесь, и ключи не совпадут, ваш вход в систему будет приостановлен и вам будет выдана информация, где в known_hosts находится конфликтующий ключ: StrictHostKeyChecking=yes Эта самая безопасная, возможно даже недружелюбная установка. Если у вас нет ключа сервера, вы вообще не сможете войти в систему: Если у вас есть ключ, но он не совпадает с ключом сервера, вы получите ошибку, такую же, как и при StrictHostKeyChecking=ask.
Почему ключ может измениться?
Типы ключей
Старый протокол SSHv1 основан на алгоритме асимметричного шифрования RSA, тогда как более новый протокол SSHv2 поддерживает RSA и алгоритм aсимметричного шифрования DSA. SSH сервер может использовать один из трех типов ключей: SSHv1 RSA ключи, SSHv2 RSA ключи, или SSHv2 DSA ключи. Я буду называть их rsa1, rsa и dsa ключи соответственно, поскольку эта терминология используется в утилитах OpenSSH.
SSH ключ создается с помощью команды ssh-keygen [сноска 8]. Вероятнее всего, когда SSH был установлен на вашу машину, программа инсталляции или стартовый скрипт создали их для вас.
В файле sshd_config, обычно находящемся в директории /etc/ssh, перечислены ключи, загружающиеся во время старта системы.
Есть ли какие-либо причины использования одного типа ключа, а не другого? Нет. Ключ rsa обычно бывает несколько быстрее с математической точки зрения, но для больших возможностей взаимодействия лучше включать оба. Оба алгоритма не запатентованы [сноска 10], поэтому насчет этого вы можете не беспокоиться. Если вам нужна поддержка SSHv1, у вас должен быть ключ rsa1.
Советы
Используйте глобальный файл известных хостов ( /etc/ssh/ssh_known_hosts ), содержащий все машины, с которыми соединяются ваши пользователи. Если вы выделите время для проверки этих ключей, вам не нужно будет полагаться на пользователей. Удостоверьтесь, что вы получаете все три типа ключа, rsa, dsa, и rsa1. Также, когда вам нужно будет изменить ключ (например, машина была переустановлена, и вы забыли сохранить старые ключи), у вас будет только один файл, который нужно обновить.
Если у вас несколько компьютеров, доступ к которым можно получить, используя одно и то же имя хоста, например пара веб серверов, включите оба ключа для общего имени. SSH клиент будет проверять все совпадения, пока не найдет нужное, так что вы можете использовать общее DNS имя, без использования общего ключа.
Вот очень простой скрипт, соединяющийся с SSH сервером и добавляющий все три возможных ключа в файл. Он может быть полезен для создания вашего глобального файла ssh_known_hosts. Обратите внимание, что здесь не происходит верификации ключа, это вам придется сделать самим.
Опции настройки
Сноски
[сноска 1] Это потому, что криптография, использующаяся для защиты вашего соединения, основана на надежном асимметричном шифровании, которое используется для верификации хоста.
[сноска 3] Существуют патчи к OpenSSH, позволяющие производить аутентификацию по стандарту X509, поэтому вы можете использовать эту модель, если хотите.
[сноска 4] Всегда есть возможность, что атакующий по схеме «человек посередине» следит за этой верификацией и может изменять ответы, чтобы убедить вас в совпадении ключей. Если атакующий хорошо подготовлен, он может доставить вам много проблем.
[сноска 5] Это действительно так, однако, отключая проверку пароля, вы по крайнее мерее должны использовать SSH Identities/PubKeys, Challenge/Response или какие-нибудь другие формы аутентификации, которые не могут быть повторно использованы атакующим.
[сноска 6] Обратное возможно, но маловероятно.
[сноска 7] SSHv1 считается менее безопасным, чем SSHv2. Если вам не нужно использовать клиентское ПО, поддерживающее только старый протокол SSHv1, в целях безопасности лучше всего будет включить поддержку только SSHv2 на вашем сервере. Строчка Protocol в файле /etc/ssh/sshd_config должны выглядеть следующим образом: [сноска 8] ssh-keygen используется и для создания SSH Identities/PubKeys. Действительно нет никакой разницы между ключом пользователя и хоста.
[сноска 9] Закрытый ключ не должен быть защищен паролем, чтобы sshd мог запуститься без вмешательства администратора после перезагрузки.
[сноска 10] Срок патента на алгоритм RSA истек в 2000 году.
Авторизация по ключу 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
Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.
Управление ключами
Теория в нескольких словах: 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-сервера и т.д.