1498781309 J * fstd_ ~fstd@x4e308972.dyn.telefonica.de 1498781776 Q * fstd Ping timeout: 480 seconds 1498781777 N * fstd_ fstd 1498789178 J * fstd_ ~fstd@x4db53b95.dyn.telefonica.de 1498789436 Q * fstd Ping timeout: 480 seconds 1498789437 N * fstd_ fstd 1498800399 M * Bertl_oO off to bed now ... have a good one everyone! 1498800401 N * Bertl_oO Bertl_zZ 1498803018 J * Ghislain ~ghislain@81.56.195.31 1498806404 J * nikolay ~nikolay@HOST.255.3.ixos.de 1498810358 Q * Defaultti Quit: WeeChat . 1498810428 J * Defaultti defaultti@lakka.kapsi.fi 1498814305 M * Ghislain the only hunk failed is in ipv6 it seems, 4.1.42 is ok apart this one 1498814378 M * Ghislain i am compiling an ipv4 only one to test (shame on me i am ipv4 only still) 1498814401 M * Ghislain i am only 19 year late so 1498816386 Q * nikolay Ping timeout: 480 seconds 1498819534 J * druschka_domaintechnik ~druschka@185.51.130.86 1498821565 Q * Aiken Ping timeout: 480 seconds 1498821750 J * nikolay ~nikolay@2001:981:4551:1:d6be:d9ff:fe33:8c86 1498821852 J * Aiken ~Aiken@d63f.h.jbmb.net 1498823667 N * Bertl_zZ Bertl 1498823673 M * Bertl morning folks! 1498825631 M * Ghislain hi, testme and testfs on ext4 are ok on 4.1.42 without ipv6 1498825657 M * Ghislain of course it compile and boot.. :) 1498825864 M * Bertl good to hear, I'm looking at the changes at the moment ... 1498827474 Q * druschka_domaintechnik Quit: druschka_domaintechnik 1498832271 Q * Aiken Remote host closed the connection 1498832470 M * Bertl off for now ... bbl 1498832471 N * Bertl Bertl_oO 1498839142 Q * nikolay Ping timeout: 480 seconds 1498839930 M * yang using 4.1.39-vs2.3.8.5.2-beng 1498839951 M * yang when I try to ssh to the guest VPS it drops me into the main host... 1498839979 M * yang Not sure either it's some kind of a network miss-match or a bug in kernel or a bug in system upgrade... 1498839995 M * yang that is when I try to connect via ipv4 1498840197 M * yang There are no IPv4 addresses assigned on the host, which are ment for the guest, those come up automatically from /etc/vservers/interfaces... 1498840428 M * gnarface yang: sounds pretty typical to me, expected behavior not specific to any version of linux-vservers. the problem is that sshd binds to "0.0.0.0" by default, so the first one that starts (usually the host's instance) intercepts all inbound connections. easy fix: just specify the exact ip for every host and guest sshd config instance 1498840583 M * yang oooh 1498840587 M * yang well 1498840639 M * yang maybe its ssh-only bug, but maybe also other services dont bind, well I'll do what you suggested, I did a system upgrade on guest....following sshd upgrade aswell 1498840692 M * gnarface yes, it's not very common for daemons to default to "0.0.0.0" but you will have to pay closer attention going forward 1498841009 M * yang ok I think your suggestion is right, I changed the host to IP instead of 0.0.0.0, and defining guest sshd aswell it seems to work now 1498841049 M * yang Now I only need to figure out if this is a standard procedure that in the Debian upgrade the ssh key gets rewritten, or if there was a breach instead 1498842064 M * gnarface which ssh key? 1498842077 M * gnarface doesn't seem right... 1498842160 M * Bertl_oO yang: the host binds all IPs issue is an ancient mistake, we have had it in the FAQ for centuries :) 1498842312 M * yang oh 1498842313 M * yang damn 1498842319 M * yang it's a relief 1498842326 M * yang I was already trying to mess with networking 1498842378 M * yang gnarface: I upgraded debian from jessie to stretch and I saw that the ssh key gets re-done...so I am interested if it's a standard procedure during debian upgrade... 1498842422 M * yang logging inside from elsewhere warns me about the new key now MITM 1498842463 M * gnarface yang: i don't know off the top of my head, but i think it's possible if the library that generated the old keys was compromised (which it was, last year) then some debconf settings may have it regenerate by default 1498842483 M * yang oh 1498842491 M * yang It would be nice to have the url about that 1498842519 M * gnarface yang: still, i'm not sure. you sure it was the key though, not just the host identifier that changed? if you changed hardware or network addresses, you'd also get ssh complaining about a potential MITM attack 1498842559 M * yang well it was only a guest jessie -> stretch upgrade 1498842570 M * yang and I saw it replacing ssh key aswell 1498842576 M * gnarface hmmm 1498842585 M * gnarface which ssh key? a user's ssh key in /home? 1498842661 M * yang http://paste.debian.net/plain/974123 1498842734 M * yang regarding dates nothing in /home/user/.ssh/ has been changed 1498842778 M * gnarface hmmm, what do you have in /etc/default/inithooks? 1498842822 M * yang no such file inithooks 1498842867 M * gnarface a brief googling suggests that updates to your sshd config defaults CAN cause this error 1498842880 M * yang url please ? 1498842895 M * yang my sshd_config has been rewritten at the same time, yes 1498842907 M * yang during an upgrade 1498842950 M * gnarface https://askubuntu.com/questions/468198/will-an-upgrade-of-ubuntu-to-a-new-lts-change-ssh-host-key well like here, for example they mention that an upgrade might have added a line like "HostKey /etc/ssh/ssh_host_ecdsa_key" to your sshd config, which would definitely cause a complaint about the ECDSA key changing, because there wasn't one declared at all before 1498842992 M * gnarface if you can check the difference between the pre-upgraded sshd config and the post-upgraded one, it would probably be obvious which change was the culprit 1498843074 M * gnarface also, btw if you were connecting by hostname just before to the sshd instance that was bound to "0.0.0.0" via interception and that was the first connection attempt, that would now also give you a MITM warning because after correcting the sshd config to use the right ip address, your local user's known_hosts file will have logged the WRONG host key for that DNS entry. make sense? 1498843168 M * gnarface and that host key is generated on-the-fly from a number of system fingerprintings that i'm not entirely aware of. other changes to your network config might make it unhappy too (change of virtual or physical MAC addresses, for example) 1498843205 M * gnarface even a change to the hostname you use to connect might give you a complaint about the ip it resolves to matching a conflicting host key 1498843218 M * yang oh right 1498843224 M * yang cause 1498843246 M * yang because after upgrade it kept redirecting me to host instead of guest, now it gives me MITM 1498843271 M * gnarface right, exactly 1498843284 M * gnarface you MITM'd yourself :-D 1498843315 M * yang hiehe 1498843316 M * yang ok 1498843321 M * yang thank you, I couldn't figure it out 1498843393 M * gnarface we were all there once 1498843404 M * yang yes, old sshd_config didn't have the line "/etc/ssh/ssh_host_ecdsa_key" and the new one has it 1498843415 M * gnarface cool, so second mystery solved 1498843435 M * gnarface it's good to be sure though 1498843486 M * yang indeed....the thing is that my server also got "randomly" rebooted today, so I contacted DC about that too, they said it was a fault on a switch...heh 1498843536 M * gnarface power is getting dirtier by the day here. i've started putting battery backups on everything. even my tivo. 1498843592 M * gnarface despite all the industry pushes to stifle growth of solar power, pretty soon it will be necessary just to have a reliable supply 1498843623 M * gnarface a simple reboot *shouldn't* change the host key though 1498843651 M * gnarface once you have all your updates done and configs dialed-in, you shouldn't see this error again 1498843658 M * gnarface if you do, THEN get paranoid. 1498843790 M * yang ok 1498844184 M * yang DC wrote back that the power switch caused the server to reboot, but it shouldnt of have, probably I have some kind of my own settings applied, that it cause that 1498844208 M * yang another unrelated issue - any idea how do I disable the touchpad temporarily ? http://paste.debian.net/plainh/664a4505 1498844220 M * yang rmmod some module probably, but which one 1498844333 M * gnarface i think it's actually a Xorg thing 1498844347 M * yang oh 1498844370 M * gnarface hmmm 1498844401 M * gnarface looks like any relevant kernel module you have statically compiled-in 1498844451 M * gnarface it would be like usbhid or something 1498844469 M * gnarface but you'd remove support for all the input devices 1498844473 M * yang oh 1498844487 M * yang so impossible to disable temporarily just he touchpad 1498844492 M * yang its annoying if i use mouse 1498844498 M * yang and accidentially skip over it with hand 1498844508 M * gnarface yea you can just change the xorg config 1498844512 M * Bertl_oO most laptops have a funktion key for that :) 1498844518 M * Bertl_oO *function 1498844531 M * gnarface also doesn't synaptic have a setting for it? 1498844534 M * yang Bertl_oO: probably its that yeah 1498844552 M * Bertl_oO but you can also remove it from the xorg device list 1498844575 M * yang I really havent explored any of the F-keys on this laptop heh 1498844595 M * gnarface i believe synaptic has a setting that automatically disables the touchpad while the keyboard is in use 1498844601 M * gnarface i'm not sure if it also will do that for mouse use 1498844607 M * gnarface also it might require hardware support 1498844613 M * gnarface (as in not all touchpads will do it) 1498844631 M * gnarface i might be wrong about that part 1498844846 M * yang ok 1498844872 M * yang right "synclient TouchpadOff=1" 1498844874 M * yang great, thanks 1498844891 M * gnarface no problem. :) 1498847936 Q * transacid Ping timeout: 480 seconds 1498848504 J * nikolay ~nikolay@2001:981:4551:1:d6be:d9ff:fe33:8c86 1498850493 J * transacid ~transacid@transacid.de 1498850877 M * yang gnarface: this is how it gets processed on all VPS's now during upgrade http://paste.debian.net/plainh/a6d31b96 1498852510 J * Aiken ~Aiken@d63f.h.jbmb.net 1498853193 Q * nikolay Quit: Leaving 1498854609 M * gnarface yang: yea, looks normal to me. you can change your debconf priority setting i think, to make it prompt you for changes to config files, but by default it won't bother asking you to replace any config files you didn't customize 1498854643 M * gnarface yang: *usually* the changes are for your own good, but it's always a good idea to keep an eye on them anyway 1498854665 M * yang yep 1498865104 Q * Ghislain Quit: Leaving.