Używanie uwierzytelniania klucza SSH

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Możesz łączyć się z repozytoriami usługi Git za pośrednictwem protokołu SSH w systemach macOS, Linux i Windows, aby zapewnić bezpieczeństwo połączeń przy użyciu uwierzytelniania HTTPS.

Ważne

Adresy URL protokołu SSH uległy zmianie, ale stare adresy URL protokołu SSH nadal działają. Jeśli masz już skonfigurowany protokół SSH, zaktualizuj zdalne adresy URL do nowego formatu:

Aktualne adresy URL protokołu SSH zaczynają się od ssh.dev.azure.com. Poprzednie adresy URL używają polecenia vs-ssh.visualstudio.com.

  • Sprawdź, które zdalnie używają protokołu SSH. Uruchom git remote -v polecenie w powłoce lub zamiast tego użyj klienta graficznego interfejsu użytkownika.
  • Odwiedź repozytorium w Internecie i wybierz pozycję Klonuj.
  • Wybierz pozycję SSH i skopiuj nowy adres URL SSH.
  • W powłoce uruchom git remote set-url <remote name> <new SSH URL> polecenie dla każdego zdalnego repozytorium, które chcesz zaktualizować. Możesz też użyć klienta graficznego interfejsu użytkownika, aby zaktualizować zdalne adresy URL.

Jak działa uwierzytelnianie za pomocą klucza SSH

Uwierzytelnianie za pomocą klucza publicznego SSH działa z asymetryczną parą wygenerowanych kluczy szyfrowania. Klucz publiczny jest współużytkowany z usługą Azure DevOps i używany do weryfikowania początkowego połączenia SSH. Klucz prywatny jest bezpieczny i bezpieczny w systemie.

Konfigurowanie uwierzytelniania za pomocą klucza SSH

Poniższe kroki obejmują konfigurację uwierzytelniania klucza SSH na następujących platformach przy użyciu wiersza polecenia (nazywanego shellrównież ):

Uwaga

Od programu Visual Studio 2017 protokół SSH może służyć do łączenia się z repozytoriami Git usługi Azure DevOps.

Napiwek

W systemie Windows zalecamy użycie menedżera poświadczeń Git lub osobistych tokenów dostępu.

Krok 1. Tworzenie kluczy SSH

Uwaga

Jeśli klucze RSA SSH zostały już utworzone w systemie, pomiń ten krok i skonfiguruj klucze SSH. Aby to sprawdzić, przejdź do katalogu macierzystego .ssh i przyjrzyj się folderowi (%UserProfile%\.ssh\ w systemach Windows lub ~/.ssh/ Linux, macOS i Windows przy użyciu powłoki Git Bash). Jeśli zobaczysz dwa pliki o nazwie id_rsa i id_rsa.pub odpowiednio kontynuuj konfigurowanie kluczy SSH.

Aby użyć uwierzytelniania opartego na kluczach, należy najpierw wygenerować pary kluczy publicznych/prywatnych dla klienta. ssh-keygen.exe służy do generowania plików kluczy, a można określić algorytmy DSA, RSA, ECDSA lub Ed25519. Jeśli nie określono żadnego algorytmu, jest używana funkcja RSA.

Uwaga

Jedynym typem klucza SSH obsługiwanym przez usługę Azure DevOps jest RSA.

Aby wygenerować pliki kluczy przy użyciu algorytmu RSA, uruchom następujące polecenie z poziomu programu PowerShell lub innej powłoki, takiej jak bash na kliencie:

ssh-keygen

Dane wyjściowe polecenia powinny zawierać następujące dane wyjściowe (gdzie username jest zastępowana przez nazwę użytkownika):

Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\username/.ssh/id_rsa):

Możesz nacisnąć klawisz Enter, aby zaakceptować wartość domyślną, lub określić ścieżkę i/lub nazwę pliku, w którym chcesz wygenerować klucze. W tym momencie zostanie wyświetlony monit o użycie hasła do szyfrowania plików kluczy prywatnych. Hasło może być puste, ale nie jest zalecane. Hasło współdziała z plikiem klucza w celu zapewnienia uwierzytelniania dwuskładnikowego.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\username/.ssh/id_rsa.
Your public key has been saved in C:\Users\username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:FHK6WjcUkcfQjdorarzlak1Ob/x7AmqQmmx5ryYYV+8 username@LOCAL-HOSTNAME
The key's randomart image is:
+---[RSA 3072]----+
|      . ** o     |
|       +.o= .    |
|      . o+       |
|      .+. .      |
|     .ooS  .     |
|  . .oo.=.o      |
|   =.= O.= .     |
|  . B BoE + . .  |
|   . *+*o. .o+   |
+----[SHA256]-----+

