Início / server / Perguntas / 1160384
Accepted
Charystag
Asked: 2024-06-04 16:21:38 +0800 CST

Por que posso usar uma chave privada SSH com permissões de grupo em um servidor remoto, mas não na minha máquina local?

  • 772

Introdução

Há algo que não entendo com permissões de chave privada SSH e gostaria de algumas explicações detalhadas sobre a diferença de comportamento que estou percebendo.
Aqui está o problema, estou tentando escrever uma documentação extensa sobre os desafios de overthewire e a questão é sobre o nível bandido13 (estou escrevendo isso apenas para ajudar pessoas que estão familiarizadas com esses desafios, mas não estou muito focado nos desafios).

Situação de host remoto

Estou logado como usuário bandit13 e recebo uma chave ssh que devo usar para me conectar como usuário bandit14 no servidor. Aqui está a saída do comando statquando executado no arquivo "sshkey.private":

  File: sshkey.private
  Size: 1679        Blocks: 8          IO Block: 4096   regular file
Device: 10301h/66305d   Inode: 517716      Links: 1
Access: (0640/-rw-r-----)  Uid: (11014/bandit14)   Gid: (11013/bandit13)
Access: 2024-06-03 16:10:51.521532387 +0000
Modify: 2023-10-05 06:19:21.815263421 +0000
Change: 2023-10-05 06:19:21.819263430 +0000
 Birth: 2023-10-05 06:19:21.815263421 +0000

Podemos ver que a chave pertence ao usuário bandit14, mas também pode ser lida pelos membros do grupo bandit13, o que parece estar em conflito com esta seção da ssh(1)página man:

~/.ssh/id_rsa
             Contains the private key for authentication.  These files contain sensitive data and should be readable by the user but not accessible by others (read/write/execute).  will simply ignore a
             private key file if it is accessible by others.  It is possible to specify a passphrase when generating the key which will be used to encrypt the sensitive part of this file using AES-128.

No entanto, posso usar esta chave privada para me conectar ao usuário bandit14 executando:

ssh -p 2220 -l bandit14 -i sshkey.private localhost

Situação da máquina local

Agora, quando recupero a chave ssh em minha máquina local, aqui está a saída que recebo do statcomando:

  File: bandit14_sshkey
  Size: 1679        Blocks: 8          IO Block: 4096   regular file
Device: 804h/2052d  Inode: 8913955     Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1001/ Charystag)   Gid: ( 1001/ Charystag)
Access: 2024-06-03 21:05:42.285372019 +0200
Modify: 2024-06-03 21:05:11.765802230 +0200
Change: 2024-06-03 21:05:11.765802230 +0200
 Birth: 2024-06-03 21:05:11.733802682 +0200

o que também parece contradizer a mesma seção da ssh(1)página de manual.

No entanto, desta vez, quando tento me conectar ao host remoto executando:

ssh -p 2220 -l bandit14 -i bandit14_sshkey bandit.labs.overthewire.orgs

Recebo o seguinte banner:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for 'bandit14_sshkey' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "bandit14_sshkey": bad permissions

Minha pergunta

O que pode explicar a diferença de comportamento entre essas duas situações? Por favor, não me diga que devo alterar minhas permissões para minha chave ssh em minha máquina local, pois já sei disso, mas explique por que posso pular de um usuário para outro no host remoto.
Certifique-se de vincular alguma documentação em sua resposta.

O que tentei entender?

Basicamente, li muitas perguntas sobre stackOverflow, as páginas ssh(1)de sshd(8)manual e perguntei ao ChatGPT 4o, mas não obtive nada de concreto, então aqui estou.

Muito obrigado a todos vocês que chegarão a este ponto e que reservarão um tempo para me responder.

Tenham um ótimo dia a todos

ssh

1 respostas

  1. Best Answer

    A diferença

    Na máquina local, o usuário que possui a chave a utiliza e é avisado de que outra pessoa também poderá lê-la. Na máquina remota, o arquivo pertence ao usuário bandit14, mas é usado por outro usuário bandit13por meio da permissão do grupo. A condição é ignorada porque bandit13já são os “outros” ao invés daquele que deveria ser avisado.

    Explicação

    Esta é uma decisão bastante antiga, pois tem sido assim desde 23 de setembro de 2001, após 7aff261 "relaxe a verificação de permissão para arquivos de chave privada" de Ben Lindstrom . O commit:

    • substituiu a condição "ou" (... || (st.st_mode & 077) != 0) por uma condição "e" ( ((st.st_uid == getuid()) && (st.st_mode & 077) != 0)) tornando-a mais relaxada,
    • separou a fstat(fd, &st) < 0condição (atualmente fstat(fd, &st) == -1de 4d28fa7 ) que ainda deve sempre resultar em um erro ( SSH_ERR_SYSTEM_ERRORem vez de 0desde 8668706 em 2014), e
    • adicionou um comentário que ainda está lá sshkey_perm_ok()em authfile.c.
    int
sshkey_perm_ok(int fd, const char *filename)
{
    struct stat st;

    if (fstat(fd, &st) == -1)
        return SSH_ERR_SYSTEM_ERROR;
    /*
     * if a key owned by the user is accessed, then we check the
     * permissions of the file. if the key owned by a different user,
     * then we don't care.
     */
#ifdef HAVE_CYGWIN
    if (check_ntsec(filename))
#endif
    if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
        error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
        error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
        error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
        error("Permissions 0%3.3o for '%s' are too open.",
            (u_int)st.st_mode & 0777, filename);
        error("It is required that your private key files are NOT accessible by others.");
        error("This private key will be ignored.");
        return SSH_ERR_KEY_BAD_PERMISSIONS;
    }
    return 0;
}

    Documentação?

    Infelizmente, o comentário no código-fonte parece ser a única documentação desse recurso; não é mencionado nas páginas do manual do OpenSSH .

    • 2

relate perguntas