Partilhar via


Configuração do OpenSSH Server para Windows Server e Windows

Aplica-se ao Windows Server 2022, ao Windows Server 2019 e ao Windows 10 (build 1809 e posterior)

Este artigo aborda a configuração específica do Windows para o OpenSSH Server (sshd).

O OpenSSH mantém a documentação detalhada das opções de configuração online em OpenSSH.com, que não está duplicada neste conjunto de documentação.

Arquivos de configuração do OpenSSH

O OpenSSH tem arquivos de configuração para servidor e cliente. O OpenSSH é um software de código aberto e é adicionado aos sistemas operacionais Windows Server e Windows Client a partir do Windows Server 2019 e do Windows 10 (build 1809). Por isso, a documentação de código aberto para arquivos de configuração do OpenSSH não será repetida aqui. Os arquivos de configuração do cliente podem ser encontrados na página do manual do ssh_config e os arquivos de configuração do Servidor OpenSSH podem ser encontrados na página do manual do sshd_config.

O OpenSSH Server (sshd) lê os dados de configuração de %programdata%\ssh\sshd_config por padrão ou um arquivo de configuração diferente pode ser especificado iniciando sshd.exe com o parâmetro -f. Se o arquivo estiver ausente, o sshd gerará um com a configuração padrão quando o serviço for iniciado.

No Windows, o Cliente OpenSSH (ssh) lê os dados de um arquivo de configuração na seguinte ordem:

  1. Ao iniciar o ssh.exe com o parâmetro -F, especificando um caminho para um arquivo de configuração e um nome de entrada desse arquivo.
  2. O arquivo de configuração de um usuário em %userprofile%\.ssh\config.
  3. O arquivo de configuração de todo o sistema em %programdata%\ssh\ssh_config.

Como configurar o shell padrão para OpenSSH no Windows

O Shell de comando padrão proporciona a experiência que um usuário vê ao se conectar ao servidor usando SSH. O Windows padrão inicial é o Shell de Comando do Windows (cmd.exe). O Windows também inclui o PowerShell, e os shells de comando de terceiros também estão disponíveis para o Windows e podem ser configurados como o shell padrão para um servidor.

Para definir o shell de comando padrão, primeiro confirme se a pasta de instalação do OpenSSH está no caminho do sistema. Para o Windows, a pasta de instalação padrão é %systemdrive%\Windows\System32\openssh. O comando a seguir mostra a configuração de caminho atual e adiciona a ela a pasta de instalação padrão do OpenSSH.

Shell de comando Comando a ser usado
Comando path
PowerShell $env:path

A configuração do shell ssh padrão é feita no Registro do Windows adicionando o caminho completo para o executável do shell em HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH, no valor da cadeia de caracteres DefaultShell.

Por exemplo, o seguinte comando do PowerShell com privilégios elevados define o shell padrão como powershell.exe:

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -PropertyType String -Force

Windows Configurations no sshd_config

No Windows, o sshd lê os dados de configuração de %programdata%\ssh\sshd_config por padrão ou um arquivo de configuração diferente pode ser especificado iniciando sshd.exe com o parâmetro -f. Se o arquivo estiver ausente, o sshd gerará um com a configuração padrão quando o serviço for iniciado.

Os elementos listados abaixo fornecem a configuração específica do Windows possível por meio de entradas no sshd_config. Há outras definições de configuração possíveis que não estão listadas aqui, pois são abordadas detalhadamente na documentação do Win32 OpenSSH online.

Dica

O OpenSSH Server (sshd) lê o arquivo de configuração quando o serviço é iniciado. Todas as alterações no arquivo de configuração exigem que o serviço seja reiniciado.

AllowGroups, AllowUsers, DenyGroups, DenyUsers

O controle de quais usuários e grupos podem se conectar ao servidor é feito usando as diretivas AllowGroups, AllowUsers, DenyGroups e DenyUsers. As diretivas allow/deny são processadas na seguinte ordem: DenyUsers, AllowUsers, DenyGroups e, por fim, AllowGroups. Todos os nomes de conta devem ser especificados em letras minúsculas. Para obter mais informações sobre PATTERNS e curinga no ssh_config, consulte a página do manual do sshd_config OpenBSD.

Ao configurar regras baseadas em usuário/grupo com um usuário ou grupo de domínio, use o seguinte formato: user?domain*. O Windows permite vários formatos para especificar entidades de segurança de domínio, mas muitos estão em conflito com os padrões do Linux. Por esse motivo, * é adicionado para cobrir FQDNs. Além disso, essa abordagem usa "?", em vez de @, para evitar conflitos com o formato nome_de_usuario@host.

Os usuários/grupos do grupo de trabalho e as contas conectadas à Internet são sempre resolvidos para o nome da conta local (sem parte do domínio, semelhante a nomes Unix padrão). Os usuários e grupos de domínio são estritamente resolvidos para o formato NameSamCompatible – domain_short_name\user_name. Todas as regras de configuração baseadas em usuário/grupo precisam aderir a esse formato.

O exemplo a seguir nega contoso\admin do host 192.168.2.23 e bloqueia todos os usuários do domínio contoso. Ele também permite os usuários que são membros dos grupos contoso\sshusers e contoso\serveroperators.

