Discussion:
[GTALUG] dreamhost reply, is dh key exchange question.
Karen Lewellen via talk
2018-10-09 20:19:20 UTC
Permalink
Hi Mike and everyone.
Below is the explanation from dreamhost regarding my dh key exchange
situation.
A bit of background.
Dreamhost has a special program allowing International Nonprofit
organizations who can demonstrate tax exempt status to have a hosting
account with their service.
My employee got such an account years back, they have offices both in new
York and Toronto. I have asked Brian to share the documentation dreamhost
provided its nonprofit organization members in this program of their so
called business decision.
I pointed out that many in the nonprofit sector are using less than hot
off the shelf tools to manage their internet efforts, with this business
decision creating a risk for more than myself. Further, I pointed out
that I am at the moment, physically incapable of making changes having
not been able to work fully since the end of June.
I share his first post, I have not gotten an answer yet to my reply.
I dare say the simple solution would be, if they exists, an easy way to
manage it, finding another company all together.
At the same time though I would welcome educating other dreamhost
customers, say via there twitter presence, if they have one.
Thoughts on their explanation?
Karen
<dreamhost e-mail begins below this line:>
Hello,
"I don't see that there should be any trouble connecting to
dreamhost.com..."
Simply connecting to dreamhost.com is not a valid test, as there are no
customers ever hosted on our main web site. That server is reserved for
internal use only. It has only internal use logins on it. Encryption is
maintained via a separate system.
"However there is a problem with Eugene.dreamhost.com Since
dreamhost.com still should allow my ssh client to connect, the question
is if my account can be placed on a server that will
allow such a connection."
Again, we are not hosting customers on any servers that support the
method of encryption you're looking for. I wish we could, but we have
made a business decision not to support that type of connection style for
customer logins. We will be updating dreamhost.com shortly.
"You were going to move our account in any case, at least I have
e-mails saying that was going to
happen."
That will simply be a move of email, to a different email server. This
is unrelated to where your web service lives.
Sorry I can't be of more help here.
Thanks!
Brian H
--
To continue this support case, just reply to this email.
Check our Knowledge Base tips and how-tos! https://help.dreamhost.com/
https://www.dreamhost.com/blog/
------------------------------------------------------------------------
Are you happy with this response to your support inquiry?
YES https://www.dreamhost.com/survey.cgi?h=y&n=154364736&m=4145361
NO https://www.dreamhost.com/survey.cgi?h=n&n=154364736&m=4145361
------------------------------------------------------------------------
---
Talk Mailing List
***@gtalu
Mike via talk
2018-10-10 19:06:39 UTC
Permalink
Hi Karen,

I'm going to guess that the "business decision" is basically to
conform to current acceptable security practices, possibly even for
liability reasons.

Question: Do you, or your colleague, have administrative (or "root")
privilege to your hosted system? If so, you could re-enable the
deprecated algorithms without Dreamhost's help (or permission).

However, I have what may be an easier solution, one that I should
already have thought of: If you still have working SSH-based shell
access to a different host, you should be able to SSH FROM THERE to
your dreamhost system.

That is, SSH to your other shell account, and instead of running your
email program, run "ssh ***@eugene...", and once connected to eugene,
proceed as though you were connected directly.

Such plumbing is often necessary for a variety of reasons. Just make
sure you know where you are. The commands "whoami", and "hostname"
are often useful!

