Paggamit ng Git mula sa PowerShell na may mga secure na kredensyal: mga pamamaraan, trick, at pag-troubleshoot

Huling pag-update: 26/08/2025
May-akda: Isaac
  • Unahin ang Microsoft OAuth Sign in; gumamit ng PAT o SSH depende sa konteksto at umasa sa Git Credential Manager.
  • Pamahalaan ang mga lihim nang secure: SecureString/Keyfile in PowerShell at mga lihim sa GitHub Actions.
  • Mag-automate gamit ang Fabric API upang kumonekta, mag-update, at gumawa ng mga pagbabago, habang sinusubaybayan ang mga pagpapatakbo ng LRO.
  • Lutasin ang mga isyu sa pagpapatotoo sa Azure DevOps sa pamamagitan ng pagwawasto sa GCM, mga remote, cache, at configuration ng network.

Git at PowerShell na may mga secure na kredensyal

Ang ligtas na paggamit ng Git mula sa PowerShell ay hindi lamang usapin ng kaginhawahan; mahalaga ito para sa pagprotekta sa iyong code at mga pipeline. Sa mga sitwasyong kinasasangkutan ng mga integrasyon ng Azure DevOps, GitHub, o Microsoft Fabric, ang wastong pagpapatotoo ang siyang nagpapaiba sa pagitan ng isang matatag at isang mahinang daloy ng trabaho.

Saklaw ng komprehensibo at praktikal na gabay na ito ang mga inirerekomendang paraan ng pagpapatotoo (Microsoft OAuth Entra, PAT, at SSH), paggamit ng Git Credential Manager, pag-iimbak ng mga sikreto gamit ang PowerShell, mga sikreto sa GitHub Actions, automation gamit ang Fabric APIs, at pag-troubleshoot ng mga karaniwang isyu sa pag-login sa Azure DevOps. Lahat ay nakatuon sa pagliit ng panganib at pagpapabuti ng produktibidad.

Mga paraan ng pagpapatunay para sa Git: OAuth, PAT, at SSH key

Ang mas mainam na paraan ngayon para sa Azure Repos/Azure DevOps ay ang paggamit ng mga Microsoft Entra token batay sa OAuth 2.0, dahil sa kanilang enterprise integration at scope controls. Maaari mo ring gamitin ang PAT bilang alternatibo at mga SSH key kung saan ito mas praktikal o kinakailangan.

  • Microsoft Login OAuth Token (inirerekomenda): Makukuha ang mga ito on demand at magamit sa parehong Git at REST API. Mula sa Azure CLI, maaari kang mag-sign in at kumuha ng access token upang idagdag sa iyong mga operasyon sa Git. Halimbawa, sa pagpapatunay ng user, maaari mong makuha ang token gamit ang az account get-access-token at ilapat ito sa Git gamit ang isang karagdagang header tulad ng http.extraheader nang may katapangan AUTHORIZATION: bearer (gamit ang “bearer” at ang ibinigay na token).
  • Personal Access Token (PAT): Ang mga ito ay kapaki-pakinabang kapag wala kang SSH o hindi mo magagamit ang OAuth. Maaari silang limitahan ng mga permit at expiration, pagbabawas ng pagkakalantad. Upang magamit ang mga ito sa HTTPS, tandaan na ang Git ay hihingi ng isang username (ito ay maaaring kathang-isip lamang) at ang password ay ang PAT. Kung kailangan mong ipadala ang PAT sa isang header o string, ang Base64 encoding ay isang karaniwang kasanayan sa panig ng kliyente kapag kailangan ito ng workflow.
  • Mga susi ng SSH: Gumagana sila sa isang pampubliko/pribadong pares na nabuo sa iyong makina. Ang pampublikong susi ay nauugnay sa iyong account (hal. sa Azure DevOps o GitHub) at ini-encrypt ng server ang komunikasyon; nagde-decrypt ka sa lokal na pribado na hindi kailanman dapat ibahagi. Ang SSH ay lalong maginhawa kung ginagamit mo na ang ahente ng SSH, kung ayaw mong pamahalaan ang PAT sa HTTPS o kung ang iyong Linux/macOS/Windows na kapaligiran (Git para sa Windows) pinakaangkop sa mga susi.
  FOCA: Paano gamitin ang tool na ito upang suriin at i-extract ang metadata

