Para desenvolvedores que têm conhecimento de infraestrutura e gostam de manter seu próprio servidor, usar o SSH para acessá-lo e fazer manutenções no WordPress e outras pastas é uma tarefa cotidiana. Normalmente o acesso se dá com a dupla usuário/senha, mas há casos, entretanto, em que a plataforma obriga ou já deixa o servidor pré-configurado para fazer o acesso somente por uma chave pública SSH.
Quando o acesso SSH por chave pública atrapalha
O acesso por chave pública é uma opção segura, mas pode ser um problema se tu não tens conhecimento dessa chave ou não estavas preparado para este tipo de acesso.
Nestes casos, ao se tentar acessar o servidor com o comando ssh usuario@servidor, recebemos aquele erro chato e sem muita explicação:Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)
Isso normalmente ocorre porque o SSH está tentando fazer a combinação de autenticação e a chave não está armazenada em tua máquina, simplesmente porque não existe.
Um exemplo comum são servidores criados nos serviços Lightsail ou EC2 da Amazon. Nestes serviços, os servidores não tem um usuário “root” e o acesso por padrão é via chave pública. Para melhorar, a documentação não é clara sobre este aspecto da configuração (até porque é quase toda em Inglês).
No caso da Umbler, é um pouco diferente. A documentação é melhor e o suporte é amistoso, o que já melhora 100%. Entretanto, para se fazer o acesso SSH é obrigatório fazer o envio da chave pública antes, não há a opção de acessar por senha.
Já na DigitalOcean, Vultr e outras, em geral é possível ter o acesso via chave pública, mas a autenticação padrão é por senha, o que pode ser menos seguro, mas é mais prático logo que se cria o servidor.
O que fazer?
O que fazer nestes casos? Na verdade é simples. Basta usar os parâmetros PreferredAuthentications (Autenticação Preferida) e PubkeyAuthentication (Autenticação por Chave Pública) para forçar o acesso por senha e dispensar a chave pública.
O comando ficaria assim:
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no usuario@servidor
Ou seja, “Autenticação Preferida = senha” e “Autenticação por Chave Pública = não”.
Com esse comando, o SSH vai responder com:
usuario@servidor's password:
Daí é só entrar com a senha e pronto.
Tenha configurações SSH diferentes para cada servidor
Outra possibilidade interessante é guardar as configurações usadas para cada servidor que precisares fazer acesso.
Isso é feito por meio de um arquivo “config” que é gravado na pasta .ssh, a mesma onde ficam as chaves de acesso.
Criando um arquivo de configurações para o SSH
1) Acessa a pasta .ssh na tua pasta de usuário e cria um documento com o nome config e ajusta as permissões do arquivo para 600.
2) Edita o arquivo e cria seções iniciando sempre com este modelo
host <servidor ou padrão>Por exemplo:
host *.gauderio.com
user gaudencio
port 9191
PubkeyAuthentication=noDaí é só usar ssh indio-veio.gauderio.com que o SSH vai consultar o arquivo de configurações e aplicar as opções listadas acima.
Ainda há a chance de haver um arquivo de configuração padrão para todo o sistema. Neste caso, será necessário “enganar” o SSH, especificando uma configuração de mentirinha:
ssh -F /dev/null usuario@servidorO parâmetro -F permite especificar um arquivo de configuração alternativo e a configuração padrão de sistema é ignorada.
Este artigo te ajudou? Ficaste com alguma dúvida sobre o SSH? Seguiste os passos e não funcionou? Deixa teu comentário aí embaixo para a gente ver juntos!