Outubro 24, 2020
Articles
Sem comentários

servidor dropbear ssh ganhou ' não me deixou conectar

Estou tentando obter acesso ssh ao meu roteador. Atualmente só tenho acesso telnet e instalei o dropbear e está rodando (usando opkg em um drive USB conectado ao roteador).

Desde o início, o que fiz foi gerar uma chave privada e descriptografá-la (desde dropbear não suporta isso ainda) e o público: 

cd .ssh openssl genrsa -des3 -out id_rsa openssl rsa -in id_rsa -out id_rsa ssh-keygen -y -f id_rsa > authorized_keys

Eu carreguei a chave pública (authorized_keys ) para /root/.ssh. Coloquei o arquivo em um servidor Apache (no meu computador local) e baixei no roteador usando wget (para que o arquivo baixado se tornasse root como proprietário / grupo) e então mudei as permissões para 0600 (o mesmo para o cliente, mas com meu usuário ).

Quando tento acessar, recebo um erro “Permission denied (publickey)”: 

$ ssh -v -i ~/.ssh/id_rsa [email protected] OpenSSH_7.4p1, OpenSSL 1.0.2j 26 Sep 2016 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/chazy/.ssh/id_rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4 debug1: Remote protocol version 2.0, remote software version dropbear debug1: no match: dropbear debug1: Authenticating to 192.168.1.1:22 as "root" debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: [email protected] debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha1 compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:1EFA75uwLp+4hBW0t3aaY05QjLzYd4jjDWoULAzF/8o debug1: Host "192.168.1.1" is known and matches the RSA host key. debug1: Found key in /home/chazy/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/chazy/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey).

A menos que eu ” estou interpretando mal o que a documentação ( repositório GitHub ) diz:

Autenticação de chave pública do servidor :

Você pode usar ~ / .ssh / authorized_keys da mesma maneira que com OpenSSH, basta colocar as entradas principais nesse arquivo. Elas devem estar no formato:

ssh- RSA AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV + ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk / yU99UVv6NWV / 5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET / MG8qyskG / 2IE2DPNIaJ3Wy + Ws4IZEgdJgPlTYUBWWtCWOGc = alguém @ hostname

Você deve se certificar de que ~ / .ssh eo arquivo de chave, são apenas gravável pelo usuário. Cuidado com os editores que dividiu a chave em várias linhas.

O Dropbear oferece suporte a algumas opções para entradas de chaves autorizadas, consulte a página de manual.

Fiz tudo que ele disse, então não sei onde pode estar o problema.

A documentação menciona outra maneira:

Autorização de chave pública do cliente:

O Dropbear pode fazer autenticação de chave pública como um cliente, mas você terá que converter as chaves de estilo OpenSSH para o formato Dropbear ou usar dropbearkey para criá-las.

Se você tiver uma chave privada no estilo OpenSSH ~ / .ssh / id_rsa, você precisa fazer:

dropbearconvert openssh dropbear ~ / .ssh / id_rsa ~ / .ssh / id_rsa.db dbclient -i ~ / .ssh / id_rsa.db

O Dropbear não oferece suporte a chaves de host criptografadas, embora possa se conectar ao ssh-agent.

Isso significa que se eu converter a chave privada em um dropbear chave privada, posso usar o cliente dropbear para me conectar ao servidor dropbear: 

dropbearconvert openssh dropbear id_rsa id_rsa.db

Vou tentar e ver se funciona. Mas de qualquer forma, a autenticação de chave pública do servidor deve funcionar.

Comentários

  • O servidor / configuração ssh dropbear permite o login de root? Por padrão, em vários servidores ssh, o login root não é permitido por questões de segurança.
  • Acho que sim, não ‘ não vejo nenhum arquivo de configuração em opt/etc/dropbear (apenas as chaves do host), e o parâmetro para desautorizá-lo é -w (não usá-lo).
  • Questão editada: siga as etapas para converter a chave ssh em um dropbear chave e nada (conforme observado pelo Ipor Sircer na primeira resposta).
  • Documentação encontrada no repo github (não é possível ‘ relatar lá, os problemas não estão habilitados) . Questão editada novamente. Mesmo problema ainda 🙁

Resposta

Resposta curta: Você provavelmente está executando o OpenWrt e precisa colocá-lo sua chave pública em /etc/dropbear/authorized_keys em vez de /root/.ssh/authorized_keys.

Resposta longa:

O GitHub O repo para o qual você aponta é aquele mantido pelo autor dropbear; ele diz que ~/.ssh/authorized_keys funciona e, de acordo com o GitHub, tem feito isso há pelo menos 14 anos. Olhando para o código em svr-authpubkey.c adiciona /.ssh/authorized_keys ao “pw_dir”.