Teraz masz parę kluczy publicznego/prywatnego rsa w określonej lokalizacji. Pliki pub są kluczami publicznymi, a pliki bez rozszerzenia są kluczami prywatnymi:

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        10/11/2022   6:29 PM           2610 id_rsa
-a----        10/11/2022   6:29 PM            578 id_rsa.pub

Ważne

Nigdy nie udostępniaj zawartości klucza prywatnego. Jeśli klucz prywatny zostanie naruszony, osoby atakujące mogą użyć go do myślenia, że połączenie pochodzi od Ciebie. Pliki kluczy prywatnych są odpowiednikiem hasła i powinny być chronione w taki sam sposób.

Krok 2. Dodawanie klucza publicznego do usługi Azure DevOps

Skojarz klucz publiczny wygenerowany w poprzednim kroku z identyfikatorem użytkownika.

Uwaga

Musisz powtórzyć tę operację dla każdej organizacji, do której masz dostęp i chcesz używać protokołu SSH.

  1. Otwórz ustawienia zabezpieczeń, przechodząc do portalu internetowego i wybierając ikonę obok awatara w prawym górnym rogu interfejsu użytkownika. W wyświetlonym menu wybierz pozycję Klucze publiczne SSH.

    Zrzut ekranu przedstawiający element menu kluczy publicznych SSH i awatar użytkownika wybrany w usłudze Azure DevOps.

  2. Wybierz pozycję + Nowy klucz.

    Zrzut ekranu przedstawiający dostęp do konfiguracji zabezpieczeń w usłudze Azure DevOps.

  3. Skopiuj zawartość klucza publicznego (na przykład id_rsa.pub), który został wygenerowany w polu Dane klucza publicznego.

    Ważne

    Unikaj dodawania białych znaków lub nowych wierszy do pola Dane klucza , ponieważ mogą one spowodować użycie nieprawidłowego klucza publicznego przez usługę Azure DevOps. Podczas wklejania w kluczu na końcu jest często dodawana nowa linia. Pamiętaj, aby usunąć ten nowy wiersz, jeśli wystąpi.

    Zrzut ekranu przedstawiający konfigurowanie klucza publicznego w usłudze Azure DevOps.

  4. Nadaj kluczowi przydatny opis (ten opis jest wyświetlany na stronie kluczy publicznych SSH dla profilu), aby można było go zapamiętać później. Wybierz pozycję Zapisz , aby zapisać klucz publiczny. Po zapisaniu nie można zmienić klucza. Możesz usunąć klucz lub utworzyć nowy wpis dla innego klucza. Nie ma żadnych ograniczeń dotyczących liczby kluczy, które można dodać do profilu użytkownika. Należy również pamiętać, że klucze SSH przechowywane w usłudze Azure DevOps wygasają po roku. Jeśli klucz wygaśnie, możesz przekazać nowy klucz lub ten sam, aby nadal uzyskiwać dostęp do usługi Azure DevOps za pośrednictwem protokołu SSH.

  5. Na stronie przeglądu zostanie wyświetlona uwaga w górnej części zawierającej odciski palców serwera. Zanotuj je, ponieważ będą one wymagane podczas pierwszego nawiązywania połączenia z usługą Azure DevOps za pośrednictwem protokołu SSH.

    Zrzut ekranu przedstawiający uzyskiwanie dostępu do konfiguracji zabezpieczeń w usługach Azure DevOps Services.

  6. Przetestuj połączenie, uruchamiając następujące polecenie:

    ssh -T git@ssh.dev.azure.com
    

    Jeśli po raz pierwszy nawiąż połączenie, powinny zostać wyświetlone następujące dane wyjściowe:

    The authenticity of host 'ssh.dev.azure.com (<IP>)' can't be established.
    RSA key fingerprint is SHA256:ohD8VZEXGWo6Ez8GSEJQ9WpafgLFsOfLOtGGQCQo6Og.
    This key is not known by any other names
    Are you sure you want to continue connecting (yes/no/[fingerprint])?
    

    Porównaj podany odcisk palca z odciskami palców oferowanymi na wyżej wymienionej stronie ustawień. Kontynuuj tylko wtedy, gdy są one zgodne!

    Jeśli wszystko jest poprawnie skonfigurowane, dane wyjściowe powinny wyglądać następująco:

    remote: Shell access is not supported.
    

    Jeśli nie, zobacz sekcję Dotyczącą pytań i rozwiązywania problemów.

