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
[gentoo-user] Re: Ssh problem : half-solved
On 2019-03-11, 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 [...] What is ? Are you using the same hostname or address that is present in the "Host" line you added? > 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 ? -- Nuno Silva
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] Server fails to boot after update to 4.19.27-r1
On Monday, March 11, 2019 9:31:58 PM CET Dan Johansson wrote: > On 11.03.19 20:55, J. Roeleveld wrote: > > On March 10, 2019 1:24:14 PM UTC, Dan Johansson > > wrote: > >> After updating a server from kernel-4.14.83 to 4.19.27-r1 (same problem > >> > >> with 4.19.23) the server will not boot. > >> > >> Grub starts fine and I can select the new kernel. > >> The kernel starts booting and after mounting "/" and "/usr" (this is a > >> server with a separate /usr") the boot-process hangs. > >> > >> Here are the last few lines displayed before it hangs: > Initializing root device... > Detected root: /dev/md127 > Mounting /dev/md127 as root... > Detected fstype: ext4 > Using mount fstype: ext4 > Using mount opts: -o ro > > >> 7.6104971 EXT4-fs (md127): mounted filesystem with ordered data > >> > >> mode. Opts (null) > >> > >> 7.6572671 init (5708) used greatest stack depth: 13280 bytes left > > Mounting /dev/dm-O as /usr: mount -t ext4 -o noatime,user_xattr,ro > >> > >> /deu/dm-O /newroot/usr > >> > >> 7.6909561 EXT4-fs (dm-0): INFO: recouery required on readonly > >> > >> filesystem > >> > >> 7.6925551 EXT4-fs (dm-0): write access will be enabled diming > >> > >> recouery > >> > >> 7.9169781 EXT4-fs (dm-0): recovery complete > >> 7.9223701 EXT4-fs (dm-0): mounted filesystem with ordered data > >> > >> mode. Opts: user_xattr > >> > >> 7.9233051 mount (5722) used greatest stack depth, 13000 bytes left > > /usr already mounted, skipping... > Booting (initramfs) > >> > >> sep-usr init: running user requested applet > >> > >> > >> As I said, the 4.14.83 kernel boots without problem with the same > >> configuration. > >> > >> Any suggestions? > > > > I updated my servers last weekend and all moved to 4.19.27, 2 use ZFS for > > the filesystem, several are VMs on top of Xen. None had any issues. > > > > The messages you show make me think they are from an initrd, not the > > actual kernel. I would investigate that first and make sure your initrd > > is actually updated as well. Did you copy the text? Or did you manage to > > grab the output somehow? > > > > Also, which init system and initrd are you using? > > > > -- > > Joost > > The text was copied from a screenshot (IPMI-KVM). > I am using sys-apps/openrc with sys-fs/eudev and I use genkernel to > build the kernel and the initramfs. > > Yes, for me it also looks like it has to do with /ginit (busybox) or > /sbin/init (sys-apps/sysvinit) and not the kernel. > > I also have a bunch of other servers which all updated fine to 4.19.?? > > I tried the suggestion from Hasan to run "make synconfig" but that did > not change any option in .config. > > I'll try to rebuild kernel/init/busybox/intel-microcode again next weekend. Are you booting with the updated initramfs? Or perhaps still with the initramfs belonging to an older kernel? Does the server respond to SSH after a while? It might simply be that the login-prompt is not showing on the correct console. -- Joost
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
