Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #198116 > unrolled thread

a dh keys question?

Back to article view | Back to linux.debian.user

Contents

  a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-07-31 17:40 +0200
    Re: a dh keys question? Dan Ritter <dsr@randomstring.org> - 2018-07-31 18:00 +0200
      Re: a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-07-31 18:10 +0200
        Re: a dh keys question? Dan Ritter <dsr@randomstring.org> - 2018-07-31 18:40 +0200
          Re: a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-07-31 19:10 +0200
            Re: a dh keys question? Dan Ritter <dsr@randomstring.org> - 2018-07-31 21:40 +0200
              Re: a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-08-01 00:00 +0200
                Re: a dh keys question? Joe <joe@jretrading.com> - 2018-08-01 09:30 +0200
      Re: a dh keys question? Richard Hector <richard@walnut.gen.nz> - 2018-08-01 04:00 +0200
        Re: a dh keys question? Dan Purgert <dan@djph.net> - 2018-08-01 12:30 +0200
          Re: a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-08-01 21:00 +0200
            Re: a dh keys question? Dan Purgert <dan@djph.net> - 2018-08-01 21:30 +0200
              Re: a dh keys question? john doe <johndoe65534@mail.com> - 2018-08-01 22:00 +0200
              Re: a dh keys question? Dan Ritter <dsr@randomstring.org> - 2018-08-01 22:40 +0200
                Re: a dh keys question? Dan Purgert <dan@djph.net> - 2018-08-01 23:30 +0200
                Re: a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-08-02 00:00 +0200
                  Re: a dh keys question? Dan Purgert <dan@djph.net> - 2018-08-02 02:40 +0200
                    Re: a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-08-02 02:50 +0200
                      Re: a dh keys question? Dan Purgert <dan@djph.net> - 2018-08-02 03:20 +0200
                        Re: a dh keys question? Karen Lewellen <klewellen@shellworld.net> - 2018-08-02 03:30 +0200
                          Re: a dh keys question? Dan Purgert <dan@djph.net> - 2018-08-02 12:30 +0200
                      Re: a dh keys question? Peter Wiersig <peter@friesenpeter.de> - 2018-08-04 06:50 +0200

Page 1 of 2  [1] 2  Next page →

#198116 — a dh keys question?

Hi everyone,
While the question seems simple, at least to me, the reason behind it is 
complicated.  so I am hoping to focus on the question first.
During the dh key exchange process, where do the user dh key packets come 
from software wise?
I have a problem now where each place I try to visit using my ssh client, 
and my sftp one, I am getting a dh key exchange failure.
using the -v command  is not shedding light on the issue.
I am using the same client now to reach another  service, but here  we use 
a different port from port 22.
the error started on the 29th of June, and the company providing my dsl 
service did claim to have a service issue on that day.
However they do not speak Linux let alone anything else Unusual.
Thoughts?

[toc] | [next] | [standalone]

#198117

On Tue, Jul 31, 2018 at 11:38:34AM -0400, Karen Lewellen wrote:
> Hi everyone,
> While the question seems simple, at least to me, the reason behind it is
> complicated.  so I am hoping to focus on the question first.
> During the dh key exchange process, where do the user dh key packets come
> from software wise?

You generate a private/public key pair with ssh-keygen, and send
the public key over to your destination in advance, so that they
can recognize you.

> I have a problem now where each place I try to visit using my ssh client,
> and my sftp one, I am getting a dh key exchange failure.
> using the -v command  is not shedding light on the issue.
> I am using the same client now to reach another  service, but here  we use a
> different port from port 22.
> the error started on the 29th of June, and the company providing my dsl
> service did claim to have a service issue on that day.
> However they do not speak Linux let alone anything else Unusual.
> Thoughts?


Are you having problems SSHing to all servers that you try, or
just to one in particular?

If it's just one, and that one uses a port other than 22, it's
likely that your DSL company started filtering that port on the
29th. 

-dsr-

[toc] | [prev] | [next] | [standalone]

#198118

Hi, thanks  with answers.

