Setting up ssh on Pandora

[levi]

I'm trying to secure down my network at the moment, but I'm having difficulty getting my pandora to connect using ed25519 keys.

I can connect over the network using ssh/scp and a password, but I want to get away from that, and connect using keys instead.  The Pandora doesn't have ssh-keygen installed, so I had to generate my keys on another machine and scp them over.  It doesn't seem to pick up ~/.ssh/id_ed25519 automatically, but I can pass it to the command line via the -i argument (with scp at least) and it asks for the password to unlock it.  However if I enter the correct or incorrect password it makes no difference, it asks again, and after three attempts it tells me permission is denied (pubkey).

I next tried using a dsa key, in case the Pandora's sshd was so old it didn't accept ed25519 keys, but it still doesn't seem to pick up my id_dsa automatically, and if forced to use it it immediately tells me permission is denied, and doesn't even ask for a password.

What's annoying is I'm sure I had this working with ed25519 keys on SZ1.71, but I forget to back up my keys before reflashing, so I'm trying to set it up again.

I think I've configured my server correctly fwiw.  All I've done for this is deny logging on with a password in /etc/sshd_config and I've added the public keys to my authorized_keys file.

 

[Linux-SWAT]

You may try to connect with ssh -vv to have a bit of verbosity.

 

[levi]

Thanks for the suggestion.  On my Pandora I get (after a bunch of startup debug lines):

Debug1: Trying private key: id_ed25519
Debug1: PEM_read_PrivateKey failed
Debug1: Read PEM private key done (type = none)
Enter passphrase for key 'id_ed25519':
Debug1: PEM_read_PrivateKey failed
Debug1: Read PEM private key done (type = none)
Debug2: Bad passphrase entered, try again...
Enter passphrase for key 'id_ed25519':

On the server I just get:

Oct 17 13:19:35 server sshd[1070]: Connection closed by 192.168.1.5 [preauth]

I guess this happens once I quit out of the password entry (or it fails after three attempts).

FWIW, if I don't pass the -i argument to ssh to specify my ed25519 key, it only seems to look for id_rsa in my .ssh directory.  That made me think perhaps it was only implementing ssh protocol version 1 connections, but even if I specify -2 on the command line, it still only looks for the rsa key then fails.  If I specify -2 and -i to my ed25519 key, it looks like the initial log, and fails.  Thinking further, I realised it would be looking for ~/.ssh/identity (not id_rsa) if it was implementing protocol 1.

So I tried generating an rsa keypair (protocol 2 version), and once I'd got that installed correctly, it seems to have worked - and I guess that's probably sufficient for my purposes.  It's still something of a mystery why ssh/scp on my Pandora can't read ed25519 keys or dsa keys, only rsa keys.  I note my ssh_config file specifies the file id_rsa to look for, but it also specifies id_dsa, and I couldn't get that to work, and it looks like it's not a problem of it looking for the wrong file anyway, since if I specify -i I can override this setting, and it still can't load any dsa or ed25519 keys.

Thanks again for the suggestion - those extra logs really helped me get a handle on what was going on.

 

[Linux-SWAT]

Np, there's a neat article about ssh speaking about ed25519 :
https://stribika.github.io/2015/01/04/secure-secure-shell.html

 

[Galaxis]

I would be very surprised if ssh on the Pandora knew of ed25519: The client is an ancient OpenSSH 5.6 (2010), and ed25519 support didn't show up in OpenSSH until about 2013. It's about the same with the ssh server (dropbear) being used.

 

[levi]

Hmm, that's worth knowing.  Actually, checking on my backups, it seems I had a public RSA key associated with my Pandora in my old authorized_keys file, so that must be how I did it. But I should still be able to get dsa keys and others to work.  What's the least hackable key type I can try with that version of openssh also?

Hmm, doing some research of old stackoverflow questions, it looks like it might just be rsa with a big key

 

[Galaxis]

Yeah, long RSA key for authentication, a good symmetric cipher, encrypt-then-MAC hash. The article Linux-SWAT linked to above has recommendations for good fallback defaults even when Elliptic Curves are not used.

The sad thing is that ed25519 / chacha20-poly1305 would be more efficient than RSA / AES on a device with limited CPU power, like the Pandora.
 

 

[levi]

The Pandora's not really the sort of limited platform those articles refer to I suspect - they talk about ARM cores running at dozens of MHz.  In my experience, sshing in from my Pandora doesn't take too long at all.

I'll have to go through that article again, especially when configuring my server which starts sshd at boot (although I generally only turn that machine on when I need it). Theoretically, the firewall in my router should block any external connections (and I check for them in the logs periodically), but I still have to guard against a man-in-the-middle type attack by a compromised device though, I guess.