GitHub-ի հին SSH բանալին պարտադիր չէ փոխել․ ստուգեք ստորագրության ալգորիթմը

GitHub-ի SSH փոփոխությունների ժամանակացույցը սահմանում է, որ 2026 թվականի հոկտեմբերի 14-ից նոր ավելացվող RSA բանալին պետք է ունենա առնվազն 3072 բիթ, իսկ 2027 թվականի հունվարի 13-ին նախատեսված է դադարեցնել SHA-1 ստորագրության ընդունումը՝ թողնելով RSA-ի SHA-2 ստորագրությունները։ Արդեն գրանցված RSA բանալին միայն չափի պատճառով փոխելու կարիք չկա, եթե դրանով միացող հաճախորդն օգտագործում է RSA-SHA-2։

Ստուգման հերթականությունը պարզ է՝ գտեք GitHub-ին միանալու համար օգտագործվող բանալին և SSH հաճախորդը, ապա դիտեք կապի ընթացքում ընտրված ստորագրությունը։ Եթե գործող RSA բանալին ստորագրում է rsa-sha2-256 կամ rsa-sha2-512 ալգորիթմով և կապը հաջողվում է, այս փոփոխության համար նոր բանալի ստեղծել պետք չէ։ Եթե կապը հենվում է SHA-1-ի վրա, նախ պարզեք՝ հնարավոր է արդյոք թարմացնել հաճախորդը։

Ո՞ւմ է վերաբերում նոր պահանջը

Չափի շեմը կիրառվում է նոր ավելացվող RSA բանալիների նկատմամբ՝ ինչպես նույնականացման, այնպես էլ ստորագրման համար։ Կարևոր է ավելացման պահը. հին բանալին GitHub հաշվից հեռացնելուց հետո կրկին ավելացնելը նոր գրանցում է։ Ուստի միայն չափը տեսնելով գործող գրառումը հեռացնելը կարող է անհարկի դժվարացնել վերադարձը նախկին կարգավորմանը։

Բանալու տեսակն ու ստորագրության ալգորիթմը տարբեր բաներ են։ Հանրային բանալու սկզբի ssh-rsa գրառումը ցույց է տալիս, որ բանալին RSA է։ Կապի ախտորոշման մեջ նույն ssh-rsa անունը որպես ստորագրության ալգորիթմ նշանակում է RSA՝ SHA-1-ով։ Նույն RSA զույգը կարող է օգտագործվել նաև rsa-sha2-256 կամ rsa-sha2-512 ստորագրությամբ, եթե հաճախորդն աջակցում է դրանց։

Սկզբում տվյալ պահոցում գործարկեք git remote -v։ Եթե օգտագործվող հեռավոր հասցեն սկսվում է https://-ով, այդ Git գործողությունը SSH բանալի չի օգտագործում։ Եթե GitHub-ին միանում եք նաև մեկ այլ համակարգչից, IDE-ից կամ ավտոմատացման միջավայրից, յուրաքանչյուրի կապը ստուգեք առանձին. նույն հաշվին միանալը չի նշանակում, որ բոլոր միջավայրերն ունեն նույն SSH ծրագիրն ու կարգավորումը։

Գտեք օգտագործվող բանալին և հաճախորդը

Linux-ի, macOS-ի կամ Git Bash-ի տերմինալում ls -la ~/.ssh հրամանը ցույց է տալիս լռելյայն պանակի ֆայլերը։ Այնտեղ կարող եք գտնել, օրինակ, id_rsa մասնավոր բանալին և id_rsa.pub հանրային բանալին։ Եթե բանալին պահված է այլ անունով կամ վայրում, ստուգեք նաև այդ ուղին. միայն լռելյայն պանակի ցուցակը ամբողջ պատկերը չի տալիս։

ssh-add -l հրամանը ցույց է տալիս SSH agent-ում բեռնված բանալիները։ Եթե ցուցակը դատարկ է, դա դեռ չի նշանակում, որ համակարգում բանալի չկա. SSH-ը կարող է կարդալ մասնավոր ֆայլը անմիջապես։ Կոնկրետ հանրային բանալու չափն ու մատնահետքը տեսնելու համար գործարկեք ssh-keygen -lf ~/.ssh/id_rsa.pub՝ ֆայլի անունը փոխելով ըստ անհրաժեշտության։ Ցուցադրվող SHA256 մատնահետքը նույնականացնում է բանալին. այն չի բացահայտում կապի ստորագրության ալգորիթմը։