Krok 3. Klonowanie repozytorium Git przy użyciu protokołu SSH

Uwaga

Aby użyć protokołu SSH z repozytorium wcześniej sklonowanym za pośrednictwem protokołu HTTPS, zobacz Aktualizowanie zdalnych do protokołu SSH.

  1. Skopiuj adres URL klonowania SSH z portalu internetowego. W tym przykładzie adres URL klonowania SSH jest przeznaczony dla repozytorium w organizacji o nazwie fabrikam-fiber, zgodnie z pierwszą częścią adresu URL po dev.azure.com.

    Zrzut ekranu przedstawiający sklonowany adres URL SSH usługi Azure Repos

    Uwaga

    W przypadku usługi Azure DevOps Services format adresu URL projektu to dev.azure.com/{your organization}/{your project}. Jednak poprzedni format odwołujący visualstudio.com się do formatu jest nadal obsługiwany. Aby uzyskać więcej informacji, zobacz Wprowadzenie do usługi Azure DevOps, Przełącz istniejące organizacje, aby używać nowego adresu URL nazwy domeny.

  2. Uruchom polecenie git clone w wierszu polecenia.

    git clone git@ssh.dev.azure.com:v3/fabrikam-fiber/FabrikamFiber/FabrikamFiber
    

    Teraz powinien zostać wyświetlony monit o wprowadzenie hasła dla klucza SSH, zanim będzie można kontynuować, chyba że jest on zarządzany przez agenta SSH:

    Cloning into 'FabrikamFiber'...
    Enter passphrase for key '/c/Users/username/.ssh/id_rsa':
    remote: Azure Repos
    remote: Found 127 objects to send. (50 ms)
    Receiving objects: 100% (127/127), 56.67 KiB | 2.58 MiB/s, done.
    Resolving deltas: 100% (15/15), done.
    

    Jeśli zamiast tego zostanie wyświetlony monit o zweryfikowanie odcisku palca, przeczytaj krok 2: Ponownie dodaj klucz publiczny do usługi Azure DevOps . W przypadku innych problemów zapoznaj się z sekcją Pytania i rozwiązywanie problemów.

Napiwek

Aby jak najlepiej wykorzystać protokół SSH, często używa się agenta SSH do zarządzania kluczami SSH. Jednak skonfigurowanie agenta wykracza poza zakres tego artykułu.

Pytania i rozwiązywanie problemów

1: Mogą zostać wyświetlone dwa różne komunikaty ostrzegawcze:

ssh-rsa is about to be deprecated and your request has been throttled. Please use rsa-sha2-256 or rsa-sha2-512 instead. Your session will continue automatically. For more details see https://devblogs.microsoft.com/devops/ssh-rsa-deprecation.

lub

You’re using ssh-rsa that is about to be deprecated and your request has been blocked intentionally. Any SSH session using SSH-RSA is subject to brown out (failure during random time periods). Please use rsa-sha2-256 or rsa-sha2-512 instead. For more details see https://devblogs.microsoft.com/devops/ssh-rsa-deprecation.

Konfiguracja SSH mogła zostać wcześniej zmodyfikowana w celu obniżenia poziomu ustawień zabezpieczeń dla usługi Azure DevOps przez dodanie następujących elementów do ~/.ssh/config pliku (%UserProfile%\.ssh\config w systemie Windows):

Host ssh.dev.azure.com vs-ssh.visualstudio.com
  HostkeyAlgorithms +ssh-rsa

Usuń te wiersze teraz i upewnij się, że rsa-sha2-256 i/lub rsa-sha2-512 są dozwolone.

Aby uzyskać więcej informacji, zapoznaj się z wpisem w blogu.

Pyt.: Protokół SSH nie może nawiązać połączenia. Co mam robić?

