Git push wymaga nazwy użytkownika i hasła

Sklonowałem repozytorium Git z mojego konta GitHub na mój komputer.

Chcę pracować zarówno z komputerem, jak i laptopem, ale z jednym kontem GitHub.

Kiedy próbuję pchać lub pobierać z GitHub za pomocą mojego komputera, wymaga to nazwy użytkownika i hasła, ale nie kiedy używam laptopa!

Nie chcę wpisywać nazwy użytkownika i hasła przy każdej interakcji  origin. Czego tu brakuje?

Częstą przyczyną jest klonowanie przy użyciu domyślnego (HTTPS) zamiast SSH. Możesz to poprawić, przechodząc do swojego repozytorium, klikając „Klonuj lub pobierz”, a następnie klikając przycisk „Użyj SSH” nad polem adresu URL i aktualizując adres URL swojego zdalnego źródła w następujący sposób:

git remote set-url origin [email protected]:username/repo.git

Jest to udokumentowane na GitHub: Przełączanie zdalnych adresów URL z HTTPS na SSH .

Trwałe uwierzytelnianie za pomocą repozytoriów Git

Uruchom następujące polecenie, aby włączyć buforowanie referencji :

$ git config credential.helper store
$ git push https://github.com/owner/repo.git

Username for 'https://github.com': <USERNAME>
Password for 'https://[email protected]': <PASSWORD>

Należy również określić wygasanie buforowania ,

git config --global credential.helper 'cache --timeout 7200'

Po włączeniu buforowania referencji będzie ono buforowane przez 7200 sekund (2 godziny) .

Właśnie natrafiłem na ten sam problem, a najprostszym rozwiązaniem, jakie znalazłem, było użycie adresu URL SSH zamiast HTTPS:

ssh://[email protected]/username/repo.git

I nie to:

https://github.com/username/repo.git

Możesz teraz sprawdzić poprawność za pomocą tylko klucza SSH zamiast usernamei password.

Oprócz zmiany na SSH możesz nadal korzystać z HTTPS, jeśli nie masz nic przeciwko, aby hasło było zapisane czystym tekstem. Umieść to w swoim, ~/.netrca nie poprosi o twoją nazwę użytkownika / hasło (przynajmniej w systemie Linux i Mac):

machine github.com
       login <user>
       password <password>

Dodawanie (patrz drugi komentarz VonC): w systemie Windows nazwa pliku to %HOME%\_netrc.

Przeczytaj także pierwszy komentarz VonC na wypadek, gdybyś chciał zaszyfrować.

Kolejny dodatek (patrz komentarz użytkownika 137717), którego możesz użyć, jeśli masz Git 1.7.10 lub nowszy .

Buforuj swoje hasło GitHub w Git za pomocą pomocnika poświadczeń :

Jeśli klonujesz repozytoria GitHub przy użyciu HTTPS, możesz użyć pomocnika poświadczeń, aby powiedzieć Gitowi, aby zapamiętał twoją nazwę użytkownika i hasło GitHub za każdym razem, gdy rozmawia z GitHub.

Działa to również w systemach Linux, Mac i Windows.

Dla niewtajemniczonych, którzy są zdezorientowani poprzednimi odpowiedziami, możesz:

git remote -v

Który zareaguje czymś takim

origin    https://[email protected]/yourname/yourrepo.git (fetch)
origin    https://[email protected]/yourname/yourrepo.git (push)

Następnie możesz uruchomić polecenie sugerowane przez wielu innych, ale teraz znasz swoje imię i nazwisko z góry, dzięki czemu możesz po prostu wyciąć i wkleić yourname/yourrepo.gitz powyższego do:

git remote set-url origin [email protected]:yourname/yourrepo.git

Jeśli używasz SSH i klucz prywatny jest zaszyfrowany za pomocą hasła, a następnie będziesz nadal być poproszony o wprowadzić hasło / hasło do klucza prywatnego podczas wykonywania operacji sieciowych z Git jak push, pulli fetch.

Użyj ssh-agent, aby zapisać hasło / hasło do klucza prywatnego

