[GTALUG] dh key exchange question.

[Karen Lewellen via talk]

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
***@gt

[Mike via talk]

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

Post by Karen Lewellen via talk
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
https://gtalug.org/mailman/listinfo/talk

---
Talk Mailing List
***@gtalug.org
https

[Karen Lewellen via talk]

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,

Post by Mike via talk
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
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

Post by Karen Lewellen via talk
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
https://gtalug.org/mailman/listinfo/talk

[Mike via talk]

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?

Post by Karen Lewellen via talk
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,

Post by Mike via talk
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
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

Post by Karen Lewellen via talk
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
https://gtalug.org/mailman/listinfo/talk

---
Talk Mailing List
talk

[Karen Lewellen via talk]

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

Post by Mike via talk
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?

Post by Karen Lewellen via talk
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,

Post by Mike via talk
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
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

Post by Karen Lewellen via talk
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
https://gtalug.org/mailman/listinfo/talk

[Mike via talk]

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.

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?

You say you can still connect to a host at - is it Scientific Linux?
Is that port 22?
You also mention that the shellworld host is at a port other than 22...

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.


Cheers,
Mike

Post by Karen Lewellen via talk
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

Post by Mike via talk
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?

Post by Karen Lewellen via talk
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,

Post by Mike via talk
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
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

Post by Karen Lewellen via talk
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
https://gtalug.org/mailman/listinfo/talk

---
Talk Mailing List
***@gtalug.org
https://gtalug.org/mailman/listin

[Karen Lewellen via talk]

Hi Mike, in context..figured that out.

Post by Mike via talk
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.

Post by Mike via talk
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.

Post by Mike via talk
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.

Post by Mike via talk
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.

Post by Mike via talk
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

Post by Mike via talk

Post by Karen Lewellen via talk
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

Post by Mike via talk
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?

Post by Karen Lewellen via talk
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,

Post by Mike via talk
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
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

Post by Karen Lewellen via talk
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
https://gtalug.org/mailman/listinfo/talk

---
Talk Mailing List
ta

[Christopher Browne via talk]

Post by Karen Lewellen via talk
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,

Unfortunately, I suspect that "less paranoid" isn't the right answer.

Older algorithms (and variants) are being deprecated because weaknesses
have been found in them.

In this particular case, the "group 1" Diffie Hellman algorithm was discovered
to have vulnerability to a particular class of attacks called "Logjam".
https://weakdh.org/
That web site points to some of the research work from 2015.

OpenSSH documentation references this:
https://www.openssh.com/legacy.html

They describe the opposite scenario to what you are experiencing; they
indicate the situation where a server is willing to accept
diffie-hellman-group1-sha1, where the client, being on a newer version
of OpenSSH, refuses to offer that. If that was the situation you were
experiencing, you could change the configuration of your SSH client to
accept lower-grade forms of encryption.

Unfortunately, for your purposes, it appears likely that what has
happened is that dreamhost has upgraded to a more recent version of
OpenSSH, and has taken the recommendation by the developers that
deprecated algorithms should not be accepted. In principle, dreamhost
could change their OpenSSH configuration to accept use of
diffie-hellman-group1-sha1, but I expect that they would be reluctant
to do this.

I work in an area where we have a lot of Java-based applications; we
wind up having regular efforts to ensure that applications are ported
to newer versions of Java for much the same reason, because the older
crypto algorithms supported by SSL libraries are being deprecated
because weaknesses have been found. It's not good enough to suppress
paranoia; organizations that ignore the weaknesses wind up getting
bitten by attackers that use these weaknesses to steal data, often
including users' passwords. It's really no fun to need to announce
that all the customers need to change their passwords because they
have gotten stolen.

I appreciate that it may be challenging to keep up with the
cryptographic "arms race"; unfortunately, the world is a sufficiently
hostile place that there seems to be no way around this. You need to
be prepared to update your ssh keys often enough to keep up with
changes in SSH.

Feel sorry for those using SSL for web server applications; Giles Orr
did a talk a few months back that made it clear that keeping up with
crypto changes is a messy and thankless task.

[Karen Lewellen via talk]

