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