Під час роботи з Git, SSH і VS Code Ubuntu може почати регулярно запитувати пароль приватного SSH-ключа. Це може траплятися навіть тоді, коли ключ уже додано до агента.
Причиною можуть бути короткий час кешування пароля, неправильна прив’язка GPG Agent до поточного термінала або одночасна присутність кількох агентів у системі.
У цьому випадку проблема була пов’язана з GPG Agent: ключ був завантажений, але агент періодично втрачав можливість виконувати операцію підпису без нового введення пароля.
Спочатку перевіряємо, який SSH Agent використовується
echo "$SSH_AUTH_SOCK" ssh-add -l ps -ef | grep -E '[s]sh-agent|[g]cr-ssh-agent'У нашому випадку використовувався GPG Agent:
/run/user/1000/gnupg/S.gpg-agent.ssh
SSH-ключ ED25519 був завантажений, але система все одно періодично вимагала його пароль.
Одночасно працював GCR SSH Agent. Сам факт наявності двох агентів ще не означає конфлікту, але важливо розуміти, який саме агент використовують термінал, Git і редактор.
Перевіряємо час кешування пароля
if [ -f ~/.gnupg/gpg-agent.conf ]; then grep -E 'cache-ttl|ssh-support|external-cache|pinentry' \ ~/.gnupg/gpg-agent.conf || trueelse echo "No custom GPG agent config"fi gpgconf --list-options gpg-agent | grep -E '^(default-cache-ttl-ssh|max-cache-ttl-ssh):'Типові стандартні значення для SSH-кешу GPG Agent:
default-cache-ttl-ssh- 1800 секунд, тобто 30 хвилин;max-cache-ttl-ssh- 7200 секунд, тобто 2 години.
Навіть якщо ключ використовується регулярно, максимальний час кешування все одно обмежує, скільки агент може зберігати розблокований пароль.
Збільшуємо час кешування
mkdir -p -m 700 ~/.gnupg cat > ~/.gnupg/gpg-agent.conf <<'EOF'default-cache-ttl-ssh 28800max-cache-ttl-ssh 43200EOF chmod 600 ~/.gnupg/gpg-agent.conf gpgconf --reload gpg-agentЦе налаштування не змінює приватний SSH-ключ і не прибирає його пароль.
Воно лише збільшує час, протягом якого GPG Agent може пам’ятати вже введений пароль.
Варто враховувати і зворотний бік: довший кеш означає довший період, протягом якого розблокований ключ доступний у поточному сеансі.
Перевіряємо, чи агент може виконувати SSH-підпис
ssh-add -T <(ssh-add -L)ssh-add -T <(ssh-add -L)Після перезавантаження конфігурації в нашому випадку з’явилася помилка:
Agent signature failed for /dev/fd/63: agent refused operation
Це означало, що ключ був видимий у списку агента, але сам агент відмовлявся виконувати операцію підпису.
Оновлюємо прив’язку GPG Agent до поточного термінала
export GPG_TTY="$(tty)" gpg-connect-agent updatestartuptty /byeОднією з можливих причин agent refused operation є неправильна прив’язка GPG Agent до термінала, у якому зараз працює користувач.
Після оновлення цієї прив’язки повторюємо перевірку ключа та підпису.
echo "===== SSH KEYS ====="ssh-add -l echoecho "===== SIGNATURE TEST 1 ====="ssh-add -T <(ssh-add -L) echoecho "===== SIGNATURE TEST 2 ====="ssh-add -T <(ssh-add -L)Після цього обидві операції підпису завершилися без помилок.
Це підтвердило, що агент знову може використовувати SSH-ключ. Водночас така перевірка сама по собі ще не доводить, що повторні запити пароля зникли назавжди.
Автоматично оновлюємо прив’язку для нових Bash-терміналів
if ! grep -qF '# GPG agent terminal setup' ~/.bashrc; then cat >> ~/.bashrc <<'EOF' # GPG agent terminal setupif [[ $- == *i* ]] && [[ -t 0 ]]; then export GPG_TTY="$(tty)" gpg-connect-agent updatestartuptty /bye >/dev/null 2>&1 || truefiEOFfi source ~/.bashrcПеревірка коментаря перед додаванням блоку не дозволяє записати ту саму конфігурацію в ~/.bashrc кілька разів.
Після цього кожен новий інтерактивний Bash оновлюватиме прив’язку GPG Agent до поточного термінала автоматично.
Фінальна перевірка в новому терміналі
echo "===== SSH AGENT ====="echo "$SSH_AUTH_SOCK" echoecho "===== SSH SIGNATURE ====="ssh-add -T <(ssh-add -L)У нашому випадку SSH_AUTH_SOCK знову вказував на /run/user/1000/gnupg/S.gpg-agent.ssh, а команда перевірки підпису завершилася без повідомлень про помилку.
Для ssh-add -T відсутність повідомлення про помилку означає успішну перевірку підпису.
Якщо проблема залишилася тільки у VS Code
Якщо звичайний термінал працює правильно, але VS Code все одно просить пароль, це вже окрема ознака.
У такому випадку треба перевірити, з яким SSH_AUTH_SOCK був запущений сам процес VS Code і чи бачить його інтегрований термінал ті самі змінні середовища.
Тобто після виправлення GPG Agent не варто одразу змінювати ключ: спочатку треба відокремити проблему агента від проблеми оточення графічного застосунку.
Що в результаті було виправлено
Під час діагностики ми:
- перевірили активний SSH Agent і завантажені ключі;
- визначили поточні обмеження кешування пароля;
- збільшили час кешування до 8-12 годин;
- виявили помилку
agent refused operation; - оновили прив’язку GPG Agent до поточного термінала;
- додали автоматичну ініціалізацію в
~/.bashrc; - успішно перевірили SSH-підпис у новому терміналі.
Ключ може бути завантажений в агент, але це ще не означає, що агент правильно прив’язаний до поточного термінала і готовий виконати підпис.
