Кэшируйте пароль, если SSH-ключи запрещены

46

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

В настоящее время; Я не могу изменить свое мнение (я пытался).

Есть ли способ хотя бы временно хранить пароли SSH, как GIT может хранить пароли в кеше в течение определенного времени?

user2667180
источник
55
the computing center explicitly forbids SSH-keys because they are "insecure"Моё мнение по этому поводу? Найдите новый хост сервера, потому что ваш, очевидно, неумелый.
Мэтт Кларк
18
@Matt: «вычислительный центр» больше похож на академическую сеточную систему, в которой конкуренция не так
велика,
27
Они ошибаются. Вероятно, они забыли отключить ssh-ключи при истечении срока их действия, поэтому решили, что ssh-ключи - это проблема.
Иисус Навин
10
Гравитация это правильно. это национальный суперкомпьютер, поэтому я застрял с ним. за что она стоит, машина приятная. Джошуа, вероятно, тоже прав, но, ну, это право не подходит ни для
кого
7
@TheHansinator Если установлен кейлоггер, вы уже скомпрометированы до такой степени, что больше не имеет значения, защищаете ли вы свои ssh-соединения. Но есть и другие преимущества publickeyаутентификации. Если вы отключите passwordаутентификацию на сервере, вы не допустите, чтобы все злоумышленники пытались угадать пароли. И если злоумышленник попытается провести небольшую атаку на клиента, который ранее не сохранял открытый ключ сервера, вы защищены гораздо лучше, publickeyчем если бы вы использовали passwordаутентификацию.
Касперд

Ответы:

63

Повторное использование соединения

SSHv2 позволяет одному и тому же аутентифицированному соединению устанавливать несколько «каналов» - интерактивную оболочку, пакетную команду, SFTP, а также вторичные, такие как переадресация агента или переадресация TCP. Ваш сервер, вероятно, поддерживает мультиплексирование соединений по умолчанию. (Если ваши администраторы жалуются, он нигде не кэширует ваш пароль - он кэширует все соединение.)

С OpenSSH у вас есть ControlMasterи ControlPathопции (-M и -S), чтобы использовать это:

  1. Запустите «главное» SSH-соединение, используя -M. (Поскольку у вас еще нет ControlPath в вашей конфигурации, вам нужно указать его в командной строке, используя -S. Он должен жить долго, поэтому я добавляю -fNопции для перетаскивания в фоновый режим ; в противном случае они технически необязательны.)

    $ ssh foo@bar.example.com -fNMS ~/.ssh/bar.socket
    foo@bar.example.com's password:
    

    Вы вернулись к местной оболочке.

  2. Начать новое соединение через мастера:

    $ ssh foo@bar.example.com -S ~/.ssh/bar.socket
    

    Ты в.

  3. Чтобы сделать это полезным для Git / rsync / SFTP, вам нужно настроить его ControlPathв своей конфигурации, потому что вы не сможете -Sвсе время указывать :

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p
    

Вы можете автоматизировать это - последние версии OpenSSH также имеют ControlPersistавтоматическое установление основного соединения в фоновом режиме, если его еще нет. Это позволяет пропустить шаг 1 и просто использовать ssh, как обычно.

  1. Конфигурация в ~/.ssh/config:

    Host *
        ControlPath ~/.ssh/S.%r@%h:%p
        ControlMaster auto
        ControlPersist 15m
    
  2. Первое соединение запрашивает пароль:

    $ ssh foo@bar.example.com
    foo@bar.example.com's password:
    [foo@bar:~]$ exit
    
  3. Второе не:

    $ ssh foo@bar.example.com
    [foo@bar:~]$ yay
    

Чтобы управлять мастером мультиплекса (остановить его или настроить переадресацию TCP), используйте -Oопцию.

Подобный метод поддерживается в последних версиях PuTTY .

grawity
источник
1
Большое спасибо за этот хороший ответ. Google не был полезен для этой проблемы, так как он всегда обращался к ssh-ключам, и я не знал правильных ключевых слов. мне очень помогло!
user2667180
1
Само собой разумеется, но если вы используете эту конфигурацию, обязательно убедитесь, что ваша учетная запись защищена, и что ваша папка .ssh правильно заблокирована, так как любой, у кого есть доступ к файлам каналов на этой машине, может получить выгоду от вашей подключение и доступ к серверу, как у вас.
Shellster
3
@shellster: Вы имеете в виду «любого с таким же UID», как и в случае с ssh-agent. Даже если вы намеренно откроете права доступа к файлу сокета (которые по умолчанию равны 0600), другие пользователи просто получат из него «несоответствие мультиплексного идентификатора».
Гравитация
3
@shellster Кто-то с правами root может установить кейлоггер и украсть ваш пароль к удаленной системе в любом случае, или совершить любое количество гнусных действий. Если мы беспокоимся о локальном корне, это не менее безопасно, чем сохранение закрытого ключа SSH.
Амаллой
1
Я не считаю локальный корень угрозой, потому что, если он когда-нибудь станет угрозой, вы будете тостом, несмотря ни на что. (Как и в случае государственного шпионажа.) Честно говоря, локальный root может просто заменить ваш ssh-клиент и ssh-agent на все, что они захотят. Сохранить все пароли и закрытые ключи в /root/.secret? Конечно.
благодарность
19