Jeśli chcesz uniknąć konieczności wpisywania hasła za każdym razem, możesz użyć ssh-agentdo zapisywania poświadczeń hasła prywatnego raz na sesję terminalową, jak wyjaśniam w mojej odpowiedzi na Nie można otworzyć połączenia z agentem uwierzytelniającym :

$ eval `ssh-agent -s`
$ ssh-add

W Windows msysgit Bash musisz ocenić dane wyjściowe ssh-agent, ale nie jestem pewien, czy musisz zrobić to samo w innych środowiskach programistycznych i systemach operacyjnych.

ssh-addszuka w prywatnym .sshfolderze domowym klucza prywatnego o nazwie id_rsadomyślnej, ale ścieżkę pliku można przekazać do klucza o innej nazwie.

Zabicie agenta

Po zakończeniu sesji terminalu możesz zamknąć ssh-agentflagę kill -k:

$ ssh-agent -k

Jak wyjaśniono w ssh-agentinstrukcji :

-k

Zabij bieżącego agenta (podanego przez zmienną środowiskową SSH_AGENT_PID).

Opcjonalny limit czasu

Może również zająć opcjonalny parametr limitu czasu, taki jak:

$ ssh-add -t <timeout>

gdzie <timeout>jest formatem <n>hdla <n>godzin <n>mna <n>minuty, i tak dalej.

Zgodnie z ssh-agentinstrukcją :

-t life

Ustaw wartość domyślną dla maksymalnego okresu istnienia tożsamości dodanych do agenta. Czas życia można określić w sekundach lub w formacie czasu określonym w sshd_config (5) . Okres istnienia określony dla tożsamości z ssh-add (1) przesłania tę wartość. Bez tej opcji domyślny maksymalny okres użytkowania jest wieczny.

Zobacz tę stronę, aby uzyskać więcej formatów czasu .

Ostrzeżenie bezpieczeństwa dla użytkowników Cygwin

Użytkownicy Cygwin powinni zdawać sobie sprawę z potencjalnego zagrożenia bezpieczeństwa podczas korzystania z ssh-agent w Cygwin :

ludzie powinni być świadomi potencjalnych zagrożeń związanych z ssh-agent w Cygwin 1 , chociaż pod lokalną siecią i zdalnym portemcan nie wydaje się, aby port określony w / tmp / ssh-foo był dostępny dla każdego ...?

[1]: http://www.cygwin.com/ml/cygwin/2001-01/msg00063.html

I pod cytowanym linkiem :

zauważ jednak, że gniazda domenowe Cygwina są PODSTAWOWO NIEBEZPIECZNE, dlatego zdecydowanie ODKRYJEM używanie ssh-agent pod Cygwin.

po uruchomieniu ssh-agent w Cygwin tworzy on gniazdo AF_UNIX w /tmp/ssh-$USERNAME/katalogu. Pod Cygwin AF_UNIX gniazda są emulowane przez gniazda AF_INET. Możesz łatwo to zobaczyć, jeśli zajrzysz do /tmp/ssh-$USERNAME/agent-socket-*pliku za pomocą Notatnika. Zobaczysz coś takiego

!<socket >2080

następnie biegnij netstat -ai zaskocz się! Masz jakiś program nasłuchujący na porcie 2080. To ssh-agent. Gdy ssh otrzymuje wyzwanie RSA od serwera, odnosi się do odpowiedniego /tmp/ssh-$USERNAME/agent-socket-*(w naszym przypadku Cygwin oznacza to, że otworzy połączenie localhost:2080) i prosi ssh-agent o przetworzenie wyzwania RSA za pomocą klucza prywatnego, który ma, a następnie po prostu przekazuje odpowiedź otrzymaną od agenta ssh na serwer.

W systemie Unix taki scenariusz działa bez problemów, ponieważ jądro systemu Unix sprawdza uprawnienia, gdy program próbuje uzyskać dostęp do gniazda AF_UNIX. Jednak w przypadku gniazd AF_INET połączenia są anonimowe (czytaj „niepewne”). Wyobraź sobie, że masz uruchomionego agenta ssh Cygwin. Złośliwy haker może przeskanować twoje urządzenie, zlokalizować otwarty port używany przez ssh-agent, otworzyć połączenie z serwerem SSH, otrzymać od niego wyzwanie RSA, wysłać go do twojego ssh-agent przez otwarty port, który znalazł, odebrać Odpowiedź RSA, wyślij ją na serwer SSH i voila, on / ona pomyślnie zalogował się na twój serwer jako ty.

Źródło: Skonfiguruj Git

Następujące polecenie zapisze twoje hasło na pewien czas (dla Git 1.7.10 lub nowszej).

$ git config --global credential.helper cache
# Set git to use the credential memory cache

$ git config --global credential.helper 'cache --timeout=3600'
# Set the cache to timeout after one hour (setting is in seconds)

Kiedy używasz https do Git pull & push, po prostu skonfiguruj remote.origin.urlswój projekt, aby uniknąć wprowadzania nazwy użytkownika (i / lub hasła) za każdym razem, gdy naciskasz.

Jak skonfigurować remote.origin.url:

Format adresu URL:
    https: // {nazwa użytkownika: hasło @} github.com/ {właściciel} / {repo}

Parametry w adresie URL:

* nazwa użytkownika 

    Opcjonalne, nazwa użytkownika do użycia w razie potrzeby. 
poświadczenie,
    jeśli jest określony, nie trzeba ponownie wprowadzać nazwy użytkownika, gdy trzeba uwierzytelnić.
    Nie używaj e-maila; użyj swojej nazwy użytkownika, która nie ma „@”, w przeciwnym razie nie można poprawnie przeanalizować adresu URL,
* hasło
    opcjonalnie hasło do użycia, gdy potrzebne jest uwierzytelnienie.
    Jeśli jest określony, nie trzeba ponownie wprowadzać hasła, gdy wymagane jest uwierzytelnienie.
    Wskazówka:
        ta wartość jest przechowywana jako zwykły tekst, więc ze względów bezpieczeństwa nie określaj tego parametru,
*

na przykład
    git config remote.origin.url https: //[email protected]/eric/myproject

@ Aktualizacja - za pomocą ssh

Myślę, że użycie sshprotokołu jest lepszym rozwiązaniem niż https, chociaż etap konfiguracji jest nieco bardziej złożony.

Ostre kroki:

• Utwórz klucze ssh za pomocą polecenia, np. W ssh-keygensystemie Linux, w systemie Windows msysgitpodaj podobne polecenia.
• Przechowuj klucz prywatny na komputerze lokalnym w odpowiedniej lokalizacji, np ~/.ssh. I dodaj go do agenta ssh za pomocą ssh-addkomendy.
• Prześlij klucz publiczny na serwer Git.
• Zmiana remote.origin.urlrepozytorium Git na sshstyl, np.[email protected]:myaccount/myrepo.git
• Następnie, gdy ciągniesz lub wypychasz, nie musisz już nigdy wprowadzać nazwy użytkownika ani hasła.

Wskazówki:

• Jeśli twój klucz ssh ma hasło, to musisz wprowadzić je przy pierwszym użyciu klucza po każdym ponownym uruchomieniu komputera.

@Update - Zmiana httpsi sshprotokół.

Wystarczy sama zmiana remote.origin.url, lub możesz edytować repo_home/.git/configbezpośrednio, aby zmienić wartość (np. Używając viLinuksa).

Zwykle dodam wiersz dla każdego protokołu i komentuję jeden z nich za pomocą #.

Na przykład

[zdalne „pochodzenie”]
        url = [email protected]: myaccount / myrepo.git
        # url = https: //[email protected]/myaccount/myrepo.git
        fetch = + referencje / głowice / *: referencje / piloty / pochodzenie / *

Możesz buforować swoje hasło GitHub w Git:

Postępuj zgodnie z instrukcjami z oficjalnej dokumentacji GitHub .

Po wykonaniu instrukcji z powyższego linku powinieneś być w stanie pchać / wyciągać do / z repozytorium bez wpisywania nazwy użytkownika / hasła za każdym razem.

Oto kolejna opcja:

Zamiast pisać

git push origin HEAD

Możesz napisać:

git push https://user:[email protected]/path HEAD

Oczywiście w przypadku większości powłok spowoduje to buforowanie hasła w historii, więc miej to na uwadze.

To, co zadziałało, to edycja .git/configi użycie

