Jak zapobiec konieczności wprowadzania hasła do odszyfrowania klucza prywatnego za każdym razem, gdy używasz Git Bash w systemie Windows?

Mam usługę automatycznego budowania, która pobiera z prywatnego repozytorium git. Problem polega na tym, że gdy próbuje sklonować repozytorium, musi podać hasło, ponieważ nie jest ono zapamiętywane; więc ponieważ nie ma interakcji z człowiekiem, zawsze czeka na hasło. Jak mogę zmusić go do zapamiętania z id_rsa.pub?

Dla użytkowników systemu Windows wystarczy uwaga, że ​​w ten sposób skonfigurowałem środowisko Git Bash, aby logowało mnie raz po uruchomieniu. Edytuję mój ~/.bashrcplik:

eval `ssh-agent`
ssh-add

Kiedy więc uruchamiam Git Bash, wygląda to tak:

Welcome to Git (version 1.7.8-preview20111206)
(etc)
Agent pid 3376
Enter passphrase for /c/Users/starmonkey/.ssh/id_dsa:
Identity added: /c/Users/starmonkey/.ssh/id_dsa (/c/Users/starmonkey/.ssh/id_dsa)

A teraz mogę ssh na inne serwery bez logowania za każdym razem.

Ta odpowiedź wyjaśnia, jak sprawić, aby nazwa użytkownika i hasło GitHub były przechowywane na stałe, a nie hasło klucza SSH.

W systemie Windows po prostu uruchom

$ git config --global credential.helper wincred

Oznacza to, że następnym razem, gdy naciśniesz, wpiszesz swoją nazwę użytkownika i hasło jak zwykle, ale zostaną one zapisane w poświadczeniach systemu Windows. Po tym nie będziesz musiał ponownie do nich wchodzić.

Podobnie jak w przypadku, Push to GitHub bez wprowadzania nazwy użytkownika i hasła za każdym razem (Git Bash w systemie Windows) .

Wolę nie wpisywać hasła SSH podczas otwierania nowych terminali; niestety rozwiązanie starmonkey wymaga wpisywania hasła przy każdej sesji. Zamiast tego mam to w swoim .bash_profilepliku:

# Note: ~/.ssh/environment should not be used, as it
#       already has a different purpose in SSH.

env=~/.ssh/agent.env

# Note: Don't bother checking SSH_AGENT_PID. It's not used
#       by SSH itself, and it might even be incorrect
#       (for example, when using agent-forwarding over SSH).

agent_is_running() {
    if [ "$SSH_AUTH_SOCK" ]; then
        # ssh-add returns:
        #   0 = agent running, has keys
        #   1 = agent running, no keys
        #   2 = agent not running
        ssh-add -l >/dev/null 2>&1 || [ $? -eq 1 ]
    else
        false
    fi
}

agent_has_keys() {
    ssh-add -l >/dev/null 2>&1
}

agent_load_env() {
    . "$env" >/dev/null
}

agent_start() {
    (umask 077; ssh-agent >"$env")
    . "$env" >/dev/null
}

if ! agent_is_running; then
    agent_load_env
fi

# If your keys are not stored in ~/.ssh/id_rsa or ~/.ssh/id_dsa, you'll need
# to paste the proper path after ssh-add
if ! agent_is_running; then
    agent_start
    ssh-add
elif ! agent_has_keys; then
    ssh-add
fi

unset env

To zapamięta również moje hasło do nowych sesji terminala; Muszę go wpisać tylko raz, kiedy otwieram mój pierwszy terminal po uruchomieniu.

Chciałbym przyznać, skąd to mam; to modyfikacja cudzej pracy, ale nie pamiętam, skąd się wzięła. Dzięki anonimowemu autorowi!

Aktualizacja 2019-07-01: Nie sądzę, że to wszystko jest konieczne. Teraz konsekwentnie działam, upewniając się, że w moim .bash_profilepliku działa ssh-agent:

eval $(ssh-agent)

Następnie ustawiłem taki sshplik konfiguracyjny:

touch ~/.ssh/config
chmod 600 ~/.ssh/config
echo 'AddKeysToAgent yes' >> ~/.ssh/config

Jeśli dobrze rozumiem pytanie, używasz już autoryzowanego klucza SSH w usłudze kompilacji, ale chcesz uniknąć konieczności wpisywania hasła dla każdego klonu?

Przychodzą mi do głowy dwa sposoby, aby to zrobić:

1. Jeśli usługa kompilacji jest uruchamiana interaktywnie: przed uruchomieniem usługi kompilacji zacznij ssh-agentod wystarczająco długiego limitu czasu ( -topcja). Następnie użyj ssh-add(msysGit powinien je mieć), aby dodać wszystkie potrzebne klucze prywatne przed uruchomieniem usługi kompilacji. Nadal musiałbyś wpisać wszystkie hasła, ale tylko raz na uruchomienie usługi.

2. Jeśli chcesz w ogóle uniknąć konieczności wpisywania haseł, zawsze możesz usunąć hasła z kluczy SSH, jak opisano w /server/50775/how-do-i-change-my- private-key-passphrase , ustawiając puste nowe hasło. Powinno to całkowicie wyeliminować monit o hasło, ale jest jeszcze mniej bezpieczne niż poprzednia opcja.

Kiedy próbowałem przesłać kod, otrzymałem poniższy błąd:

$ git push origin dev

remote: Too many invalid password attempts. Try logging in through the website with your password.
fatal: unable to access 'https://naushadqamar-1@bitbucket.org/xxxx/xxxx-api.git/': The requested URL returned error: 403

Po kilku godzinach poszukiwań stwierdziłem, że muszę użyć następującego polecenia:

$ git config --global credential.helper cache

Po wykonaniu powyższego polecenia otrzymałem monit o wprowadzenie mojej nazwy użytkownika i hasła GitHub. Po podaniu prawidłowych danych uwierzytelniających jestem w stanie przesłać kod.

Właściwe rozwiązanie to:

1. Uruchom domyślny terminal Windows - cmd i pobierz katalog swojego głównego profilu

   echo %USERPROFILE%
   

2. Uruchom Git Bash w powyższym katalogu i utwórz .bashrcplik za pomocą polecenia

   echo "" > .bashrc
   

3. Otwórz .bashrcplik za pomocą ulubionego edytora tekstu i wklej kod z Pomocy GitHub do tego pliku:

   env=~/.ssh/agent.env
   ...
   COPY WHOLE CODE FROM URL - I can't add it to Stack Overflow because it breaks layout... OMG!
   

4. Uruchom ponownie Git Bash i zapyta Cię o hasło (tylko za pierwszym razem) i gotowe. Żadne hasło nie przeszkadza ponownie.

Musisz utworzyć authorized_keysplik w .sshfolderze użytkownika, pod którym będziesz się łączyć z serwerem repozytorium. Na przykład, przy założeniu korzystania z nazwy użytkownika buildservicena repo.servermożna uruchomić:

cd ~buidservice
mkdir ./ssh
cat id_rsa.pub >> .ssh/authorized_keys

Następnie musisz sprawdzić następujące rzeczy:

1. Ten odpowiedni id_rsaklucz prywatny jest przedstawiony w pliku builservice@build.server:~/.shh/id_rsa.

2. Ten odcisk palca repo.server jest przechowywany w buildservice@build.server:~/.ssh/known_hostspliku. Zwykle zostanie to zrobione po pierwszej próbie sshpołączenia się z repo.server.