Hi,
Your tag line gave me the Giggles!
Here at shellworld while using the latest Ubuntu, they addressed the
problem security wise by moving our
port, in addition to allowing this key to remain.
Still, indeed when asked dreamhost said no, I am not their only customer
to be sure.
When seeking an alternative I came across a service called Eskimo.
They incorporate more than one Linux distribution, I could say use centos 6
but not centos 7 or Scientific 6 but not say mint.
That gave me hope that if I kept hunting I would find a company who either
allowed for a different ssh port, since that works here at shellworld and
one other test, or that I might find a back door in.
The Dreamhost door being closed means no sftp of files and things either.
Thanks for the great wisdom though. Bell just started screaming at the
word Linux so I did not get far. Add that I got some w3c information
indicating Bell had blocked port 22, and I stayed hopeful.
thanks again,
Karen

Post by Christopher Browne via talk

Post by Karen Lewellen via talk
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,

Unfortunately, I suspect that "less paranoid" isn't the right answer.
Older algorithms (and variants) are being deprecated because weaknesses
have been found in them.
In this particular case, the "group 1" Diffie Hellman algorithm was discovered
to have vulnerability to a particular class of attacks called "Logjam".
https://weakdh.org/
That web site points to some of the research work from 2015.
https://www.openssh.com/legacy.html
They describe the opposite scenario to what you are experiencing; they
indicate the situation where a server is willing to accept
diffie-hellman-group1-sha1, where the client, being on a newer version
of OpenSSH, refuses to offer that. If that was the situation you were
experiencing, you could change the configuration of your SSH client to
accept lower-grade forms of encryption.
Unfortunately, for your purposes, it appears likely that what has
happened is that dreamhost has upgraded to a more recent version of
OpenSSH, and has taken the recommendation by the developers that
deprecated algorithms should not be accepted. In principle, dreamhost
could change their OpenSSH configuration to accept use of
diffie-hellman-group1-sha1, but I expect that they would be reluctant
to do this.
I work in an area where we have a lot of Java-based applications; we
wind up having regular efforts to ensure that applications are ported
to newer versions of Java for much the same reason, because the older
crypto algorithms supported by SSL libraries are being deprecated
because weaknesses have been found. It's not good enough to suppress
paranoia; organizations that ignore the weaknesses wind up getting
bitten by attackers that use these weaknesses to steal data, often
including users' passwords. It's really no fun to need to announce
that all the customers need to change their passwords because they
have gotten stolen.
I appreciate that it may be challenging to keep up with the
cryptographic "arms race"; unfortunately, the world is a sufficiently
hostile place that there seems to be no way around this. You need to
be prepared to update your ssh keys often enough to keep up with
changes in SSH.
Feel sorry for those using SSL for web server applications; Giles Orr
did a talk a few months back that made it clear that keeping up with
crypto changes is a messy and thankless task.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

---
Talk Mailing List
talk@

[Giles Orr via talk]

Post by Karen Lewellen via talk
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

Many technical answers have been given. I would suggest starting with some
simple debugging.

$ telnet dreamhost.com 22

These days, a lot of distros don't have 'telnet' installed because it's
considered insecure. And they're not wrong - but it's also very useful for
debugging. So install it if it's not available. Then try the above
command line, which asks telnet to try to connect to dreamhost.com on port
22 (which is the standard SSH port). (You should use whatever host name
you would normally SSH to, which may be "someotherhost.dreamhost.com.")
This is a connection that can't be completed, but it can still tell you
something. If someone in between is blocking port 22 (most likely Bell,
but could be any intervening firewall possibly on your own machine or at
your office), this attempt will fail entirely. If, however, port 22 is
available, you should see something like this:

$ telnet dreamhost.com 22
Trying 192.237.213.194...
Connected to dreamhost.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.10

This means you can reach your desired host over port 22, and the problem is
something else (such as all the technical stuff that's already been
discussed). I just think it's good to start here.

P.S. telnet has now left you stranded: as it suggests, hit Control-] (the
close square bracket) and then type 'quit' at the 'telnet>' prompt.

P.P.S. Looks like Dreamhost's main machine is using a very old version of
SSH ... 7.4 is current.

[Karen Lewellen via talk]

Thanks for these suggestions, but I do not have a Linux box. I use ssh
telnet to reach a Linux shell.
I have been debugging since Late June, with others here at least letting
me know the problem may be due to locations removing access to my keys
as dreamhost has done.
thanks though,
Karen

Post by Giles Orr via talk

Post by Karen Lewellen via talk
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