Cheers,
Mike
Post by Karen Lewellen via talk
Hi Mike and everyone.
Below is the explanation from dreamhost regarding my dh key exchange
situation.
A bit of background.
Dreamhost has a special program allowing International Nonprofit
organizations who can demonstrate tax exempt status to have a hosting
account with their service.
My employee got such an account years back, they have offices both in new
York and Toronto. I have asked Brian to share the documentation dreamhost
provided its nonprofit organization members in this program of their so
called business decision.
I pointed out that many in the nonprofit sector are using less than hot
off the shelf tools to manage their internet efforts, with this business
decision creating a risk for more than myself. Further, I pointed out
that I am at the moment, physically incapable of making changes having
not been able to work fully since the end of June.
I share his first post, I have not gotten an answer yet to my reply.
I dare say the simple solution would be, if they exists, an easy way to
manage it, finding another company all together.
At the same time though I would welcome educating other dreamhost
customers, say via there twitter presence, if they have one.
Thoughts on their explanation?
Karen
<dreamhost e-mail begins below this line:>
Hello,
"I don't see that there should be any trouble connecting to
dreamhost.com..."
Simply connecting to dreamhost.com is not a valid test, as there are no
customers ever hosted on our main web site. That server is reserved for
internal use only. It has only internal use logins on it. Encryption is
maintained via a separate system.
"However there is a problem with Eugene.dreamhost.com Since
dreamhost.com still should allow my ssh client to connect, the question
is if my account can be placed on a server that will
allow such a connection."
Again, we are not hosting customers on any servers that support the
method of encryption you're looking for. I wish we could, but we have
made a business decision not to support that type of connection style for
customer logins. We will be updating dreamhost.com shortly.
"You were going to move our account in any case, at least I have
e-mails saying that was going to
happen."
That will simply be a move of email, to a different email server. This
is unrelated to where your web service lives.
Sorry I can't be of more help here.
Thanks!
Brian H
--
To continue this support case, just reply to this email.
Check our Knowledge Base tips and how-tos! https://help.dreamhost.com/
https://www.dreamhost.com/blog/
------------------------------------------------------------------------
Are you happy with this response to your support inquiry?
YES https://www.dreamhost.com/survey.cgi?h=y&n=154364736&m=4145361
NO https://www.dreamhost.com/survey.cgi?h=n&n=154364736&m=4145361
------------------------------------------------------------------------
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
***@gtalug.org
Jason Shaw via talk
2018-10-10 19:12:16 UTC
Permalink
<snip>
However, I have what may be an easier solution, one that I should
already have thought of: If you still have working SSH-based shell
access to a different host, you should be able to SSH FROM THERE to
your dreamhost system.
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
Such plumbing is often necessary for a variety of reasons. Just make
sure you know where you are. The commands "whoami", and "hostname"
are often useful!
<snip>
This is a great recommendation and can be easily automated. In your
personal ssh config, usually ~/.ssh/config you can add in:

Host *.dreamhost.com
ProxyCommand ssh -q shellworld_host nc %h %p

With this in place, you'll be able to just type 'ssh yourhost.dreamhost.com'
and you'll bounce through shellworld_host (substitiute your actual
shellworld host account) to make it mostly seamless.

-jason
Anthony de Boer via talk
2018-10-10 19:47:31 UTC
Permalink
Post by Jason Shaw via talk
Post by Mike via talk
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
This is a great recommendation and can be easily automated. In your
Host *.dreamhost.com
ProxyCommand ssh -q shellworld_host nc %h %p
Those suggestions are two very different things. Mike is suggesting
SSH'ing to the shell on the intermediate box and then SSH'ing from it,
while Jason is suggesting to SSH the intermediate and then use it to
pipe an inner SSH connection through the outer SSH connection and emerge
there for the onward hop to the destination.

Caveat for the first solution: it involves using your credentials on the
intermediate box, so if anyone evil has compromised it they can now pop
the destination box too.