1: Istnieje wiele różnych problemów, które mogą wystąpić:

  • Korzystanie z nieobsługiwanego protokołu SSH-RSA

    You’re using ssh-rsa that is unsupported. Please use rsa-sha2-256 or rsa-sha2-512 instead. For more details see https://devblogs.microsoft.com/devops/ssh-rsa-deprecation.
    

    Konfiguracja SSH mogła zostać wcześniej zmodyfikowana w celu obniżenia poziomu ustawień zabezpieczeń dla usługi Azure DevOps przez dodanie następujących elementów do ~/.ssh/config pliku (%UserProfile%\.ssh\config w systemie Windows):

    Host ssh.dev.azure.com vs-ssh.visualstudio.com
       HostkeyAlgorithms +ssh-rsa
    

    Usuń te wiersze teraz i upewnij się, że rsa-sha2-256 i/lub rsa-sha2-512 są dozwolone.

    Aby uzyskać więcej informacji, zapoznaj się z wpisem w blogu.

  • Brak pasującego klucza hosta

    Nie powinno się tak zdarzyć ani w usłudze Azure DevOps Service, ani w nowszych wersjach usługi Azure DevOps Server, jak wspomniano we wpisie w blogu.

    Unable to negotiate with <IP> port 22: no matching host key type found. Their offer: ssh-rsa
    

    Zmodyfikuj konfigurację SSH, aby obniżyć ustawienia zabezpieczeń dla usługi Azure DevOps, dodając następujący kod do pliku (%UserProfile%\.ssh\config w systemie ~/.ssh/config Windows):

    Host ssh.dev.azure.com vs-ssh.visualstudio.com
       HostkeyAlgorithms +ssh-rsa
    

    Ważne

    Protokół OpenSSH przestarzał ssh-rsa algorytm podpisu klucza publicznego w wersji 8.2 i wyłączył go domyślnie w wersji 8.8.

  • Brak pasującego adresu MAC

    Unable to negotiate with <IP> port 22: no matching MAC found. Their offer: hmac-sha2-256,hmac-sha2-512
    

    Zmodyfikuj konfigurację SSH, aby obniżyć ustawienia zabezpieczeń dla usługi Azure DevOps, dodając następujący kod do pliku (%UserProfile%\.ssh\config w systemie ~/.ssh/config Windows):

    Host ssh.dev.azure.com vs-ssh.visualstudio.com
       MACs +hmac-sha2-512,+hmac-sha2-256
    
  • Brak pasującej metody wymiany kluczy

    Unable to negotiate with <IP> 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256
    

    Zmodyfikuj konfigurację SSH, aby obniżyć ustawienia zabezpieczeń dla usługi Azure DevOps, dodając następujący kod do pliku (%UserProfile%\.ssh\config w systemie ~/.ssh/config Windows):

    Host ssh.dev.azure.com vs-ssh.visualstudio.com
       KexAlgorithms +diffie-hellman-group-exchange-sha256,+diffie-hellman-group14-sha1,+diffie-hellman-group1-sha1
    

    Ważne

    Algorytm diffie-hellman-group1-sha1 wymiany kluczy został domyślnie wyłączony w wersji 6.9 protokołu OpenSSH i diffie-hellman-group14-sha1 w wersji 8.2.

Napiwek

W przypadku własnych wystąpień serwera Azure DevOps Server i serwera TFS użyj odpowiedniej nazwy hosta w Host wierszu zamiast ssh.dev.azure.com vs-ssh.visualstudio.com.

Pyt.: Jak mogę zapamiętać hasło usługi Git dla mojego klucza?

1: W tym celu można użyć agenta SSH. Systemy Linux, macOS i Windows (począwszy od systemu Windows 10 (kompilacja 1809) lub przy użyciu narzędzia Git dla systemu Windows z powłoką Git Bash) są dostarczane z agentem SSH. Agent SSH może służyć do buforowania kluczy SSH w celu wielokrotnego użycia. Aby uzyskać szczegółowe informacje na temat sposobu korzystania z niego, zapoznaj się z podręcznikiem dostawcy SSH.

Pyt.: Używam programu PuTTY jako klienta SSH i wygenerowałem moje klucze za pomocą programu PuTTYgen. Czy mogę używać tych kluczy z usługą Azure DevOps Services?

Odpowiedź: Tak. Załaduj klucz prywatny za pomocą programu PuTTYgen, przejdź do menu Konwersje i wybierz pozycję Eksportuj klucz OpenSSH. Zapisz plik klucza prywatnego, a następnie wykonaj kroki konfigurowania kluczy innych niż domyślne. Skopiuj klucz publiczny bezpośrednio z okna Programu PuTTYgen i wklej je w polu Dane klucza w ustawieniach zabezpieczeń.

Pyt.: Jak sprawdzić, czy przekazany klucz publiczny jest tym samym kluczem co mój klucz lokalny?