Many technical answers have been given. I would suggest starting with some
simple debugging.
$ telnet dreamhost.com 22
These days, a lot of distros don't have 'telnet' installed because it's
considered insecure. And they're not wrong - but it's also very useful for
debugging. So install it if it's not available. Then try the above
command line, which asks telnet to try to connect to dreamhost.com on port
22 (which is the standard SSH port). (You should use whatever host name
you would normally SSH to, which may be "someotherhost.dreamhost.com.")
This is a connection that can't be completed, but it can still tell you
something. If someone in between is blocking port 22 (most likely Bell,
but could be any intervening firewall possibly on your own machine or at
your office), this attempt will fail entirely. If, however, port 22 is
$ telnet dreamhost.com 22
Trying 192.237.213.194...
Connected to dreamhost.com.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.10
This means you can reach your desired host over port 22, and the problem is
something else (such as all the technical stuff that's already been
discussed). I just think it's good to start here.
P.S. telnet has now left you stranded: as it suggests, hit Control-] (the
close square bracket) and then type 'quit' at the 'telnet>' prompt.
P.P.S. Looks like Dreamhost's main machine is using a very old version of
SSH ... 7.4 is current.
--
Giles
https://www.gilesorr.com/

---
Talk Mailing List
***@gtalug.org

[D. Hugh Redelmeier via talk]

| From: Karen Lewellen via talk <***@gtalug.org>

| Thanks for these suggestions, but I do not have a Linux box. I use ssh telnet
| to reach a Linux shell.

I'm not sure what "ssh telnet" is. What software are you actually
using on your Windows machine? Putty?

| I have been debugging since Late June, with others here at least letting me
| know the problem may be due to locations removing access to my keys as
| dreamhost has done.

The terminology of crypto is kind of confusing. One confusing thing is
the word "key": there are two distinct kinds of keys used by SSH.

Normally, the keys you manipulate for SSH are a private key (that you
usually keep only on your local machine) and a corresponding public
key that you put everywhere that you might want to log into.
These two keys are a pair and you cannot mix and match from other key
pairs. You generally think of these keys as close to permanent.

The DH (DIffie-Hellman) exchange is something done by SSH
autonomously, per session. This exchange creates unique but shared
"ephemeral" keys. You don't generally get involved in this. DH is
almost magical but was invented about 40 years ago.

There is one thing about DH that can require your intervention. DH
works within an algebraic structure. Sometimes the algebra becomes
obsolete because more powerful computers or algorithms are getting
close to breaking them. So SSH starts by negotiating which DH algebra
to use. If your SSH is old enough, there is a chance that it doesn't
support an algebra that the other side's SSH considers secure. That
means that a session cannot be negotiated.

Note: DH isn't related to your permanent keys. If you have key
trouble, it probably isn't anything to do with DH. If you have DH
trouble, it probably isn't anything to dow with your permanent keys.

PS: It was Hellman's birthday yesterday.

[Karen Lewellen via talk]

Hi again,
I am not using windows either, but DOS.
The program, sshdos, was created by someone involved with the freedos
project, which is still under development.
When I use the program to ssh telnet well anywhere, and run the -v option I
witness the exchange process, when it works like here and when it does
not.
The program was compiled using some parts of putty for windows yes, along
with some Linux libraries.
Proof it works, I am using it to write this e-mail.
But as expressed my host here shellworld is a small enough company to work
with me.
Djgpp is another dos project which includes some more up to date keys. I
believe my best option is going to be discovering if there is either
another DOS ssh client, the speech and screen readers for Linux directly
all use voices that stimulate my brain's dizzy centres, or seek to
upgrade sshdos since the code is open source.
Thanks for the firm information about the keys I am using.
Happy thanksgiving to the list,
Kare