On Tue, 31 Jul 2018, Dan Ritter wrote:

>
> You generate a private/public key pair with ssh-keygen, and send
> the public key over to your destination in advance, so that they
> can recognize you.

Okay, I understand.  Meaning that keygen is a part of the ssh client I 
take it?

> Are you having problems SSHing to all servers that you try, or
> just to one in particular?

I am having problems with every server I try, aside from  the one using 
the  different port from 21 & 22.
So, it is the reverse of what you suggest.  I wish I could test another 
server using an alternative port to see  if that works.

>
Thanks,
Karen

[toc] | [prev] | [next] | [standalone]

#198120

On Tue, Jul 31, 2018 at 12:07:53PM -0400, Karen Lewellen wrote:
> 
> Hi, thanks  with answers.
> 
> On Tue, 31 Jul 2018, Dan Ritter wrote:
> 
> > 
> > You generate a private/public key pair with ssh-keygen, and send
> > the public key over to your destination in advance, so that they
> > can recognize you.
> 
> Okay, I understand.  Meaning that keygen is a part of the ssh client I take
> it?

ssh-keygen is a command that comes along with your SSH client in
Debian (and all other UNIX-like systems that supply OpenSSH).


> > Are you having problems SSHing to all servers that you try, or
> > just to one in particular?
> 
> I am having problems with every server I try, aside from  the one using the
> different port from 21 & 22.
> So, it is the reverse of what you suggest.  I wish I could test another
> server using an alternative port to see  if that works.

That sounds like your DSL company decided to block port 22,
which is somewhere between ridiculous and evil.

(21 is FTP, by the way.)

1. Reboot your DSL modem and/or router just in case.

2. Test that you still can't ssh to server:22

3. Test that you can't connect via ssh to chat.shazow.net (it
will allow anyone on, no credentials)

4. Complain to your DSL company.

-dsr-

[toc] | [prev] | [next] | [standalone]

#198121

Hi again,


> ssh-keygen is a command that comes along with your SSH client in
> Debian (and all other UNIX-like systems that supply OpenSSH).
Understood.

> That sounds like your DSL company decided to block port 22,
> which is somewhere between ridiculous and evil.
>
> (21 is FTP, by the way.)
Yes, on port 21 being for ftp, meaning it would have to be blocked as well 
which   seems frankly impossible.


>
> 1. Reboot your DSL modem and/or router just in case.
Not only has that been done, I actually  got someone at Bell Canada to 
reset my account information on their side to default.
That worked once before when I could not reach dreamhost.
> 2. Test that you still can't ssh to server:22
> 3. Test that you can't connect via ssh to chat.shazow.net (it
> will allow anyone on, no credentials)

Okay, did that once producing the same dh key error, but will do it again 
with /v to note what happens.

> 4. Complain to your DSL company.

But that is why I desire a server to test that, like here at shellworld, 
is using something other than port 22.  Otherwise I just get a repeat of 
the same conversation, we do not support your operating system.
Although, I am wondering, if the port were blocked, if  I would get as much 
information as I am getting from /v?
Kare

[toc] | [prev] | [next] | [standalone]

#198123

On Tue, Jul 31, 2018 at 01:01:31PM -0400, Karen Lewellen wrote:
> Hi again,
> 
> 
> > ssh-keygen is a command that comes along with your SSH client in
> > Debian (and all other UNIX-like systems that supply OpenSSH).
> Understood.
> 
> > That sounds like your DSL company decided to block port 22,
> > which is somewhere between ridiculous and evil.
> > 
> > (21 is FTP, by the way.)
> Yes, on port 21 being for ftp, meaning it would have to be blocked as well
> which   seems frankly impossible.
> 
> 
> > 
> > 1. Reboot your DSL modem and/or router just in case.
> Not only has that been done, I actually  got someone at Bell Canada to reset
> my account information on their side to default.
> That worked once before when I could not reach dreamhost.
> > 2. Test that you still can't ssh to server:22
> > 3. Test that you can't connect via ssh to chat.shazow.net (it
> > will allow anyone on, no credentials)
> 
> Okay, did that once producing the same dh key error, but will do it again
> with /v to note what happens.
> 
> > 4. Complain to your DSL company.
> 
> But that is why I desire a server to test that, like here at shellworld, is
> using something other than port 22.  Otherwise I just get a repeat of the
> same conversation, we do not support your operating system.
> Although, I am wondering, if the port were blocked, if  I would get as much
> information as I am getting from /v?

