Re: Dropbear difficulties due to outdated version?
James, What I suggested was not to recompile dropbear for the VPS, but download and compile the same version of dropbear *on your computer* (or whatever is the machine you are using to connect to the VPC from). Then use dbclient instead of ssh to connect to the VPS. If you can write on the VPC, another thing you can do is to *cross compile* a newer version of dropbear on your PC using a toolchain for VPS, then install dropbear Regards, Fabrizio On Tue, Jun 28, 2022 at 12:52 AM James Miller wrote: > Thanks to all for your responses and apologies for the delay in > responding. I decided that perhaps including in this response output from > the ssh -v command might be the best way to proceed since answers to some > of the questions asked will be found there. Thus, the following > slightly-obfuscated and commented output: > > ### below with key-pair authentication enabled > OpenSSH_9.0p1, OpenSSL 1.1.1p 21 Jun 2022 > debug1: Reading configuration data /home/user/.ssh/config > debug1: /home/user/.ssh/config line 6: Applying options for vps > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connecting to 12.34.56.78 [12.34.56.78] port 2. > debug1: Connection established. > debug1: identity file /home/user/.ssh/MyMachine.id.rsa type 0 > debug1: identity file /home/user/.ssh/MyMachine.id.rsa-cert type -1 > debug1: Local version string SSH-2.0-OpenSSH_9.0 > debug1: Remote protocol version 2.0, remote software version > dropbear_2017.75 > debug1: compat_banner: no match: dropbear_2017.75 > debug1: Authenticating to 12.34.56.78:2 as 'user' > debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or > directory > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or > directory > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or > directory > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: algorithm: curve25519-sha...@libssh.org > debug1: kex: host key algorithm: ssh-rsa > debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 > compression: none > debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 > compression: none > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: SSH2_MSG_KEX_ECDH_REPLY received > debug1: Server host key: ssh-rsa SHA256: chars here> > debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or > directory > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or > directory > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or > directory > debug1: Host '[12.34.56.78]:2' is known and matches the RSA host key. > debug1: Found key in /home/user/.ssh/known_hosts:95 > debug1: rekey out after 4294967296 blocks > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: rekey in after 4294967296 blocks > debug1: get_agent_identities: bound agent to hostkey > debug1: get_agent_identities: agent returned 1 keys > debug1: Will attempt key: /home/user/.ssh/MyMachine.id.rsa RSA > SHA256: explicit agent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Offering public key: /home/user/.ssh/MyMachine.id.rsa RSA > SHA256: explicit agent > debug1: send_pubkey_test: no mutual signature algorithm > debug1: No more authentication methods to try. > user@12.34.56.78: Permission denied (publickey). > > ### below with key-pair authentication disabled (no -s switch under > /etc/default/dropbear config file) > OpenSSH_9.0p1, OpenSSL 1.1.1p 21 Jun 2022 > debug1: Reading configuration data /home/user/.ssh/config > debug1: /home/user/.ssh/config line 6: Applying options for vps > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connecting to 12.34.56.78 [12.34.56.78] port 2. > debug1: Connection established. > debug1: identity file /home/user/.ssh/MyMachine.id.rsa type 0 > debug1: identity file /home/user/.ssh/MyMachine.id.rsa-cert type -1 > debug1: Local version string SSH-2.0-OpenSSH_9.0 > debug1: Remote protocol version 2.0, remote software version > dropbear_2017.75 > debug1: compat_banner: no match: dropbear_2017.75 > debug1: Authenticating to 12.34.56.78:2 as 'user' > debug1: load_hostkeys: fopen /home/user/.ssh/known_hosts2: No such file or > directory > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or > directory > debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or > directory > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: algorithm: curve25519-sha...@libssh.org > debug1: kex: host key algorithm: ssh-rsa > debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 > compression: none > debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 > compression: none > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > debug1: SSH2_MSG_KEX_ECDH_REPLY
Re: Dropbear difficulties due to outdated version?
On 2022-06-25 7:49 am, James Miller wrote: I set up a small low-resource VPS a few years ago to use mainly as a light-use xmpp server. I got Dropbear operating there so I could admin it. Dropbear seemed a good choice since system resources were so anemic. I recall it being quite challenging to get key-pair authentication to finally work there, though I can't recall many details about how I finally succeeded. Most likely would be OpenSSH requiring sha2 for RSA signatures. If you can use ecdsa keys instead those should work OK. Alternatively to keep using RSA, set Host old-host HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa in your .ssh/config for the client which will allow the older sha1 RSA signatures. Which OpenSSH version is it? https://www.openssh.com/releasenotes.html has details of what has been deprecated. Matt The VPS runs Ubuntu 16.04 (EMS), so the version of Dropbear there is a bit outdated (v2017.75). Since that release was made, various changes have happened to openssh that may, I assume, make it incompatible with this version of Dropbear. I am using ssh when I try to connect to the VPS, btw.
Re: Dropbear difficulties due to outdated version?
I know I am not directly answering your question, but have you thought of building dropbear v2017.75 on your PC and use dbclient to connect (instead of ssh) to your VPS ? If you must use openssh, I would look into the ssh client settings to see if there is some sort of configurable parameters that restricts some of the functionalities (e.g. GSSAPIKexAlgorithms, HostKeyAlgorithms, ...) My 5 cents... Fabrizio On Sat, Jun 25, 2022 at 1:56 AM James Miller wrote: > I set up a small low-resource VPS a few years ago to use mainly as a > light-use xmpp server. I got Dropbear operating there so I could admin it. > Dropbear seemed a good choice since system resources were so anemic. I > recall it being quite challenging to get key-pair authentication to > finally work there, though I can't recall many details about how I finally > succeeded. > > Sometime during the interval after I set that up, key-pair authentication > has stopped working again. So I've had to re-enable username/password > authentication. I'm now trying to determine why it happened that the > key-pair authentication stopped working and am hoping I can somehow > re-enable it. > > The VPS runs Ubuntu 16.04 (EMS), so the version of Dropbear there is a bit > outdated (v2017.75). Since that release was made, various changes have > happened to openssh that may, I assume, make it incompatible with this > version of Dropbear. I am using ssh when I try to connect to the VPS, btw. > > So I'd like to start off by just asking whether the challenges I am > encountering as I try to re-enable key-pair authentication are likely > related to the version mismatch between the Dropbear I have installed on > the VPS and the much more current version of openssh I have on the home > computer from which I'm trying to connect? > > Input on that question will be appreciated. If it seems unreasonable to > expect modern versions of openssh to interoperate with a Dropbear server > dating to 2017, I will need to just give up on it and seek some other > solution. > > Thank you >
Re: Dropbear difficulties due to outdated version?
> Sometime during the interval after I set that up, key-pair authentication > has stopped working again. So I've had to re-enable username/password > authentication. I'm now trying to determine why it happened that the > key-pair authentication stopped working and am hoping I can somehow > re-enable it. You can debug most of connection issue by using ssh -v. In this case most likely culprit is that your key pair was generated using outdated algorithms which are disabled in modern OpenSSH (most likely "ssh-rsa" which was default for a long time). If this is actually the case, you can try to generate new key pair with modern algorithms supported by both OpenSSH and your version of Dropbear (I guess it should be ecdsa, as ed25519 would require newer Dropbear). -- Regards, Konstantin
