Início / computer / Perguntas / 1846364
Accepted
M_D
Asked: 2024-06-19 16:36:50 +0800 CST

Esta configuração do OpenSSH fornecerá a melhor segurança

  • 772

Configurando meu servidor OpenSSH em um servidor Windows 10 para ser exposto à WAN. (Até agora só foi usado na LAN).

O que estou tentando alcançar:

Quando a conexão for pela internet, apenas 1 usuário específico deverá ser permitido ( remoteuser). Os usuários que se conectam pela Internet devem ter permissão para fazer muito pouco: apenas encaminhar portas TCP para alguns hosts específicos (veja minha PermitOpendiretiva), sem acesso ao shell, sem SFTP, sem nenhum dos outros recursos dos quais provavelmente nunca ouvi falar .

Então, usei um Matchbloco para combinar conexões provenientes de minhas LANs seguras. Para estes, a segurança deveria ser mais relaxada. Permitir autenticação por senha, permitir mais usuários (embora sftpuser1deva ser limitado apenas a SFTP), etc.

Perguntas: Meus blocos de Partida funcionarão conforme planejado? São uma forma válida de atingir meus objetivos? Além disso, há algum outro recurso que não conheço e que devo desabilitar para clientes da Internet (além do shell, SFTP, encaminhamento X11)?

Configuração até agora:


Port 22
AddressFamily inet #IPv4 only 
ListenAddress 10.10.10.15 #Listen on servers LAN IP

Protocol 2
TCPKeepAlive yes

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

RekeyLimit 1G

#SyslogFacility AUTH # LOCAL0 - Logs to %programdata%\ssh\logs, AUTH - Logs to event viewer
LogLevel DEBUG

LoginGraceTime 1m
StrictModes yes
MaxAuthTries 3
MaxStartups 3:50:10

# SET TO 0 ON WAN TO DISABLE ALL BUT TUNNELS. INCREASED FOR LAN CONNECTIONS

MaxSessions 0

PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

AuthorizedKeysFile  __PROGRAMDATA__/ssh/keys/%u/authorized_keys #Where to look for keys for each user.

AllowUsers remoteuser (Allow only one port forwarding user for access from WAN)

X11Forwarding no
AllowTcpForwarding yes
PermitOpen ws1.internal:80 ws2.internal:80 #Only allow forwards to certain hosts & ports.

Match Address 10.10.10.0/24, 10.10.20.0/24
    LoginGraceTime 1m
    MaxAuthTries 5
    MaxStartups 10
    MaxSessions 5
    PubkeyAuthentication yes
    PasswordAuthentication yes
    AllowUsers john sftpuser1

Match User sftpuser1
    ChrootDirectory E:\
    X11Forwarding no
    AllowTcpForwarding no
    AllowAgentForwarding no
    ForceCommand internal-sftp -d /%u

Esclarecimento: My Aim - servidor SSH aberto para WAN e LAN. Quando a conexão é da WAN (o IP de origem do IE NÃO é uma das minhas LANs), só remoteuseré permitido conectar ( AllowUsers remoteuser), podendo SOMENTE USAR O ENCAMINHAMENTO TCP. Quando a conexão é feita pela LAN, os usuários johntêm sftpuser1permissão para se conectar e podem usar recursos como acesso shell, SFTP, etc.

Então, basicamente, tentar executar uma configuração de WAN reforçada com recursos mínimos habilitados e uma configuração apenas local mais relaxada, sem executar duas instâncias separadas do sshd.

Editar: acabei de encontrar este recurso que ajuda até certo ponto com as instruções Match...

windows-10

1 respostas

  1. Best Answer

    Alguns progressos:

    Depois de alguns testes, tive que:

    • Remover diretivas LoginGraceTime& MaxStartupsde dentro dos blocos Match, pois sshd.exereclama que elas não são permitidas dentro de um bloco Match.
    • Adicione a linha Subsystem sftp sftp-server.exena configuração global para permitir o funcionamento do SFTP.

    Além desses pontos, os blocos Match parecem funcionar, e eu tenho um servidor que é protegido para conexões NÃO da LAN local (IE Internet), permitindo apenas o encaminhamento de TCP, sendo mais permissivo para clientes na LAN. (Permitir autenticação de senha, permitir shell e SFTP, etc.).

    Observarei que descobri que se as permissões estiverem erradas nos arquivos de chave de cada usuário, suas chaves serão rejeitadas sem nenhuma indicação óbvia do problema nos logs, etc. Como eu especifiquei um caminho diferente para as chaves (não na página inicial dos usuários diretórios), para cada pasta de usuários, defino o proprietário como SYSTEMe somente SYSTEMo próprio usuário tem permissão para sua pasta. Isso pareceu funcionar.

    • 0

relate perguntas