Show us the whole output.

-dsr-

[toc] | [prev] | [next] | [standalone]

#198125

Hi
just putting my answer at the top.
My client does have a log option, will aim for that.  still again my first 
priority is finding a place to test  with a nonstandard port.  then I can 
be sure  it really is all about port 22 and 21.
Kare



On Tue, 31 Jul 2018, Dan Ritter wrote:

> On Tue, Jul 31, 2018 at 01:01:31PM -0400, Karen Lewellen wrote:
>> Hi again,
>>
>>
>>> ssh-keygen is a command that comes along with your SSH client in
>>> Debian (and all other UNIX-like systems that supply OpenSSH).
>> Understood.
>>
>>> That sounds like your DSL company decided to block port 22,
>>> which is somewhere between ridiculous and evil.
>>>
>>> (21 is FTP, by the way.)
>> Yes, on port 21 being for ftp, meaning it would have to be blocked as well
>> which   seems frankly impossible.
>>
>>
>>>
>>> 1. Reboot your DSL modem and/or router just in case.
>> Not only has that been done, I actually  got someone at Bell Canada to reset
>> my account information on their side to default.
>> That worked once before when I could not reach dreamhost.
>>> 2. Test that you still can't ssh to server:22
>>> 3. Test that you can't connect via ssh to chat.shazow.net (it
>>> will allow anyone on, no credentials)
>>
>> Okay, did that once producing the same dh key error, but will do it again
>> with /v to note what happens.
>>
>>> 4. Complain to your DSL company.
>>
>> But that is why I desire a server to test that, like here at shellworld, is
>> using something other than port 22.  Otherwise I just get a repeat of the
>> same conversation, we do not support your operating system.
>> Although, I am wondering, if the port were blocked, if  I would get as much
>> information as I am getting from /v?
>
> Show us the whole output.
>
> -dsr-
>
>

[toc] | [prev] | [next] | [standalone]

#198137

On Tue, 31 Jul 2018 17:49:52 -0400 (EDT)
Karen Lewellen <klewellen@shellworld.net> wrote:

> Hi
> just putting my answer at the top.
> My client does have a log option, will aim for that.  still again my
> first priority is finding a place to test  with a nonstandard port.
> then I can be sure  it really is all about port 22 and 21.
> Kare
> 

Do you have access to the client's router? If not, can you ask someone
who does to forward a high port to 22? This is the simplest way of
running sshd on a non-standard port and does not interfere with its
operation on 22. sshd doesn't care about this kind of redirection.

> 
> 
> On Tue, 31 Jul 2018, Dan Ritter wrote:
> 
> > On Tue, Jul 31, 2018 at 01:01:31PM -0400, Karen Lewellen wrote:  
> >> Hi again,

> >>  Otherwise I
> >> just get a repeat of the same conversation, we do not support your
> >> operating system. 

"I'm not paying you to support my operating system, I'm paying you for
a functional Internet connection."

Having said all that, I've often lost contact with an ssh server, but
never seen this kind of error, just a 'timed out' message.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#198133

[Multipart message — attachments visible in raw view] — view raw

On 01/08/18 03:57, Dan Ritter wrote:
> On Tue, Jul 31, 2018 at 11:38:34AM -0400, Karen Lewellen wrote:
>> Hi everyone,
>> While the question seems simple, at least to me, the reason behind it is
>> complicated.  so I am hoping to focus on the question first.
>> During the dh key exchange process, where do the user dh key packets come
>> from software wise?
> 
> You generate a private/public key pair with ssh-keygen, and send
> the public key over to your destination in advance, so that they
> can recognize you.

