Ssh problem

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Ssh problem

Philip Webb-2
I updated Ssh yesterday :

  net-misc/openssh
  Available versions:  7.5_p1-r4 7.7_p1-r9^t 7.9_p1-r4^t {X X509 audit bindist debug (+)hpn kerberos ldap ldns libedit libressl livecd pam +pie sctp selinux skey ssh1 +ssl static test ABI_MIPS="n32" KERNEL="linux"}
  Installed versions:  7.9_p1-r4^t([2019-03-09 22:25:11])(X ssl -X509 -audit -bindist -debug -hpn -kerberos -ldns -libedit -libressl -livecd -pam -pie -sctp -selinux -static -test ABI_MIPS="-n32" KERNEL="linux")

Previously, I was using :  net-misc/openssh-7.7_p1-r9 .

Today, I tried to access an off-site via Ssh ,
which I've been doing for years & got this :

  ssh x.y.z
  Unable to negotiate with 128.100.160.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

'x.y.z' disguises the site's URL, which doesn't seem to be a problem.

Can anyone suggest what's gone wrong ?

--
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca


Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem

Nikos Chantziaras-2
On 10/03/2019 09:25, Philip Webb wrote:
> no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

First hit on a web search:

https://unix.stackexchange.com/questions/340844/how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0


Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem

Nils Freydank
In reply to this post by Philip Webb-2
Hi Philip,

Am Sonntag, 10. März 2019, 08:25:54 CET schrieb Philip Webb:
> I updated Ssh yesterday :
> [...]
>   ssh x.y.z
>   Unable to negotiate with 128.100.160.1 port 22: no matching key
> exchange method found. Their offer:
> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
ssh tells you straight forward what the issue is: Within the key exchange
at the begin of the communication there was no way to establish a
connection between the server and the client, probably because the client
has a more secure setup than the server. This happens mostly due to old ssh
versions serverside.

You can find solutions pretty fast by just searching for "Their offer: <key
exchange offers>", e.g. https://unix.stackexchange.com/questions/340844/
how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0

(Please enable legacy and possible less secure key exchange formats and
ciphers only per server and not globally - and if possible upgrade the SSH
server version.)

> 'x.y.z' disguises the site's URL, which doesn't seem to be a problem.
That is indeed perfectly fine; you might want to hide the IP address in the
future aswell ;-)


Greetings,
Nils

--
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Philip Webb-2
190310 Nils Freydank wrote:

> Am Sonntag, 10. März 2019, 08:25:54 CET schrieb Philip Webb:
>> I updated Ssh yesterday :
>> [...]
>>   ssh x.y.z
>>   Unable to negotiate with 128.100.160.1 port 22: no matching key
>> exchange method found. Their offer:
>> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> ssh tells you straight forward what the issue is:
> Within the key exchange at the begin of the communication
> there was no way to establish a connection between server and client,
> probably because the client has a more secure setup than the server.
> This happens mostly due to old ssh versions serverside.

Yes, they mb a bit slow to upgrade.

> You can find solutions pretty fast
> by just searching for "Their offer: <key exchange offers>",
> e.g. https://unix.stackexchange.com/questions/340844/
> how-to-enable-diffie-hellman-group1-sha1-key-exchange-on-debian-8-0

That forum contains a solution :

  ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 123.123.123.123

That gets me thro' & I can do my work there.

> Enable legacy and possible less secure key exchange formats and ciphers
> only per server and not globally
> and if possible upgrade the SSH server version.

However, I've tried to insert an instruction in config files,
but nothing changes after a reboot.
I've tried adding to  ~/.ssh/config  &  /etc/ssh/ssh_config :

  Host 128.100.160.1
    KexAlgorithms +diffie-hellman-group1-sha1

That is what seems to be required by 'man 5 ssh_config'.

Can anyone suggest what + where to tell Ssh to do it every time ?

>> 'x.y.z' disguises the site's URL, which doesn't seem to be a problem.
> That is indeed perfectly fine;
> you might want to hide the IP address in the future as well ;-)

