Usare l'autenticazione con chiave SSH

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

È possibile connettersi al repository Git tramite SSH in macOS, Linux o Windows per connettersi in modo sicuro tramite l'autenticazione HTTPS.

Importante

Gli URL SSH sono stati modificati, ma gli URL SSH precedenti continuano a funzionare. Se è già stato configurato SSH, aggiornare gli URL remoti al nuovo formato:

Gli URL SSH aggiornati iniziano con ssh.dev.azure.com. Gli URL precedenti usano vs-ssh.visualstudio.com.

• Verificare quali remote usano SSH. Eseguire git remote -v nella shell o usare invece un client GUI.
• Visitare il repository sul Web e selezionare Clona.
• Selezionare SSH e copiare il nuovo URL SSH.
• Nella shell eseguire git remote set-url <remote name> <new SSH URL> per ogni repository remoto da aggiornare. In alternativa, usare un client GUI per aggiornare gli URL remoti.

Funzionamento dell'autenticazione della chiave SSH

L'autenticazione con chiave pubblica SSH funziona con una coppia asimmetrica di chiavi di crittografia generate. La chiave pubblica viene condivisa con Azure DevOps e usata per verificare la connessione SSH iniziale. La chiave privata viene mantenuta sicura e protetta nel sistema.

Configurare l'autenticazione della chiave SSH

I passaggi seguenti illustrano la configurazione dell'autenticazione della chiave SSH nelle piattaforme seguenti usando la riga di comando (denominata shellanche ):

• Linux
• macOS
• Sistemi Windows che eseguono Git per Windows

Nota

A partire da Visual Studio 2017, è possibile usare SSH per connettersi ai repository Git di Azure DevOps.

Suggerimento

In Windows è consigliabile usare Git Credential Manager o Token di accesso personale.

Passaggio 1: Creare le chiavi SSH

Nota

Se nel sistema sono già state create chiavi SSH RSA, ignorare questo passaggio e configurare le chiavi SSH. Per verificare questa operazione, passare alla home directory e esaminare la .ssh cartella (%UserProfile%\.ssh\ in Windows o ~/.ssh/ in Linux, macOS e Windows con Git Bash). Se vengono visualizzati due file denominati id_rsa e id_rsa.pub si continua con la configurazione delle chiavi SSH.

Per usare l'autenticazione basata su chiavi, occorre prima generare alcune coppie di chiavi pubblica/privata per il client. ssh-keygen.exe viene usato per generare file di chiave e è possibile specificare gli algoritmi DSA, RSA, ECDSA o Ed25519. Se non viene specificato alcun algoritmo, viene utilizzato RSA.

Nota

L'unico tipo di chiave SSH supportato da Azure DevOps è RSA.

Per generare file di chiave usando l'algoritmo RSA, eseguire il comando seguente da powerShell o da un'altra shell, ad bash esempio nel client:

ssh-keygen

L'output del comando dovrebbe visualizzare l'output seguente (dove username viene sostituito dal nome utente):

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

È possibile premere Invio per accettare l'impostazione predefinita, oppure specificare un percorso e/o un nome file in cui si desidera che vengano generate le chiavi. A questo punto, ti verrà richiesto di usare una passphrase per crittografare i file di chiave privata. La passphrase può essere vuota, ma non è consigliata. La passphrase in combinazione con il file di chiave fornisce l'autenticazione a due fattori.

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]-----+

A questo punto è presente una coppia di chiavi rsa pubblica/privata nella posizione specificata. I file con estensione pub sono chiavi pubbliche e i file senza estensione sono chiavi private:

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

Importante

Non condividere mai il contenuto della chiave privata. Se la chiave privata è compromessa, gli utenti malintenzionati possono usarla per ingannare i server a pensare che la connessione proviene dall'utente. I file di chiave privata sono equivalenti a una password e devono essere protetti allo stesso modo.

Passaggio 2: Aggiungere la chiave pubblica ad Azure DevOps

Associare la chiave pubblica generata nel passaggio precedente all'ID utente.

Nota

È necessario ripetere questa operazione per ogni organizzazione a cui si ha accesso e si vuole usare SSH.

1. Aprire le impostazioni di sicurezza passando al portale Web e selezionando l'icona accanto all'avatar in alto a destra dell'interfaccia utente. Selezionare Chiavi pubbliche SSH nel menu visualizzato.

   

2. Selezionare + Nuova chiave.

   