использование sshpass

sshpass ( github , man page ) - это инструмент, который автоматически передает пароль в ssh. Безопасный способ использовать это это:

% echo 'correct horse battery staple' > ~/.ssh/compute_password
% chmod go-rw ~/.ssh/compute_password

% sshpass -f ~/.ssh/compute_password ssh foo@host

Это будет считывать пароль ~/.ssh/compute_password, подобно файлу с закрытым ключом без ключевой фразы. Вы можете поместить sshpassкоманду в небольшой скрипт оболочки или псевдоним оболочки, чтобы избежать ввода этой полной команды. К сожалению, я не нашел способ сделать это из ~/.ssh/config.

(Можно также указать пароль непосредственно в командной строке sshpass, но этого следует избегать, так как это дает утечку паролю любому, кто может это сделать ps)

Сравнение с другими методами

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

Он также менее безопасен, чем ответ @ grawity о повторном использовании соединения, но имеет то преимущество, что вообще не вводит пароль в интерактивном режиме.

Вы могли бы рассмотреть ответ @ grawity как альтернативу auth pubkey с парольной фразой и кэшированием закрытого ключа (т.е. ssh-agent). Тогда мой ответ будет альтернативой аутентификации pubkey без ключевой фразы в файле закрытого ключа.

marcelm
источник
3
Если политика вычислительного центра была написана на основе «но пары ключей хранятся на диске, где кто-то может их украсть!», То похоже, что эта политика будет иметь неприятные последствия.
Гравитация
6
@ grawity Ну, плохие политики приводят к еще худшим временным решениям ¯ \ _ (ツ) _ / ¯
marcelm
1
Если вы генерируете свой пароль в виде достаточно длинного потока случайных символов (скажем, head -c 16 /dev/urandom | base64для 128 бит) и не используете его в других системах, он с точки зрения безопасности аналогичен ключу. Как трудно перебор, и как просто использовать из файла, если не зашифрован. Это касается и плохого парня, если он получит файл. Единственное отличие состоит в том, что пароль отправляется на сервер как есть, в то время как ключи имеют более точную математику, чтобы доказать, что вы владеете правильным закрытым ключом, не раскрывая его, и с точки зрения удобства использования труднее зашифровать файл, содержащий пароль (нет стандартные инструменты).
ilkkachu
1

Используйте менеджер паролей.

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

Не нужно ничего копировать, запоминать что-либо (кроме пароля для разблокировки базы данных), и вы можете иметь надежный пароль, не используя эти 30 символов каждый раз, когда вы пытаетесь войти в систему.

Вы можете выбрать свой любимый из этого списка: https://en.wikipedia.org/wiki/List_of_password_managers

пенополистирол летать
источник
3
Я не уверен, что функция автоматического ввода работает хорошо с терминальными программами. Обнаружение будет искать конкретный заголовок окна, а сам автотипирование лучше всего не будет обладать такими необычными функциями «анти-кейлоггинга», как у KeePass2 ...
grawity
1
@grawity gnome-terminalменяет свой заголовок на, ssh somehostкогда ssh запрашивает у меня пароль, чтобы вы могли сопоставить окно заголовка с этим без проблем. Я ничего не знаю о функциях «анти-кейлоггинга» - я ежедневно использую KeePassXC в терминале, и худшее, с чем мне пришлось столкнуться, - это выбрать подходящую учетную запись из списка.
пенополистирол летать
2
@grawity Функции анти-кейлогинга должны быть включены для каждой записи в любом случае (именно по той причине, что многие программы не поддерживают вставку).
Боб
0

Другой альтернативой является использование ssh-клиента с графическим интерфейсом. На Windows очевидным выбором будет PuTTY . Существует также версия PuTTY для Linux, в частности, большинство дистрибутивов на основе Debian, таких как Ubuntu, обычно включают PuTTY в свои репозитории.

Другой действительно хороший клиент - Termius . Он поддерживает не только Windows и Linux, но также OSX, iOS и Android. Несмотря на то, что он был в первую очередь предназначен для телефонов, настольная версия на самом деле довольно хорошая.

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

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

slebetman
источник
2
«На основе GUI» не означает автоматически, что позволит вам сохранить ваш пароль, что PuTTY явно отказывается делать . Версия HyperTerminal, поставляемая в комплекте с Windows, была предназначена только для Telnet и больше ориентирована на последовательные каналы. Может быть, вы думаете о CKermit для Windows, который имеет поддержку SSH, но его поддержка шифров настолько устарела, что он не сможет легко подключиться ко многим текущим серверам.
grawity