Indeed (red face) : it was at the end of my day.
No point in trying to hide it now (wry smile).

--
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca


Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Mick-10
On Monday, 11 March 2019 05:41:19 GMT Philip Webb wrote:

[snip ...]

> However, I've tried to insert an instruction in config files,
> but nothing changes after a reboot.
> I've tried adding to  ~/.ssh/config  &  /etc/ssh/ssh_config :
>
>   Host 128.100.160.1
>     KexAlgorithms +diffie-hellman-group1-sha1
>
> That is what seems to be required by 'man 5 ssh_config'.
>
> Can anyone suggest what + where to tell Ssh to do it every time ?
You probably have more than one User and identity file and you could define
them both in .ssh/config to make sure the correct user is invoked, without
having to add it to the CLI:

Host 128.100.160.1
User my_remote_ssh_user
IdentityFile /home/<username>/.ssh/id_rsa
KexAlgorithms +diffie-hellman-group1-sha1

--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Neil Bothwick
In reply to this post by Philip Webb-2
On Mon, 11 Mar 2019 01:41:19 -0400, Philip Webb wrote:

> That forum contains a solution :
>
>   ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 123.123.123.123
>
> That gets me thro' & I can do my work there.
>
> > Enable legacy and possible less secure key exchange formats and
> > ciphers only per server and not globally
> > and if possible upgrade the SSH server version.  
>
> However, I've tried to insert an instruction in config files,
> but nothing changes after a reboot.
> I've tried adding to  ~/.ssh/config  &  /etc/ssh/ssh_config :
>
>   Host 128.100.160.1
>     KexAlgorithms +diffie-hellman-group1-sha1
>
> That is what seems to be required by 'man 5 ssh_config'.
Try without the +, that works for me here. I have an appliance that uses
outdated algorithms and this config works for me

Host 1.2.3.4
    Ciphers 3des-cbc
    KexAlgorithms diffie-hellman-group1-sha1
    HostKeyAlgorithms ssh-dss


--
Neil Bothwick

New sig wanted good price paid.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Mick-10
On Monday, 11 March 2019 08:31:33 GMT Neil Bothwick wrote:

> On Mon, 11 Mar 2019 01:41:19 -0400, Philip Webb wrote:
> > That forum contains a solution :
> >   ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 123.123.123.123
> >
> > That gets me thro' & I can do my work there.
> >
> > > Enable legacy and possible less secure key exchange formats and
> > > ciphers only per server and not globally
> > > and if possible upgrade the SSH server version.
> >
> > However, I've tried to insert an instruction in config files,
> > but nothing changes after a reboot.
> >
> > I've tried adding to  ~/.ssh/config  &  /etc/ssh/ssh_config :
> >   Host 128.100.160.1
> >  
> >     KexAlgorithms +diffie-hellman-group1-sha1
> >
> > That is what seems to be required by 'man 5 ssh_config'.
>
> Try without the +, that works for me here. I have an appliance that uses
> outdated algorithms and this config works for me
>
> Host 1.2.3.4
>     Ciphers 3des-cbc
>     KexAlgorithms diffie-hellman-group1-sha1
>     HostKeyAlgorithms ssh-dss
As I understand it the "+" merely adds one more cipher to the collection.  
This is probably safer.  If the server has been updated and non-legacy key
exchange algorithms are now available they can be used.  Without "+" the
directive for the client is exclusive:  only use this algorithm and nothing
else.
--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Neil Bothwick
On Mon, 11 Mar 2019 08:43:52 +0000, Mick wrote:

> > Try without the +, that works for me here. I have an appliance that
> > uses outdated algorithms and this config works for me
> >
> > Host 1.2.3.4
> >     Ciphers 3des-cbc
> >     KexAlgorithms diffie-hellman-group1-sha1
> >     HostKeyAlgorithms ssh-dss  
>
> As I understand it the "+" merely adds one more cipher to the
> collection. This is probably safer.  If the server has been updated and
> non-legacy key exchange algorithms are now available they can be used.
> Without "+" the directive for the client is exclusive:  only use this
> algorithm and nothing else.
That's how I read it, but it says it appends to the list, so this is the
last option tried, while an earlier one could possibly be triggering the
failure. With + would be better, but it would be worth trying without.