ssh -V հրամանը ցույց է տալիս տվյալ տերմինալից կանչվող OpenSSH-ի տարբերակը։ Սակայն Git for Windows-ը, IDE-ն կամ CI առաջադրանքը կարող են գործարկել մեկ այլ SSH ծրագիր։ Եթե տարբերությունը կարևոր է, ստուգեք նաև Git-ի core.sshCommand կարգավորումը և տվյալ միջավայրի GIT_SSH_COMMAND փոփոխականը։ Տարբերակը նախնական հուշում է, իսկ որոշիչը հենց այն կապի փորձն է, որով կատարվում է աշխատանքը։

Կապի փորձով պարզեք ստորագրությունը

Գործող RSA բանալին առանձին փորձարկելու համար գործարկեք ssh -vvvT -o ControlMaster=no -o ControlPath=none -o IdentitiesOnly=yes -i ~/.ssh/id_rsa [email protected]։ -i-ից հետո նշեք մասնավոր ֆայլի իրական ուղին՝ առանց .pub վերջավորության։ -vvv մանրամասնությունն անհրաժեշտ է, քանի որ OpenSSH-ի «signing using» ախտորոշիչ տողը սովորական -v ելքում կարող է չերևալ։ Կապի վերօգտագործումն անջատող ընտրանքներն օգնում են տեսնել նոր բանակցության արդյունքը։

Ելքում նախ գտեք «Offering public key» տողը և համոզվեք, որ առաջարկվել է նախատեսված բանալին։ Այնուհետև փնտրեք «sign_and_send_pubkey: signing using» տողը։ Եթե դրա շարունակությունը rsa-sha2-256 կամ rsa-sha2-512 է, տվյալ փորձի ընթացքում RSA բանալին ստորագրել է SHA-2-ով։ «ssh-rsa» գրառումը հենց այդ տողում, ի տարբերություն հանրային բանալու սկզբի, ցույց է տալիս SHA-1 ստորագրություն։

Հաջող նույնականացման դեպքում GitHub-ի պատասխանում երևում է «Hi USERNAME» ողջույնը՝ ձեր հաշվի անունով։ Եթե ելքում կա միայն «Offering public key», բայց չկա ստորագրման տող, առաջարկը դեռ չի ապացուցում, թե որ ալգորիթմն է կիրառվել։ «Permission denied (publickey)» պատասխանի դեպքում համեմատեք առաջարկված բանալու մատնահետքը հաշվին ավելացվածի հետ և ստուգեք՝ արդյոք կապն ուղարկվում է ճիշտ հաշվին։

Եթե հաճախորդը SHA-2-ով RSA ստորագրություն չի կատարում, փորձեք թարմացնել հենց այդ հաճախորդը կամ այն օգտագործող գրադարանը։ Ավելի երկար RSA բանալի ստեղծելը ինքնին չի փոխում հին հաճախորդի ստորագրության հնարավորությունները։ Եթե թարմացումը հնարավոր չէ, ստուգեք՝ արդյոք նույն միջավայրն աջակցում է Ed25519-ին. այդ դեպքում նոր բանալին կարող է լուծել համատեղելիության խնդիրը։

Անհրաժեշտության դեպքում ստեղծեք նոր զույգ

Նոր բանալի ստեղծելիս GitHub-ի բանալու ստեղծման հրահանգը առաջարկում է Ed25519, իսկ այն չաջակցող հին համակարգի համար՝ RSA 4096 տարբերակը։ Հատուկ ֆայլի անուն ընտրեք, որպեսզի նոր զույգը չվերագրի գործողը։ Հետևյալ օրինակներում [email protected]ը փոխարինեք ձեր էլփոստի հասցեով. այն բանալու պիտակն է։

