Безопасность SSH-подключений: как передавать пароли, чтобы они не стали лёгкой добычей злоумышленников?
В этой статье мы рассмотрим, в чём заключается эта угроза, приведём реальные примеры утечки паролей, а также предложим скрипты и методы для обнаружения и предотвращения такой уязвимости. Отдельное внимание уделим инструментам, часто используемым администраторами (PuTTY Connection Manager, SuperPuTTY, mRemoteNG, WinSCP CLI, plink, pscp, rsync, sshpass и др.), и рекомендациям по безопасной работе.
Опасность передачи пароля в командной строке
Передача пароля через аргументы командной строки означает, что секретный пароль фактически «зашит» в текст команды. Несмотря на то, что сама SSH‑сессия шифрует данные при передаче по сети, пароль, указанный в параметрах, остаётся видимым на локальном компьютере. Главная угроза здесь — такой пароль может быть легко прочитан посторонними процессами или пользователями на той же системе. В операционных системах семейства Unix/Linux любой пользователь по умолчанию может просмотреть список процессов и командные строки, с которыми они запущены (например, с помощью команд ps или через чтение файлов /proc/[PID]/cmdline). Аналогично в Windows диспетчер задач или утилиты вроде Sysinternals Process Explorer позволяют увидеть полную командную строку запущенных процессов.
Другими словами, если администратор запускает утилиту с указанием пароля в явном виде, этот пароль может попасть в историю командной оболочки или отобразиться в списке процессов, доступном для просмотра локальными пользователями. В результате злоумышленник, имеющий ограниченный доступ к системе (либо другой пользователь на том же сервере, либо вредоносное ПО), может незаметно прочитать пароль из командной строки. Таким образом, обходится сама суть SSH‑авторизации — пароль не передаётся в открытую по сети, но становится «открытым» на стороне клиента, где его не защищает шифрование.
Администраторы часто пользуются надстройками и утилитами для удобной работы с SSH: например, GUI‑менеджеры сессий (PuTTY CM, SuperPuTTY, mRemoteNG), инструменты автоматизации файловых трансферов (WinSCP, psftp, pscp), скриптовые обёртки (plink, sshpass) и даже команды резервного копирования (rsync с паролем). Все эти средства могут предоставлять возможность указать пароль в параметрах командной строки, что несёт одинаковый риск. Даже утилиты вроде sshpass в документации подчёркивают, что подобный способ аутентификации небезопасен и не рекомендуется, так как пароли передаются или хранятся в виде открытого текста. В целом, любая программа, принимающая пароль через аргумент командной строки, потенциально уязвима, если использовать эту возможность.
Примеры утечки пароля через параметры SSH‑инструментов
В диспетчере задач Windows, можно определить процесс PuTTY (psftp) запущен с опцией ‑pw и явным указанием пароля. В таком случае пароль присутствует в открытом виде в командной строке процесса. Это наглядно подтверждает, что любые пароли, переданные через параметры, могут быть прочитаны из списка процессов локальной системой. Аналогичным образом в Linux достаточно выполнить команду вроде ps ‑ef или просмотреть файл /proc//cmdline, чтобы увидеть всю командную строку активного процесса. К примеру, если администратор выполнил:
то другой пользователь на этом же узле может выполнить ps aux | grep sshpass и обнаружить в выводе строку с указанным паролем. В журнале Red Hat приводится предупреждение:
«Все примеры предоставления пароля в командной строке включают риск того, что пароль будет захвачен в истории оболочки пользователя или будет виден всем системным пользователям в списке процессов».
Документация PuTTY также отмечает, что опция ‑pw делает пароль видимым для других локальных пользователей (например, через команду w) и не рекомендуется к использованию.
Не только sshpass или PuTTY грешат этой проблемой. Утилиты plink, pscp, psftp (входящие в состав PuTTY) принимают параметр ‑pw <пароль> для автоматизации входа и таким образом отображают пароль в памяти процесса. Исследователи подтвердили, что на Linux такой пароль можно получить, просмотрев командную строку процесса через /proc. На Windows ситуация аналогична: несколько кликов в диспетчере задач достаточно, чтобы увидеть полный запуск процесса вместе с переданным паролем. WinSCP в командном режиме позволяет передавать пароль через ключ /password=<пароль>, что также означает видимость этого пароля локальноt. Администратор WinSCP предупреждает, что такой способ небезопасен.
Даже инструменты, не связанные напрямую с SSH, демонстрируют аналогичную уязвимость. Например, клиент MySQL позволяет указать пароль через параметр ‑password= или короткий ‑p: при таком использовании MySQL выводит предупреждение: «Using a password on the command line interface can be insecure» (использование пароля в командной строке может быть небезопасно). Причина всё та же — пароль может быть перехвачен локально, пока процесс выполняется. Хотя некоторые современные программы пытаются очистить или скрыть пароль в аргументах после запуска, полностью полагаться на это нельзя. Всегда существует короткий промежуток времени, когда пароль присутствует в памяти процесса в явном виде и может быть прочитан посторонними. Кроме того, списки процессов нередко собираются различными системами мониторинга и журналирования, поэтому пароль, даже использованный в быстром одноразовом процессе, может сохраниться в логах аудитора или мониторинга.
Вывод простой: передавая пароль через аргументы команд, вы фактически делаете его открыто доступным на локальной машине. Ниже мы рассмотрим, как выявить такие случаи и какие меры принять, чтобы этого избежать.
Поиск утечки пароля в процессах Windows (PowerShell)
Администраторы Windows могут воспользоваться PowerShell для сканирования запущенных процессов и обнаружения тех, в командных строках которых присутствуют подозрительные параметры, похожие на пароли. Для этого нужно запрашивать у системы командные строки процессов (атрибут CommandLine класса Win32_Process) и искать в них известные ключи или паттерны (например, ‑p, ‑pw, ‑password, /password= и т. п.). Ниже приведён PowerShell‑скрипт, который можно запустить вручную на отдельной системе для выявления таких случаев:
Данный скрипт выводит таблицу с идентификатором процесса, именем и полной командной строкой для каждого найденного случая. В фильтре условия ‑match используются регулярные выражения для поиска различных способов передачи пароля. Здесь мы проверяем наличие подстрок ‑p (дефис p и пробел), ‑pw, а также ‑password= и /password=. Эти шаблоны охватывают типичные ключи, используемые разными утилитами (sshpass, plink/pscp, WinSCP, mysql и др.). При необходимости список можно расширить или уточнить.
Версия для SCCM: Если нужно выполнить подобную проверку централизованно на многих машинах через System Center Configuration Manager (SCCM) или аналогичную систему, можно адаптировать скрипт. Например, SCCM‑скрипт проверки может возвращать код выполнения или вывод, на основании которого система сделает вывод о соответствии политики. Ниже приведён вариант, который в случае обнаружения небезопасного процесса завершится кодом 1 (несоответствие), а при отсутствии — кодом 0 (всё чисто):
Этот сценарий перебирает процессы, записывает обнаруженные случаи (PID, имя, команду) в локальный лог‑файл и устанавливает флаг $found. В конце скрипта возвратом exit 1 он может сигнализировать SCCM о проблеме. Администратор SCCM может настроить соответствующее правило конфигурации, помечающее машину как «Non‑compliant» (несоответствующую требованиям безопасности), если скрипт вернул 1, что позволит быстро выявить системы, где кто‑то использует небезопасные способы передачи паролей.
Проверка утечек пароля в Linux (Bash)
В среде Linux/UNIX подобную проверку можно выполнить с помощью скрипта Bash, анализируя вывод команды ps или содержимое директорий /proc//cmdline. Скрипт должен выполняться с правами, достаточными для просмотра процессов всех пользователей (например, от имени root), иначе он увидит только свои процессы. Ниже приведён пример Bash‑скрипта, который ищет активные процессы с признаками передачи пароля через аргументы командной строки:
Этот скрипт построчно читает информацию о процессе (PID, пользователь, команда) и с помощью условных конструкций [[... =~... ]] проверяет наличие подозрительных паттернов:
‑p или ‑pw — типичные опции sshpass, plink/pscp;‑password= — опция у многих утилит (например, mysql ‑password=...);/password= — опция WinSCP или других программ;шаблон://user:pass@ — на случай, если в команде встречаются URL с открытым паролем (например, ftp://user:password@host или вызовы smbclient с учетными данными).
При нахождении совпадения выводится строка с деталями: PID процесса, пользователь и полная командная строка (которая содержит пароль). Результат проверки можно перенаправить в лог или обработать иначе. Если скрипт ничего не выводит, значит, подозрительных процессов не обнаружено на момент запуска.
Важно: Скрипт ищет только активные процессы. Пароль, переданный моментально и уже отработавший (например, быстро отработавший sshpass), может не попасть в выборку. Для более детального анализа можно просматривать историю команд (в файлах ~/.bash_history и т. п.) или журналы запуска задач (например, логи Cron), однако это выходит за рамки простого сканирования процессов.
Централизованная проверка Linux‑серверов с помощью Ansible
Когда необходимо проверить сразу множество Linux‑серверов на предмет использования небезопасных утилит с паролями, удобнее автоматизировать это через систему управления конфигурацией, такую как Ansible. С помощью Ansible можно запустить вышеописанную проверку на группе серверов и собрать результаты централизованно. Ниже приведён фрагмент Ansible‑плейбука, выполняющего такую проверку на всех целевых узлах:
Что делает этот плейбук? Он проходит по всем узлам (hosts: all), поднимает привилегии до root (become: yes), и выполняет команду, аналогичную нашей Bash‑проверке, с помощью модуля shell. Конструкция grep ‑E ищет в выводе ps заданные регулярные выражения (здесь для краткости записаны подряд через |). Результат команды сохраняется в переменную proc_check. Далее, через задачи debug плейбук выводит:
Общее количество найденных подозрительных процессов на каждом хосте.Сами строки команд, если они найдены (выводится список строк proc_check.stdout_lines).
Такой плейбук при запуске покажет для каждого сервера, есть ли запущенные процессы с явными паролями. Например, вывод может указать, что на сервере X обнаружен процесс sshpass ‑p SuperSecret ssh backup@backup‑server, что явным образом сигнализирует о проблеме. Администратор, получив отчет Ansible, сможет оперативно связаться с ответственными за этот сервер и устранить небезопасный скрипт.
Разумеется, плейбук можно доработать: например, вместо вывода на экран результаты могут складываться в отчётный файл; либо можно сразу помечать хост как non‑compliant. Однако приведённого примера достаточно, чтобы развернуть проверку на десятках и сотнях машин одновременно.
Уязвимые сценарии и примеры
Стоит обратить внимание, в каких ситуациях администраторы или автоматизация чаще всего допускают передачу пароля через командную строку. Ниже перечислены несколько типичных уязвимых сценариев:
CI/CD конвейеры и скрипты развертывания: В системах непрерывной интеграции/развертывания (Jenkins, GitLab CI, TeamCity и др.) иногда пишут шаги, где для доступа к удалённым серверам используются утилиты типа sshpass или plink с паролем в аргументах. Например, pipeline, автоматически деплоящий приложение на сервер по SSH, может содержать строку с паролем. Такой пароль попадёт в логи сборки, доступные другим участникам команды, и потенциально сохранится на контроллере CI/CD.Резервное копирование и batch‑скрипты: Сценарии бэкапа, запускаемые по расписанию (cron‑job"ы на Linux или задания планировщика Windows), иногда используют утилиты командной строки для копирования данных на удалённый сервер. Если для этого применён, скажем, pscp или rsync с указанием пароля через параметры, то пароль будет виден каждому, кто просмотрит информацию о запущенном процессе (а такие задачи могут выполняться длительно, увеличивая окно экспозиции). Аналогично, скрипты резервного копирования баз данных могут вызывать mysqldump ‑password=..., из‑за чего пароль от БД окажется в памяти процесса и консольных логах.Сценарии автоматизации и обслуживания: Администраторы нередко пишут собственные скрипты автоматизации (на Bash, PowerShell, Python и т. д.), в которых для удобства жестко прописывают пароль в команду. Например, скрипт обновления нескольких серверов, который по SSH выполняет команды, или скрипт массового копирования файлов. Если такие скрипты передают пароль напрямую утилите, то каждая их сессия несёт риск компрометации пароля. На соревнованиях по кибербезопасности и в реальных атаках находились десятки действующих паролей именно через анализ запущенных процессов и содержимого сценариев автоматизации.CI/CD и DevOps инструменты с плагинами: Некоторые инструменты, если настроены неправильно, могут логировать секреты. Например, плагин для деплоя, вызывающий команду SSH с паролем, может вывести эту команду в консоль. Это делает пароль видимым не только локально, но и в централизованных логах системы сборки.Удалённый доступ и RDP‑консолидаторы: Хотя SSH является фокусом данной статьи, упомянем, что похожий принцип относится и к другим средствам доступа. Например, запуск утилиты Remote Desktop с паролем через командную строку (в стандартном mstsc такого ключа нет, но существуют сторонние консоли) или использование менеджеров, хранящих пароли, может привести к утечке. Некоторые GUI‑клиенты (вроде mRemoteNG, MobaXterm) могут сохранять пароли локально в незащищённом виде или передавать их внешним утилитам, хотя и не через явный аргумент, но через временные файлы или параметры командной строки. Это также требует внимания, хотя механизмы несколько иные.
Инструменты, передающие пароль в аргументах команд
Помимо уже названных, приведём расширенный список программ и утилит, которые потенциально могут использовать небезопасную передачу пароля через командную строку:
PuTTY и производные: plink, pscp, psftp, а также форки PuTTY вроде KiTTY — все они имеют параметр ‑pw для пароля и подвержены описанной уязвимости. PuTTY Connection Manager и SuperPuTTY являются надстройками, которые при сохранении паролей могут запускать PuTTY/Plink с этими паролями, делая их видимыми локально.WinSCP (CLI): В командном режиме winscp.exe позволяет указать /password=... в URL соединения или аргументе. Как отмечалось на форуме разработчиков, этот пароль будет отображён в Task Manager, поэтому рекомендуется использовать другие методы (например, хранение в файле настроек или нововведённый ключ /passfile).rsync при прямом подключении к демону rsync: Хотя обычно rsync используется поверх SSH‑ключей, при работе с удалённым rsync‑сервером (протокол rsync://) применяют переменную окружения RSYNC_PASSWORD или опцию ‑password‑file. В старых реализациях опция ‑password могла встречаться, что, как и в других случаях, недопустимо — пароль должен быть либо в файле (с правами 600), либо вовсе не использоваться, а вместо этого настроена аутентификация ключами.sshpass: Специализированная утилита для автоматической передачи пароля в ssh. Она поддерживает несколько способов задать пароль: через аргумент ‑p, через файл (‑f) или через переменную окружения (‑e). Опция ‑p в sshpass прямо вставляет пароль в команду и наиболее опаснаlebco.ru. Использование ‑f и ‑e чуть безопаснее, так как не оставляет пароль в списке процессов (но могут возникнуть другие риски — например, файл с паролем должен быть защищён правами доступаlebco.ru). Многие дистрибутивы Linux даже не устанавливают sshpass по умолчанию, а политики безопасности запрещают его применение из‑за описанных рисков.FTP‑клиенты и утилиты для других протоколов: Командные ftp‑клиенты (например, классическая команда ftp или утилита lftp) позволяют аутоматизировать ввод пароля, но если кто‑то передаст пароль как параметр или в скрипте напрямую, он может быть виден. Например, команда lftp ‑u user,password ftp://host запустит процесс с отображением user,password в списке аргументов. Инструменты для SMB/CIFS — например, smbclient «//сервер/ресурс» ‑U пользователь%пароль — также вставляют пароль после символа% в командной строке, что легко читается локально.Утилиты баз данных: Многие консольные клиенты баз данных принимают пароль через аргумент. MySQL/MariaDB‑клиент (mysql, mysqldump) — через ‑password=... (или ‑p...), PostgreSQL предлагает избегать этого и использовать переменную окружения PGPASSWORD или файл.pgpass. Если администратор скриптом запускает, например, mysqldump ‑u backup ‑password=Secr3t dbname > backup.sql, то строка с паролем будет видна всем процессам/пользователям, а сам MySQL при этом явно указывает на небезопасность такого подхода предупреждением.cURL, Wget и другие HTTP‑клиенты: Если URL содержит учетные данные (например, http://user:pass@domain), они тоже становятся частью командной строки. Вызов curl ‑u user:pass https://api.example.com отобразит user:pass в аргументах процесса. Хотя HTTPS шифрует передачу, пароль до шифрования присутствует в памяти процесса и может утечь локально. Лучше использовать токены или передавать пароль через интерактивный запрос либо конфигурационный файл.Прочие утилиты: Сюда можно отнести telnet‑клиенты, если ими ещё кто‑то пользуется (они иногда имеют опцию для пароля), старые команды вроде rlogin/rsh (где пароль нельзя передать напрямую, но сам протокол небезопасен), и даже некоторые архиваторы/шифровальщики, которые могут принимать пароль архивного файла через аргумент (в таком случае пароль архива тоже может быть виден). Всегда, когда программа предлагает параметр для пароля или ключа доступа, следует насторожиться и предпочесть более безопасную альтернативу.
Рекомендации по безопасной работе
В заключение, приведём ряд рекомендаций, соблюдение которых поможет избежать рассматриваемой проблемы и в целом повысит безопасность при использовании SSH и других утилит:
Никогда не передавайте пароли через параметры командной строки. Это главное правило. Если утилита предполагает такой вариант — не используйте его. Пароль, переданный через аргумент, следует считать скомпрометированным, поскольку он мог быть перехвачен локально. Вместо этого ищите другие способы автоматизации аутентификации.Используйте SSH‑ключи с агентом или безпарольной фразой. Для автоматизации SSH‑подключений наилучшей практикой является переход на ключевую аутентификацию. Сгенерируйте пару ключей, установите публичный ключ на сервере, а приватный ключ храните у себя. При необходимости его можно защитить парольной фразой. Тогда скрипты могут выполнять ssh без запроса пароля, и при этом не нужно нигде прописывать секреты. SSH‑ключи практически исключают риск утечки в процессы, а также не подвержены перебору (в отличие от слабых паролей).Применяйте менеджеры паролей и хранилища секретов. Если использование пароля неизбежно (например, для утилиты, где нельзя задействовать ключи), храните и передавайте его безопасно с помощью менеджера паролей (ОдинКлюч, Пассворк, BearPass).Регулярно проводите аудит и мониторинг. Включите проверку на небезопасное использование паролей в процессы стандартного аудита безопасности. Как мы показали, подобные утечки можно сканировать автоматически. Регулярный аудит (например, раз в неделю или постоянно через мониторинг) позволит быстро выявлять случаи, когда кто‑то из сотрудников запускает запрещённые утилиты или передаёт пароль открыто. Отчёты аудита можно настроить на уведомление службы безопасности или ответственных администраторов.Запрещайте и ограничивайте использование небезопасных утилит и практик. На уровне политики компании можно принять список запрещённых к использованию инструментов (той же sshpass, или опций типа PuTTY ‑pw). Технически это можно подкрепить:GPO (Group Policy) в Windows: можно запретить запуск определённых программ (например, AppLocker способен блокировать sshpass.exe или winscp.com с параметром пароля). Также можно настроить Windows Event Log Audit на запись события при запуске определённых команд.ACL и права на исполнение: убедитесь, что обычные пользователи не имеют прав устанавливать или запускать утилиты, которыми они не должны пользоваться. Например, на продакшн‑серверах может быть целесообразно вовсе не иметь установленного sshpass или WinSCP CLI.Информирование и обучение: иногда проще донести до IT‑персонала, что такие практики недопустимы. Объясните разработчикам скриптов и DevOps‑инженерам, почему нельзя хардкодить пароль в команду, и предложите им альтернативные подходы.
Подводя итог: SSH остаётся надёжным протоколом, если соблюдать правила, использовать надёжные решения, например российский МС22 или зарубежные SecureCRT, MobaXTerm, Xshell и др. Проблемы возникают не из‑за уязвимости в SSH, а из‑за компромиссов, на которые идут люди ради удобства. Пароль, переданный через командную строку, перестаёт быть тайной — это равносильно тому, что наклеить стикер с паролем на монитор: канал связи по‑прежнему шифрован, но злоумышленнику уже и не нужен перехват трафика, когда пароль можно прочитать «с экрана» вашей системы. Следуйте рекомендациям, используйте ключи и безопасные хранилища, и тогда даже при автоматизации вы сохраните высокий уровень безопасности SSH‑подключений.