Re: [gentoo-user] ssh problem
211226 Michael wrote: > On Sun, 26 Dec 2021 11:42:41 -0500, Philip Webb wrote: >> I want to login to a remote site using 'ssh'. >> The response I get is "Unable to negotiate with port >> : no matching host key type found. Their offer: ssh-rsa,ssh-dss". >> Yesterday, I updated 'openssh' : > It sounds like the host may be running an old version of sshd > that only offers ciphers that are now disabled by default in newer releases. > You can get round this by enabling those ciphers for this host, > with something like this in ssh_config : 'HostKeyAlgorithms +ssh-rsa'. Thanks to all the respondents : adding that line makes it work again. I've made a note of the Ssh help site & updated by own nn too. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] ssh problem
On Sun, 26 Dec 2021 18:07:56 +, Michael wrote: > > Host a..cc > > Ciphers +ssh-rsa > > The initial error is about "no matching host key type", so the option > needed would be: > > HostKeyAlgorithms +ssh-rsa You're right, I was looking at the wrong file when I looked for how I dealt with this a while ago. -- Neil Bothwick Top Oxymorons Number 21: "Now, then ..." pgpevRu2A4QEv.pgp Description: OpenPGP digital signature
Re: [gentoo-user] ssh problem
On 12/26/21 9:42 AM, Philip Webb wrote: I want to login to a remote site using 'ssh'. The response I get is "Unable to negotiate with port : no matching host key type found. Their offer: ssh-rsa,ssh-dss". Yesterday, I updated 'openssh' : Michael's pointing in the proper direction. Check out the OpenSSH Legacy Options page for more details. I've successfully used this information to log into Red Hat 5.x from the '90s. (Not contemporary RHEL.) Link - OpenSSH: Legacy Options - https://www.openssh.com/legacy.html Note: This works exceedingly well in the ssh client config file (~/.ssh/config or /etc/ssh/ssh_config). Using the config file means that anything that uses OpenSSH commands benefits from and inherits the configuration parameters; rsync, git, what have you. -- Grant. . . . unix || die
Re: [gentoo-user] ssh problem
On Sunday, 26 December 2021 17:00:46 GMT Neil Bothwick wrote: > On Sun, 26 Dec 2021 11:42:41 -0500, Philip Webb wrote: > > I want to login to a remote site using 'ssh'. > > The response I get is "Unable to negotiate with port > > : no matching host key type found. Their offer: ssh-rsa,ssh-dss". > > > Yesterday, I updated 'openssh' : > It sounds like the host may be running an old version of sshd that only > offers ciphers that are now disabled by default in newer releases. You > can get round this by enabling those ciphers for this host, with > something like this in ssh_config > > Host a..cc > Ciphers +ssh-rsa The initial error is about "no matching host key type", so the option needed would be: HostKeyAlgorithms +ssh-rsa After which another error may pop up, probably about Ciphers. ;-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ssh problem
On Sun, 26 Dec 2021 11:42:41 -0500, Philip Webb wrote: > I want to login to a remote site using 'ssh'. > The response I get is "Unable to negotiate with port > : no matching host key type found. Their offer: ssh-rsa,ssh-dss". > Yesterday, I updated 'openssh' : It sounds like the host may be running an old version of sshd that only offers ciphers that are now disabled by default in newer releases. You can get round this by enabling those ciphers for this host, with something like this in ssh_config Host a..cc Ciphers +ssh-rsa -- Neil Bothwick Last words of a Windows user: = Why does that work now? pgpxxfRiE82eu.pgp Description: OpenPGP digital signature
Re: [gentoo-user] ssh problem
On Sun, 2021-12-26 at 11:42 -0500, Philip Webb wrote: > I want to login to a remote site using 'ssh'. > The response I get is "Unable to negotiate with port > : > no matching host key type found. Their offer: ssh-rsa,ssh-dss". > Yesterday, I updated 'openssh' : > > Installed versions: 8.8_p1-r4^t([2021-12-25 06:12:24]) > (X ssl -X509 -audit -debug -hpn -kerberos -ldns -libedit -livecd - > pam -pie -scp -sctp -security-key -selinux -static -test -xmss > ABI_MIPS="-n32" KERNEL="linux") > > Occasionally, I have had a similar problem trying to do this, > but ordinarily it has worked smoothly. > > Does anyone have helpful suggestions how to get past the blockage ? > Hi, Have you looked at news 2021-10-08-openssh-rsa-sha1[1] Could be related. Regards, Branko [1] https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=8dea6aa24c3ec9ee9a391fb602733c1a803a1ad1
[gentoo-user] ssh problem
I want to login to a remote site using 'ssh'. The response I get is "Unable to negotiate with port : no matching host key type found. Their offer: ssh-rsa,ssh-dss". Yesterday, I updated 'openssh' : Installed versions: 8.8_p1-r4^t([2021-12-25 06:12:24]) (X ssl -X509 -audit -debug -hpn -kerberos -ldns -libedit -livecd -pam -pie -scp -sctp -security-key -selinux -static -test -xmss ABI_MIPS="-n32" KERNEL="linux") Occasionally, I have had a similar problem trying to do this, but ordinarily it has worked smoothly. Does anyone have helpful suggestions how to get past the blockage ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Ssh problem : solved but weird
On Tuesday, 12 March 2019 15:12:46 GMT Neil Bothwick wrote: > On 12 March 2019 15:10:24 GMT, Philip Webb wrote: > >190312 Philip Webb wrote: > >> Progress, but still a puzzle. I commented the lines in /etc/... > >> & when I use the IP, not the URL, the connection goes thro' ; Good, we're getting somewhere. :-) > >> when I use the URL, it still doesn't. Here's the output : > > ... skip ... > > > >> So why does IP vs URL make a difference ?? Because the config file is parsed and used as a literal match against whatever you type on the CLI. So, if you specify an IP address it will use the corresponding settings for this IP address only. > >Thanks to Nuno Silva : it seems to use only the URL or IP, > >depending on which you specify in the config file. > >When I copy the 2 lines, but substitute the URL for the IP, > >the command also goes thro' properly. Right, that's how it is meant to work. A literal match against what you type on the CLI. > Give both the address and URL on the Host line. Yes, Neil's suggestion will work, i.e. specify all potential Host invocations separated by white space on the Host line. Alternatively, you can still have the IP address as Host, but then set the URL as hostname, e.g.: Host 123.456.78.9 hostname example.com User my_username IdentityFile /home/user/.ssh/id_rsa KexAlgorithms +diffie-hellman-group1-sha1 I expect the above may fail if/when the IP address changes, but if nothing else it will give you reason to investigate what may be happening. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : solved but weird
On 12 March 2019 15:10:24 GMT, Philip Webb wrote: >190312 Philip Webb wrote: >> 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 : > ... skip ... >> So why does IP vs URL make a difference ?? > >Thanks to Nuno Silva : it seems to use only the URL or IP, >depending on which you specify in the config file. >When I copy the 2 lines, but substitute the URL for the IP, >the command also goes thro' properly. > >This is weird : I would expect Ssh to copy all the info in the file, >then use whatever applies once it's made contact. >What it seems to do is look for an exact match from the command line >& if it doesn't find it, it then ignores the rest. >There doesn't seem to be an explicit account of this in the man file. > >So the real-life problem has been solved, but the man file needs >correcting. Give both the address and URL on the Host line. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Ssh problem : solved but weird
190312 Philip Webb wrote: > 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 : ... skip ... > So why does IP vs URL make a difference ?? Thanks to Nuno Silva : it seems to use only the URL or IP, depending on which you specify in the config file. When I copy the 2 lines, but substitute the URL for the IP, the command also goes thro' properly. This is weird : I would expect Ssh to copy all the info in the file, then use whatever applies once it's made contact. What it seems to do is look for an exact match from the command line & if it doesn't find it, it then ignores the rest. There doesn't seem to be an explicit account of this in the man file. So the real-life problem has been solved, but the man file needs correcting. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Ssh problem : half-solved
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 0x0102 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
Re: [gentoo-user] Ssh problem : half-solved
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
Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : half-solved
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
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 21:35:54 +, 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 > > > > > > > > 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" pgpo88sAtUJV7.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
On Monday, 11 March 2019 17:34:20 GMT Neil Bothwick wrote: > On Mon, 11 Mar 2019 16:06:59 +, 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 > > > > > > 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 Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 16:06:59 +, 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 > > > > 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. pgp3G625wqLxr.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
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 > > 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 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 > > 0x0102 debug1: Authenticating to :22 as 'purslow' > > > > debug1: SSH2_MSG_KEXINIT sent > > debug1: SSH2_MSG_KEXINIT received > > debug1: kex: algorithm: (no match) > > Unable to negotiate with 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 > > 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 Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : half-solved
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 > 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 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 > 0x0102 debug1: Authenticating to :22 as 'purslow' > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: algorithm: (no match) > Unable to negotiate with 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 Do you have any other Host stanzas in the config? -- Neil Bothwick Make it idiot proof and someone will make a better idiot. pgpuoXCsnatB5.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
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 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 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 0x0102 debug1: Authenticating to :22 as 'purslow' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: (no match) Unable to negotiate with 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
Re: [gentoo-user] Ssh problem : half-solved
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. pgp97Ullhxm8N.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
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.
Re: [gentoo-user] Ssh problem : half-solved
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
Re: [gentoo-user] Ssh problem : half-solved
On Mon, 11 Mar 2019 08:43:52 +, 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 pgpum6cP4udJj.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
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 Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : half-solved
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. pgpcfUAMujEUC.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Ssh problem : half-solved
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//.ssh/id_rsa KexAlgorithms +diffie-hellman-group1-sha1 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Ssh problem : half-solved
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: ", > 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
Re: [gentoo-user] Ssh problem
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: ", 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 Description: This is a digitally signed message part.
[gentoo-user] Ssh problem
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
Re: [gentoo-user] ssh problem
The nc command does nothing when run from the same host I'm trying to ssh in to. Ok so you may not have an ssh problem (so ignore the ssh specific stuff for now) you have a network problem. It will be either routing or firewalling. If you can ping the box, then its a firewall problem. So, try pinging it first, and if that works then you know that routing is in place and its a firewall problem. If that doesn't work try traceroute to see how far you can get, and the last hop may provide clues as to why you can access it by sending an ICMP message. Post back what you find.
Re: [gentoo-user] ssh problem
On Saturday 26 February 2011 07:49:44 Adam Carter wrote: The nc command does nothing when run from the same host I'm trying to ssh in to. Ok so you may not have an ssh problem (so ignore the ssh specific stuff for now) you have a network problem. It will be either routing or firewalling. If you can ping the box, then its a firewall problem. So, try pinging it first, and if that works then you know that routing is in place and its a firewall problem. If that doesn't work try traceroute to see how far you can get, and the last hop may provide clues as to why you can access it by sending an ICMP message. Post back what you find. Depending on configuration of routers and firewalls ICMP packets may be dropped, so if plain ping/traceroute fails use httping and tcptraceroute (or traceroute -T -p 22) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ssh problem
On 02/26/2011 03:13 AM, Mick wrote: On Saturday 26 February 2011 07:49:44 Adam Carter wrote: The nc command does nothing when run from the same host I'm trying to ssh in to. Ok so you may not have an ssh problem (so ignore the ssh specific stuff for now) you have a network problem. It will be either routing or firewalling. If you can ping the box, then its a firewall problem. So, try pinging it first, and if that works then you know that routing is in place and its a firewall problem. If that doesn't work try traceroute to see how far you can get, and the last hop may provide clues as to why you can access it by sending an ICMP message. Post back what you find. Depending on configuration of routers and firewalls ICMP packets may be dropped, so if plain ping/traceroute fails use httping and tcptraceroute (or traceroute -T -p 22) I don't know why I would have a firewall or network problem, the set up I have has been here for 8+ years. The setup is like this. In the basement the cable internet comes in and into a cable modem. Then an RJ45 out of the cable modem into an 8-port NETGEAR Router/Switch. Upstairs is a hub with three computers connected and this hub is connected to the switch in the basement. The only problem I ever had was when the dhcp address changed, then it needed to be added to the PORT FORWARDING section of the switch with port 22. Remember I can still log in remotely from Redhat and Suse boxes that weren't updated with the new openssh. When ssh'ing in from a remote updated Gentoo box the Read from socket failed: Connection reset by peer message is displayed. This message is not displayed when trying to ssh in from inside the network. Alright, back to the task at hand. When I tell the switch to Respond to Ping on Internet WAN Port the ping statistics are good: 3 packets transmitted, 3 received, 0% packet loss, time 2007ms. I'm not sure where to go from here. Is there anything in the sshd_config or ssh_config files that I need? After the upgrade the new files were merged with the current. Thanks dhk
Re: [gentoo-user] ssh problem
When ssh'ing in from a remote updated Gentoo box the Read from socket failed: Connection reset by peer message is displayed. This message is not displayed when trying to ssh in from inside the network. Ok that's different (and not consistent with the Connection timed out message, but lets ignore that for now)... try the HPN stuff i posted earlier, or even better restart sshd on the remote box.
Re: [gentoo-user] ssh problem
Did you remember to restart the sshd on your amd64 system? If not, try disabling the new high performance stuff on the client. I had a problem logging into a solaris box until i disabled it. In my ~/.ssh/config file I added; host ip or hostname HPNDisabled yes
Re: [gentoo-user] ssh problem
On 02/24/2011 08:08 PM, dhk wrote: On 02/24/2011 06:30 PM, Mick wrote: On Thursday 24 February 2011 21:51:56 dhk wrote: Thanks, but I've tried that. ssh'ing to the hostname and loopback address work. However, when I go out to the WAN it doesn't. So I can't ssh user@123.123.123.123 even though I have port 22 open on the switch for my ip. Just to state the obvious, have your tried something like: $ nc -v -z 123.123.123.123 22 123.123.123.123 (ssh) open from a WAN client to make sure that the port is open? I don't have the nc comand. What package is it in? The nc command does nothing when run from the same host I'm trying to ssh in to. I'm not sure what that means other than it can't make a connection. With the -w option I get: # nc -w 3 -v -z 123.123.123.123 22 ool-43505ef2.dyn.optonline.net [123.123.123.123] 22 (ssh) : Connection timed out
Re: [gentoo-user] ssh problem
On 02/25/2011 05:36 AM, Adam Carter wrote: Did you remember to restart the sshd on your amd64 system? If not, try disabling the new high performance stuff on the client. I had a problem logging into a solaris box until i disabled it. In my ~/.ssh/config file I added; host ip or hostname HPNDisabled yes I don't have a ~/.ssh/config. Will it default to ssh_config in /etc/ssh or do I need to create one?
Re: [gentoo-user] ssh problem
dhk writes: On 02/25/2011 05:36 AM, Adam Carter wrote: Did you remember to restart the sshd on your amd64 system? If not, try disabling the new high performance stuff on the client. I had a problem logging into a solaris box until i disabled it. In my ~/.ssh/config file I added; host ip or hostname HPNDisabled yes I don't have a ~/.ssh/config. Will it default to ssh_config in /etc/ssh or do I need to create one? ~/.ssh/config overrides settings in /etc/ssh/ssh_config. BTW, ~/.ssh/config is very convenient so simplify access to hosts you acess frequently. Example: With this entry, a 'ssh -p 12345 it...@foo.long.domain.org' can be done simply as 'ssh foo'. Host foo bar HostName foo.long.domain.org Port 12345 User itsme Wonko
Re: [gentoo-user] ssh problem
On Friday 25 February 2011 12:09:38 dhk wrote: On 02/24/2011 08:08 PM, dhk wrote: On 02/24/2011 06:30 PM, Mick wrote: On Thursday 24 February 2011 21:51:56 dhk wrote: Thanks, but I've tried that. ssh'ing to the hostname and loopback address work. However, when I go out to the WAN it doesn't. So I can't ssh user@123.123.123.123 even though I have port 22 open on the switch for my ip. Just to state the obvious, have your tried something like: $ nc -v -z 123.123.123.123 22 123.123.123.123 (ssh) open from a WAN client to make sure that the port is open? I don't have the nc comand. What package is it in? The nc command does nothing when run from the same host I'm trying to ssh in to. I'm not sure what that means other than it can't make a connection. With the -w option I get: # nc -w 3 -v -z 123.123.123.123 22 ool-43505ef2.dyn.optonline.net [123.123.123.123] 22 (ssh) : Connection timed out OK, this proves that you have a connectivity problem. If the port was open and there was a ssh server listening on port 22 for connections you would get an open response. BTW, nc is not necessary, you could use e.g. telnet to check the connection: $ telnet 123.123.123.123 22 SSH-2.0-OpenSSH_5.8p1-hpn13v10lpk If instead of the above you are getting no response and you are confident that you have not defined something other than port 22 for connections to your ssh server, then there is perhaps a firewall problem? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ssh problem
On Tue, Feb 22, 2011 at 6:43 AM, dhk dhk...@optonline.net wrote: After a recent upgrade to ssh I can no longer log into my Gentoo box (amd64) from another Gentoo box (x86) that has also had a recent upgrade to ssh. However, I can log in to it from Suse and Redhat boxes. Any ideas? Thanks dhk While this may not help you now, one of the things Gentoo devs recommend, after updating the ssh daemon and restarting it, is to immediately try to ssh back in and make sure you still can. Do not close your original ssh connection when you do this. I've had these instructions save me a few times; since I was still connected, I was able to fix the sshd_config file.
Re: [gentoo-user] ssh problem
On 02/23/2011 03:42 AM, Joost Roeleveld wrote: On Tuesday 22 February 2011 14:51:31 Mick wrote: On 22 February 2011 14:19, dhk...@optonline.net wrote: - Original Message - From: Mick There was a change in the default ssh encryption algorithm. You may want to check if that is causing the problem. How would I do that? By examining your config files? Previously your keys would be in ~/.ssh/id_dsa[rsa].pub, but now with ECDSA being the default they would be in ~/.ssh/id_ecdsa.pub I recall something being mentioned in the elog asking to regenerate the key-pair. HTH. If this is the case, you could try speciying your key on the command-line using the -i flag: # ssh -i .ssh/id_dsa.pub host Replace the file with the one on your machine. HTH, Joost I still haven't gotten this to work. Am I the only one using this? The ssh -i .ssh/id_dsa.pub host didn't work. I get a message Read from socket failed: Connection reset by peer with or without the -i option. When I re-emerged openssh the following output is displayed. # emerge openssh Calculating dependencies... done! Verifying ebuild manifests Emerging (1 of 1) net-misc/openssh-5.8_p1-r1 Installing (1 of 1) net-misc/openssh-5.8_p1-r1 Jobs: 1 of 1 complete Load avg: 2.80, 1.95, 1.43 * Messages for package net-misc/openssh-5.8_p1-r1: * Starting with openssh-5.8p1, the server will default to a newer key * algorithm (ECDSA). You are encouraged to manually update your stored * keys list as servers update theirs. See ssh-keyscan(1) for more info. * Remember to merge your config files in /etc/ssh/ and then * reload sshd: '/etc/init.d/sshd reload'. * Please be aware users need a valid shell in /etc/passwd * in order to be allowed to login. Auto-cleaning packages... No outdated packages were found on your system. * GNU info directory index is up-to-date. The ssh-keyscan man page hasn't helped. As of now I can only log in from older systems. dhk
Re: [gentoo-user] ssh problem
On 24 February 2011 13:17, dhk dhk...@optonline.net wrote: On 02/23/2011 03:42 AM, Joost Roeleveld wrote: On Tuesday 22 February 2011 14:51:31 Mick wrote: On 22 February 2011 14:19, dhk...@optonline.net wrote: - Original Message - From: Mick There was a change in the default ssh encryption algorithm. You may want to check if that is causing the problem. How would I do that? By examining your config files? Previously your keys would be in ~/.ssh/id_dsa[rsa].pub, but now with ECDSA being the default they would be in ~/.ssh/id_ecdsa.pub I recall something being mentioned in the elog asking to regenerate the key-pair. HTH. If this is the case, you could try speciying your key on the command-line using the -i flag: # ssh -i .ssh/id_dsa.pub host Replace the file with the one on your machine. HTH, Joost I still haven't gotten this to work. Am I the only one using this? The ssh -i .ssh/id_dsa.pub host didn't work. I get a message Read from socket failed: Connection reset by peer with or without the -i option. When I re-emerged openssh the following output is displayed. # emerge openssh Calculating dependencies... done! Verifying ebuild manifests Emerging (1 of 1) net-misc/openssh-5.8_p1-r1 Installing (1 of 1) net-misc/openssh-5.8_p1-r1 Jobs: 1 of 1 complete Load avg: 2.80, 1.95, 1.43 * Messages for package net-misc/openssh-5.8_p1-r1: * Starting with openssh-5.8p1, the server will default to a newer key * algorithm (ECDSA). You are encouraged to manually update your stored * keys list as servers update theirs. See ssh-keyscan(1) for more info. * Remember to merge your config files in /etc/ssh/ and then * reload sshd: '/etc/init.d/sshd reload'. * Please be aware users need a valid shell in /etc/passwd * in order to be allowed to login. Auto-cleaning packages... No outdated packages were found on your system. * GNU info directory index is up-to-date. The ssh-keyscan man page hasn't helped. As of now I can only log in from older systems. This would imply that your older (rsa/dsa) server keys still work. What have you changed on your Gentoo client? Have you tried using ssh user@host to login with? -- Regards, Mick
Re: [gentoo-user] ssh problem
On 02/24/2011 08:53 AM, Mick wrote: On 24 February 2011 13:17, dhk dhk...@optonline.net wrote: On 02/23/2011 03:42 AM, Joost Roeleveld wrote: On Tuesday 22 February 2011 14:51:31 Mick wrote: On 22 February 2011 14:19, dhk...@optonline.net wrote: - Original Message - From: Mick There was a change in the default ssh encryption algorithm. You may want to check if that is causing the problem. How would I do that? By examining your config files? Previously your keys would be in ~/.ssh/id_dsa[rsa].pub, but now with ECDSA being the default they would be in ~/.ssh/id_ecdsa.pub I recall something being mentioned in the elog asking to regenerate the key-pair. HTH. If this is the case, you could try speciying your key on the command-line using the -i flag: # ssh -i .ssh/id_dsa.pub host Replace the file with the one on your machine. HTH, Joost I still haven't gotten this to work. Am I the only one using this? The ssh -i .ssh/id_dsa.pub host didn't work. I get a message Read from socket failed: Connection reset by peer with or without the -i option. When I re-emerged openssh the following output is displayed. # emerge openssh Calculating dependencies... done! Verifying ebuild manifests Emerging (1 of 1) net-misc/openssh-5.8_p1-r1 Installing (1 of 1) net-misc/openssh-5.8_p1-r1 Jobs: 1 of 1 complete Load avg: 2.80, 1.95, 1.43 * Messages for package net-misc/openssh-5.8_p1-r1: * Starting with openssh-5.8p1, the server will default to a newer key * algorithm (ECDSA). You are encouraged to manually update your stored * keys list as servers update theirs. See ssh-keyscan(1) for more info. * Remember to merge your config files in /etc/ssh/ and then * reload sshd: '/etc/init.d/sshd reload'. * Please be aware users need a valid shell in /etc/passwd * in order to be allowed to login. Auto-cleaning packages... No outdated packages were found on your system. * GNU info directory index is up-to-date. The ssh-keyscan man page hasn't helped. As of now I can only log in from older systems. This would imply that your older (rsa/dsa) server keys still work. What have you changed on your Gentoo client? Have you tried using ssh user@host to login with? At first all I did was an update: emerge -uDN world . They when it didn't work I removed all public and private keys and restarted sshd. That didn't work then I tried the ssh-keygen and ssh-keyscan. That didn't work so I removed all keys again and restarted sshd. Are there ssh_config or sshd_config options that should be set? Thanks, dhk
Re: [gentoo-user] ssh problem
On 02/24/2011 03:01 PM, Matthew Marlowe wrote: On Thursday, February 24, 2011 10:09:22 am dhk wrote: I still haven't gotten this to work. Am I the only one using this? The ssh -i .ssh/id_dsa.pub host didn't work. I get a message Read from socket failed: Connection reset by peer with or without the -i option. I encountered a similar, if not the same, problem this morning. Upgraded SSH, rebooted server, and no longer able to login. Logs showed errors I had not seen before. I managed to solve the problem when I noticed that ssh'ing to the fqdn of the server failed, but ssh'ing to the server hostname worked. This implied there might be an issue with the known_hosts file, so I blew away that on both the client and server and all was well. I'm guessing the upgrade modified the default ssh host keys, the new code somehow doesn't give the normal error about discrepencies in known_hosts, and consequently although ones user keys are still fine, it fails. The issue here is really the new error isn't nearly as understandable as the old. Anyhow, try it and I hope it works. Matt Thanks, but I've tried that. ssh'ing to the hostname and loopback address work. However, when I go out to the WAN it doesn't. So I can't ssh user@123.123.123.123 even though I have port 22 open on the switch for my ip.
Re: [gentoo-user] ssh problem
On Thursday 24 February 2011 18:09:22 dhk wrote: On 02/24/2011 08:53 AM, Mick wrote: Have you tried using ssh user@host to login with? At first all I did was an update: emerge -uDN world . They when it didn't work I removed all public and private keys and restarted sshd. That didn't work then I tried the ssh-keygen and ssh-keyscan. That didn't work so I removed all keys again and restarted sshd. Are there ssh_config or sshd_config options that should be set? I recommend you have another look at: http://www.gentoo.org/doc/en/articles/openssh-key-management-p1.xml and from there Part 2 and Part 3 just in case you are missing something basic. The only difference being that the latest openssh version is now using ECDSA as the default. Therefore you should specify it as the prefered option in your server's and client's config files (which from the elog I am led to believe that it is the new default setting). Also, note the elog comment about users needing a valid shell in /etc/passwd. Does your user have /bin/bash (or other shell of choice) at the end of the line in /etc/passwd? PS. I am able to login into a gentoo box which is running 5.8_p1-r1 using my ssh_host_rsa_key from a client also running 5.8_p1-r1. So it seems that old keys should work fine - unless you have removed them from your server. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ssh problem
On Thursday 24 February 2011 21:51:56 dhk wrote: Thanks, but I've tried that. ssh'ing to the hostname and loopback address work. However, when I go out to the WAN it doesn't. So I can't ssh user@123.123.123.123 even though I have port 22 open on the switch for my ip. Just to state the obvious, have your tried something like: $ nc -v -z 123.123.123.123 22 123.123.123.123 (ssh) open from a WAN client to make sure that the port is open? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ssh problem
On 02/24/2011 06:30 PM, Mick wrote: On Thursday 24 February 2011 21:51:56 dhk wrote: Thanks, but I've tried that. ssh'ing to the hostname and loopback address work. However, when I go out to the WAN it doesn't. So I can't ssh user@123.123.123.123 even though I have port 22 open on the switch for my ip. Just to state the obvious, have your tried something like: $ nc -v -z 123.123.123.123 22 123.123.123.123 (ssh) open from a WAN client to make sure that the port is open? I don't have the nc comand. What package is it in?
Re: [gentoo-user] ssh problem
On 25/2/2011, at 1:08am, dhk wrote: I don't have the nc comand. What package is it in? net-analyzer/netcat
Re: [gentoo-user] ssh problem
On Tuesday 22 February 2011 14:51:31 Mick wrote: On 22 February 2011 14:19, dhk...@optonline.net wrote: - Original Message - From: Mick There was a change in the default ssh encryption algorithm. You may want to check if that is causing the problem. How would I do that? By examining your config files? Previously your keys would be in ~/.ssh/id_dsa[rsa].pub, but now with ECDSA being the default they would be in ~/.ssh/id_ecdsa.pub I recall something being mentioned in the elog asking to regenerate the key-pair. HTH. If this is the case, you could try speciying your key on the command-line using the -i flag: # ssh -i .ssh/id_dsa.pub host Replace the file with the one on your machine. HTH, Joost
[gentoo-user] ssh problem
After a recent upgrade to ssh I can no longer log into my Gentoo box (amd64) from another Gentoo box (x86) that has also had a recent upgrade to ssh. However, I can log in to it from Suse and Redhat boxes. Any ideas? Thanks dhk
Re: [gentoo-user] ssh problem
On Tuesday 22 February 2011 06:43:33 dhk wrote: After a recent upgrade to ssh I can no longer log into my Gentoo box (amd64) from another Gentoo box (x86) that has also had a recent upgrade to ssh. However, I can log in to it from Suse and Redhat boxes. Any ideas? None whatsoever. Supplying logs might change that though. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] ssh problem
On 22 February 2011 13:24, dhk dhk...@optonline.net wrote: On 02/22/2011 07:37 AM, Alan McKinnon wrote: On Tuesday 22 February 2011 06:43:33 dhk wrote: After a recent upgrade to ssh I can no longer log into my Gentoo box (amd64) from another Gentoo box (x86) that has also had a recent upgrade to ssh. However, I can log in to it from Suse and Redhat boxes. Any ideas? None whatsoever. Supplying logs might change that though. I don't see anything in the logs, but with the -v command I get the following when trying to log in through the WAN. Also port 22 is open on the switch. $ ssh -v -v -v user@12.12.12.123 OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0d 8 Feb 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 12.12.12.123 [12.12.12.123] port 22. There was a change in the default ssh encryption algorithm. You may want to check if that is causing the problem. -- Regards, Mick
Re: [gentoo-user] ssh problem
On 02/22/2011 07:37 AM, Alan McKinnon wrote: On Tuesday 22 February 2011 06:43:33 dhk wrote: After a recent upgrade to ssh I can no longer log into my Gentoo box (amd64) from another Gentoo box (x86) that has also had a recent upgrade to ssh. However, I can log in to it from Suse and Redhat boxes. Any ideas? None whatsoever. Supplying logs might change that though. I don't see anything in the logs, but with the -v command I get the following when trying to log in through the WAN. Also port 22 is open on the switch. $ ssh -v -v -v user@12.12.12.123 OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0d 8 Feb 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 12.12.12.123 [12.12.12.123] port 22.
Re: [gentoo-user] ssh problem
- Original Message -From: Mick Date: Tuesday, February 22, 2011 9:11 amSubject: Re: [gentoo-user] ssh problemTo: gentoo-user@lists.gentoo.org On 22 February 2011 13:24, dhk wrote: On 02/22/2011 07:37 AM, Alan McKinnon wrote: On Tuesday 22 February 2011 06:43:33 dhk wrote: After a recent upgrade to ssh I can no longer log into my Gentoo box (amd64) from another Gentoo box (x86) that has also had a recent upgrade to ssh. However, I can log in to it from Suse and Redhat boxes. Any ideas? None whatsoever. Supplying logs might change that though. I don't see anything in the logs, but with the -v command I get the following when trying to log in through the WAN. Also port 22 is open on the switch.$ ssh -v -v -v user@12.12.12.123 OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0d 8 Feb 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 12.12.12.123 [12.12.12.123] port 22. There was a change in the default ssh encryption algorithm. You may want to check if that is causing the problem. -- Regards, Mick How would I do that?
Re: [gentoo-user] ssh problem
On 22 February 2011 14:19, dhk...@optonline.net wrote: - Original Message - From: Mick There was a change in the default ssh encryption algorithm. You may want to check if that is causing the problem. How would I do that? By examining your config files? Previously your keys would be in ~/.ssh/id_dsa[rsa].pub, but now with ECDSA being the default they would be in ~/.ssh/id_ecdsa.pub I recall something being mentioned in the elog asking to regenerate the key-pair. HTH. -- Regards, Mick
[gentoo-user] ssh problem (No such file or directory)
On my recent gentoo install, I can't get past the password prompt when trying to log into the box via ssh. $ ssh [EMAIL PROTECTED] (password: and hangs) $ ssh [EMAIL PROTECTED] bash --login --noprofile -i (works) /var/log/messages Jun 14 20:13:37 spot sshd[10366]: error: openpty: No such file or directory Jun 14 20:13:37 spot sshd[10366]: error: session_pty_req: session 0 alloc failed Thanks in advance for any tips/help. -- Travis Osterman -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ssh problem (No such file or directory)
Travis Osterman wrote: On my recent gentoo install, I can't get past the password prompt when trying to log into the box via ssh. $ ssh [EMAIL PROTECTED] (password: and hangs) $ ssh [EMAIL PROTECTED] bash --login --noprofile -i (works) /var/log/messages Jun 14 20:13:37 spot sshd[10366]: error: openpty: No such file or directory Jun 14 20:13:37 spot sshd[10366]: error: session_pty_req: session 0 alloc failed Thanks in advance for any tips/help. -- Travis Osterman I searched for you: http://www.google.com/search?hl=enq=%22error%3A+openpty%3A+No+such+file+or+directory%22 Do you have CONFIG_UNIX98_PTYS and CONFIG_DEVPTS_FS in the kernel config? gzcat /proc/config.gz | grep CONFIG_UNIX98_PTYS gzcat /proc/config.gz | grep CONFIG_DEVPTS_FS Zac -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] ssh problem (No such file or directory)
On 6/15/05, Zac Medico [EMAIL PROTECTED] wrote: Travis Osterman wrote: On my recent gentoo install, I can't get past the password prompt when trying to log into the box via ssh. $ ssh [EMAIL PROTECTED] (password: and hangs) $ ssh [EMAIL PROTECTED] bash --login --noprofile -i (works) /var/log/messages Jun 14 20:13:37 spot sshd[10366]: error: openpty: No such file or directory Jun 14 20:13:37 spot sshd[10366]: error: session_pty_req: session 0 alloc failed Thanks in advance for any tips/help. -- Travis Osterman I searched for you: http://www.google.com/search?hl=enq=%22error%3A+openpty%3A+No+such+file+or+directory%22 Do you have CONFIG_UNIX98_PTYS and CONFIG_DEVPTS_FS in the kernel config? gzcat /proc/config.gz | grep CONFIG_UNIX98_PTYS gzcat /proc/config.gz | grep CONFIG_DEVPTS_FS Zac -- gentoo-user@gentoo.org mailing list [SOLVED] Thanks for helping to narrow my search. I had been focusing on devpts (which my kernel wasn't giving me an option for, but once I checked the unix98 pty stuff, it came up for selection. After compilation, all is well. Thank you. -- Travis -- gentoo-user@gentoo.org mailing list