3. Copiare il contenuto della chiave pubblica ( ad esempio , id_rsa.pub) generato nel campo Dati chiave pubblica.

   Importante

   Evitare di aggiungere spazi vuoti o nuove righe nel campo Dati chiave, perché possono causare l'uso di una chiave pubblica non valida in Azure DevOps. Quando si incolla nella chiave, viene spesso aggiunta una nuova riga alla fine. Assicurarsi di rimuovere questa nuova riga se si verifica.

   

4. Assegnare alla chiave una descrizione utile (questa descrizione viene visualizzata nella pagina delle chiavi pubbliche SSH per il profilo) in modo da poterla ricordare in un secondo momento. Selezionare Salva per archiviare la chiave pubblica. Dopo il salvataggio, non è possibile modificare la chiave. È possibile eliminare la chiave o creare una nuova voce per un'altra chiave. Non esistono restrizioni sul numero di chiavi che è possibile aggiungere al profilo utente. Si noti anche che le chiavi SSH archiviate in Azure DevOps scadono dopo un anno. Se la chiave scade, è possibile caricare una nuova chiave o la stessa per continuare ad accedere ad Azure DevOps tramite SSH.

5. Nella pagina di panoramica viene visualizzata una nota nella parte superiore contenente le impronte digitali del server. Prendere nota di essi perché saranno necessari quando ci si connette per la prima volta ad Azure DevOps tramite SSH.

   

6. Testare la connessione eseguendo il comando seguente:

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

   Se è stata la prima volta che ci si connette, si dovrebbe ricevere l'output seguente:

   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])?
   

   Confrontare l'impronta digitale specificata con le impronte digitali offerte nella pagina delle impostazioni precedente. Procedere solo se corrispondono!

   Se tutto è configurato correttamente, l'output dovrebbe essere simile al seguente:

   remote: Shell access is not supported.
   

   In caso contrario, vedere la sezione Domande e risoluzione dei problemi.

Passaggio 3: Clonare il repository Git con SSH

Nota

Per usare SSH con un repository clonato in precedenza tramite HTTPS, vedere Aggiornare i dati remoti a SSH.

1. Copiare l'URL clone SSH dal portale Web. In questo esempio, l'URL clone SSH è per un repository in un'organizzazione denominata fabrikam-fiber, come indicato dalla prima parte dell'URL dopo dev.azure.com.

   

   Nota

   Con Azure DevOps Services, il formato per l'URL del progetto è dev.azure.com/{your organization}/{your project}. Tuttavia, il formato precedente che fa riferimento al visualstudio.com formato è ancora supportato. Per altre informazioni, vedere Introduzione ad Azure DevOps, Cambiare le organizzazioni esistenti per usare il nuovo URL del nome di dominio.

2. Eseguire git clone dal prompt dei comandi.

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

   Verrà ora richiesto di immettere la passphrase per la chiave SSH prima di continuare, a meno che non sia gestita da un agente 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.
   

   Se viene invece richiesto di verificare un'impronta digitale, leggere il passaggio 2: Aggiungere di nuovo la chiave pubblica ad Azure DevOps . Per altri problemi, vedere la sezione Domande e risoluzione dei problemi.

Suggerimento

Per sfruttare al meglio SSH, è comune usare un agente SSH per gestire le chiavi SSH. Tuttavia, la configurazione di un agente non rientra nell'ambito di questo articolo.

Domande e risoluzione dei problemi

D: Sono visualizzati avvisi correlati a SSH-RSA. Cosa devo fare?

R: Potrebbero essere visualizzati due diversi messaggi di avviso:

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.

or

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.

È possibile che la configurazione SSH sia stata modificata in precedenza per effettuare il downgrade delle impostazioni di sicurezza per Azure DevOps aggiungendo il codice seguente al ~/.ssh/config file (%UserProfile%\.ssh\config in Windows):

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

Rimuovere ora queste righe e assicurarsi rsa-sha2-256 che e/o rsa-sha2-512 siano consentite.

Per altri dettagli, vedere il post di blog.

D: SSH non è in grado di stabilire una connessione. Cosa devo fare?

R: Esistono diversi problemi che possono verificarsi:

