Por que o SSH é mais seguro que o HTTPS em conexões diretas com um repositório Git com credenciais

Não está claro para mim se você foi informado de que o SSH é mais seguro que o HTTPS em seu caso específico (onde não temos todos os detalhes), o que pode estar absolutamente correto ou se você recebeu isso como um conselho geral. A análise de SSH vs. HTTPS pode ser surpreendentemente complexa para aqueles que não são bem versados ​​em análise de sistemas de segurança, e é por isso que tendemos a fazer declarações amplas como "SSH é mais seguro que HTTPS": geralmente será verdade, mesmo que seja não é verdade em todos os casos. De qualquer forma, aqui estão alguns pensamentos sobre o assunto.

Como você mencionou o armazenamento de credenciais em um arquivo, esta resposta pressupõe que você esteja usando autenticação de chave pública/privada para HTTPS e SSH. A autenticação por senha é significativamente menos segura em ambos os casos.

Armazenamento local de credenciais

Primeiro, você está trabalhando com a suposição de que a credencial do usuário armazenada no disco não está protegida por uma senha. Isso pode ou não ser verdade, mas se fosse protegido por uma senha, isso aumentaria muito a segurança.

No caso do SSH, é mais provável que a credencial seja protegida por uma senha porque os principais agentes são mais fáceis de usar e usados ​​com mais frequência com o SSH. Com o SSH, um agente chave está quase invariavelmente disponível porque ssh-agentou similar faz parte de quase todos os conjuntos padrão de ferramentas de cliente SSH. Isso também facilita o treinamento para usar o agente, pois o treinamento para o uso de uma ferramenta de uma maneira específica funciona praticamente em qualquer lugar.

Os principais agentes para sistemas HTTPS são muito mais diversos, provavelmente menos comumente instalados e, mesmo se disponíveis em um determinado sistema, é menos provável que alguém saiba que um determinado está disponível e saiba como usá-lo.

Agentes Remotos

Em segundo lugar, o SSH oferece suporte a conexões de agentes remotos, permitindo remover o material de chave do sistema no qual você está fazendo o git fetch que, em muitos casos, pode levar a uma segurança muito melhor. Isso é melhor descrito por um exemplo do meu fluxo de trabalho mais comum.

Meu laptop é uma máquina "pessoal" no sentido de que sou o único que tem acesso a ele. (Tem criptografia de disco total e contas de usuário apenas para mim.) Quando eu faço login, inicio um local ssh-agente carrego minha chave (também protegida por senha) nele, com ssh-askpass confirmação habilitada via ssh-add -c.

Quando faço SSH no host no qual estou desenvolvendo, geralmente compartilhado com outras pessoas, uso ssh -Apara habilitar o encaminhamento do agente. Eu então git fetch, que inicia uma sessão SSH do host de desenvolvimento para o servidor para o controle remoto do Git.

Esse SSH, quando solicitado pelo controle remoto para autenticação, recebe a solicitação e a encaminha de volta ao agente no meu laptop. Recebo um alerta em minha tela de que meu agente local recebeu uma solicitação de autenticação, o que já esperava, pois acabei de iniciar uma ação que causaria isso e, portanto, aprovo a autenticação. O processo SSH no host de desenvolvimento recebe de volta as informações de que precisa para autenticar (válido apenas para aquela sessão específica), autentica com sucesso no servidor remoto e git fetchcontinua.

Observe que isso é consideravelmente mais seguro porque a) a chave nunca esteve no servidor de desenvolvimento e, portanto, muito, muito menos acessível aos invasores (eles precisariam acessar meu laptop particular) e b) recebo notificações sobre solicitações para meu chave a ser usada, permitindo-me detectar tentativas inesperadas de usar a chave. (Qualquer usuário com root no servidor de desenvolvimento também pode encaminhar solicitações de autenticação para meu laptop.) E não precisei digitar uma frase secreta todas as vezes, portanto, ter um arquivo de chave protegido por senha é muito menos complicado.