Despois de catro meses de desenvolvemento liberación , unha implementación aberta de cliente e servidor para traballar a través dos protocolos SSH 2.0 e SFTP.
Unha mellora clave no lanzamento de OpenSSH 8.2 foi a capacidade de usar a autenticación de dous factores mediante dispositivos compatibles co protocolo. , desenvolvido pola alianza . U2F permite a creación de tokens de hardware de baixo custo para verificar a presenza física do usuario, interactuando con eles a través de USB, Bluetooth ou NFC. Estes dispositivos promóvense como un medio de autenticación de dous factores nos sitios web, xa son compatibles cos principais navegadores e son producidos por varios fabricantes, incluíndo Yubico, Feitian, Thetis e Kensington.
Para interactuar cos dispositivos que confirman a presenza do usuario, engadíronse a OpenSSH novos tipos de chave "ecdsa-sk" e "ed25519-sk", que utilizan os algoritmos de sinatura dixital ECDSA e Ed25519, combinados co hash SHA-256. Os procedementos para interactuar cos tokens colócanse nunha biblioteca intermedia, que se carga de forma similar á biblioteca para compatibilidade con PKCS#11 e é un envoltorio na parte superior da biblioteca. , que ofrece ferramentas para comunicarse con tokens a través de USB (admítense os protocolos FIDO U2F/CTAP 1 e FIDO 2.0/CTAP 2). Biblioteca intermedia libsk-libfido2 preparada polos desenvolvedores de OpenSSH no núcleo libfido2, así como para OpenBSD.
Para autenticar e xerar unha clave, debes especificar o parámetro "SecurityKeyProvider" na configuración ou establecer a variable de ambiente SSH_SK_PROVIDER, indicando o camiño á biblioteca externa libsk-libfido2.so (exportar SSH_SK_PROVIDER=/path/to/libsk-libfido2. así). É posible construír openssh con soporte incorporado para a biblioteca de capas (--with-security-key-builtin), neste caso cómpre configurar o parámetro "SecurityKeyProvider=internal".
A continuación, cómpre executar "ssh-keygen -t ecdsa-sk" ou, se as chaves xa foron creadas e configuradas, conectarse ao servidor mediante "ssh". Cando executa ssh-keygen, o par de claves xerado gardarase en “~/.ssh/id_ecdsa_sk” e pódese usar de xeito similar a outras claves.
A chave pública (id_ecdsa_sk.pub) debería copiarse no servidor no ficheiro authorized_keys. No lado do servidor, só se verifica a sinatura dixital e a interacción cos tokens realízase no lado do cliente (non é necesario instalar libsk-libfido2 no servidor, pero o servidor debe admitir o tipo de chave "ecdsa-sk"). . A clave privada xerada (id_ecdsa_sk) é esencialmente un identificador de chave, formando unha clave real só en combinación coa secuencia secreta almacenada no lado do token U2F. Se a clave id_ecdsa_sk cae en mans dun atacante, para pasar a autenticación tamén terá que acceder ao token de hardware, sen o cal a clave privada almacenada no ficheiro id_ecdsa_sk é inútil.
Ademais, por defecto, ao realizar calquera operación con claves (tanto durante a xeración como durante a autenticación), é necesaria a confirmación local da presenza física do usuario, por exemplo, proponse tocar o sensor do token, o que dificulta realizar ataques remotos a sistemas cun token conectado. Como outra liña de defensa, tamén se pode especificar un contrasinal durante a fase de inicio de ssh-keygen para acceder ao ficheiro de chave.
A nova versión de OpenSSH tamén anunciou a próxima desaparición dos algoritmos que usan hash SHA-1 debido a a eficacia dos ataques de colisión cun prefixo determinado (o custo de seleccionar unha colisión estímase en aproximadamente 45 mil dólares). Nun dos próximos lanzamentos, planean desactivar de forma predeterminada a posibilidade de usar o algoritmo de sinatura dixital de chave pública "ssh-rsa", que se menciona no RFC orixinal para o protocolo SSH e segue estendido na práctica (para probar o uso de ssh-rsa nos seus sistemas, pode tentar conectarse mediante ssh coa opción "-oHostKeyAlgorithms=-ssh-rsa").
Para suavizar a transición a novos algoritmos en OpenSSH, nunha versión futura habilitarase a configuración UpdateHostKeys de forma predeterminada, que migrará automaticamente os clientes a algoritmos máis fiables. Os algoritmos recomendados para a migración inclúen rsa-sha2-256/512 baseado en RFC8332 RSA SHA-2 (soportado desde OpenSSH 7.2 e usado por defecto), ssh-ed25519 (soportado desde OpenSSH 6.5) e ecdsa-sha2-nistp256/384 based en RFC521 ECDSA (soportado desde OpenSSH 5656).
En OpenSSH 8.2, aínda está dispoñible a posibilidade de conectarse usando "ssh-rsa", pero este algoritmo foi eliminado da lista CASignatureAlgorithms, que define os algoritmos permitidos para asinar dixitalmente novos certificados. Do mesmo xeito, o algoritmo diffie-hellman-group14-sha1 foi eliminado dos algoritmos de intercambio de claves predeterminados admitidos. Nótase que o uso de SHA-1 nos certificados está asociado a un risco adicional, xa que o atacante ten tempo ilimitado para buscar unha colisión para un certificado existente, mentres que o tempo de ataque ás claves do host está limitado polo tempo de espera da conexión (LoginGraceTime ).
A execución de ssh-keygen agora usa o algoritmo rsa-sha2-512, que se admite desde OpenSSH 7.2, que pode crear problemas de compatibilidade ao intentar procesar certificados asinados en OpenSSH 8.2 en sistemas que executan versións anteriores de OpenSSH (para evitar o problema cando xerando unha sinatura, pode especificar explícitamente "ssh-keygen -t ssh-rsa" ou usar os algoritmos ecdsa-sha2-nistp256/384/521, compatibles desde OpenSSH 5.7).
Outros cambios:
- Engadiuse a sshd_config unha directiva Include, que lle permite incluír o contido doutros ficheiros na posición actual do ficheiro de configuración (pódense usar máscaras globo ao especificar o nome do ficheiro);
- Engadiuse a ssh-keygen a opción "non-touch-required", que desactiva a necesidade de confirmar fisicamente o acceso ao token ao xerar a chave;
- Engadiuse a sshd_config unha directiva PubkeyAuthOptions, que combina varias opcións relacionadas coa autenticación de chave pública. Actualmente, só se admite a marca "non é necesario tocar" para omitir as comprobacións de presenza física para a autenticación de token. Por analoxía, engadiuse a opción "non-touch-required" ao ficheiro authorized_keys;
- Engadiuse a opción "-O write-attestation=/path" a ssh-keygen para permitir que se escriban certificados de certificación FIDO adicionais ao xerar claves. OpenSSH aínda non usa estes certificados, pero posteriormente pódense usar para verificar que a chave está colocada nunha ferretería de confianza;
- Na configuración ssh e sshd, agora é posible establecer o modo de priorización do tráfico mediante a directiva IPQoS (Comportamento de menor esforzo por salto);
- En ssh, ao establecer o valor "AddKeysToAgent=yes", se a chave non contén un campo de comentario, engadirase a ssh-agent indicando o camiño da chave como comentario. EN
ssh-keygen e ssh-agent tamén usan agora as etiquetas PKCS#11 e o nome do asunto X.509 en lugar da ruta da biblioteca como comentarios na clave; - Engadida a posibilidade de exportar PEM para claves DSA e ECDSA a ssh-keygen;
- Engadiuse un novo executable, ssh-sk-helper, usado para illar a biblioteca de acceso ao token FIDO/U2F;
- Engadiuse a opción de compilación "--with-zlib" a ssh e sshd para a compilación co soporte da biblioteca zlib;
- De acordo co requisito de RFC4253, no banner que se amosa durante a conexión ofrécese unha advertencia sobre o bloqueo de acceso por exceder os límites de MaxStartups. Para simplificar o diagnóstico, a cabeceira do proceso sshd, visible cando se utiliza a utilidade ps, agora mostra o número de conexións autenticadas actualmente e o estado do límite de MaxStartups;
- En ssh e ssh-agent, ao chamar a un programa para mostrar unha invitación na pantalla, especificada a través de $SSH_ASKPASS, agora transmítese adicionalmente unha marca co tipo de invitación: "confirmar" - diálogo de confirmación (si/non), "ningunha". ” - mensaxe informativa, "en branco" - solicitude de contrasinal;
- Engadiuse unha nova operación de sinaturas dixitais "find-principals" a ssh-keygen para buscar no ficheiro de signadores permitidos o usuario asociado cunha sinatura dixital especificada;
- Compatibilidade mellorada para o illamento de procesos sshd en Linux mediante o mecanismo seccomp: desactivando as chamadas do sistema IPC, permitindo clock_gettime64(), clock_nanosleep_time64 e clock_nanosleep().
Fonte: opennet.ru