Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo aborda a configuração específica do Windows para OpenSSH Server (sshd).
OpenSSH mantém documentação detalhada para opções de configuração on-line em OpenSSH.com. Esta documentação não está duplicada neste conjunto de documentos.
Arquivos de configuração OpenSSH
O OpenSSH tem arquivos de configuração para as configurações do servidor e do cliente. O OpenSSH é de código aberto e foi adicionado aos sistemas operacionais Windows Server e Windows client a partir do Windows Server 2019 e Windows 10 (build 1809). A documentação de código aberto para arquivos de configuração OpenSSH não é repetida aqui. Os arquivos de configuração do cliente podem ser encontrados na página de manual do ssh_config. Os arquivos de configuração do servidor OpenSSH podem ser encontrados na página de manual do sshd_config.
O OpenSSH Server lê os dados de configuração por %programdata%\ssh\sshd_config padrão. Você pode especificar um arquivo de configuração diferente executando sshd.exe com o -f parâmetro. Se o arquivo estiver ausente, o sshd gerará um com a configuração padrão quando o serviço for iniciado.
No Windows, o OpenSSH Client (ssh) lê dados de configuração de um arquivo de configuração na seguinte ordem:
- Via
ssh.execomeçou com o parâmetro-F, com um caminho para um ficheiro de configuração e um nome de entrada desse ficheiro especificado. - Através do arquivo de configuração de um usuário em
%userprofile%\.ssh\config. - Através do arquivo de configuração de todo o sistema em
%programdata%\ssh\ssh_config.
Configurando o shell padrão para OpenSSH no Windows
O shell de comando padrão fornece a experiência que um usuário vê ao se conectar ao servidor usando SSH. O padrão inicial no Windows é o prompt de comando do Windows (cmd.exe). O Windows também inclui o PowerShell, e shells de comando que não sejam da Microsoft 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 Windows, a pasta de instalação padrão é %systemdrive%\Windows\System32\openssh.
O comando a seguir mostra a configuração do caminho atual e adiciona a pasta de instalação padrão do OpenSSH a ele.
| Shell de comando | Comando a utilizar |
|---|---|
| Command | path |
| PowerShell | $env:path |
Você pode configurar o shell ssh padrão no registro do Windows adicionando o caminho completo para o executável do shell no valor da cadeia de caracteres HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSHDefaultShell.
O comando PowerShell elevado de exemplo a seguir define o shell padrão como sendo powershell.exe para o OpenSSH Server. (Definir este caminho não se aplica ao OpenSSH Client.)
$NewItemPropertyParams = @{
Path = "HKLM:\SOFTWARE\OpenSSH"
Name = "DefaultShell"
Value = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
PropertyType = "String"
Force = $true
}
New-ItemProperty @NewItemPropertyParams
Configurações do Windows no sshd_config
No Windows, o sshd lê os dados de configuração por %programdata%\ssh\sshd_config padrão. Você pode especificar um arquivo de configuração diferente executando sshd.exe com o -f parâmetro.
Se o arquivo estiver ausente, o sshd gerará um com a configuração padrão quando o serviço for iniciado.
As seções a seguir descrevem definições de configuração específicas do Windows que são possíveis por meio de entradas no sshd_config. Há outras definições de configuração possíveis que não estão listadas aqui. Eles são abordados em detalhes na documentação do Win32 OpenSSH.
Tip
O OpenSSH Server (sshd) lê o arquivo de configuração quando o serviço é iniciado. Quaisquer alterações no arquivo de configuração exigem que o serviço seja reiniciado.
PermitirGrupos, PermitirUtilizadores, NegarGrupos, NegarUtilizadores
Você pode controlar quais usuários e grupos podem se conectar ao servidor usando as AllowGroupsdiretivas , AllowUsers, DenyGroupse DenyUsers .
As diretivas de permissão e negação são processadas na seguinte ordem: DenyUsers, AllowUsers, DenyGroupse finalmente AllowGroups.
Todos os nomes de conta devem ser especificados em minúsculas.
Para obter mais informações sobre padrões e curingas no ssh_config, consulte a página de 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 domínio, mas pode entrar em conflito com padrões padrão do Linux. Por esse motivo, * é utilizado para abranger Nomes de Domínio Totalmente Qualificados (FQDNs). Além disso, essa abordagem usa ?, em vez de @, para evitar conflitos com o username@host formato.
Usuários de grupos de trabalho, grupos e contas conectadas à Internet são sempre resolvidos para seu nome de conta local (sem parte de domínio, semelhante aos nomes Unix padrão). Os usuários e grupos de domínio são estritamente resolvidos para o formato domain_short_name\user_name.
Todas as regras de configuração baseadas em usuários e grupos 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 que os usuários que são membros do contoso\sshusers e contoso\serveroperators grupos.
DenyUsers contoso\admin@192.168.2.23
DenyUsers contoso\*
AllowGroups contoso\sshusers contoso\serveroperators
O exemplo a seguir permite que o usuário localuser entre a partir do host 192.168.2.23 e permite que 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.
Important
Atualmente, não há suporte para autenticação por meio de uma conta Microsoft Entra.
AuthorizedKeysFile
A predefinição é .ssh/authorized_keys. Se você não especificar um caminho absoluto, o OpenSSH procurará o arquivo relativo ao seu diretório base, como C:\Users\username. Se o usuário pertencer ao grupo de administradores, %programdata%/ssh/administrators_authorized_keys será usado em vez disso.
Tip
O arquivo administrators_authorized_keys só deve ter entradas de permissão para a conta e NT Authority\SYSTEM o BUILTIN\Administrators grupo de segurança. A conta NT Authority\SYSTEM deve ter controle total. O BUILTIN\Administrators security group é necessário para permitir 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)
Esta diretiva só é suportada com sessões SFTP. Uma sessão remota em cmd.exe não honra 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 permite apenas SCP e SFTP.
GSSAPIAuthentication
O GSSAPIAuthentication argumento de configuração especifica se a autenticação de usuário baseada em GSSAPI (Kerberos) é permitida. O padrão para GSSAPIAuthentication é não.
A autenticação GSSAPI também requer o uso do switch -K que especifica o nome do host quando utiliza o Cliente OpenSSH. Como alternativa, você pode criar uma entrada correspondente na configuração do cliente SSH. No Windows, o Cliente OpenSSH lê os dados de configuração por %userprofile%\.ssh\config padrão.
Aqui está um exemplo de configuração do GSSAPI OpenSSH Client:
# 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
Important
O GSSAPI só está disponível a partir do Windows Server 2022, Windows 11 e Windows 10 (atualização de maio de 2021).
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 quando o serviço for iniciado.
Match
Corresponde às condições usando um ou mais critérios. Após uma correspondência, os argumentos de configuração subsequentes são aplicados. Match usa as regras de padrão abordadas na seção AllowGroups, AllowUsers, DenyGroups, DenyUsers . Os nomes de usuários e grupos devem estar em minúsculas.
PermitRootLogin
Não aplicável no Windows. Para impedir que os administradores entrem, use Administradores com a DenyGroups diretiva.
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, o AUTH direciona o log para o ETW. Para obter mais informações, consulte Logging Facilities in 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 (Atualização de maio de 2021):
GSSAPIAuthentication
Os seguintes argumentos de configuração não estão disponíveis na versão OpenSSH fornecida no Windows Server e no Windows:
AcceptEnvAllowStreamLocalForwardingAuthorizedKeysCommandAuthorizedKeysCommandUserAuthorizedPrincipalsCommandAuthorizedPrincipalsCommandUserExposeAuthInfoGSSAPICleanupCredentialsGSSAPIStrictAcceptorCheckHostbasedAcceptedKeyTypesHostbasedAuthenticationHostbasedUsesNameFromPacketOnlyIgnoreRhostsIgnoreUserKnownHostsKbdInteractiveAuthenticationKerberosAuthenticationKerberosGetAFSTokenKerberosOrLocalPasswdKerberosTicketCleanupPermitTunnelPermitUserEnvironmentPermitUserRCPidFilePrintLastLogPrintMotdRDomainStreamLocalBindMaskStreamLocalBindUnlinkStrictModesX11DisplayOffsetX11ForwardingX11UseLocalhostXAuthLocation