Zamiast tego można sprawdzić odcisk palca klucza publicznego przekazanego za pomocą tego, który jest wyświetlany w profilu, za pomocą następującego ssh-keygen polecenia uruchom polecenie względem klucza publicznego przy użyciu wiersza polecenia. Jeśli nie używasz wartości domyślnych, musisz zmienić ścieżkę i nazwę pliku klucza publicznego.

ssh-keygen -l -E md5 -f ~/.ssh/id_rsa.pub

Następnie możesz porównać podpis MD5 z podpisem w profilu. Ta kontrola jest przydatna, jeśli występują problemy z połączeniem lub występują problemy z niepoprawnym wklejaniem klucza publicznego w polu Dane klucza podczas dodawania klucza do usługi Azure DevOps.

Pyt.: Jak rozpocząć korzystanie z protokołu SSH w repozytorium, w którym obecnie używam protokołu HTTPS?

Uwierzytelnianie: należy zaktualizować zdalne narzędzie origin w usłudze Git, aby zmienić się z adresu HTTPS na adres URL SSH. Po utworzeniu adresu URL klonowania SSH uruchom następujące polecenie:

git remote set-url origin <SSH URL to your repository>

Polecenia git, które uzyskują dostęp do zdalnego wywołania origin , będą teraz używać protokołu SSH.

P: Korzystam z rozszerzenia Git LFS z usługami Azure DevOps Services i otrzymuję błędy podczas ściągania plików śledzonych przez rozszerzenie Git LFS.

1: Usługa Azure DevOps Services obecnie nie obsługuje usługi LFS za pośrednictwem protokołu SSH. Użyj protokołu HTTPS, aby nawiązać połączenie z repozytoriami z plikami śledzonymi przez rozszerzenie Git LFS.

Pyt.: Jak mogę użyć lokalizacji klucza innego niż domyślna, czyli nie ~/.ssh/id_rsa i ~/.ssh/id_rsa.pub?

1: Aby użyć klucza przechowywanego w innym miejscu niż domyślne, wykonaj następujące dwa zadania:

  1. Klucze muszą znajdować się w folderze, który można tylko odczytać lub edytować. Jeśli folder ma szersze uprawnienia, protokół SSH nie będzie używać kluczy.

  2. Należy poinformować protokół SSH o lokalizacji klucza, np. określając go jako "Tożsamość" w konfiguracji SSH:

    Host ssh.dev.azure.com
      IdentityFile ~/.ssh/id_rsa_azure
      IdentitiesOnly yes
    

Ustawienie IdentitiesOnly yes zapewnia, że protokół SSH nie będzie używać żadnej innej dostępnej tożsamości do uwierzytelniania. Jest to szczególnie ważne, jeśli jest dostępna więcej niż jedna tożsamość.

Pyt.: Mam wiele kluczy SSH. Jak mogę użyć poprawnego klucza SSH dla usługi Azure DevOps?

1: Ogólnie rzecz biorąc, jeśli skonfigurujesz wiele kluczy dla klienta SSH i połączysz się z serwerem SSH, klient może wypróbować klucze pojedynczo, dopóki serwer nie zaakceptuje jednego.

Nie działa to jednak z usługą Azure DevOps ze względów technicznych związanych z protokołem SSH i strukturą naszych adresów URL protokołu SSH usługi Git. Usługa Azure DevOps niewidomie zaakceptuje pierwszy klucz, który klient udostępnia podczas uwierzytelniania. Jeśli ten klucz jest nieprawidłowy dla żądanego repozytorium, żądanie zakończy się niepowodzeniem bez próby wykonania innych dostępnych kluczy z powodu następującego błędu:

remote: Public key authentication failed.
fatal: Could not read from remote repository.

W przypadku usługi Azure DevOps należy skonfigurować protokół SSH tak, aby jawnie używał określonego pliku klucza. Procedura jest taka sama jak w przypadku używania klucza przechowywanego w lokalizacji innej niż domyślna. Po prostu poinformuj protokół SSH o użyciu poprawnego klucza SSH dla hosta usługi Azure DevOps.

Pyt.: Jak mogę używać różnych kluczy SSH dla różnych organizacji w usłudze Azure DevOps?

Uwierzytelnianie: Usługa Azure DevOps niewidomie zaakceptuje pierwszy klucz, który klient udostępnia podczas uwierzytelniania. Jeśli ten klucz jest nieprawidłowy dla żądanego repozytorium, żądanie zakończy się niepowodzeniem z powodu następującego błędu:

remote: Public key authentication failed.
fatal: Could not read from remote repository.

