On 12/26/19 6:35 AM, Stuart Henderson wrote:
On 2019/12/25 21:02, Steve Sether wrote:
Basically I've had to turn on telnet access again, lowering security.
Does it really lower security? The very old embedded OS is not going to
be secure anyway, this type of device should only be used on a trusted
private network. (New embedded OS are often not much better so I'd take
the same view there).
The RNG used to generate the key is probably rubbish too - I don't expect
there to be all that much entropy in those 768 bits..
Not being able to use ssh is an annoyance but there are trade-offs to be
made when using old hardware. The way I deal with these is to use telnet
from a console server / "jump box" which itself runs modern sshd.
For me personally? No. This is my home device, and I'm not really all
that worried. For a lot of companies in the world? Absolutely. This is
primarily because it's extremely common to re-use administrator
passwords. Sniff some network traffic and raise your privilege level.
I think most people agree that the perimeter defense is not something
you should rely on, and to use encryption inside your own network. I
understand that one can perform mitigations to lower the risk, but it
just doesn't make sense to me that openSSH has decided to not support this.
I've no doubt that someone could (likely) hack into the APC-UPS device
with enough effort. I don't personally know of any vulnerabilities for
this device, (and I did just check). So hacking into it would take some
effort, finding an exploit, writing some kind of means to obtain a
password from the device, etc. Sniffing telnet and doing ARP poisoning
attacks and the like is pretty trivial by comparison. These are well
known ways to obtain passwords that have been around for 20+ years, and
the very reason ssh was invented in the 90s.
Someone here suggested generating a 1024 bit RSA key offline and
uploading it. That's exactly what I tried doing, and the APC rejected
it. I suspect because, as you say below, the CPU isn't powerful enough
for a 1024 bit key.
To me, not providing a way to over-ride the minimum key size is just a bit
heavy-handed. The vendor doesn't support this device anymore, and it's
failed all attempts at replacing the 768 bit key with a 1024 bit one.
The APC devices I used struggled with even a 768-bit key, I suspect
handling numbers 2^256 times larger will be too hard on the CPU.
I note that other legacy, potentially insecure options are supported via
configuration changes. https://www.openssh.com/legacy.html
Most of these (though not ssh-dss) relate to per-session keying.
I think you can get away with a bit more weakness there (which would
have to be attacked while the session is active and before rekeying)
whereas short host keys are more of a long term risk.
Note that other things were removed with no fallback available (also
with good reason) - SSH1 for example.
ssh1 I can certainly understand, primarily because maintaining the
protocol requires maintenance. I don't see a huge amount of maintenance
in a config option for minimum key size. I also don't know that I've
seen a device that only supports SSH1. IIRC ssh2 came out in something
like 1996, shortly after ssh1. I'm not even sure if ssh1 really gained
much popularity, since those early days it was just Tatu with his idea
of encrypted telnet.
I guess my main problem with setting this hard-coded is that it puts a
LOT of control in the hands of the developers, and little or no control
in the system administrators. i.e. "We Know What's Good For You!".
Well, not for everyone. One size rarely fits all.
Why isn't the
same true for a minimum key size? This device isn't exactly ancient at
around 12 years old and a 10 year old firmware. I'd imagine there's other
hardware that has limited support for ssh key sizes that the current
openssh won't connect to anymore.
The other place I've seen it is on old switches but there is usually
less reason to keep them than old power control hardware.
I'd rather not dredge up a big fight, but I _would_ like to express a
desire for some form of overriding the minimum key size.
This can be done by recompiling if necessary. This restriction has been
a pain for me at times but honestly I think it's for the best that it's
been done.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
