grep + regex: как написать шаблон для сопоставления данных с контекстно-зависимыми элементами?

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

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

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

Пароль также может просочиться через резервные копии. Например, если резервная копия вашего домашнего каталога скомпрометирована (или вы случайно загрузили свой файл закрытого ключа на Github — вы не будете первым¹ ), злоумышленник получит доступ к файлу ключа. Формат файла закрытого ключа OpenSSH уязвим для атак методом перебора пароля . Начиная с OpenSSH 6.5, существует новый формат (, выбранный с помощью ssh-keygen -o, который правильно использует медленный хэш , но он не используется по умолчанию, начиная с OpenSSH 7.7. Поэтому, если злоумышленник получит доступ к вашему ключевому файлу, существует серьезный риск того, что он получит пароль, который позволит ему использовать ключ и войти в систему без ключа. Даже при медленном хэшировании, если ваш пароль слишком слабый, злоумышленник, у которого есть файл ключа, может взломать его в автономном режиме (, т.е. он ограничен только тем, сколько электроэнергии он готов потратить ).

По этим причинамвы не должны использовать один и тот же пароль для ключа SSH и для учетной записи пользователя. Если вы хотите защитить ключевой файл, но не хотите запоминать отдельный пароль, лучше использовать незапоминающийся -пароль и сохранить его в связке ключей(в Gnome. keyring использует медленный хэш ).²

¹ _{Я думаю, Github теперь защищает от прямой загрузки файла ключа.}
² _{И не забывайте не допускать утечки резервных копий вашей связки ключей, но на практике это меньше проблем, чем с SSH, потому что люди склонны создавать резервные копии своего каталога .ssh, который содержит файлы конфигурации, такие как configи authorized_keys..}