Można jednak zmodyfikować konfigurację protokołu SSH, aby odróżnić różne organizacje i udostępnić różne klucze dla każdego z nich. W tym celu należy użyć aliasów hostów do utworzenia oddzielnych Host sekcji w konfiguracji SSH. Dzieje się tak, ponieważ wszystkie hostowane adresy URL usługi Azure DevOps mają taką samą nazwę hosta (ssh.dev.azure.com), więc protokół SSH nie ma możliwości ich domyślnego odróżnienia.

# The settings in each Host section are applied to any Git SSH remote URL with a
# matching hostname.
# Generally:
# * SSH uses the first matching line for each parameter name, e.g. if there's
#   multiple values for a parameter across multiple matching Host sections
# * "IdentitiesOnly yes" prevents keys cached in ssh-agent from being tried before
#   the IdentityFile values we explicitly set.
# * On Windows, ~/.ssh/your_private_key maps to %USERPROFILE%\.ssh\your_private_key,
#   e.g. C:\Users\<username>\.ssh\your_private_key.

# Imagine that we have the following two SSH URLs:
# * git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo
#   * For this, we want to use `fabrikamkey`, so we'll create `devops_fabrikam` as
#     a Host alias and tell SSH to use `fabrikamkey`.
# * git@ssh.dev.azure.com:v3/Contoso/Project2/con_repo
#   * For this, we want to use `contosokey`, so we'll create `devops_contoso` as
#     a Host alias and tell SSH to use `contosokey`.
#
# To set explicit keys for the two host aliases and to tell SSH to use the correct
# actual hostname, add the next two Host sections:
Host devops_fabrikam
  HostName ssh.dev.azure.com
  IdentityFile ~/.ssh/private_key_for_fabrikam
  IdentitiesOnly yes

Host devops_contoso
  HostName ssh.dev.azure.com
  IdentityFile ~/.ssh/private_key_for_contoso
  IdentitiesOnly yes

Następnie, zamiast używać rzeczywistych adresów URL, poinformuj usługę Git, że chcesz używać tych adresów URL dla każdego repozytorium jako zdalnego, zastępując nazwę hosta w istniejących zdalnych devops_fabrikamdevops_contoso i odpowiednio . Na przykład git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo stanie się .git@devops_fabrikam:v3/Fabrikam/Project1/fab_repo

Pyt.: Jakie powiadomienia mogą otrzymywać moje klucze SSH?

1: Za każdym razem, gdy zarejestrujesz nowy klucz SSH w usłudze Azure DevOps Services, otrzymasz powiadomienie e-mail z informacją o dodaniu nowego klucza SSH do twojego konta.

Przykład powiadomienia SSH

Pyt.: Co zrobić, jeśli uważam, że ktoś inny niż ja dodaje klucze SSH na moim koncie?

1: Jeśli otrzymasz powiadomienie o zarejestrowaniu klucza SSH i nie przekazano go ręcznie do usługi, twoje poświadczenia mogły zostać naruszone.

Następnym krokiem będzie zbadanie, czy twoje hasło zostało naruszone. Zmiana hasła jest zawsze dobrym pierwszym krokiem do obrony przed tym wektorem ataku. Jeśli jesteś użytkownikiem firmy Microsoft Entra, skontaktuj się z administratorem, aby sprawdzić, czy twoje konto zostało użyte z nieznanego źródła/lokalizacji.

Pyt.: Co zrobić, jeśli nadal pojawia się monit o podanie hasła i GIT_SSH_COMMAND="ssh -v" git fetch jest wyświetlany no mutual signature algorithm lub corresponding algo not in PubkeyAcceptedAlgorithms?

1: Niektóre dystrybucje systemu Linux, takie jak Fedora Linux, mają zasady kryptograficzne wymagające silniejszych algorytmów podpisu SSH niż obsługiwane przez usługę Azure DevOps (od stycznia 2021 r.). Istnieje otwarte żądanie funkcji, aby dodać tę pomoc techniczną.

Problem można obejść, dodając następujący kod do konfiguracji SSH (~/.ssh/config):

Host ssh.dev.azure.com vs-ssh.visualstudio.com
  PubkeyAcceptedKeyTypes +ssh-rsa

Napiwek

W przypadku własnych wystąpień serwera Azure DevOps Server i serwera TFS użyj odpowiedniej nazwy hosta w Host wierszu zamiast ssh.dev.azure.com vs-ssh.visualstudio.com.