Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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. Esta documentação não está duplicada neste conjunto de documentação.
Arquivos de configuração openSSH
O OpenSSH tem arquivos de configuração para configurações de servidor e cliente. O OpenSSH é de software livre e foi adicionado aos sistemas operacionais cliente Windows Server e Windows a partir do Windows Server 2019 e do Windows 10 (build 1809). A documentação de software livre para arquivos de configuração openSSH não é repetida aqui. Os arquivos de configuração do cliente podem ser encontrados na página manual ssh_config. Os arquivos de configuração do servidor OpenSSH podem ser encontrados na página manual sshd_config.
O OpenSSH Server lê 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 Cliente OpenSSH (ssh) lê dados de configuração de um arquivo de configuração na seguinte ordem:
- Por meio
ssh.exe
do-F
parâmetro iniciado, com um caminho para um arquivo de configuração e um nome de entrada desse arquivo especificado. - Por meio do arquivo de configuração de um usuário em
%userprofile%\.ssh\config
. - Por meio do arquivo de configuração em 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 são 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 o 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 ela.
Shell de comando | Comando a ser usado |
---|---|
Command | path |
PowerShell | $env:path |
Você pode configurar o shell ssh padrão no Registro do Windows adicionando o caminho completo ao executável HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH
do shell no valor DefaultShell
da cadeia de caracteres.
O comando do PowerShell com privilégios elevados a seguir define o shell padrão para powershell.exe
o Servidor OpenSSH. (Definir esse caminho não se aplica ao Cliente OpenSSH.)
$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ê 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 as configurações específicas do Windows que são possíveis por meio de entradas em sshd_config. Há outras configurações possíveis que não estão listadas aqui. Eles são abordados em detalhes na documentação do Win32 OpenSSH.
Tip
O Servidor OpenSSH (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
Você pode controlar quais usuários e grupos podem se conectar ao servidor usando as AllowGroups
diretivas, AllowUsers
e DenyGroups
DenyUsers
as diretivas.
As diretivas de permissão e negação são processadas na seguinte ordem: DenyUsers
, , AllowUsers
e DenyGroups
por fim AllowGroups
.
Todos os nomes de conta devem ser especificados em letras minúsculas.
Para obter mais informações sobre padrões e curingas no ssh_config, consulte a página manual 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, *
é usado para abranger FQDNs (Nomes de Domínio Totalmente Qualificados). Além disso, essa abordagem usa ?
, em vez de @
, para evitar conflitos com o username@host
formato.
Usuários do grupo de trabalho, grupos e contas conectadas à Internet são sempre resolvidos para o nome da conta local (sem parte de domínio, semelhante aos nomes padrão do Unix). 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 grupo e de usuário precisam aderir a esse formato.
O exemplo a seguir nega contoso\admin
o 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 grupo e do contoso\sshusers
grupo contoso\serveroperators
.
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 no 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
No momento, não há suporte para autenticação por meio de uma conta do Microsoft Entra.
AuthorizedKeysFile
O padrão é .ssh/authorized_keys
. Se você não especificar um caminho absoluto, o OpenSSH procurará o arquivo em relação ao 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 deve ter apenas entradas de permissão para a conta e NT Authority\SYSTEM
o BUILTIN\Administrators
grupo de segurança. A conta NT Authority\SYSTEM deve receber controle total. O BUILTIN\Administrators
grupo de segurança é 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 à v7.7.0.0)
Essa diretiva só tem suporte com sessões SFTP. Uma sessão cmd.exe
remota em não respeita ChrootDirectory
. Para configurar um servidor chroot exclusivo para 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 da opção -K
que especifica o nome do host quando você usa 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 por %userprofile%\.ssh\config
padrão.
Veja um exemplo de configuração do cliente GSSAPI OpenSSH:
# 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 no início do serviço.
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. A correspondência usa as regras de padrão abordadas na seção AllowGroups, AllowUsers, DenyGroups, DenyUsers . Os nomes de usuário e grupo devem estar em letras 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, AUTH direciona o registro de logs para o ETW. Para obter mais informações, consulte Logging Facilities in Windows.
Argumentos de configuração
O argumento de configuração a seguir 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 que é fornecida no Windows Server e no 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