Yes, but that's not the dh (Diffie-Hellman) key. Diffie-Hellman key
exchange is to generate a one-time session key that is discarded after
the session is finished.

>> I have a problem now where each place I try to visit using my ssh client,
>> and my sftp one, I am getting a dh key exchange failure.
>> using the -v command  is not shedding light on the issue.
>> I am using the same client now to reach another  service, but here  we use a
>> different port from port 22.
>> the error started on the 29th of June, and the company providing my dsl
>> service did claim to have a service issue on that day.
>> However they do not speak Linux let alone anything else Unusual.
>> Thoughts?
> 
> 
> Are you having problems SSHing to all servers that you try, or
> just to one in particular?
> 
> If it's just one, and that one uses a port other than 22, it's
> likely that your DSL company started filtering that port on the
> 29th. 

If it was a simple port filtering issue, then you'd get something like
'Connection Refused' or 'Destination unreachable' or 'Connection timed
out' - you wouldn't get as far as dh key exchange.

I'm not an expert in this, so might have some details wrong, but I think
the gist of it is right. Happy to be corrected.

Richard

[toc] | [prev] | [next] | [standalone]

#198140

Richard Hector wrote:
> On 01/08/18 03:57, Dan Ritter wrote:
>> On Tue, Jul 31, 2018 at 11:38:34AM -0400, Karen Lewellen wrote:
>>> I have a problem now where each place I try to visit using my ssh
>>> client, and my sftp one, I am getting a dh key exchange failure.
>>> using the -v command  is not shedding light on the issue. I am using
>>> the same client now to reach another  service, but here  we use a
>>> different port from port 22. the error started on the 29th of June,
>>> and the company providing my dsl service did claim to have a service
>>> issue on that day. However they do not speak Linux let alone
>>> anything else Unusual.
>>> Thoughts?
>>
>> Are you having problems SSHing to all servers that you try, or
>> just to one in particular?
>>
>> If it's just one, and that one uses a port other than 22, it's
>> likely that your DSL company started filtering that port on the
>> 29th.
>
> If it was a simple port filtering issue, then you'd get something like
> 'Connection Refused' or 'Destination unreachable' or 'Connection timed
> out' - you wouldn't get as far as dh key exchange.
>
> I'm not an expert in this, so might have some details wrong, but I think
> the gist of it is right. Happy to be corrected.

Precisely.  DH failures are typically because one end or the other is
trying to use an "out of bounds" keysize.  E.g. you have a SSH 7.x
client, and the server is 6.0 or lower.