DenyUsers contoso\admin@192.168.2.23
DenyUsers contoso\*
AllowGroups contoso\sshusers contoso\serveroperators

O exemplo a seguir permite a entrada do usuário localusers do host 192.168.2.23 e permite os membros do grupo sshusers.

AllowUsers localuser@192.168.2.23
AllowGroups sshusers

AuthenticationMethods

Para o Windows OpenSSH, os únicos métodos de autenticação disponíveis são password e publickey.

Importante

No momento, não há suporte para autenticação usando uma conta do Microsoft Entra.

AuthorizedKeysFile

O padrão é .ssh/authorized_keys. Se o caminho não for absoluto, ele é considerado relativo ao diretório inicial do usuário (ou ao caminho da imagem do perfil), por exemplo, C:\Users\nome_do_usuario. Se o usuário pertencer ao grupo de administradores, então será usado %programdata%/ssh/administrators_authorized_keys.

Dica

O arquivo administrators_authorized_keys só deve ter entradas de permissão para a conta do NT Authority\SYSTEM e para o grupo de segurança BUILTIN\Administrators. A conta do NT Authority\SYSTEM deve receber controle total. O grupo de segurança BUILTIN\Administrators é necessário para que os administradores gerenciem as chaves autorizadas. Você pode escolher o acesso necessário. Para conceder permissões, você pode abrir um prompt do PowerShell com privilégios elevados e executar o comando icacls.exe "C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "Administrators:F" /grant "SYSTEM:F".

ChrootDirectory (suporte adicionado na v7.7.0.0)

Essa diretiva só tem suporte com sessões sftp. Uma sessão remota em cmd.exe não honraria o ChrootDirectory. Para configurar um servidor chroot somente sftp, defina ForceCommand como internal-sftp. Você também pode configurar o scp com chroot implementando um shell personalizado que permita apenas scp e sftp.

GSSAPIAuthentication

O argumento de configuração GSSAPIAuthentication especifica se a autenticação de usuário baseada em GSSAPI é permitida. O padrão para GSSAPIAuthentication é não.

A autenticação GSSAPI também requer o uso da opção -K que especifica o nome do host ao usar o cliente OpenSSH. Como alternativa, você pode criar uma entrada correspondente na configuração do cliente SSH. No Windows, o cliente OpenSSH lê dados de configuração de %userprofile%.ssh\config por padrão.

Você pode ver um exemplo de configuração do cliente GSSAPI OpenSSH abaixo.

# Specify a set of configuration arguments for a host matching the pattern SERVER01.contoso.com
# Patterns are case sensitive
Host SERVER01.contoso.com
    # Enables GSSAPI authentication
    GSSAPIAuthentication yes
    # Forward (delegate) credentials to the server.
    GSSAPIDelegateCredentials yes

Importante

O GSSAPI só está disponível a partir do Windows Server 2022, Windows 11 e Windows 10 xxxx.

HostKey

Os padrões são:

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

Se os padrões não estiverem presentes, o sshd os gerará automaticamente no início do serviço.

Corresponder a

Condições de correspondência usando um ou mais critérios. Após uma correspondência, os argumentos de configuração subsequentes são aplicados. As correspondências usam as regras padrão abordadas na seção AllowGroups, AllowUsers, DenyGroups, DenyUsers. Os nomes de usuários e grupos devem estar em letras minúsculas.

PermitRootLogin

Não aplicável no Windows. Para impedir que os administradores entrem, use Administradores com a diretiva DenyGroups.

SyslogFacility

Se você precisar de registro em log baseado em arquivo, use LOCAL0. Os logs são gerados em %programdata%\ssh\logs. Para qualquer outro valor incluindo o valor padrão, AUTH direciona o log para o ETW. Para obter mais informações, confira Recursos de Registro em Log no Windows.

Argumentos de configuração

O seguinte argumento de configuração está disponível a partir do Windows Server 2022, Windows 11 e Windows 10 xxxx:

  • GSSAPIAuthentication

Os seguintes argumentos de configuração não estão disponíveis na versão OpenSSH que é fornecida no Windows Server e no cliente Windows:

  • AcceptEnv
  • AllowStreamLocalForwarding
  • AuthorizedKeysCommand
  • AuthorizedKeysCommandUser
  • AuthorizedPrincipalsCommand
  • AuthorizedPrincipalsCommandUser
  • ExposeAuthInfo
  • GSSAPICleanupCredentials
  • GSSAPIStrictAcceptorCheck
  • HostbasedAcceptedKeyTypes
  • HostbasedAuthentication
  • HostbasedUsesNameFromPacketOnly
  • IgnoreRhosts
  • IgnoreUserKnownHosts
  • KbdInteractiveAuthentication
  • KerberosAuthentication
  • KerberosGetAFSToken
  • KerberosOrLocalPasswd
  • KerberosTicketCleanup
  • PermitTunnel
  • PermitUserEnvironment
  • PermitUserRC
  • PidFile
  • PrintLastLog
  • PrintMotd
  • RDomain
  • StreamLocalBindMask
  • StreamLocalBindUnlink
  • StrictModes
  • X11DisplayOffset
  • X11Forwarding
  • X11UseLocalhost
  • XAuthLocation