SSH chaves para um Linux VPS: criar, instalar e testar acesso

Confirme a conta real, host e método de recuperação

Use esta lista de verificação para um Linux VPS que você possui ou está autorizado a administrar. Comece com o host, nome da conta e porta SSH realmente atribuído ao seu serviço. Não adivinhar um nome de utilizador a partir de um nome de distribuição. Confirme como você recuperaria o acesso se uma alteração de autenticação falhar, usando um método que seu operador realmente disponibilizou.

Mantenha aberta uma sessão autenticada existente enquanto testa um novo método de login. Se você ainda não tiver acesso funcional, resolva os detalhes iniciais da conexão primeiro. Um plano de hospedagem público ou uma ordem paga não é em si uma conta de shell que funcione; aguarde os detalhes reais do serviço antes de aplicar as instruções do servidor.

Review Linux VPS software e recursos

Criar a chave no dispositivo usado para ligar

Execute o ssh-keygen no seu próprio dispositivo cliente, não dentro do remoto VPS. Para um cliente OpenSSH que o suporta, o ssh-keygen -t ed25519 cria um par de chaves Ed25519 e pede uma localização de arquivo e frase-passe. Escolha um novo nome de arquivo se uma chave existente já estiver presente; não sobreponha uma chave que outro servidor ainda use.

Proteja a chave privada com uma frase-passe e armazenamento seguro do dispositivo. Use o prompt interativo em vez de colocar uma frase- senha em um comando que pode ser salvo no histórico do shell. Mantenha o controle do propósito chave e da impressão digital de chave pública para que você possa identificar mais tarde a entrada certa ao revisar ou revogar o acesso.

Instalar a metade pública para a conta do servidor pretendida

A chave pública normalmente tem o mesmo nome de arquivo com .pub anexado. Adicione essa chave pública ao local da chave autorizada para a conta que você usará no VPS. Muitas instalações OpenSSH usam ~/.ssh/authorized_keys para a conta remota, mas a configuração eficaz do servidor pode especificar um local diferente. Verifique a localização em vez de assumir que cada sistema usa a mesma política.

Quando disponível, o ssh-copy-id pode instalar uma chave pública através de uma ligação autorizada existente. Uma instalação manual deve preservar as chaves existentes e manter cada chave pública em uma linha. Não substitua todo o arquivo por uma única entrada nova, a menos que tenha deliberadamente revisado todos os titulares de acesso. A chave privada fica no seu próprio dispositivo.

Role a tabela horizontalmente, se necessário.

Verificar a máquina e testar uma ligação nova

Compare a impressão digital da chave do servidor com um valor confiável obtido através do seu operador ou outro canal verificado antes de aceitar uma nova identidade de host. Se uma impressão digital anteriormente conhecida mudar inesperadamente, investigue a alteração. Excluir a entrada de hosts conhecidos do cliente e aceitar o que quer que apareça não estabelece que você alcançou o servidor correto.

Abra um segundo terminal e conecte-se com sua conta real, host e caminho de chave privada escolhido. A opção OpenSSH -i seleciona um arquivo de identidade, e -p seleciona uma porta não-padrão quando uma foi atribuída. Confirme a conta esperada após o login. Um prompt de senha de chave privada desbloqueia sua chave local; ela é diferente de uma prompt de senha de conta remota.

Rejeição do diagnóstico antes de alterar a política de autenticação

Se a chave for rejeitada, verifique se você usou a conta certa e que a chave pública corresponde à identidade privada selecionada pelo cliente. Reveja a localização do arquivo de chave autorizada, propriedade e permissões. Em uma conta OpenSSH típica, permissões restritivas como 700 em .ssh e 600 em authorized_keys impedem outros usuários de modificar arquivos de autenticação; a conta correta deve possuí-los.

Inspecione os diagnósticos do cliente e os registros de autenticação do servidor disponíveis para você. A política do servidor pode restringir usuários, tipos de chaves ou combinações de autenticação. Não amplie as permissões para fazer uma chave rejeitada funcionar. Compartilhar uma mensagem de erro redatada ao procurar ajuda, em vez de uma chave privada, frase-passe ou registro diagnóstico completo sensível.

Alterar as configurações de autenticação somente após o acesso ser comprovado

Uma chave de trabalho não altera automaticamente a política de senha do servidor. Se você pretende alterar as configurações de autenticação, inspecione a configuração principal do OpenSSH e quaisquer arquivos incluídos que afetem a conta. SenhaAutenticação e autenticação interativa com teclado são configurações separadas, e uma política de operador ou bloco Match pode alterar o resultado efetivo.

Faça backup da configuração relevante e valide-a com o servidor instalado antes de aplicar alterações; sudo sshd -t é a verificação de sintaxe OpenSSH em sistemas onde esse comando e privilégio se aplicam. Use o método de gerenciamento de serviços documentado para sua distribuição. Mantenha a sessão original aberta e prove outra conexão de chave fresca após a mudança antes de fechá-la.

Continue com a lista de verificação de segurança Linux VPS

Rodar o acesso e manter a recuperação independente de um laptop

Dê a cada administrador sua própria chave para que uma alteração de acesso não exija compartilhar um arquivo privado. Ao substituir um dispositivo, instale e teste a nova chave pública primeiro, em seguida, remova a antiga entrada de chave pública após identificá-lo. Uma frase- senha perdida não é recuperável da chave privada criptografada; crie uma substituição através de um método de acesso autorizado de trabalho.

Reveja as chaves quando um membro da equipe sai ou um dispositivo é perdido. Removendo uma entrada de chave pública impede futuras logins de chave através dessa entrada, mas também rever sessões ativas e outros métodos de acesso. Mantenha um procedimento de recuperação aprovado com seus registros de serviço para que o acesso não depende inteiramente do dispositivo que você está substituindo.

• A chave privada nunca foi carregada ou enviada para suporte.
• Uma segunda conexão funciona com a conta e identidade pretendidas.
• A impressão digital da máquina foi verificada através de um canal de confiança.
• Recuperação e revogação chave são documentados antes de mudanças políticas.

Planeje backups independentes e recuperação · Validar um site Nginx após estabelecer o acesso