--
Neil Bothwick

""  "   """  "  ""   "  """  <-- random quotes

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Philip Webb-2
190311 Neil Bothwick + Mick wrote:
NB> Try without the +, that works for me here.  I have an appliance
> that uses outdated algorithms and this config works for me
>   Host 1.2.3.4
>   Ciphers 3des-cbc
>   KexAlgorithms diffie-hellman-group1-sha1
>   HostKeyAlgorithms ssh-dss  

I tried adding the  2  extra lines to ~/.ssh/config , but no joy.
I didn't reboot, but it's not clear that that would make any difference.

M> As I understand it the "+" merely adds one more cipher to the collection.
> This is probably safer.  If the server has been updated
> and non-legacy key exchange algorithms are now available they can be used.
> Without "+" the directive for the client is exclusive :
> only use this algorithm and nothing else.

That's what the 'man' says.

NB> That's how I read it, but it says it appends to the list,
> so this is the last option tried,
> while an earlier one could possibly be triggering the failure.
> With + would be better, but it would be worth trying without.

I tried both & neither gets Ssh to recognise the config.

This is a puzzle : are they any other suggestions ?

--
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca


Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

William Kenworthy
On 11/3/19 5:23 pm, Philip Webb wrote:

> 190311 Neil Bothwick + Mick wrote:
> NB> Try without the +, that works for me here.  I have an appliance
>> that uses outdated algorithms and this config works for me
>>   Host 1.2.3.4
>>   Ciphers 3des-cbc
>>   KexAlgorithms diffie-hellman-group1-sha1
>>   HostKeyAlgorithms ssh-dss  
> I tried adding the  2  extra lines to ~/.ssh/config , but no joy.
> I didn't reboot, but it's not clear that that would make any difference.
>
> M> As I understand it the "+" merely adds one more cipher to the collection.
>> This is probably safer.  If the server has been updated
>> and non-legacy key exchange algorithms are now available they can be used.
>> Without "+" the directive for the client is exclusive :
>> only use this algorithm and nothing else.
> That's what the 'man' says.
>
> NB> That's how I read it, but it says it appends to the list,
>> so this is the last option tried,
>> while an earlier one could possibly be triggering the failure.
>> With + would be better, but it would be worth trying without.
> I tried both & neither gets Ssh to recognise the config.
>
> This is a puzzle : are they any other suggestions ?
>
This works for me (ancient Cisco ...)

rattus ~ # cat ~/.ssh/config
Host 192.168.44.1
       KexAlgorithms +diffie-hellman-group1-sha1
Host ghost
       KexAlgorithms +diffie-hellman-group1-sha1

Which file are putting it in? - this is the client side user.


Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Neil Bothwick
In reply to this post by Philip Webb-2
On Mon, 11 Mar 2019 05:23:36 -0400, Philip Webb wrote:

> NB> That's how I read it, but it says it appends to the list,
> > so this is the last option tried,
> > while an earlier one could possibly be triggering the failure.
> > With + would be better, but it would be worth trying without.  
>
> I tried both & neither gets Ssh to recognise the config.

Have you run ssh with -v to see what configuration options it is reading
from where.

Bear in mind that ssh stops at the first matching host definition, so if
you have a "host *" in your config, it must be last.


--
Neil Bothwick

When puns are outlawed only outlaws will have puns.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Philip Webb-2
190311 Neil Bothwick wrote:
> Have you run ssh with -v
> to see what configuration options it is reading from where.
> Bear in mind that ssh stops at the first matching host definition,
> so if you have a "host *" in your config, it must be last.

This is what I get :

  522: ~> ssh -v <URL>
  OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
  debug1: Reading configuration data /home/purslow/.ssh/config
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: Connecting to <URL> <IP> port 22.
  debug1: Connection established.
  debug1: identity file /home/purslow/.ssh/id_rsa type -1
  debug1: identity file /home/purslow/.ssh/id_rsa-cert type -1
  debug1: identity file /home/purslow/.ssh/id_dsa type -1
  debug1: identity file /home/purslow/.ssh/id_dsa-cert type -1
  debug1: identity file /home/purslow/.ssh/id_ecdsa type -1
  debug1: identity file /home/purslow/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/purslow/.ssh/id_ed25519 type -1
  debug1: identity file /home/purslow/.ssh/id_ed25519-cert type -1
  debug1: identity file /home/purslow/.ssh/id_xmss type -1
  debug1: identity file /home/purslow/.ssh/id_xmss-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_7.9
  debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2
  debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* compat 0x01000002
  debug1: Authenticating to <URL>:22 as 'purslow'
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug1: kex: algorithm: (no match)
  Unable to negotiate with <IP> port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Is that any help ?

--
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca


Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Neil Bothwick
On Mon, 11 Mar 2019 09:08:14 -0400, Philip Webb wrote:

> 190311 Neil Bothwick wrote:
> > Have you run ssh with -v
> > to see what configuration options it is reading from where.
> > Bear in mind that ssh stops at the first matching host definition,
> > so if you have a "host *" in your config, it must be last.  
>
> This is what I get :
>
>   522: ~> ssh -v <URL>
>   OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
>   debug1: Reading configuration data /home/purslow/.ssh/config
>   debug1: Reading configuration data /etc/ssh/ssh_config
>   debug1: Connecting to <URL> <IP> port 22.
>   debug1: Connection established.
>   debug1: identity file /home/purslow/.ssh/id_rsa type -1
>   debug1: identity file /home/purslow/.ssh/id_rsa-cert type -1
>   debug1: identity file /home/purslow/.ssh/id_dsa type -1
>   debug1: identity file /home/purslow/.ssh/id_dsa-cert type -1
>   debug1: identity file /home/purslow/.ssh/id_ecdsa type -1
>   debug1: identity file /home/purslow/.ssh/id_ecdsa-cert type -1
>   debug1: identity file /home/purslow/.ssh/id_ed25519 type -1
>   debug1: identity file /home/purslow/.ssh/id_ed25519-cert type -1
>   debug1: identity file /home/purslow/.ssh/id_xmss type -1
>   debug1: identity file /home/purslow/.ssh/id_xmss-cert type -1
>   debug1: Local version string SSH-2.0-OpenSSH_7.9
>   debug1: Remote protocol version 2.0, remote software version
> OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* compat
> 0x01000002 debug1: Authenticating to <URL>:22 as 'purslow'
>   debug1: SSH2_MSG_KEXINIT sent
>   debug1: SSH2_MSG_KEXINIT received
>   debug1: kex: algorithm: (no match)
>   Unable to negotiate with <IP> port 22: no matching key exchange
> method found. Their offer:
> diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
>
> Is that any help ?
It shows that ssh is reading your config file, but not picking up the
options for this host. I would expect to see something like

debug1: Reading configuration data /home/nelz/.config/ssh
debug1: /home/nelz/.config/ssh line N: Applying options for <HOST>

Do you have any other Host stanzas in the config?


--
Neil Bothwick

Make it idiot proof and someone will make a better idiot.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Mick-10
On Monday, 11 March 2019 13:42:14 GMT Neil Bothwick wrote:

> On Mon, 11 Mar 2019 09:08:14 -0400, Philip Webb wrote:
> > 190311 Neil Bothwick wrote:
> > > Have you run ssh with -v
> > > to see what configuration options it is reading from where.
> > > Bear in mind that ssh stops at the first matching host definition,
> > > so if you have a "host *" in your config, it must be last.
> >
> > This is what I get :
> >   522: ~> ssh -v <URL>
> >   OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
> >   debug1: Reading configuration data /home/purslow/.ssh/config
> >   debug1: Reading configuration data /etc/ssh/ssh_config
> >   debug1: Connecting to <URL> <IP> port 22.
> >   debug1: Connection established.
> >   debug1: identity file /home/purslow/.ssh/id_rsa type -1
> >   debug1: identity file /home/purslow/.ssh/id_rsa-cert type -1
> >   debug1: identity file /home/purslow/.ssh/id_dsa type -1
> >   debug1: identity file /home/purslow/.ssh/id_dsa-cert type -1
> >   debug1: identity file /home/purslow/.ssh/id_ecdsa type -1
> >   debug1: identity file /home/purslow/.ssh/id_ecdsa-cert type -1
> >   debug1: identity file /home/purslow/.ssh/id_ed25519 type -1
> >   debug1: identity file /home/purslow/.ssh/id_ed25519-cert type -1
> >   debug1: identity file /home/purslow/.ssh/id_xmss type -1
> >   debug1: identity file /home/purslow/.ssh/id_xmss-cert type -1
> >   debug1: Local version string SSH-2.0-OpenSSH_7.9
> >   debug1: Remote protocol version 2.0, remote software version
> >
> > OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* compat
> > 0x01000002 debug1: Authenticating to <URL>:22 as 'purslow'
> >
> >   debug1: SSH2_MSG_KEXINIT sent
> >   debug1: SSH2_MSG_KEXINIT received
> >   debug1: kex: algorithm: (no match)
> >   Unable to negotiate with <IP> port 22: no matching key exchange
> >
> > method found. Their offer:
> > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> >
> > Is that any help ?
>
> It shows that ssh is reading your config file, but not picking up the
> options for this host. I would expect to see something like
>
> debug1: Reading configuration data /home/nelz/.config/ssh
> debug1: /home/nelz/.config/ssh line N: Applying options for <HOST>
>
> Do you have any other Host stanzas in the config?
Check both config files for conflicts:

/home/purslow/.ssh/config
/etc/ssh/ssh_config

just in case it is defined in both.
--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Neil Bothwick
On Mon, 11 Mar 2019 16:06:59 +0000, Mick wrote:

> > It shows that ssh is reading your config file, but not picking up the
> > options for this host. I would expect to see something like
> >
> > debug1: Reading configuration data /home/nelz/.config/ssh
> > debug1: /home/nelz/.config/ssh line N: Applying options for <HOST>
> >
> > Do you have any other Host stanzas in the config?  
>
> Check both config files for conflicts:
>
> /home/purslow/.ssh/config
> /etc/ssh/ssh_config
>
> just in case it is defined in both.
The user file should take precedence in that case. ssh checks that one
first and stops looking if it finds a host match there.


--
Neil Bothwick

Linux like wigwam. No windows, no gates, Apache inside.

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Mick-10
On Monday, 11 March 2019 17:34:20 GMT Neil Bothwick wrote:

> On Mon, 11 Mar 2019 16:06:59 +0000, Mick wrote:
> > > It shows that ssh is reading your config file, but not picking up the
> > > options for this host. I would expect to see something like
> > >
> > > debug1: Reading configuration data /home/nelz/.config/ssh
> > > debug1: /home/nelz/.config/ssh line N: Applying options for <HOST>
> > >
> > > Do you have any other Host stanzas in the config?
> >
> > Check both config files for conflicts:
> >
> > /home/purslow/.ssh/config
> > /etc/ssh/ssh_config
> >
> > just in case it is defined in both.
>
> The user file should take precedence in that case. ssh checks that one
> first and stops looking if it finds a host match there.
Quite and if it finds the wrong setup there, it'll run with it.

--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Neil Bothwick
On Mon, 11 Mar 2019 21:35:54 +0000, Mick wrote:

> > > > It shows that ssh is reading your config file, but not picking up
> > > > the options for this host. I would expect to see something like
> > > >
> > > > debug1: Reading configuration data /home/nelz/.config/ssh
> > > > debug1: /home/nelz/.config/ssh line N: Applying options for <HOST>
> > > >
> > > > Do you have any other Host stanzas in the config?  
> > >
> > > Check both config files for conflicts:
> > >
> > > /home/purslow/.ssh/config
> > > /etc/ssh/ssh_config
> > >
> > > just in case it is defined in both.  
> >
> > The user file should take precedence in that case. ssh checks that one
> > first and stops looking if it finds a host match there.  
>
> Quite and if it finds the wrong setup there, it'll run with it.
Exactly, which is why I asked the question. It seems we are both saying
the same thing :) Th output shows only the user file being read.


--
Neil Bothwick

"Self-explanatory": technospeak for "Incomprehensible & undocumented"

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Philip Webb-2
190311 Neil Bothwick wrote:
> Do you have any other Host stanzas in the config?  

No :  /etc/ssh/ssh_config  has the following uncommented lines :

  # Send locale environment variables. #367017
  SendEnv LANG LC_ALL LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME LANGUAGE LC_ADDRESS LC_IDENTIFICATION LC_MEASUREMENT LC_NAME LC_PAPER LC_TELEPHONE
  # Send COLORTERM to match TERM. #658540
  SendEnv COLORTERM
  # PP 190312
  Host 128.100.160.1
    KexAlgorithms +diffie-hellman-group1-sha1
  # Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr

I tried adding the 'Ciphers' line, which is mentioned in the I/net page,
but Ssh chokes, so I commented it again :

  528: ~> ssh -v chass.utoronto.ca
  OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
  debug1: Reading configuration data /home/purslow/.ssh/config
  debug1: Reading configuration data /etc/ssh/ssh_config
  /etc/ssh/ssh_config line 57: Bad SSH2 cipher spec '3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr'.
 
> Check both config files for conflicts

 ~/.ssh/config  has :

  Host 128.100.160.1
    KexAlgorithms +diffie-hellman-group1-sha1

The latest output ('538' above) shows that it reads  ~/.ssh/config ,
but apparently doesn't find what it wants there
& therefore goes on to  /etc/ssh/ssh_config , on which it chokes.
Without the 'Cipher' line in the latter, it carries on with the handshake,
but eventually can't do the key exchange.

I've just looked at the USE flags :

  root:528 ssh> eix net-misc/openssh
     Available versions:  7.5_p1-r4 7.7_p1-r9^t 7.9_p1-r4^t {X X509 audit bindist debug (+)hpn kerberos ldap ldns libedit libressl livecd pam +pie sctp selinux skey ssh1 +ssl static test ABI_MIPS="n32" KERNEL="linux"}
     Installed versions:  7.9_p1-r4^t([2019-03-09 22:25:11])(X ssl -X509 -audit -bindist -debug -hpn -kerberos -ldns -libedit -libressl -livecd -pam -pie -sctp -selinux -static -test ABI_MIPS="-n32" KERNEL="linux")

NB Eix shows a Use flag 'ssh1', which Euses describes as :

  net-misc/openssh:ssh1 - Support the legacy/weak SSH1 protocol

That looks as if it sb enabled, but when I try to enable it,
it's available only for the oldest version :

  root:529 ssh> USE="ssh1" emerge -pv =openssh-7.5_p1-r4

  Calculating dependencies... done!
  [ebuild UD] net-misc/openssh-7.5_p1-r4::gentoo [7.9_p1-r4::gentoo] USE="X -X509 -audit -bindist -debug -hpn -kerberos -ldap% -ldns -libedit -libressl -livecd -pam -pie -sctp (-selinux) -skey% ssh1%* ssl -static -test"

  root:530 ssh> USE="ssh1" emerge -pv =openssh-7.7_p1-r9

  Calculating dependencies... done!
  [ebuild UD] net-misc/openssh-7.7_p1-r9::gentoo [7.9_p1-r4::gentoo] USE="X -X509 -audit -bindist -debug -hpn -kerberos -ldns -libedit -libressl -livecd -pam -pie -sctp (-selinux) -skey% ssl -static -test"

  root:531 ssh> USE="ssh1" emerge -pv =openssh-7.9_p1-r4

  Calculating dependencies... done!
  [ebuild R] net-misc/openssh-7.9_p1-r4::gentoo  USE="X -X509 -audit -bindist -debug -hpn -kerberos -ldns -libedit -libressl -livecd -pam -pie -sctp (-selinux) ssl -static -test"

Can anyone offer further advice ? -- Thanks so far.

--
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca


Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Mick-10
Hi Philip,

On Tuesday, 12 March 2019 10:02:07 GMT Philip Webb wrote:

> 190311 Neil Bothwick wrote:
> > Do you have any other Host stanzas in the config?
>
> No :  /etc/ssh/ssh_config  has the following uncommented lines :
>
>   # Send locale environment variables. #367017
>   SendEnv LANG LC_ALL LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC
> LC_TIME LANGUAGE LC_ADDRESS LC_IDENTIFICATION LC_MEASUREMENT LC_NAME
> LC_PAPER LC_TELEPHONE # Send COLORTERM to match TERM. #658540
>   SendEnv COLORTERM
>   # PP 190312
>   Host 128.100.160.1
>     KexAlgorithms +diffie-hellman-group1-sha1
>   # Ciphers 3des-cbc,blowfish-cbc,aes128-cbc,aes128-ctr,aes256-ctr
>
> I tried adding the 'Ciphers' line, which is mentioned in the I/net page,
> but Ssh chokes, so I commented it again :
The ciphers do not come into play until the key exchange algos have been
agreed upon.  In your case the handshake does not reach this far and therefore
you do not need (yet) to specify any additional ciphers.  The server problem
is still with the KexAlgorithms.

>  ~/.ssh/config  has :
>
>   Host 128.100.160.1
>     KexAlgorithms +diffie-hellman-group1-sha1
>
> The latest output ('538' above) shows that it reads  ~/.ssh/config ,
> but apparently doesn't find what it wants there
> & therefore goes on to  /etc/ssh/ssh_config , on which it chokes.
> Without the 'Cipher' line in the latter, it carries on with the handshake,
> but eventually can't do the key exchange.
>
> I've just looked at the USE flags :
>
>   root:528 ssh> eix net-misc/openssh
>      Available versions:  7.5_p1-r4 7.7_p1-r9^t 7.9_p1-r4^t {X X509 audit
> bindist debug (+)hpn kerberos ldap ldns libedit libressl livecd pam +pie
> sctp selinux skey ssh1 +ssl static test ABI_MIPS="n32" KERNEL="linux"}
> Installed versions:  7.9_p1-r4^t([2019-03-09 22:25:11])(X ssl -X509 -audit
> -bindist -debug -hpn -kerberos -ldns -libedit -libressl -livecd -pam -pie
> -sctp -selinux -static -test ABI_MIPS="-n32" KERNEL="linux")
>
> NB Eix shows a Use flag 'ssh1', which Euses describes as :
>
>   net-misc/openssh:ssh1 - Support the legacy/weak SSH1 protocol
If you watch The Matrix, a 20 year old film, you will see why ssh version 1
should be disabled by default, or the machine on which it is enabled isolated
from the Internet.


> Can anyone offer further advice ? -- Thanks so far.

I suggest you remove all settings for Host 128.100.160.1 from the /etc/ssh/
ssh_config file and place them in your ~/.ssh/config file only.  Then run ssh:

ssh -v 128.100.160.1

and check for a line like this:

debug1: Reading configuration data /home/purslow/.ssh/config
debug1: /home/purslow/.ssh/config line xx: Applying options for 128.100.160.1
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 128.100.160.1 ... blah-blah

This will show you if ~/.ssh/config is being sourced, if the lines you have
specified for Host 128.100.160.1 therein are being parsed by ssh and if the
connection is attempted.

The line which should come next is:

debug1: Connection established.

which will be followed with algos and ciphers exchange.

HTH.
--
Regards,
Mick

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ssh problem : half-solved

Philip Webb-2
190312 Mick wrote:
> On Tuesday, 12 March 2019 10:02:07 GMT Philip Webb wrote:
>> I tried adding the 'Ciphers' line, which is mentioned in the I/net page,
>> but Ssh chokes, so I commented it again :
> The ciphers do not come into play
> until the key exchange algos have been agreed upon.
> In your case the handshake does not reach this far
> and therefore you do not need (yet) to specify any additional ciphers.
> The server problem is still with the KexAlgorithms.

Yes, that seems sensible.

>> NB Eix shows a Use flag 'ssh1', which Euses describes as :
>>   net-misc/openssh:ssh1 - Support the legacy/weak SSH1 protocol
> If you watch The Matrix, a 20 year old film,
> you will see why ssh version 1 should be disabled by default
> or the machine on which it is enabled isolated from the Internet.
> I suggest you remove all settings for Host 128.100.160.1
> from the /etc/ssh/ssh_config file
> and place them in your ~/.ssh/config file only.
> Then run : 'ssh -v 128.100.160.1'

Progress, but still a puzzle.  I commented the lines in  /etc/...
& when I use the IP, not the URL, the connection goes thro' ;
when I use the URL, it still doesn't.  Here's the output :

  561: ~> ssh -v 128.100.160.1
OpenSSH_7.9p1, OpenSSL 1.0.2r  26 Feb 2019
debug1: Reading configuration data /home/purslow/.ssh/config
debug1: /home/purslow/.ssh/config line 1: Applying options for 128.100.160.1
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 128.100.160.1 [128.100.160.1] port 22.
debug1: Connection established.
debug1: identity file /home/purslow/.ssh/id_rsa type -1
debug1: identity file /home/purslow/.ssh/id_rsa-cert type -1
debug1: identity file /home/purslow/.ssh/id_dsa type -1
debug1: identity file /home/purslow/.ssh/id_dsa-cert type -1
debug1: identity file /home/purslow/.ssh/id_ecdsa type -1
debug1: identity file /home/purslow/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/purslow/.ssh/id_ed25519 type -1
debug1: identity file /home/purslow/.ssh/id_ed25519-cert type -1
debug1: identity file /home/purslow/.ssh/id_xmss type -1
debug1: identity file /home/purslow/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2
debug1: match: OpenSSH_3.7.1p2 pat OpenSSH_3.* compat 0x01000002
debug1: Authenticating to 128.100.160.1:22 as 'purslow'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha1
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: 3des-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: 3des-cbc MAC: hmac-sha1 compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:QrYQ/7OU5PUyPucvn/Yxj7/xLmsOH/tqfBGaocfSuaw
debug1: Host '128.100.160.1' is known and matches the RSA host key.
debug1: Found key in /home/purslow/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/purslow/.ssh/id_rsa
debug1: Will attempt key: /home/purslow/.ssh/id_dsa
debug1: Will attempt key: /home/purslow/.ssh/id_ecdsa
debug1: Will attempt key: /home/purslow/.ssh/id_ed25519
debug1: Will attempt key: /home/purslow/.ssh/id_xmss
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/purslow/.ssh/id_rsa
debug1: Trying private key: /home/purslow/.ssh/id_dsa
debug1: Trying private key: /home/purslow/.ssh/id_ecdsa
debug1: Trying private key: /home/purslow/.ssh/id_ed25519
debug1: Trying private key: /home/purslow/.ssh/id_xmss
debug1: Next authentication method: password
purslow@128.100.160.1's password:

> and check for a line like this:
>   debug1: Reading configuration data /home/purslow/.ssh/config
>   debug1: /home/purslow/.ssh/config line xx: Applying options for 128.100.160.1
>   debug1: Reading configuration data /etc/ssh/ssh_config
>   debug1: Connecting to 128.100.160.1 ... blah-blah

As you can see, that's what I got above.

> This will show you if ~/.ssh/config is being sourced,
> if the lines you have specified for Host 128.100.160.1 therein
> are being parsed by ssh and if the connection is attempted.
> The line which should come next is:
>   debug1: Connection established.

There it is.

> which will be followed with algos and ciphers exchange.

As above.

> HTH.

Indeed, but not in the way you intended.

So why does IP vs URL make a difference ??

--
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca


12