Для доступа по shh нужно знать к кому подключаться (ip или host name), порт (по умолчанию 22), имя пользователя и пароль. Также нужен клиент, вообще все протоколы из стека TCP/IP это клиент-серверные протоколы, т.е. есть сервер, ожидающий подключения от клиента, и есть клиент, инициирующий подключение к серверу. Почти во всех дистрибутивах линукс клиент ssh идет в комплекте и доступен по команде «ssh»

где -p это номер порта, -l — имя пользователя. Можно подключаться и так:

а если порт 22 то

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

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

Конфигурационный файл сервера sshd находится по пути "/etc/ssh/sshd_config", доступ к которому имеет только администратор. А каждый пользователь, имеющий доступ по ssh, в домашнем каталоге хранит папку .ssh, в которой располагаются ключи аутентификации, файл с хешем открытых ключей клиентов и хеши открытых ключей серверов.

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

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

Наверное тут надо сказать, что алгортмы шифрования делятся на 2 типа: симметричные и ассиметричные; симметричные алгоритмы шифрования (AES, Blowfish, DES) используют один ключ для шифрования и дешифрования информации (типо пароль), ассиметричные алгоритмы шифрования (RSA) использют пару ключей: открытый для шифрования и закрытый для дешифрования. Например Оля и Вася решили обмениваться зашифрованными с помощью RSA сообщениями. Для этого Вася генерирует себе пару ключей (открытый и закрытый) и Оля делает тоже самое. Чтобы начать общение Вася должен передать Оле свой открытый ключ и Оля должна передать вас свой открытый ключ. Теперь Вася шифрует свое сообщение открытым ключем Оли, а Оля может прочитать это сообщение дешифровав своим закрытым ключем. По открытому ключу невозможно расшифровать сообщение или восстановить закрытый ключ, в свою очередь зная закрытый ключ можно восстановить открытый. Т.е. для обеспечения защиты передаваемой информации оба должы обменяться открытыми ключами и обеспечить сохранность своих закрытых ключей.

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

Менеджер спросит куда сохранить ключи и парольную фразу. Если ввести пароль то для работы с ключами надо будет его вводить. Если не менять путь сохранения ключей, то лежать они будут по пути "~/.ssh/", там "id_rsa" - приватный ключ, "id_rsa.pub" - публичный ключ. Теперь нужно передать этот ключ на ssh сервер. Можно воспользоваться командой

Синтаксис тут такой же как и у "ssh". Будет запрошен пароль сервера. После этого можно коннектиться к серверу как обычно, так как файлы ключей лежат по пути по умолчанию то

если же нет то во-первых: приватный ключ должен иметь права 600, во-вторых: публичный - 644; и нужно добавить ключ "-i"

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

Существует и другой способ прогрузки публичного ссш ключа.

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

Как я уже сказал у пользователя есть директория .ssh, кстати ее можно и создать, так вот в этой директории есть файл "authorized_keys" в котором и хранятся публичные ключи прогружаемые через "ssh-copy-id" и ничего не мешает тебе в ручную просто вставить свой публичный ключ в новую строку в этот файл. Результат будет одинаковый.

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

Через ssh можно не только выполнять команды, а еще и серфить интернет, для этого трафик между локальной машиной и сервером туннелируется и во вне трафик идет уже с сервера. Для проброса одного порта (создания прокси) используется такая команда

Параметр -T отключит псевдо терминал, а -D прибиндит порт. Таким образом на локал хосте у тебя будет висеть прокси на порту 8080. Пару скринов для POC

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

тут я еще указал путь до ключа. Теперь надо прописать прокси в браузер. Для менеджеринга прокси я юзаю FoxyProxy

Теперь мой внешний ип равен ип ссш сервера

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

Еще один пример создания туннеля с порта на порт. К примеру на удаленном сервере запущен какой то сервис, например IP телефонии, который работает на порту 5901. И тебе нужно соединиться с сервером так чтобы трафик между клиентом и сервером был зашифрован, то ты будешь пробрасывать туннель на конкретный порт.

Теперь указываешь в клиенте SIP адрес хоста как 127.0.0.1 и он заработает. Магия! Такая практика используется для проброса порта сервера базы данных, когда настраивают горизонтальное масшабирование для балансировки нагрузки или когда 2 сервера юзают один сервер с БД или просто когда сервер с БД хостится отдельно, в общем в любой ситуации когда необходимо получить доступ к серверу БД удаленно. Это лучше чем светить порт сервера БД в интернет, по ряду причин, одна из очевидных - это безопасность.

Если и этого недостаточно и хочется большего, то встречайте sshuttle. Утилита легко и просто настроит тебе глобальное туннелирование всего системного трафика. Делается это так:

параметр --dns включит еще и форвардинг днс запросов, -e позволяет указать свою команду запуска ssh, в данном случае я указал путь до ключа. Выключаю прокси в браузере и результат, как говорится, на лицо ;-)

И как я уже сказал, трафик туннелируется весь

ifconfig.me упорно отказывается отвечать если юзер агент не указывать

Заметил, что при использовании sshuttle на вхуере не светится, что я использую прокси? Чем же туннелирование лучше ТОРа в котором тоже невозожно перехватить и дешифровать трафик между тобой и выходной нодой? SSH туннели не поднимают куча правительственных организаций, чтобы мониторить пользователей ssh - это раз, быстрее чем ТОР - это два. И все это исключительно мое мнение!

Если ты полюбишь ссш, то придется полюбить и брутить ссш любишь кататься люби и с санками ебаться. А для начала вспомним, как можно узнать кто работает на машине? Правильно w/who. А что же делать, спросишь ты? Все достаточно просто. SSH позволяет последним параметром указать команду, которая будет выполнена на удаленном сервере (такой тип параметров называется позиционным). Если сделать вот так:

то ты увидишь информацию о системе на удаленном сервере и будешь отключен от него. Ну а чтобы не палить свою сессию можно подключиться к серверу вот так:

и получить сессию sh в интерактивном режиме.

На гифке видно, что я подключился к серверу дважды, а в списке w видно только одну сессию, это как раз потому что вторую сессию я запускал с указанием "/bin/sh -i" последним параметром. Таким нехитрым способом можно скрыть свое присутствие. Хотя тебя все равно можно обнаружить, просто для этого придется затратить больше усилий. Кстати пробрасывать туннель тоже лучше с указанием "/bin/sh -i".

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