Caveat for the second solution: the SSH conversation still involves the
near-end client negotiating crypto with the far-end server, so if that
started off being the problem it's still that problem. Also, the middle
box might not have nc (netcat) installed but there are other tactics
like LocalForward configuration that can do the same thing.
Post by Jason Shaw via talk
Post by Mike via talk
Such plumbing is often necessary for a variety of reasons. Just make
sure you know where you are. The commands "whoami", and "hostname"
are often useful!
Setting the bash prompt to include the hostname is helpful. Always pause
a moment to be sure where you are before typing commands like reboot,
poweroff, and such. I've even known people to alias away commands like
that on shared servers after inadvertently using them a time too many
thinking they were on their test rig.
--
Anthony de Boer
---
Talk Mailing List
***@gtalug.org
https://gtalug.org/mailm
Mike via talk
2018-10-10 19:52:21 UTC
Permalink
... and not forgetting that Karen's DOS-based SSH client may not
provide these UNIX-style openssh features and configuration niceties!
Post by Anthony de Boer via talk
Post by Jason Shaw via talk
Post by Mike via talk
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
This is a great recommendation and can be easily automated. In your
Host *.dreamhost.com
ProxyCommand ssh -q shellworld_host nc %h %p
Those suggestions are two very different things. Mike is suggesting
SSH'ing to the shell on the intermediate box and then SSH'ing from it,
while Jason is suggesting to SSH the intermediate and then use it to
pipe an inner SSH connection through the outer SSH connection and emerge
there for the onward hop to the destination.
Caveat for the first solution: it involves using your credentials on the
intermediate box, so if anyone evil has compromised it they can now pop
the destination box too.
Caveat for the second solution: the SSH conversation still involves the
near-end client negotiating crypto with the far-end server, so if that
started off being the problem it's still that problem. Also, the middle
box might not have nc (netcat) installed but there are other tactics
like LocalForward configuration that can do the same thing.
Post by Jason Shaw via talk
Post by Mike via talk
Such plumbing is often necessary for a variety of reasons. Just make
sure you know where you are. The commands "whoami", and "hostname"
are often useful!
Setting the bash prompt to include the hostname is helpful. Always pause
a moment to be sure where you are before typing commands like reboot,
poweroff, and such. I've even known people to alias away commands like
that on shared servers after inadvertently using them a time too many
thinking they were on their test rig.
--
Anthony de Boer
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
***@gtalug.org
https://gtalug.org/m
Karen Lewellen via talk
2018-10-12 17:06:05 UTC
Permalink
Mike,
Post by Mike via talk
... and not forgetting that Karen's DOS-based SSH client may not
provide these UNIX-style openssh features and configuration niceties!
Well...just so!
There might be an option somewhere in the <risk of misspelling> wat.pcp
configurations used to be sure, but it might be simpler to incorporate the
additional dh key options in the djpgg libraries too...not that I know how.

Kare
Post by Mike via talk
Post by Anthony de Boer via talk
Post by Jason Shaw via talk
Post by Mike via talk
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
This is a great recommendation and can be easily automated. In your
Host *.dreamhost.com
ProxyCommand ssh -q shellworld_host nc %h %p
Those suggestions are two very different things. Mike is suggesting
SSH'ing to the shell on the intermediate box and then SSH'ing from it,
while Jason is suggesting to SSH the intermediate and then use it to
pipe an inner SSH connection through the outer SSH connection and emerge
there for the onward hop to the destination.
Caveat for the first solution: it involves using your credentials on the
intermediate box, so if anyone evil has compromised it they can now pop
the destination box too.
Caveat for the second solution: the SSH conversation still involves the
near-end client negotiating crypto with the far-end server, so if that
started off being the problem it's still that problem. Also, the middle
box might not have nc (netcat) installed but there are other tactics
like LocalForward configuration that can do the same thing.
Post by Jason Shaw via talk
Post by Mike via talk
Such plumbing is often necessary for a variety of reasons. Just make
sure you know where you are. The commands "whoami", and "hostname"
are often useful!
Setting the bash prompt to include the hostname is helpful. Always pause
a moment to be sure where you are before typing commands like reboot,
poweroff, and such. I've even known people to alias away commands like
that on shared servers after inadvertently using them a time too many
thinking they were on their test rig.
--
Anthony de Boer
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List

Jason Shaw via talk
2018-10-10 19:53:16 UTC
Permalink
Post by Anthony de Boer via talk
Post by Jason Shaw via talk
Post by Mike via talk
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
This is a great recommendation and can be easily automated. In your
Host *.dreamhost.com
ProxyCommand ssh -q shellworld_host nc %h %p
Those suggestions are two very different things. Mike is suggesting
SSH'ing to the shell on the intermediate box and then SSH'ing from it,
while Jason is suggesting to SSH the intermediate and then use it to
pipe an inner SSH connection through the outer SSH connection and emerge
there for the onward hop to the destination.
Caveat for the first solution: it involves using your credentials on the
intermediate box, so if anyone evil has compromised it they can now pop
the destination box too.
Caveat for the second solution: the SSH conversation still involves the
near-end client negotiating crypto with the far-end server, so if that
started off being the problem it's still that problem. Also, the middle
box might not have nc (netcat) installed but there are other tactics
like LocalForward configuration that can do the same thing.
Ooh, you're absolutely right! I've been using this for sold that I didn't
stop to think about how it actually works under the hood.
Post by Anthony de Boer via talk
Post by Jason Shaw via talk
Such plumbing is often necessary for a variety of reasons. Just make
Post by Mike via talk
sure you know where you are. The commands "whoami", and "hostname"
are often useful!
Great recommendation.
Karen Lewellen via talk
2018-10-12 16:58:49 UTC
Permalink
Hi Anthony,
One issue not covered with this back door is what happens if shellworld
itself is down? That happened for two weeks recently. If I used
shellworld to somehow reach dreamhost, and shellworld is compromised, I
personally end up with no electronic contact with the outside world
whatsoever.
I am likewise not personally comfortable tapping shellworld servers to
reach the dreamhost ones, I agree with you that the problem would likely
remain. More important though neither of these solutions provide a from
my desktop to my dreamhost shared account workspace solution which is a
must have here.

