dreamhost reply, is dh key exchange question.
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:> On Mon, 8 Oct 2018, DreamHost Customer Support Team wrote:
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/ Don't forget the expert content on our blog: 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 ------------------------------------------------------------------------
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 user@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 On 10/9/18, Karen Lewellen via talk <talk@gtalug.org> wrote:
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:>
On Mon, 8 Oct 2018, DreamHost Customer Support Team wrote:
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/ Don't forget the expert content on our blog: 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 talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On Wed, Oct 10, 2018 at 3:06 PM Mike via talk <talk@gtalug.org> wrote:
<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 email program, run "ssh user@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! <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
Jason Shaw via talk wrote:
On Wed, Oct 10, 2018 at 3:06 PM Mike via talk <talk@gtalug.org> wrote:
That is, SSH to your other shell account, and instead of running your email program, run "ssh user@eugene...", and once connected to eugene, proceed as though you were connected directly.
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
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.
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
... and not forgetting that Karen's DOS-based SSH client may not provide these UNIX-style openssh features and configuration niceties! On 10/10/18, Anthony de Boer via talk <talk@gtalug.org> wrote:
Jason Shaw via talk wrote:
On Wed, Oct 10, 2018 at 3:06 PM Mike via talk <talk@gtalug.org> wrote:
That is, SSH to your other shell account, and instead of running your email program, run "ssh user@eugene...", and once connected to eugene, proceed as though you were connected directly.
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
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.
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 talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
Mike, On Wed, 10 Oct 2018, Mike via talk wrote:
... 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
On 10/10/18, Anthony de Boer via talk <talk@gtalug.org> wrote: Jason Shaw via talk wrote:
On Wed, Oct 10, 2018 at 3:06 PM Mike via talk <talk@gtalug.org> wrote:
That is, SSH to your other shell account, and instead of running your email program, run "ssh user@eugene...", and once connected to eugene, proceed as though you were connected directly.
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
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.
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 talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
On Wed, Oct 10, 2018, 15:47 Anthony de Boer via talk <talk@gtalug.org> wrote:
Jason Shaw via talk wrote:
On Wed, Oct 10, 2018 at 3:06 PM Mike via talk <talk@gtalug.org> wrote:
That is, SSH to your other shell account, and instead of running your email program, run "ssh user@eugene...", and once connected to eugene, proceed as though you were connected directly.
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
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.
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!
Great recommendation.
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 On Wed, 10 Oct 2018, Anthony de Boer via talk wrote:
Jason Shaw via talk wrote:
On Wed, Oct 10, 2018 at 3:06 PM Mike via talk <talk@gtalug.org> wrote:
That is, SSH to your other shell account, and instead of running your email program, run "ssh user@eugene...", and once connected to eugene, proceed as though you were connected directly.
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
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.
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 talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
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 On Wed, 10 Oct 2018, Jason Shaw wrote:
On Wed, Oct 10, 2018 at 3:06 PM Mike via talk <talk@gtalug.org> wrote:
<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 email program, run "ssh user@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! <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
Hi Mike, In context below, I am reading these ideas starting with yours here. On Wed, 10 Oct 2018, Mike wrote:
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.
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?
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.
That is, SSH to your other shell account, and instead of running your email program, run "ssh user@eugene...", and once connected to eugene, 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.
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!
Thanks again Holmes! Cheers, Kare
On 10/9/18, Karen Lewellen via talk <talk@gtalug.org> wrote:
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:>
On Mon, 8 Oct 2018, DreamHost Customer Support Team wrote:
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/ Don't forget the expert content on our blog: 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 talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
participants (4)
-
Anthony de Boer -
Jason Shaw -
Karen Lewellen -
Mike