Ir diretamente para o conteúdo

Definições de cookies

Escolha que tipos de cookies permite. Pode alterar a sua escolha a qualquer momento em Definições de cookies, no fundo de cada página. Política de privacidade

Necessários

Sempre ativos

Necessários para iniciar sessão, manter o seu carrinho e memorizar as suas escolhas. Estão sempre ativos.

Que cookies?
  • weboke_sessie, weboke_klant, weboke_remember: a sua sessão e manter a sessão iniciada
  • weboke_basket: o seu carrinho
  • wkBtwIncl: mostrar preços com ou sem IVA
  • wok_cookies: a sua escolha de cookies, 12 meses

Mede que anúncio leva a uma visita ou encomenda, para não pagarmos por anúncios que não dão resultado.

Que cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), até 90 dias
  • OpenAI Ads, anúncios no ChatGPT
  • wok_aff: através de que parceiro chegou até nós (programa de afiliados), 60 dias

4,6

País e idioma

Cada país tem o seu próprio site, com os preços e o IVA desse país.

Ver

Desativar o início de sessão com palavra-passe e como root

Qualquer servidor na Internet recebe, em pouco tempo, visitas de programas que tentam adivinhar palavras-passe. Se só for possível iniciar sessão com uma chave, esses programas não têm qualquer hipótese. É isso que vai ativar agora.

Atenção: O início de sessão com a sua chave como anna funciona (consulte Um utilizador próprio com sudo)? Nesse caso, crie primeiro um snapshot (consulte Snapshots: uma rede de segurança para cada alteração importante) e mantenha uma sessão aberta durante estes passos. Se algo correr mal, pode entrar através da consola (consulte A consola: o seu VPS no navegador).

Um ficheiro de configuração próprio

No Debian e no Ubuntu, o servidor SSH lê primeiro os ficheiros em /etc/ssh/sshd_config.d/, por ordem alfabética. Para cada definição, conta o primeiro valor que encontra. Por isso, o seu próprio ficheiro recebe um nome que fica no início da lista:

anna@web1:~$ sudo nano /etc/ssh/sshd_config.d/00-eigen.conf

Coloque nele:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
  • PasswordAuthentication no: deixa de haver palavras-passe através de SSH.
  • KbdInteractiveAuthentication no: também não é pedida nenhuma palavra-passe por uma via alternativa.
  • PermitRootLogin no: o root deixa de poder iniciar sessão através de SSH, nem mesmo com uma chave. Trabalha como anna com sudo. Se ainda pretender permitir o root com uma chave, utilize prohibit-password.

Verificar e aplicar

anna@web1:~$ sudo sshd -t
anna@web1:~$ sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'
passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin no
anna@web1:~$ sudo systemctl restart ssh

sshd -t não mostra nada se o ficheiro estiver correto. sshd -T mostra os valores que estão realmente em vigor. Ainda aparece passwordauthentication yes? Então há outro ficheiro em sshd_config.d que volta a ativar essa opção, muitas vezes 50-cloud-init.conf. O seu 00-eigen.conf vem antes e prevalece; verifique se o nome está correto.

No AlmaLinux e no Rocky Linux, o serviço chama-se sshd: sudo systemctl restart sshd.

Testar antes de fechar a sessão

Abra uma nova janela e experimente:

ssh anna@203.0.113.10
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@203.0.113.10
anna@203.0.113.10: Permission denied (publickey).
ssh root@203.0.113.10
root@203.0.113.10: Permission denied (publickey).

A primeira tentativa deve funcionar. As outras duas devem ser recusadas. Está tudo correto? Então elimine o snapshot.

Dica: Um número de porta diferente de 22 mantém o seu registo mais tranquilo, mas não torna o seu servidor mais seguro. Quem faz o trabalho é a chave. Se mesmo assim alterar a porta, abra-a primeiro na sua firewall (consulte Uma firewall com ufw (ou nftables)).

Um momento…

Configurar os seus domínios

Para cada domínio, defina os servidores de nomes, a ligação ao seu alojamento e quem fica como titular.

A carregar os seus domínios…