Одна из машин в моей сети (рабочая станция Mint 12, последняя версия) периодически переходит в плохое состояние, когда все исходящие SSH-соединения возвращаются к аутентификации по паролю с ошибкой «агент признал невозможность подписать с использованием ключа» вместо использования ключа настроенная аутентификация.
Когда он находится в этом состоянии, он будет отказывать в 100% случаев для всех исходящих соединений. Входящая аутентификация на основе ключей работает нормально. Я попытался удалить и восстановить пару ключей и перераспределить открытый ключ, но ошибка не исчезла.
Перезагрузка временно устранит ошибку, но через несколько дней она снова появится. Кажется, не совпадает с каким-либо конкретным событием / рабочим процессом, но мне может что-то не хватать.
Кто-нибудь еще видел это?
«Агент» здесь ssh-agent
, программа, которая загружает закрытый ключ в память и сохраняет его для будущих ssh-соединений, чтобы вам не приходилось повторно вводить пароль. Похоже, что где-то в строке ему дана команда забыть ключ (вы приостанавливаете работу на диск / переходите в спящий режим? Это может сделать это, чтобы предотвратить запись незашифрованного ключа на диск) или есть ошибка, которая заставляет его забыть ключ. В любом случае, ssh-add
должен позволить вам добавить ключ обратно в агент.
я честно уверен, что вы получите другое сообщение об ошибке, если ssh
не мог поговорить с ssh-agent
по какой-то причине. Если ssh-add
говорит, что не может открыть соединение с вашим агентом аутентификации, тогда настоящая проблема в том, что он перестал работать, или переменные среды, которые говорят ssh
как связаться с агентом пропали или пропал файл сокета. Если переменные среды $SSH_AUTH_SOCK
и $SSH_AGENT_PID
оба по-прежнему установлены, когда это происходит (с echo $SSH_AGENT_PID
) убедитесь, что на процесс ssh-agent ссылается $SSH_AGENT_PID
все еще работает, и если это так, то файл сокета в $SSH_AUTH_SOCK
все еще там. Возможно, у вас агрессивный /tmp
процесс очистки, который снимает розетку.