[remote "origin"]
        url = https://<login>:<password>@gitlab.com(...).git

Jest rzeczą oczywistą, że jest to niebezpieczny sposób przechowywania hasła, ale istnieją środowiska / przypadki, w których może to nie stanowić problemu.

Jeśli klucz lub .netrcplik SSH nie działał dla Ciebie, to innym prostym, ale mniej bezpiecznym rozwiązaniem, które może Ci pomóc, jest git-credential-store - Pomocnik w przechowywaniu poświadczeń na dysku:

git config --global credential.helper store

Domyślnie poświadczenia zostaną zapisane w pliku ~/.git-credentials. Zostanie utworzony i napisany do.

Pamiętaj, że użycie tego pomocnika będzie przechowywać hasła nieszyfrowane na dysku, chronione tylko przez uprawnienia systemu plików. Jeśli może to nie być akceptowalny kompromis w zakresie bezpieczeństwa.

Miałem ten sam problem.

Więc zmieniłem .git/configplik z mojego projektu,

url = https://github.com/<your-user-here>/<your-repo-here>

do

url = [email protected]:<your-user-here>/<your-repo-here>

i dodał klucz publiczny SSH do ustawionego profilu Git.

W przypadku klucza publicznego SSH:

cat ~/.ssh/id_rsa.pub

Aktualizacja dla HTTPS:

GitHub uruchomił nowy program dla systemu Windows, który przechowuje dane uwierzytelniające podczas korzystania z HTTPS:

Używać:

• Pobierz program stąd

• Po uruchomieniu program dokona edycji .gitconfigpliku. Sprawdź ponownie, czy edytował poprawny, .gitconfigjeśli masz kilka z nich. Jeśli nie edytował poprawnego, dodaj następujące elementy do swojego.gitconfig

  [credential]
      helper = !'C:\\Path\\To\\Your\\Downloaded\\File\\git-credential-winstore.exe'
  

  UWAGA podział linii po [credential]. Jest wymagane.

• Otwórz klienta linii poleceń i spróbuj git push origin masterraz. Jeśli poprosi Cię o hasło, wpisz je i gotowe. Hasło zapisane!

W przypadku użytkowników Windows Git, po uruchomieniu git config --global credential.helper store, jeśli nadal monituje o hasło, lepiej sprawdzić, gdzie zapisany jest plik konfiguracyjny, za pomocą tego polecenia

git config --list --show-origin

W moim przypadku po ręcznej edycji pliku konfiguracyjnego „C: \ Program Files \ Git \ mingw64 \ etc \ gitconfig” i dodaniu następującego tekstu zadziałało.

[credential]
    helper = store

Zasadniczo masz dwie opcje.

Jeśli używasz tego samego użytkownika na obu komputerach, musisz skopiować klucz .pub na komputer, aby GitHub wiedział, że jesteś tym samym użytkownikiem.

Jeśli utworzyłeś nowy plik .pub dla swojego komputera i chcesz traktować maszyny jak różnych użytkowników, musisz zarejestrować nowy plik .pub na stronie GitHub.

Jeśli to nadal nie działa, może to być spowodowane tym, że ssh nie jest poprawnie skonfigurowany i że ssh nie może znaleźć lokalizacji twoich kluczy. Próbować

ssh -vv [email protected]

Aby uzyskać więcej informacji o tym, dlaczego SSH nie działa.

Bezpośrednia aktualizacja pliku konfiguracyjnego Git ( jeśli nie chcesz zapamiętywać fantazyjnych poleceń ):

Otwórz .git/configplik w swoim ulubionym edytorze tekstu. Będzie on w folderze, który sklonowałeś lub w repozytorium, w którym wykonałeś git init. Przejdź do tego repozytorium. .gitjest ukrytym folderem, a naciśnięcie Ctrl+ Hpowinno pokazać ukryty folder ( ls -aw terminalu).

Poniżej znajduje się próbka .git/configpliku. Skopiuj i wklej te linie i pamiętaj, aby zaktualizować je o informacje Git.

[user]
        name = Tux
        email = [email protected]
        username = happy_feet