Post by D. Hugh Redelmeier via talk
| Thanks for these suggestions, but I do not have a Linux box. I use ssh telnet
| to reach a Linux shell.
I'm not sure what "ssh telnet" is. What software are you actually
using on your Windows machine? Putty?
| I have been debugging since Late June, with others here at least letting me
| know the problem may be due to locations removing access to my keys as
| dreamhost has done.
The terminology of crypto is kind of confusing. One confusing thing is
the word "key": there are two distinct kinds of keys used by SSH.
Normally, the keys you manipulate for SSH are a private key (that you
usually keep only on your local machine) and a corresponding public
key that you put everywhere that you might want to log into.
These two keys are a pair and you cannot mix and match from other key
pairs. You generally think of these keys as close to permanent.
The DH (DIffie-Hellman) exchange is something done by SSH
autonomously, per session. This exchange creates unique but shared
"ephemeral" keys. You don't generally get involved in this. DH is
almost magical but was invented about 40 years ago.
There is one thing about DH that can require your intervention. DH
works within an algebraic structure. Sometimes the algebra becomes
obsolete because more powerful computers or algorithms are getting
close to breaking them. So SSH starts by negotiating which DH algebra
to use. If your SSH is old enough, there is a chance that it doesn't
support an algebra that the other side's SSH considers secure. That
means that a session cannot be negotiated.
Note: DH isn't related to your permanent keys. If you have key
trouble, it probably isn't anything to do with DH. If you have DH
trouble, it probably isn't anything to dow with your permanent keys.
PS: It was Hellman's birthday yesterday.
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

---
Talk Mailing List
***@gtalug.org
https://gtalug.org/mailman

[Lennart Sorensen via talk]

Post by Karen Lewellen via talk
Hi again,
I am not using windows either, but DOS.
The program, sshdos, was created by someone involved with the freedos
project, which is still under development.
When I use the program to ssh telnet well anywhere, and run the -v option I
witness the exchange process, when it works like here and when it does not.
The program was compiled using some parts of putty for windows yes, along
with some Linux libraries.
Proof it works, I am using it to write this e-mail.
But as expressed my host here shellworld is a small enough company to work
with me.
Djgpp is another dos project which includes some more up to date keys. I
believe my best option is going to be discovering if there is either another
DOS ssh client, the speech and screen readers for Linux directly all use
voices that stimulate my brain's dizzy centres, or seek to upgrade sshdos
since the code is open source.
Thanks for the firm information about the keys I am using.
Happy thanksgiving to the list,
Kare

Well sshdos (useless since it is protocol 1.5) and ssh2dos (protocol 2.0)
look pretty close to useless by now. Last update to ssh2dos was in 2006.
ssh and security has moved on in the last 12 years.

For example last yearh people were having issues
connecting to new openssh versions with it:
http://freedos.10956.n7.nabble.com/Some-struggle-with-SSH2DOS-solved-td25894.html
Openssh simply doesn't allow the outdated key methods that ancient ssh
client wants anymore because they have been found to be insecure.
But I see you were part of that discussion so you already know about
those problems.

I guess freedos could use an updated ssh client.

[Karen Lewellen via talk]

Yes, and if you read that discussion about open ssh, you will find the
person also found a solution.
It is part of how shellworld allows me here, and shellworld uses a more
current edition of openssh than dreamhost.
ssh may have moved on in 12 years, but while there are options the aspect
of my body requiring my set up have not, with the synthesis I use computer
wise getting worse in other platforms
not better .
sshdos is open source now which is why I hinted my best door might be
getting it updated. The dhpgg options have already been discussed.
still Mike points out that dreamhost should still let my key in, making it
less about the program and more about something else.

Post by Lennart Sorensen via talk

Post by Karen Lewellen via talk
Hi again,
I am not using windows either, but DOS.
The program, sshdos, was created by someone involved with the freedos
project, which is still under development.
When I use the program to ssh telnet well anywhere, and run the -v option I
witness the exchange process, when it works like here and when it does not.
The program was compiled using some parts of putty for windows yes, along
with some Linux libraries.
Proof it works, I am using it to write this e-mail.
But as expressed my host here shellworld is a small enough company to work
with me.
Djgpp is another dos project which includes some more up to date keys. I
believe my best option is going to be discovering if there is either another
DOS ssh client, the speech and screen readers for Linux directly all use
voices that stimulate my brain's dizzy centres, or seek to upgrade sshdos
since the code is open source.
Thanks for the firm information about the keys I am using.
Happy thanksgiving to the list,
Kare

Well sshdos (useless since it is protocol 1.5) and ssh2dos (protocol 2.0)
look pretty close to useless by now. Last update to ssh2dos was in 2006.
ssh and security has moved on in the last 12 years.
For example last yearh people were having issues
http://freedos.10956.n7.nabble.com/Some-struggle-with-SSH2DOS-solved-td25894.html
Openssh simply doesn't allow the outdated key methods that ancient ssh
client wants anymore because they have been found to be insecure.
But I see you were part of that discussion so you already know about
those problems.
I guess freedos could use an updated ssh client.
--
Len Sorensen