Eu, no entanto , teve o mesmo problema que você e descobri que o binário fornecido no OpenWrt 18.06.1 está na verdade abrindo /etc/dropbear/authorized_keys. Usar esse arquivo funciona para mim .

Esse comportamento está documentado nos documentos OpenWrt .

Então, por que?

Dado que o código acima não pode produzir esse nome de arquivo por conta própria (o .ssh está ausente) e não há .ssh link simbólico em lugar nenhum, executei strings no binário. Isso mostrou que /etc/dropbear/authorized_keys é mencionado explicitamente, logo antes do %s/.ssh/authorized_keys que pode ser esperado do código GitHub. Concluo que o binário OpenWrt não é compilado das mesmas fontes … e, de fato, o OpenWrt corrige o código upstream com este patch . Ele muda o arquivo usado para /etc/dropbear/authorized_keys se (e somente se) o usuário alvo for root.

Já que você mencionou opkg, imagino que você também esteja usando OpenWrt, e que esse é o seu problema. Eu adicionei uma tag OpenWrt à sua pergunta.

Resposta

authorized_keys é um arquivo, não um diretório.

Um exemplo de arquivo authorized_keys: 

 # Comments allowed at start of line ssh-rsa AAAAB3Nza...LiPk== [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected]

http://man.he.net/man5/authorized_keys

Também o .ssh/ e todos os arquivos nele devem pertencer e ser lidos apenas pelo usuário, neste caso root.

Comentários

  • Acabei de consertar isso, mas ainda não tive sorte 🙁 (veja a pergunta atualizada).

Resposta

man dropbearkeys: 

NOTES The program dropbearconvert(1) can be used to convert between Dropbear and OpenSSH key formats. Dropbear does not support encrypted keys. EXAMPLE generate a host-key: # dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key extract a public key suitable for authorized_keys from private key: # dropbearkey -y -f id_rsa | grep "^ssh-rsa " >> authorized_keys

Comentários

  • Consegui converter a chave privada, mas ainda não tive sorte 🙁 (veja a pergunta atualizada).

Resposta

Você precisa criar a chave ssh usando a ferramenta dropbearkey. RSA_KEYFILE = / etc / dropbear / dropbear_rsa_host_key DSS_KEYFILE = / etc / dropbear / dropbear_dss_host_key

dropbearkey -t dss -f $ DSS_KEYFILE

dropbearkey -t rsa -f $ RSA_KEYFILE

Em seguida, reinicie o daemon dropbear. Em seguida, tente conectar, deve funcionar.

Resposta

Algumas dicas que podem ajudá-lo a se conectar usando PKI com Dropbear, este testou um contêiner baseado em pacotes Alpine Linux 3.12, conectando de um cliente OpenSSH.

  1. O usuário precisa de um shell.
  2. O usuário não precisa de uma senha de login.
  3. O usuário “s ~ não deve ser gravável em grupo / mundo (ou seja chmod 755, pelo menos; você deve usar 700 para diretórios pessoais).
  4. O usuário “s ~/.ssh e ~/.ssh/authorized_keys deve ser acessível apenas pelo proprietário (por exemplo, 700 no diretório e 600 no arquivo).
  5. Lá deve ser um diretório /tmp gravável
  6. As authorized_keys entradas estão no mesmo formato usado por OpenSSH.

Estou criando containers usando arquivos escolhidos a dedo de pacotes alpinos; Eu tenho uma imagem de aproximadamente 2 MB para a qual posso fazer SSH, desde que todos os requisitos acima sejam atendidos.

Resposta

I acabei de me deparar com essa pergunta enquanto procurava os motivos pelos quais a conexão via dropbear ao meu servidor parou de funcionar de repente (tem funcionado há meses, mas é usado apenas ocasionalmente a cada duas semanas).

a solução / explicação i finalmente encontrado foi na mensagem debug1: send_pubkey_test: no mutual signature algorithm com maior detalhamento na tentativa de conexão SSH de meus clientes, o que me levou a um artigo de solução de problemas de bitbucket .

esse artigo menciona O algoritmo RSA está sendo rapidamente descontinuado em sistemas operacionais e clientes SSH devido a várias vulnerabilidades de segurança […] como uma causa e lista como possíveis soluções alternativas ou:

  • adicionando PubkeyAcceptedKeyTypes +ssh-rsa ao arquivo cfg do cliente (use isso apenas como um solução temporária , pois é pote ncionalmente inseguro!)

  • use o algoritmo / chaves ECDSA ou ED25519. agora, com a versão dropbear presente em meu sistema, eu poderia apenas usar ECDSA, pois ED25519 me dava erros de algoritmo desconhecido no lado dropbears.

Espero que isso ajude alguém a tropeçar nesta questão como eu fiz mesmo difícil, provavelmente não é uma solução para a questão original, pls. perdoe.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *