Re: Nettle can't SSH into RaspPi

[druck]

On 25/07/2023 18:43, Bob Latham wrote:
> RISCOS 5.29
> Nettle v0.2043b
> Raspberry pi: Raspberry Pi OS lite
>
> I have several raspberry pi devices running the standard OS not
> RISCOS. Using Putty.exe on a PC I can SSH into the pi just fine but I
> can't manage this with Nettle.
>
> In Nettle I get this error..
>
> Nettle: SSH connection failed in step 0: Unable to exchange
> encryption keys.

There's two ways around this, the first and best is to get hold of a
more recent version of the command line ssh port for RISC OS, which
supports modern key exchange types. There is one out there somewhere as
I'm using it.

The other alternative is to check which key exchange mechanisms your
version is offering using the -vv option, then make an exception on the
Linux machine to support this old method - luckily you can make it
specific to your RISC OS machine(s) IP address, so you aren't opening up
a massive vulnerability to everyone.

I can provide more details if pressed.

> However, I can use Nettle to access my Synology NAS and that works
> fine.

It probably supports all the old cypher suites which everyone else
considers too risky to use, and SMBv1 too. When was the last time the
firmware was updated? Although even then they more likely to leave old
stuff enabled than to break anything customers might still be using.

---druck

[Brian Howlett]

On 25 Jul, Bob Latham <b...@sick-of-spam.invalid> wrote:

> RISCOS 5.29
> Nettle v0.2043b
> Raspberry pi: Raspberry Pi OS lite

> I have several raspberry pi devices running the standard OS not
> RISCOS. Using Putty.exe on a PC I can SSH into the pi just fine but I
> can't manage this with Nettle.

> In Nettle I get this error..

> Nettle: SSH connection failed in step 0: Unable to exchange
> encryption keys.

> I can't find a way passed this error.

> However, I can use Nettle to access my Synology NAS and that works
> fine.

> Any advice?

There's a version of Nettle called NettleSSH updated by Gerph, but the
site it was hosted on is gone. I did a quick search, but couldn't find it
anywhere else.

The version I have is from 2002, but it may not have been developed any
further; it was clearly labelled as Beta software.

Of course, this could be the version you are using, and the Help page says
it is SSH1, which may need to be enabled on the Pi before it will connect.
--
Brian Howlett - Email to From: address deleted unseen
---------------------------------------------------------
Now is the time for all good men to come to. (Walt Kelly)

[Theo]

Brian Howlett <news-s...@brianhowlett.me.uk> wrote:
> There's a version of Nettle called NettleSSH updated by Gerph, but the
> site it was hosted on is gone. I did a quick search, but couldn't find it
> anywhere else.
>
> The version I have is from 2002, but it may not have been developed any
> further; it was clearly labelled as Beta software.

I wrote something called SSHProxy that is very very old, and I think Gerph
turned that into NettleSSH. But that's all SSHv1 which servers won't
support these days as it's insecure:

http://gerph.org/riscos/ramble/miniprojects-nettlessh.html#NettleSSH

Later support was added to Nettle directly, and that is more modern and
supports SSHv2.

> Of course, this could be the version you are using, and the Help page says
> it is SSH1, which may need to be enabled on the Pi before it will connect.

Using Nettle's own SSH implementation (which uses libssh2) is the way
forward these days. That's the one Gerph has contributed to recently:
https://github.com/dpt/Nettle/

I think it should need a recompile with a newer libssh2 for newer cipher
support. There is infrastructure there to build it using his
JFPatch-as-a-service, but I'm not sure if those builds are made available
anywhere.

Either way, the build made available in PackMan (and also downloadable from
riscos.info for manual install) should be updated. I'll take a todo to look
at that, but no promises on timeline...

Theo

[druck]

On 26/07/2023 09:29, Bob Latham wrote:
> In article <u9pbmu$1716r$1...@dont-email.me>,

> druck <ne...@druck.org.uk> wrote:
>> On 25/07/2023 18:43, Bob Latham wrote:
>>> RISCOS 5.29
>>> Nettle v0.2043b
>>> Raspberry pi: Raspberry Pi OS lite
>>>
>>> I have several raspberry pi devices running the standard OS not
>>> RISCOS. Using Putty.exe on a PC I can SSH into the pi just fine but I
>>> can't manage this with Nettle.
>>>
>>> In Nettle I get this error..
>>>
>>> Nettle: SSH connection failed in step 0: Unable to exchange
>>> encryption keys.
>
>> There's two ways around this, the first and best is to get hold of
>> a more recent version of the command line ssh port for RISC OS,
>> which supports modern key exchange types. There is one out there
>> somewhere as I'm using it.
>

> I've done a comprehensive search for this but all links seem to be
> dead. :-(

I've had a look at my RISC OS machine, and it seems I'm using !Nettle
v0.2043b (11 April 2010) built in ssh client, which is mentioned later
in the thread, and this does work - so get that unless you want to get
involved technical stuff below.

BTW It's a bit confusing as I initially used Nettle and command line
ssh, then NettleSSH came along with a built in ssh. However this stopped
working with Linux machines, so I went back to Nettle with a newer
command line ssh again. Forgot the latest Nettle has a newer ssh built
in like NettleSSH used to.

I've checked both the command line ssh clients I've found on my systems,
neither of which work on the Pi 4B, although they run on the Mini.M
(versions 6.0p1-1 16-Aug-2012 and 3.8.1p1)

> I've no idea where to enter the -vv command and experimenting has
> only given embarrassing results. So info on that please and how to
> modify my Pi devices please.

If you are using the command line client you do a:-

ssh -vvv <host name>

It will then print out lots of stuff about what it is doing. At some
point it will say what key exchange mechanisms it offers and the server
accepts, and these will differ and it will stop shortly after. Find that
bit and paste it here.

---druck

[Theo]

druck <ne...@druck.org.uk> wrote:
> I've had a look at my RISC OS machine, and it seems I'm using !Nettle
> v0.2043b (11 April 2010) built in ssh client, which is mentioned later
> in the thread, and this does work - so get that unless you want to get
> involved technical stuff below.

What are you testing against, OOI? The change in not accepting certain RSA
keys and some ciphers took effect in OpenSSH 7 (I think) which appeared in
Ubuntu 22.04, and I presume whatever Debian version that was based upon. So
if you're running an older OS on the Pi you might be OK with an older
client, and you would only notice this if you upgraded to a newer OS on the
Pi.

However where I've seen this is newer clients talking to older servers, not
so much older clients talking to newer servers. So it may not have been
related to that change.

> BTW It's a bit confusing as I initially used Nettle and command line
> ssh, then NettleSSH came along with a built in ssh. However this stopped
> working with Linux machines, so I went back to Nettle with a newer
> command line ssh again. Forgot the latest Nettle has a newer ssh built
> in like NettleSSH used to.
>
> I've checked both the command line ssh clients I've found on my systems,
> neither of which work on the Pi 4B, although they run on the Mini.M
> (versions 6.0p1-1 16-Aug-2012 and 3.8.1p1)

They should probably be rebuilt since upstream is on OpenSSH 9.3 now. I'm
not sure of the status of the GCCSDK autobuilder builds and whether they're
buildable or how broken things are.

Likewise the builds of PuTTY floating around are very out of date too.

> If you are using the command line client you do a:-
>
> ssh -vvv <host name>
>
> It will then print out lots of stuff about what it is doing. At some
> point it will say what key exchange mechanisms it offers and the server
> accepts, and these will differ and it will stop shortly after. Find that
> bit and paste it here.

Something like:

debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ecdsa-sha2-nis...@openssh.com,ssh-ed2551...@openssh.com,ssh-rsa-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
...
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
...

For example, we said we could do key exchange algorithms A/B/C/D/E and host key
algorithms X/Y/Z, and the server said it can do CDFG and TUZ, so they have to
pick one of C or D and only Z as those are the only common algorithms we can
agree on.

The problem in question being that our client said we can do ABCD and the
server said it can do GHIJ but there's nothing in common, so we have to
specifically tell the server to use older insecure algorithms C or D so it
can allow the connection.

The recent update to OpenSSH was changing the default set of allowed host
key algorithms so that older algorithms were removed from the list, which
makes a problem for communicating with older clients.

Theo

[Theo]

Bob Latham <b...@sick-of-spam.invalid> wrote:
> In article <J9j*LW...@news.chiark.greenend.org.uk>,

> Theo <theom...@chiark.greenend.org.uk> wrote:
>
> > Using Nettle's own SSH implementation (which uses libssh2) is the
> > way forward these days. That's the one Gerph has contributed to
> > recently: https://github.com/dpt/Nettle/
>
> > I think it should need a recompile with a newer libssh2 for newer
> > cipher support. There is infrastructure there to build it using
> > his JFPatch-as-a-service, but I'm not sure if those builds are made
> > available anywhere.
>

> > I'll take a todo to look at that, but no promises on
> > timeline...
>

> Thanks for that Theo.

That was less painful than I thought. Here is a test build:
http://www.chiark.greenend.org.uk/~theom/ephemeral/Nettle_0-2050b-1_arm.zip

This is a rebuild with a much more modern libssh2 than the one from 2010.

Please give this a try and let me know if it fixes the problem. I have a Pi
running Raspberry Pi OS 'bullseye' and both this one (I'm tentatively
calling it 0.2050b but that's not official) and 0.2043b managed to
SSH in successfully, but this one went through much more quickly while
0.2043b printed several screenfuls of dots (I suspect they were
arguing over which ciphers to support).

If it's looking good I'll upstream the changes and if that's all happy I'll
put a new version on riscos.info where PackMan should pick it up.

Theo

[druck]

On 27/07/2023 09:58, Bob Latham wrote:
> In article <u9rvvi$1i3np$1...@dont-email.me>,

> druck <ne...@druck.org.uk> wrote:
>> On 26/07/2023 09:29, Bob Latham wrote:
>
>> I've had a look at my RISC OS machine, and it seems I'm using
>> !Nettle v0.2043b (11 April 2010) built in ssh client, which is
>> mentioned later in the thread, and this does work - so get that
>> unless you want to get involved technical stuff below.
>

> That is the exact version I'm trying to use. Works with synology NAS
> DSM6 but cannot get into pi os.

Which Pi OS? Mine are all on the current Raspbian Bullseye.

---druck

[druck]

On 27/07/2023 20:23, Bob Latham wrote:
> I can indeed ssh into my pi with this latest build [of Nettle]
> all be it with many lines of dots first.

Well that's something.

> One slight oddity though which is probably going to show my ignorance
> more than anything else.
>
> When you log in, is shows the usual default..
> pi@name:~$
>
> But it became clear very quickly that in fact it was at..
> pi@name:~/home/pi~$

'~' is an abbreviation for the users home directory, which with the
default username of pi will be /home/pi

> I don't think it's possible to get above that into the root and then
> into boot or etc.

You need to do have root privileges to get in to /root, do a

sudo -i

But be careful! Ctrl+D to return to a normal user.

/boot can be accessed but not writen to by a user, to write become root.

> Why would it do that, putty.exe doesn't?

Putty doesn't do what?

---druck

[Theo]

Bob Latham <b...@sick-of-spam.invalid> wrote:
> I can indeed ssh into my pi with this latest build all be it with

> many lines of dots first.
>

> Well done and thank you. Greatly appreciate what you've done.

That's good. I've made a pull request to the upstream repository (ie asked
them to accept my changes).

> One slight oddity though which is probably going to show my ignorance
> more than anything else.
>
> When you log in, is shows the usual default..
> pi@name:~$
>
> But it became clear very quickly that in fact it was at..
> pi@name:~/home/pi~$

~ is a shortcut for your home directory, eg /home/pi if you are the 'pi'
user (the default on Pi OS)

~bob is a shortcut for the home directory of user bob, eg /home/bob

As an aside, the same goes for URLs, eg in:
https://www.chiark.greenend.org.uk/~theom/ephemeral/Nettle_0-2050b-1_arm.zip

~theom is the (web) home directory for user 'theom'.

> I don't think it's possible to get above that into the root and then
> into boot or etc.

You can cd to change directory, ie:

cd /etc

As druck says, some places you can't cd as a normal user, you need to use
'sudo'. Or you can cd but you can't edit any files.

> Why would it do that, putty.exe doesn't?

Maybe Putty is doing a cd command for you? I'm not sure why you would land
in a different place otherwise.

One other thing to note is the 'pi@name:~$' is called your shell prompt, and
you can change it via an environment variable PS1:
https://wiki.archlinux.org/title/Bash/Prompt_customization

For example, I can type:
PS1="\$(date) \$(pwd) : "

and now the prompt looks like this, with the time and current directory
shown in full:

Thu 27 Jul 21:48:35 BST 2023 /home/pi :
Thu 27 Jul 21:49:00 BST 2023 /home/pi :
Thu 27 Jul 21:49:01 BST 2023 /home/pi : cd /
Thu 27 Jul 21:50:02 BST 2023 / :

> I'm most grateful for you efforts but I don't really understand what
> it's doing.

If you need a place to ask for help on the Pi OS side, I can recommend the
newsgroup comp.sys.raspberry-pi

Theo

[Theo]

Bob Latham <b...@sick-of-spam.invalid> wrote:
> In article <5acaae...@sick-of-spam.invalid>,

> Bob Latham <b...@sick-of-spam.invalid> wrote:
>
> > I can indeed ssh into my pi with this latest build all be it with
> > many lines of dots first.
>

> Would I be right in thinking I'm expecting too much for sudo
> raspi-config to work? You get a menu but can't use anything.

Hmm, that's puzzling. There's several things going wrong that I can see.

First of all, Nettle defaults to vt220 terminal. If you choose xterm-color,
you get colours. You can tell Nettle to remember that in settings.

Second, on my setup the Pi defaults to UTF-8 character set, but ZapRedraw in
Nettle is defaulting to ISO8859-1. This means the box drawing is messed up.
You can fix that by running on the Pi:

sudo dpkg-reconfigure locales

and select en_GB.iso8859-1 to install. Once installed, run

export LANG=en_GB.iso8859-1

in your SSH session, then you can 'sudo raspi-config'. Now the box drawing
should work.

But the thing I can't work out is why the Return key doesn't work, so you
can't choose any options. I ran a terminal debugger
(/usr/lib/ncurses/examples/demo_altkeys after installing the
ncurses-examples package) and both Return and keypad Enter are sending the
newline character (10, ^J), which is the same as my Linux laptop (both
natively and SSHed into the same Pi). So puzzled as to why Nettle isn't
working.

I'll continue to ponder in search of ideas as to what might be wrong...

Theo