Thanks,
Karen
Post by Anthony de Boer via talk
Post by Jason Shaw via talk
Post by Mike via talk
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
This is a great recommendation and can be easily automated. In your
Host *.dreamhost.com
ProxyCommand ssh -q shellworld_host nc %h %p
Those suggestions are two very different things. Mike is suggesting
SSH'ing to the shell on the intermediate box and then SSH'ing from it,
while Jason is suggesting to SSH the intermediate and then use it to
pipe an inner SSH connection through the outer SSH connection and emerge
there for the onward hop to the destination.
Caveat for the first solution: it involves using your credentials on the
intermediate box, so if anyone evil has compromised it they can now pop
the destination box too.
Caveat for the second solution: the SSH conversation still involves the
near-end client negotiating crypto with the far-end server, so if that
started off being the problem it's still that problem. Also, the middle
box might not have nc (netcat) installed but there are other tactics
like LocalForward configuration that can do the same thing.
Post by Jason Shaw via talk
Post by Mike via talk
Such plumbing is often necessary for a variety of reasons. Just make
sure you know where you are. The commands "whoami", and "hostname"
are often useful!
Setting the bash prompt to include the hostname is helpful. Always pause
a moment to be sure where you are before typing commands like reboot,
poweroff, and such. I've even known people to alias away commands like
that on shared servers after inadvertently using them a time too many
thinking they were on their test rig.
--
Anthony de Boer
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
talk@
Karen Lewellen via talk
2018-10-12 16:50:41 UTC
Permalink
Hi Jason,
I am guessing that you did not follow the start of our informative
discussion here.
i have no personal ssh.config because I cannot run Linux directly as a
computer system due to my individual accessibility needs.
I run the programs with which Mike profoundly helped me troubleshoot from
my DOS desktop,
reaching a company where I have a shell account of my own, who is using
an alternative
port from 22 and who still incorporates the factors Mike discovered for
my user logging in.
further as i just shared this does not give me direct access as I cannot
download or upload items to my dreamhost work space from another shell.
The dreamhost shell, while far less detailed than my personal shared
account at shellworld, contains e-mail programs, browsers, text editors
file conversion tools and the like , comparative to I guess? the Ubuntu
command line, although I am not firm on what Ubuntu is like first hand.
Regardless for my professional needs, I must reach a comparative setup
from my desktop to get tings done.

Thanks, Karen
Post by Jason Shaw via talk
<snip>
However, I have what may be an easier solution, one that I should
already have thought of: If you still have working SSH-based shell
access to a different host, you should be able to SSH FROM THERE to
your dreamhost system.
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
Such plumbing is often necessary for a variety of reasons. Just make
sure you know where you are. The commands "whoami", and "hostname"
are often useful!
<snip>
This is a great recommendation and can be easily automated. In your
Host *.dreamhost.com
ProxyCommand ssh -q shellworld_host nc %h %p
With this in place, you'll be able to just type 'ssh yourhost.dreamhost.com'
and you'll bounce through shellworld_host (substitiute your actual
shellworld host account) to make it mostly seamless.
-jason
---
Talk Mailing List
***@gtalug
Karen Lewellen via talk
2018-10-12 16:38:10 UTC
Permalink
Hi Mike,
In context below, I am reading these ideas starting with yours here.
Post by Mike via talk
Hi Karen,
I'm going to guess that the "business decision" is basically to
conform to current acceptable security practices, possibly even for
liability reasons.
granted, I have not as of yet heard back from Brian regarding my question.
However since dreamhost benefits from their corporate hosting donating
program with the IRS, failing to inform nonprofit organizations of said
business decision
prior to impacting their mission could carry legal ramifications as well.
I have asked Brian to document how this information was shared with all
of the organizations in their program in advance.
Post by Mike via talk
Question: Do you, or your colleague, have administrative (or "root")
privilege to your hosted system? If so, you could re-enable the
deprecated algorithms without Dreamhost's help (or permission).
I doubt this, as our account is a shared one. However what would I review
in our control panel to learn if this might be the case?
Post by Mike via talk
However, I have what may be an easier solution, one that I should
already have thought of: If you still have working SSH-based shell
access to a different host, you should be able to SSH FROM THERE to
your dreamhost system.
Mike, this is the ban-aid I have been using to at least try and manage
company communications.
i ssh from my shellworld personal account into our dreamhost one.
I suspect security concerns, the process lists a slightly incorrect domain
name for us. Further shortly after this started, i began getting more
of those ransom related e-mails
using our password as proof they know me.
Most important though, I require direct access to our dreamhost shell
space from my desktop.