---
Talk Mailing List
***@gtalug.org
https://gtalug.org/mailman/

[Mike via talk]

Hi Karen,

I'm still puzzled by exactly what "letting your key in" actually
means. That might refer to the initial key exchange (likely DH), host
key verification, or user public key authentication. Do you have any
detail from support on that?

Cheers,
Mike

Post by Karen Lewellen via talk
Yes, and if you read that discussion about open ssh, you will find the
person also found a solution.
It is part of how shellworld allows me here, and shellworld uses a more
current edition of openssh than dreamhost.
ssh may have moved on in 12 years, but while there are options the aspect
of my body requiring my set up have not, with the synthesis I use computer
wise getting worse in other platforms
not better .
sshdos is open source now which is why I hinted my best door might be
getting it updated. The dhpgg options have already been discussed.
still Mike points out that dreamhost should still let my key in, making it
less about the program and more about something else.

Post by Lennart Sorensen via talk

Post by Karen Lewellen via talk
Hi again,
I am not using windows either, but DOS.
The program, sshdos, was created by someone involved with the freedos
project, which is still under development.
When I use the program to ssh telnet well anywhere, and run the -v option I
witness the exchange process, when it works like here and when it does not.
The program was compiled using some parts of putty for windows yes, along
with some Linux libraries.
Proof it works, I am using it to write this e-mail.
But as expressed my host here shellworld is a small enough company to work
with me.
Djgpp is another dos project which includes some more up to date keys. I
believe my best option is going to be discovering if there is either another
DOS ssh client, the speech and screen readers for Linux directly all use
voices that stimulate my brain's dizzy centres, or seek to upgrade sshdos
since the code is open source.
Thanks for the firm information about the keys I am using.
Happy thanksgiving to the list,
Kare

Well sshdos (useless since it is protocol 1.5) and ssh2dos (protocol 2.0)
look pretty close to useless by now. Last update to ssh2dos was in 2006.
ssh and security has moved on in the last 12 years.
For example last yearh people were having issues
http://freedos.10956.n7.nabble.com/Some-struggle-with-SSH2DOS-solved-td25894.html
Openssh simply doesn't allow the outdated key methods that ancient ssh
client wants anymore because they have been found to be insecure.
But I see you were part of that discussion so you already know about
those problems.
I guess freedos could use an updated ssh client.
--
Len Sorensen

---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

---
Talk Mailing List
***@gtalug

[Karen Lewellen via talk]

Hi Mike,
In these keys I am logging into a shell. Dreamhost provides them with
their hosting account.
On their shell for example I have access to alpine for office mail,
several browsers, those sorts of things.
what letting my key in means is that if the exchange works I can provide
my password for the shell service itself.
You are right, it is a bit of both because I am told the host key
information, when using the -v option at least, and the service is
verifying me as a user.
Does that make more sense?
If one could create screen shots with speech I could illustrate, the
readme file for the program explains it too.
Cheers,
Kare

Post by Mike via talk
Hi Karen,
I'm still puzzled by exactly what "letting your key in" actually
means. That might refer to the initial key exchange (likely DH), host
key verification, or user public key authentication. Do you have any
detail from support on that?
Cheers,
Mike

Post by Karen Lewellen via talk
Yes, and if you read that discussion about open ssh, you will find the
person also found a solution.
It is part of how shellworld allows me here, and shellworld uses a more
current edition of openssh than dreamhost.
ssh may have moved on in 12 years, but while there are options the aspect
of my body requiring my set up have not, with the synthesis I use computer
wise getting worse in other platforms
not better .
sshdos is open source now which is why I hinted my best door might be
getting it updated. The dhpgg options have already been discussed.
still Mike points out that dreamhost should still let my key in, making it
less about the program and more about something else.

Post by Lennart Sorensen via talk

Post by Karen Lewellen via talk
Hi again,
I am not using windows either, but DOS.
The program, sshdos, was created by someone involved with the freedos
project, which is still under development.
When I use the program to ssh telnet well anywhere, and run the -v option I
witness the exchange process, when it works like here and when it does not.
The program was compiled using some parts of putty for windows yes, along
with some Linux libraries.
Proof it works, I am using it to write this e-mail.
But as expressed my host here shellworld is a small enough company to work
with me.
Djgpp is another dos project which includes some more up to date keys. I
believe my best option is going to be discovering if there is either another
DOS ssh client, the speech and screen readers for Linux directly all use
voices that stimulate my brain's dizzy centres, or seek to upgrade sshdos
since the code is open source.
Thanks for the firm information about the keys I am using.
Happy thanksgiving to the list,
Kare