1. Ed25519-ի համար գործարկեք ssh-keygen -t ed25519 -f ~/.ssh/github_ed25519 -C [email protected]։ Եթե անհրաժեշտ է RSA տարբերակը, գործարկեք ssh-keygen -t rsa -b 4096 -f ~/.ssh/github_rsa_4096 -C [email protected]։ Ընտրեք ձեր հաճախորդի և օգտագործվող ծառայությունների հետ համատեղելի տարբերակը։
2. Երբ ssh-keygen-ը խնդրի գաղտնաբառային արտահայտություն, ընտրեք ուժեղ արտահայտություն։ Ստուգեք, որ ստեղծվել են նոր մասնավոր ֆայլը և նույն անունով .pub հանրային ֆայլը։ Հին զույգը թողեք տեղում. նորի ստեղծումը դեռ չի նշանակում, որ GitHub հաշվին կամ պահոցներին հասանելիությունն արդեն փոխվել է։
3. Նոր մասնավոր բանալին ավելացրեք agent-ին՝ օրինակ ssh-add ~/.ssh/github_ed25519 հրամանով։ Եթե ընտրել եք RSA-ն, այստեղ նշեք github_rsa_4096 ֆայլը։ Agent-ի աշխատանքը կախված է համակարգից, ուստի դատարկ կամ անհասանելի agent-ի դեպքում նախ գործարկեք այն ձեր միջավայրի համար ընդունված ձևով։

Ավելացրեք հանրային բանալին հաշվին

GitHub-ի հանրային բանալի ավելացնելու քայլերով բացեք Settings, ապա SSH and GPG keys բաժինը և ընտրեք New SSH key։ Տվեք տարբերակելի անուն, ընտրեք Authentication Key և Key դաշտում տեղադրեք միայն նոր .pub ֆայլի պարունակությունը։ Մասնավոր բանալու ֆայլը մի պատճենեք հաշվին։

Հանրային տողը կարող եք տեսնել cat ~/.ssh/github_ed25519.pub հրամանով՝ անունը փոխելով ըստ ձեր ընտրության։ Պատճենեք այն ամբողջությամբ՝ առանց ավելորդ բացատների կամ նոր տողերի։ Այս փուլում հին բանալու գրառումը պահեք հաշվին. այդպես նոր բանալին կարելի է փորձարկել, մինչ նախկին մուտքի եղանակը դեռ հասանելի է։

Փորձարկեք սովորական աշխատանքային ուղին, հետո հեռացրեք հինը

Նոր բանալիով կրկնեք կապի փորձը՝ ssh -vvvT -o ControlMaster=no -o ControlPath=none -o IdentitiesOnly=yes -i ~/.ssh/github_ed25519 [email protected]։ Ստուգեք և առաջարկված ֆայլը, և պատասխանում երևացող հաշվի անունը։ Եթե առաջին կապի ժամանակ SSH-ը խնդրի հաստատել GitHub սերվերի մատնահետքը, նախ համեմատեք այն GitHub-ի հրապարակած մատնահետքի հետ։ RSA տարբերակի դեպքում նույն հրամանում փոխեք միայն բանալու ուղին։

Հաջորդը կարգավորեք ձեր սովորական Git միջավայրը, որպեսզի այն նույնպես ընտրի նոր բանալին, և համապատասխան պահոցում գործարկեք git ls-remote origin։ Այս հրամանը կարդում է հեռավոր հղումները՝ առանց պահոցի բովանդակությունը փոխելու։ Առանձին ssh -i փորձի հաջողությունը դեռ չի երաշխավորում, որ IDE-ն, մյուս համակարգիչը կամ CI առաջադրանքն անցել է նոր բանալուն. ստուգեք յուրաքանչյուր օգտագործվող ուղին։

Երբ նոր բանալիով մուտքը հաստատված է բոլոր անհրաժեշտ միջավայրերում, SSH and GPG keys ցանկում մատնահետքով գտեք և հեռացրեք հին գրառումը։ Տեղական հին մասնավոր ֆայլը ջնջեք միայն այն ժամանակ, երբ համոզվել եք, որ այն այլ ծառայության կամ միջավայրի համար այլևս պետք չէ։

Կարդացեք նաև:

• GitHub Actions-ի ամպային բանալիները փոխարինեք մեկ job-ի OIDC token-ով
• YouTube-ի կանաչ նշանը թույլտվություն չէ․ ստուգեք նաև Content ID-ի սահմանը
• Stripe թե PayPal Հայաստանում․ հանձնաժողովից առաջ ստուգեք՝ գումար կստանա՞ք