Estou tentando obter acesso ssh ao meu roteador. Atualmente eu só tenho acesso telnet e instalei o dropbear e estou rodando (usando o opkg em um drive usb conectado ao roteador).
Desde o início, o que eu fiz foi gerar uma chave privada e descriptografá-la (já que dropbear ainda não suporta isso) e a pública:
cd .ssh
openssl genrsa -des3 -out id_rsa
openssl rsa -in id_rsa -out id_rsa
ssh-keygen -y -f id_rsa > authorized_keys
Enviei a chave pública ( authorized_keys ) para /root/.ssh . Eu coloquei o arquivo em um servidor Apache (no meu computador local) e baixei no roteador usando wget (para que o arquivo baixado receba root como dono / grupo) e então mudei as permissões para 0600 (mesmo para o cliente mas com meu usuário ).
Quando tento acessar, me ocorre um erro "Permissão negada (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 esteja interpretando mal o que a documentação ( repositório do GitHub ) diz:
Server public key auth:
You can use ~/.ssh/authorized_keys in the same way as with OpenSSH, just put the key entries in that file. They should be of the form:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwVa6M6cGVmUcLl2cFzkxEoJd06Ub4bVDsYrWvXhvUV+ZAM9uGuewZBDoAqNKJxoIn0Hyd0Nk/yU99UVv6NWV/5YSHtnf35LKds56j7cuzoQpFIdjNwdxAN0PCET/MG8qyskG/2IE2DPNIaJ3Wy+Ws4IZEgdJgPlTYUBWWtCWOGc= someone@hostname
You must make sure that ~/.ssh, and the key file, are only writable by the user. Beware of editors that split the key into multiple lines.
Dropbear supports some options for authorized_keys entries, see the manpage.
Eu fiz tudo o que diz, então não sei onde o problema poderia estar.
A documentação menciona outra maneira:
Client public key auth:
Dropbear can do public key auth as a client, but you will have to convert OpenSSH style keys to Dropbear format, or use dropbearkey to create them.
If you have an OpenSSH-style private key ~/.ssh/id_rsa, you need to do:
dropbearconvert openssh dropbear ~/.ssh/id_rsa ~/.ssh/id_rsa.db dbclient -i ~/.ssh/id_rsa.db
Dropbear does not support encrypted hostkeys though can connect to ssh-agent.
Portanto, isso me parece que, se eu converter a chave privada em uma chave privada dropbear, posso usar o cliente dropbear para conectar-me ao servidor dropbear:
dropbearconvert openssh dropbear id_rsa id_rsa.db
Vou experimentar e ver se funciona. Mas, de qualquer forma, a autenticação da chave pública do servidor deve funcionar.
authorized_keys é um arquivo, não um diretório.
An example authorized_keys file:
# 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]
Além disso, o .ssh/ e todos os arquivos contidos nele devem ser de propriedade e legíveis apenas pelo usuário, neste caso root .
homem 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
Resposta curta: provavelmente você está executando o OpenWrt e precisa colocar sua chave pública em /etc/dropbear/authorized_keys em vez de /root/.ssh/authorized_keys .
Resposta longa:
O repositório do GitHup para o qual você aponta é o mantido pelo autor dropbear; ele diz que ~/.ssh/authorized_keys funciona e, de acordo com a culpa, ele tem feito isso por pelo menos 14 anos. Observando o código em svr-authpubkey.c , ele adiciona /.ssh/authorized_keys ao " pw_dir ".
Eu, no entanto, tive o mesmo problema que você, e descobri que o binário fornecido no OpenWrt 18.06.1 é na verdade abrindo /etc/dropbear/authorized_keys . Usar esse arquivo funciona para mim.
Esse comportamento está documentado em os documentos do OpenWrt .
Então, como vem?
Dado que o código acima não pode produzir esse nome de arquivo sozinho (o .ssh está faltando) e não há nenhum .ssh symlink em lugar algum, eu corri 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 do GitHub. Eu concluo que o binário OpenWrt não é compilado a partir das mesmas fontes ... e, de fato, o OpenWrt corrige o código upstream com este patch . Ele altera o arquivo usado para /etc/dropbear/authorized_keys if (e somente se) o usuário de destino é raiz.
Como você mencionou opkg , imagino que também esteja usando o OpenWrt e que esse é o seu problema. Vou adicionar uma tag do OpenWrt à sua pergunta (se eu puder).
Isso acontece cerca de 20 meses depois da sua pergunta, mas espero que ajude!
Você precisa criar uma 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. Então tente se conectar, deve funcionar.