Hi Mike, in context..figured that out.
On Wed, 3 Oct 2018, Mike wrote:
Hi Karen,
Ironically, dreamhost.com does still seem to support group1 diffie hellman.
I poked at it with nmap and it listed group1 along with a bunch of old
ciphers, so that doesn't seem likely to be your problem.
Really? gosh that has me feeling better on that front at least.
Bell doesn't say they block outbound access to port 22 (this would be
quite rude) but the symptoms you describe could be explained by such a
block. You say you can't connect to anyone on port 22 anymore?
That is correct.
I could share the e-mail from my w3c source about bell. Reason why it
might impact me is because around the same time, do not ask why, bell had
set my modem for an internal network ip addresss of theirs.
If the incoming is impacted, it might be the cause. It is odd that it
started on a particular day that Bell told me they had an issue.
>
You say you can still connect to a host at - is it Scientific Linux?
Is that port 22?
Let me explain this better as it speaks to how I tested.
because shellworld.net uses an alternate port from port 22, yet is also
using the same edition of Ubuntu for their shell that Dreamhost uses, my
first effort was to test places where the port could be different.
my command line looks like this
ssh2d386 -B username placeiamgoing.com
For Dreamhost, that place is my office, curtainupdistribution.org
the -B makes the screen talk without extra steps.
I can add a -p for port and change it,
and use a -g which tries the dh key g1, in case the default key is not
allowed..will have to check what the default key is honestly.
So I asked individuals with servers to create an account for me to test.
I joined pair network for a while <terrific company> but they could not
provide a port other than 22.
However on the few attempts where I could change the port to somewhere
else, I could log in.
These were simple options.
Lastly I joined a service called Eskimo, which offers several different
Linux distributions for the same account shell wise.
This is the only place where I could use port 22, but this was not
consistent. Scientific Linux 6 but not 7 centos 6 but not 7, and
nothing else no Debian for example.
Lots of details, but I hope that makes more sense.
You also mention that the shellworld host is at a port other than 22...
That is correct,
for example my command line for shellworld is something like.
ssh2d386 -g -B -p different port number klewellen shellworld.net
when I add the different port it works fine as this e-mail shows.
As technical background, regarding SSH and keys: as others have
mentioned, DH is used to exchange session keys in order to establish a
private connection - only after that are your user public / private
key pair used to authenticate you as a user.
That is understood, my example above should make that more clear.
When I add the -v command to places where I have issues the details state
say the edition of openssh a remote host is using, the edition of ssh 2.0
or so that my client is using.
The error comes after I the keys are exchanged, Stating that the
exchange failing and the error stating that
the host has closed the connection.
However when I could get logs from my testing, most did not even show my
attempts, which is again part of why I still suspect a bell issue.
Thanks for providing more wisdom Mike and Everyone,
Kare
On 10/2/18, Karen Lewellen <[email protected]> wrote:
No,
It is opensource now with the author having moved on.
that means likely my hunting for someone to compile.
I am told that the djpgg project includes security keys that are more
current, with the possibility existing I hope for upgrading that way.
The client has some putty components but putty is not opensource I
understand.
Checking for an upgrade was my first step some months back.
Kare
On Tue, 2 Oct 2018, Mike wrote:
Hi Karen,
SSH has seen a lot of activity in the past couple of years, with
vulnerabilities published against various algorithms and standard
advice to stop using them. It's possible that all those servers have
also deprecated group 1 (only a 768 bit key). Group 14 is the minimum
considered acceptable these days (2048 bit key).
Is it possible that the author of the SSH client you are using has
updated the software?
On 10/2/18, Karen Lewellen <[email protected]> wrote:
Hi Mike,
Thanks for that information.
I would feel better though if the same problem was not happening
practically everywhere else.
i can check my list, I believe, but imagine it will take someone skilled
in compiling to update anything.
Meaning I will need to either find that skill, or move our office
hosting
services somewhere equal to dreamhost but less paranoid.
Thanks again,
On Tue, 2 Oct 2018, Mike wrote:
Hi Karen,
I found a reference at Dreamhost wherein a user says that Support hold
him that "diffie-hellman-group1-sha1 was recently removed for security
concerns". This is 26 days ago. The reference URL is:
https://discussion.dreamhost.com/t/ssh-issue-with-key-exchange-algorithms/68804
It may be that your SSH client does not support newer DH modes, for
example group 14. Is there a way you can find out what key exchange
modes and ciphers your SSH client supports?
Regards,
Mike
On 10/2/18, Karen Lewellen via talk <[email protected]> wrote:
Hi folks,
The accessible ssh client I use provides a way to send dh keys when I
use
ssh TELNET to reach a location.
I have a bell dsl account, and since the first of July I have not been
able to reach dreamhost who hosts my office shell.
While I have not ruled out Bell as the problem, it started one day
when
they claimed to have a service interruption, and refuse to discuss
Linux
at all, I want to see if something else might have happened.
With very few exceptions, every place where I visit involving port 22
presents the same dh key exchange failure.
Was openssh updated on June 29 2018?
Hosting companies who use some different Linux options for their
shell
services, scientific for example, still work. Shellworld does too,
but
we
use a different port for ssh and the administrator still allows most
public keys.
can anyone provide wisdom here?
Thanks,
Karen
---
Talk Mailing List
[email protected]
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
[email protected]
https://gtalug.org/mailman/listinfo/talk