• Uso di SSH-RSA non supportato

  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.
  

  È possibile che la configurazione SSH sia stata modificata in precedenza per effettuare il downgrade delle impostazioni di sicurezza per Azure DevOps aggiungendo il codice seguente al ~/.ssh/config file (%UserProfile%\.ssh\config in Windows):

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

  Rimuovere ora queste righe e assicurarsi rsa-sha2-256 che e/o rsa-sha2-512 siano consentite.

  Per altri dettagli, vedere il post di blog.

• Nessuna chiave host corrispondente

  Questo problema non dovrebbe verificarsi né nel servizio Azure DevOps né nelle versioni più recenti di Azure DevOps Server, come indicato nel post di blog.

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

  Modificare la configurazione SSH per effettuare il downgrade delle impostazioni di sicurezza per Azure DevOps aggiungendo il codice seguente al ~/.ssh/config file (%UserProfile%\.ssh\config in Windows):

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

  Importante

  OpenSSH deprecato l'algoritmo ssh-rsa di firma della chiave pubblica nella versione 8.2 e disabilitato per impostazione predefinita nella versione 8.8.

• Nessun MAC corrispondente

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

  Modificare la configurazione SSH per effettuare il downgrade delle impostazioni di sicurezza per Azure DevOps aggiungendo il codice seguente al ~/.ssh/config file (%UserProfile%\.ssh\config in Windows):

  Host ssh.dev.azure.com vs-ssh.visualstudio.com
     MACs +hmac-sha2-512,+hmac-sha2-256
  

• Nessun metodo di scambio di chiavi corrispondente

  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
  

  Modificare la configurazione SSH per effettuare il downgrade delle impostazioni di sicurezza per Azure DevOps aggiungendo il codice seguente al ~/.ssh/config file (%UserProfile%\.ssh\config in Windows):

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

  Importante

  L'algoritmo diffie-hellman-group1-sha1 di scambio delle chiavi è stato disabilitato per impostazione predefinita nella versione 6.9 di OpenSSH e diffie-hellman-group14-sha1 nella versione 8.2.

Suggerimento

Per le istanze self-hosted di Azure DevOps Server e TFS, usare il nome host appropriato nella Host riga anziché ssh.dev.azure.com vs-ssh.visualstudio.com.

D: Come è possibile memorizzare Git nella passphrase per la chiave?