I need to access files uploading and downloading from there, and keeping
that information separate from my personal shell.
As it stands anything that must change hands has to be first uploaded to
shellworld, than sent as an attachment to curtain up which cannot be done
when the file is production audio etc.
Post by Mike via talk
That is, SSH to your other shell account, and instead of running your
proceed as though you were connected directly.
Accept that I am not connected directly, I am connected via another
shell. I cannot move files to and from, which is important for what we
do.
Post by Mike via talk
Such plumbing is often necessary for a variety of reasons. Just
make > sure you know where you are. The commands "whoami", and "hostname"
Post by Mike via talk
are often useful!
Thanks again Holmes!
Cheers,
Kare
Post by Mike via talk
Post by Karen Lewellen via talk
Hi Mike and everyone.
Below is the explanation from dreamhost regarding my dh key exchange
situation.
A bit of background.
Dreamhost has a special program allowing International Nonprofit
organizations who can demonstrate tax exempt status to have a hosting
account with their service.
My employee got such an account years back, they have offices both in new
York and Toronto. I have asked Brian to share the documentation dreamhost
provided its nonprofit organization members in this program of their so
called business decision.
I pointed out that many in the nonprofit sector are using less than hot
off the shelf tools to manage their internet efforts, with this business
decision creating a risk for more than myself. Further, I pointed out
that I am at the moment, physically incapable of making changes having
not been able to work fully since the end of June.
I share his first post, I have not gotten an answer yet to my reply.
I dare say the simple solution would be, if they exists, an easy way to
manage it, finding another company all together.
At the same time though I would welcome educating other dreamhost
customers, say via there twitter presence, if they have one.
Thoughts on their explanation?
Karen
<dreamhost e-mail begins below this line:>
Hello,
"I don't see that there should be any trouble connecting to
dreamhost.com..."
Simply connecting to dreamhost.com is not a valid test, as there are no
customers ever hosted on our main web site. That server is reserved for
internal use only. It has only internal use logins on it. Encryption is
maintained via a separate system.
"However there is a problem with Eugene.dreamhost.com Since
dreamhost.com still should allow my ssh client to connect, the question
is if my account can be placed on a server that will
allow such a connection."
Again, we are not hosting customers on any servers that support the
method of encryption you're looking for. I wish we could, but we have
made a business decision not to support that type of connection style for
customer logins. We will be updating dreamhost.com shortly.
"You were going to move our account in any case, at least I have
e-mails saying that was going to
happen."
That will simply be a move of email, to a different email server. This
is unrelated to where your web service lives.
Sorry I can't be of more help here.
Thanks!
Brian H
--
To continue this support case, just reply to this email.
Check our Knowledge Base tips and how-tos! https://help.dreamhost.com/
https://www.dreamhost.com/blog/
------------------------------------------------------------------------
Are you happy with this response to your support inquiry?
YES https://www.dreamhost.com/survey.cgi?h=y&n=154364736&m=4145361
NO https://www.dreamhost.com/survey.cgi?h=n&n=154364736&m=4145361
------------------------------------------------------------------------
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk
---
Talk Mailing List
***@gtalug.org
https://gtalug.org
Loading...