Git Credential Manager: Pagpapatotoo nang walang palagiang pagta-type

CEO ng GitHub
24/09/2024 logo ng GitHub.
Kabuhayan
UNSPLASH

Ang Git Credential Manager (GCM) ay nag-iimbak at nag-iisyu ng mga token kapag hiniling, kaya hindi mo na kailangang mag-re-authenticate para sa bawat operasyon. Kapag naka-install na ang GCM, magla-log in ka nang isang beses, at ligtas na iniimbak ng manager ang token (Preferred Login o PAT OAuth) para magamit sa Git at iba pang mga client.

Mga Pinakamahusay na Kasanayan sa GCM : Kapag binago mo ang mga pamamaraan o nakakita ka ng mga conflict, i-uninstall ang mga lumang configuration ng credential manager at i-reconfigure ang mga ito. Pagkatapos, bawiin o i-rotate ang mga kredensyal kapag hindi na kailangan ang mga ito upang igalang ang prinsipyo ng least privilege.

Paggawa gamit ang mga kasalukuyang repositoryo: source, PAT, at cloning

Alisin ang dating remote kung ito ay na-configure gamit ang isang lumang paraan (hal. username/password). Maaari mong alisin ang remote gamit ang git remote remove origin para maiwasan ang credential clashes bago ito idagdag muli.

Muling idagdag ang remote na may pagpapatunay Maaaring malutas ng paggamit ng PAT sa pamamagitan ng HTTPS ang mga agarang isyu. Maaaring ipahayag ang remote sa isang URL na may naka-embed na PAT sa user, o maaaring gamitin ang GCM para maiwasang ilantad ang token sa text. Pagkatapos idagdag ang remote, itulak ang mga sanga sa git push -u origin --all.

Pag-clone gamit ang Azure DevOps: Kasama sa repo path sa Azure DevOps ang segment /_git/. Ang karaniwang clone URL ay isang katulad nito https://dev.azure.com/{organization}/{project}/_git/{repository}, isinasaalang-alang iyon pinapalitan ang aktwal na pangalan ng repo sa kaukulang marker.

SSH sa GitHub: Suriin, bumuo, at iugnay ang mga key

Pinapayagan ng GitHub ang authentication at paglagda ng mga commit at tag gamit ang SSH. Bago magdagdag ng bagong key, suriin kung mayroon ka nang nakarehistrong key; kung wala pa, bumuo ng bago at idagdag ito sa SSH agent ng iyong system.

Ang pag-uugnay ng iyong pampublikong key sa iyong GitHub.com account ay nagbibigay-daan sa pag-access sa SSH. Kung gusto mong gamitin ang parehong key para sa pagpapatotoo at pag-sign, kakailanganin mong i-upload ito nang dalawang beses , isang beses para sa bawat layunin. Pagkatapos, maaari mong i-configure muli ang isang remote upang gamitin ang SSH sa halip na HTTPS.

  Ang Windows 11 ay hindi nakakakita ng printer na nakakonekta sa pamamagitan ng USB o network: kumpletong gabay sa pag-troubleshoot