R: È possibile usare un agente SSH per tale agente. Linux, macOS e Windows (a partire da Windows 10 (build 1809) o usando Git per Windows con Git Bash, vengono forniti tutti con un agente SSH. L'agente SSH può essere usato per memorizzare nella cache le chiavi SSH per un uso ripetuto. Consultare il manuale del fornitore SSH per informazioni dettagliate su come usarlo.

D: Usare PuTTY come client SSH e generare le chiavi con PuTTYgen. È possibile usare queste chiavi con Azure DevOps Services?

R: Sì. Caricare la chiave privata con PuTTYgen, passare al menu Conversioni e selezionare Esporta chiave OpenSSH. Salvare il file di chiave privata e quindi seguire la procedura per configurare chiavi non predefinite. Copiare la chiave pubblica direttamente dalla finestra PuTTYgen e incollarla nel campo Dati chiave nelle impostazioni di sicurezza.

D: Come è possibile verificare che la chiave pubblica caricata sia la stessa chiave della chiave locale?

R: È possibile verificare l'impronta digitale della chiave pubblica caricata con quella visualizzata nel profilo tramite il comando seguente ssh-keygen eseguito sulla chiave pubblica usando la riga di comando. Se non si usano le impostazioni predefinite, sarà necessario modificare il percorso e il nome file della chiave pubblica.

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

È quindi possibile confrontare la firma MD5 con quella nel profilo. Questo controllo è utile se si verificano problemi di connessione o si verificano problemi di incollamento non corretto nella chiave pubblica nel campo Dati chiave quando si aggiunge la chiave ad Azure DevOps.

D: Come è possibile iniziare a usare SSH in un repository in cui si usa attualmente HTTPS?

R: È necessario aggiornare il origin telecomando in Git per passare da un HTTPS a un URL SSH. Dopo aver ottenuto l'URL clone SSH, eseguire il comando seguente:

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

I comandi Git che accedono al chiamato origin remoto useranno ora SSH.

D: Si usa Git LFS con Azure DevOps Services e si ricevono errori durante il pull di file rilevati da Git LFS.

R: Azure DevOps Services attualmente non supporta LFS tramite SSH. Usare HTTPS per connettersi ai repository con i file rilevati da Git LFS.

D: Come è possibile usare un percorso di chiave non predefinito, ovvero ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub?

R: Per usare una chiave archiviata in una posizione diversa da quella predefinita, eseguire queste due attività:

1. Le chiavi devono trovarsi in una cartella che solo è possibile leggere o modificare. Se la cartella dispone di autorizzazioni più ampie, SSH non userà le chiavi.

2. È necessario informare SSH del percorso della chiave, ad esempio specificandolo come "Identità" nella configurazione SSH:

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

L'impostazione IdentitiesOnly yes garantisce che SSH non userà altre identità disponibili per l'autenticazione. Questo aspetto è particolarmente importante se sono disponibili più identità.

D: Ho più chiavi SSH. Ricerca per categorie usare la chiave SSH corretta per Azure DevOps?

R: in genere, se si configurano più chiavi per un client SSH e ci si connette a un server SSH, il client può provare le chiavi una alla volta fino a quando il server non ne accetta uno.

Tuttavia, questo non funziona con Azure DevOps per motivi tecnici correlati al protocollo SSH e come sono strutturati gli URL SSH Git. Azure DevOps accetterà in modo cieco la prima chiave fornita dal client durante l'autenticazione. Se tale chiave non è valida per il repository richiesto, la richiesta avrà esito negativo senza tentare altre chiavi disponibili a causa dell'errore seguente:

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

Per Azure DevOps, è necessario configurare SSH per usare in modo esplicito un file di chiave specifico. La procedura è la stessa di quando si usa una chiave archiviata in un percorso non predefinito. È sufficiente indicare a SSH di usare la chiave SSH corretta per l'host Azure DevOps.

D: Ricerca per categorie usare chiavi SSH diverse per organizzazioni diverse in Azure DevOps?

R: Azure DevOps accetterà in modo cieco la prima chiave fornita dal client durante l'autenticazione. Se la chiave non è valida per il repository richiesto, la richiesta avrà esito negativo con l'errore seguente:

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

Tuttavia, è possibile modificare la configurazione SSH per distinguere tra organizzazioni diverse e fornire chiavi diverse per ognuna. A tale scopo, è necessario usare gli alias host per creare sezioni separate Host nella configurazione SSH. Questo perché tutti gli URL di Azure DevOps ospitati hanno lo stesso nome host (ssh.dev.azure.com), quindi SSH non può distinguerli per impostazione predefinita.

# 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

In seguito, invece di usare gli URL reali, indicare a Git di voler usare questi URL per ogni repository come remoto sostituendo rispettivamente il nome host nei remote esistenti con devops_fabrikam e devops_contoso . Ad esempio git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo , diventa git@devops_fabrikam:v3/Fabrikam/Project1/fab_repo.

D: Quali notifiche è possibile ricevere sulle chiavi SSH?

R: Ogni volta che si registra una nuova chiave SSH con Azure DevOps Services, si riceve una notifica tramite posta elettronica che informa che è stata aggiunta una nuova chiave SSH all'account.

D: Cosa faccio se credo che qualcuno diverso da me stia aggiungendo chiavi SSH nel mio account?

R: Se si riceve una notifica di una chiave SSH registrata e non è stata caricata manualmente nel servizio, le credenziali potrebbero essere state compromesse.

Il passaggio successivo consiste nell'esaminare se la password è stata compromessa o meno. La modifica della password è sempre un buon primo passo per difendersi da questo vettore di attacco. Se si è un utente di Microsoft Entra, rivolgersi all'amministratore per verificare se l'account è stato usato da un'origine/posizione sconosciuta.

D: Cosa fare se viene ancora richiesta la password e GIT_SSH_COMMAND="ssh -v" git fetch viene visualizzata no mutual signature algorithm o corresponding algo not in PubkeyAcceptedAlgorithms?

R: Alcune distribuzioni linux, ad esempio Fedora Linux, hanno criteri di crittografia che richiedono algoritmi di firma SSH più avanzati rispetto al supporto di Azure DevOps (a partire da gennaio 2021). È disponibile una richiesta di funzionalità aperta per aggiungere questo supporto.

È possibile risolvere il problema aggiungendo il codice seguente alla configurazione SSH (~/.ssh/config):

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

Suggerimento

Per le istanze self-hosted di Azure DevOps Server e TFS, usare il nome host appropriato nella Host riga anziché ssh.dev.azure.com vs-ssh.visualstudio.com.