[remote "origin"]
        url = https://github.com/happy_feet/my_code.git
        fetch = +refs/heads/*:refs/remotes/origin/*

Zmień część adresu URL za pomocą następującego formatu SSH:

url = [email protected]:happy_feet/my_code.git

( Powyższe formaty nie zmieniają się w przypadku różnych zdalnych serwerów Git, takich jak GitHub lub Bitbucket. Tak samo jest, jeśli używasz Git do kontroli wersji ):

Uwaga: sposób połączenia SSH ze zdalnym repozytorium Git wymaga dodania publicznego klucza SSH do zdalnego serwera Git ( takiego jak GitHub lub Bitbucket. Wyszukaj klucze SSH na stronie ustawień ).

Aby dowiedzieć się, jak wygenerować klucze SSH, patrz: Tworzenie kluczy SSH

Oto, co zadziałało dla mnie:

git remote set-url origin https://[email protected]/username/reponame.git

Przykład:

git remote set-url origin https://[email protected]/jsmith/master.git

Musisz wykonać dwa kroki -

1. git remote remove origin
2. git remote add origin [email protected]:NuggetAI/nugget.git

Zauważ, że Git URL to URL SSH, a nie URL HTTPS ... Który możesz wybrać tutaj:

Jeśli sklonowałeś HTTPS zamiast SSH i napotkałeś problem z pytaniem o nazwę użytkownika i hasło przy pobieraniu, wypychaniu i pobieraniu. Możesz rozwiązać ten problem po prostu dla UBUNTU

Krok 1: przejdź do katalogu głównego

cd ~/

utwórz plik .git-credentials

Dodaj tę zawartość do tego pliku z tobą usename passwordigithosting URL

https://user:[email protected]

Następnie wykonaj polecenie

git config --global credential.helper store

Teraz będziesz mógł bez problemu wyciągać push i pobrać wszystkie szczegóły z repozytorium.

Jeśli używasz Git (na przykład Git Bash) w systemie Windows (i nie chcesz przełączać się z HTTPS na SSH), możesz także użyć Git Credential Manager dla Windows

Ta aplikacja zachowa dla Ciebie nazwę użytkownika i hasło ...

Jak wielu użytkowników powiedziało, wystarczy zmienić adres URL repozytorium Git z HTTPS na SSH.

Jeśli nie wygenerowałeś klucza SSH na swoim komputerze, będziesz musiał to zrobić.

Jako dodatkową informację, po wprowadzeniu tej zmiany nadal otrzymywałem ten sam błąd:

Odmowa zezwolenia.

W moim przypadku problem polegał na tym, że korzystałem z powłoki systemu Windows, aby wykonać polecenie ngh; ponieważ to polecenie powinno otworzyć monit o żądanie wyrażenia SSH, a powłoka systemu Windows nie otwiera tego rodzaju monitów, uwierzytelnianie po prostu nie powiodło się.

Musiałem więc po prostu otworzyć powłokę Git i wykonać tam polecenie ngh, wstawić wyrażenie SSH do monitu za każdym razem, gdy o to poprosił, i „voilà” ... Po prostu działało dobrze!

    # create the company identity file
    ssh-keygen -t rsa -b 4096 -C "[email protected]"
    # save private key to ~/.ssh/id_rsa.corp, 
    cat ~/.ssh/id_rsa.corp.pub # copy paste this string into your corp web ui security ssh keys

    # create your private identify file
    ssh-keygen -t rsa -b 4096 -C "[email protected]"
    # save private key to ~/.ssh/id_rsa.me, note the public key ~/.ssh/id_rsa.me.pub
    cat ~/.ssh/id_rsa.me.pub # copy paste this one into your githubs, private keys

    # clone company internal repo as follows
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git clone [email protected]:corp/project.git

    export git_msg="my commit msg with my corporate identity"
    git add --all ; git commit -m "$git_msg" --author "MeFirst MeLast <[email protected]>"
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git push 

    # clone public repo as follows
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.corp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git clone [email protected]:acoolprojectowner/coolproject.git

    export git_msg="my commit msg with my personal identity"
    git add --all ; git commit -m "$git_msg" --author "MeFirst MeLast <[email protected]>"
    GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.me -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" \
    git push 

    # stop :: how-to use different ssh identity files