Automation gamit ang Microsoft Fabric: Git API Integration

  • Nag-aalok ang tela ng mga REST API para sa pagsasama sa Git para sa CI/CD at mga karaniwang operasyon: pagkonekta sa mga workspace, pagsisimula ng mga koneksyon, pag-update mula sa Git, paggawa ng maramihan o piling mga pagbabago, at pagsubaybay sa mga matagal nang operasyon.
  • Pagkonekta at pag-update ng workspace: pagkatapos mag-authenticate (halimbawa sa Connect-AzAccount) at kumuha ng token na may Get-AzAccessToken, hinihimok ang connect API upang iugnay ang workspace, repositoryo, at sangay. pagkatapos, sinisimulan ang koneksyon gamit ang nakalaang API; depende sa tugon, maaaring kailanganin ang "UpdateFromGit".
  • Update mula sa Git nagsasangkot ng pagbuo ng katawan gamit ang remote commit at ang workspace na estado, pagsasagawa ng tawag at suriin ang estado ng matagal na operasyon. Ang server ay nagbabalik ng isang operation identifier at isang retry interval, na maaari mong suriin nang pana-panahon hanggang sa makumpleto ang operasyon.
  • Iba pang mga pagpapatakbo ng API: I-commit ang lahat ng pagbabago sa workspace, piliing i-commit lang ang ilang partikular na item pagkatapos suriin ang status, at suriin ang mga operasyon ng LRO pagkuha ng operationId mula sa mga nakaraang tawag upang suriin ang pag-usad.
  • Mga koneksyon sa kredensyal para sa Git provider: Maraming mga tawag ang nangangailangan ng a connectionId. Maaari kang lumikha ng isang bagong koneksyon na mag-imbak ng isang GitHub PAT bilang isang kredensyal (opsyonal na nililimitahan ito sa isang partikular na imbakan) o ilista ang mga umiiral nang koneksyon upang muling gamitin ang kanilang id. Ang mga endpoint na ito ay nagbabalik ng mga katangian tulad ng displayName, landas, uri ng kredensyal at iba pang metadata.
  • Mga limitasyon na dapat isaalang-alang: Ang pagsasama ng API ay nagmamana ng mga paghihigpit sa UI, ang pag-authenticate ng pangunahing serbisyo ay sinusuportahan lamang para sa GitHub at ilang semantikong modelo maaaring lumitaw na may mga pagkakaiba pagkatapos ng pinahusay na mga update.

Ligtas na i-save ang mga kredensyal gamit ang PowerShell

Binibigyang-daan ka ng PowerShell na i-encrypt ang mga password at lihim at i-save ang mga ito sa disk para sa pagkonsumo sa ibang pagkakataon sa mga script. Sa Read-Host -AsSecureString Maaari kang kumuha ng secure na kredensyal gamit ang ConvertFrom-SecureString i-serialize ito na naka-encrypt sa isang file na may bisa lamang para sa parehong user at computer.

  • Gamitin sa parehong user: ang naka-encrypt na string na na-save gamit ang ConvertFrom-SecureString pwede lang na-decrypt ng user na nakabuo nito. Upang basahin ito pabalik sa a script, mag-apply Get-Content y ConvertTo-SecureString upang muling itayo ang ligtas na bagay sa memorya.
  • Portable Keyfile: Kung kailangan mo ng ibang mga user o machine para ma-decrypt ang sikreto, bumuo ng simetriko na key (halimbawa sa RNGCryptoServiceProvider) at gamitin ito sa ConvertFrom-SecureString -Key. Ise-save mo ang susi sa isang file at sa ibang pagkakataon, buuin mong muli ang SecureString sa ConvertTo-SecureString -Key gamit ang parehong keyfile.
  • Gumawa ng PSCredential Mula sa lihim na pagbabasa ito ay direkta: pinagsama mo ang gumagamit at ang SecureString en New-Object System.Management.Automation.PSCredential. Sa ganitong paraan, na-parameter mo ang user name at password nang hindi inilalantad ang malinaw na text sa script.
  • Kalinisan ng memorya: bagaman SecureString isolates ang string, may mga kaso kung saan mo binago ito sa text para sa interoperation. Kung gagawin mo ito, palayain ang pointer memory gamit ang ZeroFreeCoTaskMemUnicode pagkatapos gamitin SecureStringToBSTR y PtrToStringUni, pag-iwas sa pag-aaksaya ng memorya.