Well sshdos (useless since it is protocol 1.5) and ssh2dos (protocol 2.0)
look pretty close to useless by now. Last update to ssh2dos was in 2006.
ssh and security has moved on in the last 12 years.
For example last yearh people were having issues
http://freedos.10956.n7.nabble.com/Some-struggle-with-SSH2DOS-solved-td25894.html
Openssh simply doesn't allow the outdated key methods that ancient ssh
client wants anymore because they have been found to be insecure.
But I see you were part of that discussion so you already know about
those problems.
I guess freedos could use an updated ssh client.
--
Len Sorensen

---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

---
Talk Mailing List
***@gtalug.org
https://gtalug.org/ma

[Mike via talk]

Strange...

I set up an openssh -dd server on a weird port for Karen to connect
to, and it said this:

Client reports itself as: SSHDOS_0.2.1
Server used is: SSH-2.0-OpenSSH_6.0p1

Negotiation yielded:

Key exhange (KEX): diffie-hellman-group-exchange-sha1
Host key algorithm: ssh-dss (a.k.a. DSA)
Session cipher: aes128-cbc
Message authentication Code (MAC): hmac-sha1

What bugs me is that running
nmap --script ssh2-enum-algos dreamhost.com
lists, among others,

kex_algorithms:
... diffie-hellman-group-exchange-sha1

server_host_key_algorithms:
... ssh-dss

encryption_algorithms:
... aes128-cbc

mac_algorithms:
... hmac-sha1


I don't see that there should be any trouble connecting to dreamhost.com...
---
Talk Mailing List
***@gtalug.org
https://gtalug.org/mailman/listi

[Karen Lewellen via talk]

Hi Mike, all,
that is most impressive and I am beyond thankful.
I did do a second test, using an option that I run for shellworld, but
your data shows I should be having no issues..save for the port itself.
unless your test of dreamhost.com is using port 22?
in which case I am back to Bell somehow impacting my accessing the port.
Thanks!
Kare

Post by Mike via talk
Strange...
I set up an openssh -dd server on a weird port for Karen to connect
Client reports itself as: SSHDOS_0.2.1
Server used is: SSH-2.0-OpenSSH_6.0p1
Key exhange (KEX): diffie-hellman-group-exchange-sha1
Host key algorithm: ssh-dss (a.k.a. DSA)
Session cipher: aes128-cbc
Message authentication Code (MAC): hmac-sha1
What bugs me is that running
nmap --script ssh2-enum-algos dreamhost.com
lists, among others,
... diffie-hellman-group-exchange-sha1
... ssh-dss
... aes128-cbc
... hmac-sha1
I don't see that there should be any trouble connecting to dreamhost.com...

---
Talk Mailing List
ta

[Mike via talk]

Got it! So you can definitely connect outbound on port 22!
And yes, I was probing dreamhost.com on port 22.
They got some 'splaining to do.
I suggest you might want to hit up their support folks again armed
with the information that your SSH client is using:

diffie-hellman-group-exchange-sha1 OR diffie-hellman-group1-sha1 for
key exchange,
ssh-dss for host key, and
aes128-cbc and hmac-sha1 for session encryption.

Good luck, Watson!
Let us know what explanation they offer...

Cheers,
Mike

[Karen Lewellen via talk]

Just found the e-mail for my dreamhost contact.
Will share all of your brilliant deductions with them.
My only guess now is that there is something wrong with how my account is
configured on their eugene.dreamhost.com server, since elementary, security
and keys should work the same through out!
Thanks so much.
Kare Watson

Post by Mike via talk
Got it! So you can definitely connect outbound on port 22!
And yes, I was probing dreamhost.com on port 22.
They got some 'splaining to do.
I suggest you might want to hit up their support folks again armed
diffie-hellman-group-exchange-sha1 OR diffie-hellman-group1-sha1 for
key exchange,
ssh-dss for host key, and
aes128-cbc and hmac-sha1 for session encryption.
Good luck, Watson!
Let us know what explanation they offer...
Cheers,
Mike