The error message is _probably_ something like this, right (note - may
require "ssh -vv" in order to see):

   debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
   debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
   DH_GEX group out of range: 1536 !< 1024 !< 8192`

The likely cause is that you're trying to use the KexAlgorithm
"diffie-hellman-group-exchange-sha256". 

A simple check to make things work is running the ssh command as 

  ssh -oKexAlgorithms="diffie-hellman-group14-sha1" you@host

This WILL limit you to the single KexAlgorithm noted, but we're only
using it to force a cipher that pretty much will go through.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#198151

Hi,
just a slight update..and correction of an idea below.



On Wed, 1 Aug 2018, Dan Purgert wrote:

> Precisely.  DH failures are typically because one end or the other is
> trying to use an "out of bounds" keysize.  E.g. you have a SSH 7.x
> client, and the server is 6.0 or lower.
Not the case here,
as stated the problem exists, on every server I have tried,  that uses 
port 22.

>
> The error message is _probably_ something like this, right (note - may
> require "ssh -vv" in order to see):
not at all.
As stated I was able to do this until about 5:00 p. m. on the last  Friday 
of   June.
Additionally, one test done this morning, of a server using a port other 
than   22 proves my concern.  I could reach it perfectly.
Granted I intend doing yet another test  on a different server  with only 
the port number changed. However regardless of where I visit, even  when 
I should have no issues  like the chat.shazow  idea,
The error is the same.
> A simple check to make things work is running the ssh command as

My client already allows an option for  some slight dh key manipulation, 
no difference.
I cannot type the command you put here, but  it does not seem to be   the 
fastest solution.

Kare

[toc] | [prev] | [next] | [standalone]

#198154

On August 1, 2018 2:50:39 PM EDT, Karen Lewellen <klewellen@shellworld.net> wrote:
>Hi,
>just a slight update..and correction of an idea below.
>
>
>
>On Wed, 1 Aug 2018, Dan Purgert wrote:
>
>> Precisely.  DH failures are typically because one end or the other is
>> trying to use an "out of bounds" keysize.  E.g. you have a SSH 7.x
>> client, and the server is 6.0 or lower.
>Not the case here,
>as stated the problem exists, on every server I have tried,  that uses 
>port 22.
>

That doesn't prove or disprove anything about a mismatch between client and server versions.

>>
>> The error message is _probably_ something like this, right (note -
>may
>> require "ssh -vv" in order to see):
>not at all.
>As stated I was able to do this until about 5:00 p. m. on the last 
>Friday 
>of   June.
>Additionally, one test done this morning, of a server using a port
>other 
>than   22 proves my concern.  I could reach it perfectly.
>Granted I intend doing yet another test  on a different server  with
>only 
>the port number changed. However regardless of where I visit, even 
>when 
>I should have no issues  like the chat.shazow  idea,
>The error is the same.

As someone else said, it might be your ISP, though if it was them, you'd be getting a different error than the Diffie-Hellman key exchange.

But without seeing logs, it's kind of impossible to see what's going on.

>> A simple check to make things work is running the ssh command as
>
>My client already allows an option for  some slight dh key
>manipulation, 
>no difference.

What client are you using that you can change them?  I mean, the DH Key Exchange parameters are hard-coded in the openssh source (and cannot be changed without recompiling the client).

>I cannot type the command you put here, but  it does not seem to be the fastest solution.

I don't follow what you mean here.

(Apologies to all in case of weird formatting, responding from my mobile)

[toc] | [prev] | [next] | [standalone]

#198155

On 8/1/2018 9:16 PM, Dan Purgert wrote:
> On August 1, 2018 2:50:39 PM EDT, Karen Lewellen <klewellen@shellworld.net> wrote:
>> Hi,
>> just a slight update..and correction of an idea below.
>>
>>
>>
>> On Wed, 1 Aug 2018, Dan Purgert wrote:
>>
>>> Precisely.  DH failures are typically because one end or the other is
>>> trying to use an "out of bounds" keysize.  E.g. you have a SSH 7.x
>>> client, and the server is 6.0 or lower.
>> Not the case here,
>> as stated the problem exists, on every server I have tried,  that uses
>> port 22.
>>
> 
> That doesn't prove or disprove anything about a mismatch between client and server versions.
> 
>>>
>>> The error message is _probably_ something like this, right (note -
>> may
>>> require "ssh -vv" in order to see):
>> not at all.
>> As stated I was able to do this until about 5:00 p. m. on the last
>> Friday
>> of   June.
>> Additionally, one test done this morning, of a server using a port
>> other
>> than   22 proves my concern.  I could reach it perfectly.
>> Granted I intend doing yet another test  on a different server  with
>> only
>> the port number changed. However regardless of where I visit, even
>> when
>> I should have no issues  like the chat.shazow  idea,
>> The error is the same.
> 
> As someone else said, it might be your ISP, though if it was them, you'd be getting a different error than the Diffie-Hellman key exchange.
> 
> But without seeing logs, it's kind of impossible to see what's going on.
> 
>>> A simple check to make things work is running the ssh command as
>>
>> My client already allows an option for  some slight dh key
>> manipulation,
>> no difference.
> 
> What client are you using that you can change them?  I mean, the DH Key Exchange parameters are hard-coded in the openssh source (and cannot be changed without recompiling the client).
> 
>> I cannot type the command you put here, but  it does not seem to be the fastest solution.
> 
> I don't follow what you mean here.
> 
> (Apologies to all in case of weird formatting, responding from my mobile)
> 
> 

TL;DR

You seem to use your own domain name, it might be some policy changes 
that restrict the use of ssh and not your ISP.

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#198156

On Wed, Aug 01, 2018 at 03:16:26PM -0400, Dan Purgert wrote:
> On August 1, 2018 2:50:39 PM EDT, Karen Lewellen <klewellen@shellworld.net> wrote:
> But without seeing logs, it's kind of impossible to see what's going on.

She's been asked for logs and exact error message several times
now, and has not provided any.

-dsr-

[toc] | [prev] | [next] | [standalone]

#198157

Dan Ritter wrote:
> On Wed, Aug 01, 2018 at 03:16:26PM -0400, Dan Purgert wrote:
>> On August 1, 2018 2:50:39 PM EDT, Karen Lewellen <klewellen@shellworld.net> wrote:
>> But without seeing logs, it's kind of impossible to see what's going on.
>
> She's been asked for logs and exact error message several times
> now, and has not provided any.
>
> -dsr-

Indeed.  Kind of defeats the purpose, doesn't it.

The DH thing gave me heartburn for like 3 weeks earlier this year, until
we realized it was the other party using a positively _ancient_ ssh
client.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#198158

Hi,

On Wed, 1 Aug 2018, Dan Ritter wrote:

> She's been asked for logs and exact error message several times
> now, and has not provided any.
That is because according to the locations I am trying to visit, i. e. 
our organizations new server with pair network,  my attempts are not 
producing logs at all.
I did provide them with the errors real time, as at least for the moment, 
I have no other way to capture them.
I did state the error,
Remote host closed connection
DH Key exchange failed
remote reset connection.
that is all I am getting .
As for my comment in another post about the fastest solution, that refers 
to finding a hosting company for our office that provides server  access 
that does not use port 22.
Apparently hostgator is one such company.

  Kare

[toc] | [prev] | [next] | [standalone]

#198162

Karen Lewellen wrote:
> Hi,
>
> On Wed, 1 Aug 2018, Dan Ritter wrote:
>
>> She's been asked for logs and exact error message several times
>> now, and has not provided any.
> That is because according to the locations I am trying to visit, i. e. 
> our organizations new server with pair network,  my attempts are not 
> producing logs at all.

The output when you run the command "ssh -vv" is the log information
that we're asking for.  It's spit out right there on your stderr.  You
can then copy/paste that into a message for us to read.

Now, if you're not using the (linux) command-line ssh client, it would
be kind of a good idea to tell us this information (if you already did,
I apologize, as I missed it).

> [...]
> Remote host closed connection
> DH Key exchange failed
> remote reset connection.
> that is all I am getting .
> As for my comment in another post about the fastest solution, that refers 
> to finding a hosting company for our office that provides server  access 
> that does not use port 22.

Using a port other than 22 has absolutely zero to do with the
diffie-hellman error you are receiving.  If you would run the ssh
commands with higher verbosity (IIRC, minimally "-vv"), you would see
the actual error.

If you feel like testing this assertion out, feel free to ssh as
karen@djph.net. Also try karen@djph.net:2022 (both are non-existant
accounts).

Both ports forward to the same relatively modern server (ssh version
6.7p1+), and I fully expect you to get the error:
    "Permission Denied (publickey)"

Although, that being said, they are also running pretty limited sets of
allowed ciphers/kexalgos/micalgs ... so if it is indeed your client that
is old, you may get some other error, such as a Diffie-Hellman
out-of-range error.

Again, the proper minimal command to get the full logs for review would be 

    ssh -vv karen@djph.net

or

    ssh -vv -p 2022 karen@djph.net


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#198163

1.
I am not using Linux, but an ssh client compiled from a combination of 
tools, Linux and otherwise, including putty.
I have been very firm in not stating that I use Linux at all.
In fact the first sentence of my question stated that while the issue is 
complex, the question, where dh keys are generated, was simple.
2. I can state firmly that the port number  has absolutely a great  deal 
to do with my issue.
best evidence?  your getting this e-mail at all.
I am writing using a shell service that uses Ubuntu 16.04 as its 
platform...same as dreamhost.
we do not use port 22 here, and I can use my ssh client to reach my 
workspace..doing such as we speak..
Likewise  an associate who hosts their  own servers created a temp account 
for   me, using port 4460...worked perfectly.
I respect other factors might  be involved, but my goal is the swiftest 
solution that lets us move our services from dreamhost somewhere else to 
which I can ssh from my desktop.
If choosing a location with a port other than 22 solves the issue, it is 
good enough for me.
Karen



On Thu, 2 Aug 2018, Dan Purgert wrote:

> Karen Lewellen wrote:
>> Hi,
>>
>> On Wed, 1 Aug 2018, Dan Ritter wrote:
>>
>>> She's been asked for logs and exact error message several times
>>> now, and has not provided any.
>> That is because according to the locations I am trying to visit, i. e.
>> our organizations new server with pair network,  my attempts are not
>> producing logs at all.
>
> The output when you run the command "ssh -vv" is the log information
> that we're asking for.  It's spit out right there on your stderr.  You
> can then copy/paste that into a message for us to read.
>
> Now, if you're not using the (linux) command-line ssh client, it would
> be kind of a good idea to tell us this information (if you already did,
> I apologize, as I missed it).
>
>> [...]
>> Remote host closed connection
>> DH Key exchange failed
>> remote reset connection.
>> that is all I am getting .
>> As for my comment in another post about the fastest solution, that refers
>> to finding a hosting company for our office that provides server  access
>> that does not use port 22.
>
> Using a port other than 22 has absolutely zero to do with the
> diffie-hellman error you are receiving.  If you would run the ssh
> commands with higher verbosity (IIRC, minimally "-vv"), you would see
> the actual error.
>
> If you feel like testing this assertion out, feel free to ssh as
> karen@djph.net. Also try karen@djph.net:2022 (both are non-existant
> accounts).
>
> Both ports forward to the same relatively modern server (ssh version
> 6.7p1+), and I fully expect you to get the error:
>    "Permission Denied (publickey)"
>
> Although, that being said, they are also running pretty limited sets of
> allowed ciphers/kexalgos/micalgs ... so if it is indeed your client that
> is old, you may get some other error, such as a Diffie-Hellman
> out-of-range error.
>
> Again, the proper minimal command to get the full logs for review would be
>
>    ssh -vv karen@djph.net
>
> or
>
>    ssh -vv -p 2022 karen@djph.net
>
>
> -- 
> |_|O|_| Registered Linux user #585947
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281
>
>

[toc] | [prev] | [next] | [standalone]

#198166

Karen Lewellen wrote:
> 1.
> I am not using Linux, but an ssh client compiled from a combination of 
> tools, Linux and otherwise, including putty.
> I have been very firm in not stating that I use Linux at all.

Kind of a bad move, what with this being a Debian (Linux) mailing list.
Lot of wasted effort would've been saved.

> In fact the first sentence of my question stated that while the issue is 
> complex, the question, where dh keys are generated, was simple.

They're generated on the fly at the time of connection.  The server and
client each (should) have a "moduli" file somewhere, where they can seed
the DH key generation from (in whichever version of Debian I'm running
on this test box, it happens to be /etc/ssh/moduli)

> 2. I can state firmly that the port number  has absolutely a great  deal 
> to do with my issue.

You can say that til you're blue in the face, it doesn't make you
correct though.  As I said before, the selection of a standard vs.
nonstandard port for ssh (or, any service for that matter) has no
bearing on the Diffie-Hellman Key Exchange portion of the handshake.

> best evidence?  your getting this e-mail at all.

I assume you mean to imply that you're ssh'd into some remote host and
it just so happens to be running a service on a nonstandard port.  See
above for the refutation of this claim.

> I am writing using a shell service that uses Ubuntu 16.04 as its 
> platform...same as dreamhost.
> we do not use port 22 here, and I can use my ssh client to reach my 
> workspace..doing such as we speak..
> Likewise  an associate who hosts their  own servers created a temp account 
> for   me, using port 4460...worked perfectly.
> I respect other factors might  be involved, but my goal is the swiftest 
> solution that lets us move our services from dreamhost somewhere else to 
> which I can ssh from my desktop/
> If choosing a location with a port other than 22 solves the issue, it is 
> good enough for me.

The thing is, it's NOT the selection of the port that's making it work
(or not) - it's a difference between your SSH client and the server's
acceptable range for key moduli.  

For Openssh 6.7p1
  DH_GRP_MIN  1024
  DH_GRP_MAX  8192


For Openssh 7.4
  DH_GRP_MIN 2048
  DH_GRP_MIN 8192

Since you're running a series of ssh clients (? ... or a amalgamation of
all of them ...?), it's up to you to check the various changelogs of
them to see if you need updates (or if they've been abandoned or ... )


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#198168

There is no error at all in any way shape or form that I am given 
indicating that there is a key range overflow.
I have successfully reached  locations with various editions of openssh, 
including in the 7 plus range...on a different port. 
There are some indications likewise  that my isp indeed blocked port 22 
and 
21 access for what they consider non standard applications i. e. Linux, 
which  is not on my desktop, or DOS, which is on my desktop.
i cannot update what does not exist for me.
I can however invest resources  where the solution  I have discovered does exist.
Karen



On Thu, 2 Aug 2018, Dan Purgert wrote:

> Karen Lewellen wrote:
>> 1.
>> I am not using Linux, but an ssh client compiled from a combination of
>> tools, Linux and otherwise, including putty.
>> I have been very firm in not stating that I use Linux at all.
>
> Kind of a bad move, what with this being a Debian (Linux) mailing list.
> Lot of wasted effort would've been saved.
>
>> In fact the first sentence of my question stated that while the issue is
>> complex, the question, where dh keys are generated, was simple.
>
> They're generated on the fly at the time of connection.  The server and
> client each (should) have a "moduli" file somewhere, where they can seed
> the DH key generation from (in whichever version of Debian I'm running
> on this test box, it happens to be /etc/ssh/moduli)
>
>> 2. I can state firmly that the port number  has absolutely a great  deal
>> to do with my issue.
>
> You can say that til you're blue in the face, it doesn't make you
> correct though.  As I said before, the selection of a standard vs.
> nonstandard port for ssh (or, any service for that matter) has no
> bearing on the Diffie-Hellman Key Exchange portion of the handshake.
>
>> best evidence?  your getting this e-mail at all.
>
> I assume you mean to imply that you're ssh'd into some remote host and
> it just so happens to be running a service on a nonstandard port.  See
> above for the refutation of this claim.
>
>> I am writing using a shell service that uses Ubuntu 16.04 as its
>> platform...same as dreamhost.
>> we do not use port 22 here, and I can use my ssh client to reach my
>> workspace..doing such as we speak..
>> Likewise  an associate who hosts their  own servers created a temp account
>> for   me, using port 4460...worked perfectly.
>> I respect other factors might  be involved, but my goal is the swiftest
>> solution that lets us move our services from dreamhost somewhere else to
>> which I can ssh from my desktop/
>> If choosing a location with a port other than 22 solves the issue, it is
>> good enough for me.
>
> The thing is, it's NOT the selection of the port that's making it work
> (or not) - it's a difference between your SSH client and the server's
> acceptable range for key moduli.
>
> For Openssh 6.7p1
>  DH_GRP_MIN  1024
>  DH_GRP_MAX  8192
>
>
> For Openssh 7.4
>  DH_GRP_MIN 2048
>  DH_GRP_MIN 8192
>
> Since you're running a series of ssh clients (? ... or a amalgamation of
> all of them ...?), it's up to you to check the various changelogs of
> them to see if you need updates (or if they've been abandoned or ... )
>
>
> -- 
> |_|O|_| Registered Linux user #585947
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281
>
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web