[04:22] <mkoninckx> Hey guys, having a bit of trouble setting up ssh pubkey authentication. I've done some research and made sure the permissions are set correctly, etc. I turned on debug-level logging in sshd_config and am getting an error message I'm not seeing mentioned anywhere: debug1: Could not open authorized keys '/home/mkoninckx/.ssh/authorized_keys': No such file or directory
[04:22] <mkoninckx> The file does exist, but I guess the ssh service can't see it for some reason?
[04:25] <mason> mkoninckx: Check ownership and permissions.
[04:25] <sarnold> are you sure you checked on the server?
[04:25] <mkoninckx> mason, good suggestion. I vaguely remember checking, but I'll do it again.
[04:25] <mason> mkoninckx: And check ownership and permissions of /home/mkoninckx and /home/mkoninckx/.ssh too
[04:25] <mkoninckx> sarnold, yes
[04:26] <sarnold> namei -l /home/mkoninckx/.ssh/authorized_keys  is probably the quickest way to find the missing step :)
[04:26] <Neo4> mkoninckx: file doesn't exists, you need specify right path to key
[04:27] <mason> Oh, neat. When did namei pop into existence?
[04:27] <mason> Neo4: Nah, that'd be on the client side.
[04:27] <sarnold> mason: dunno but I wish it'd been there two decades ago :)
[04:28] <sarnold> cause I'm bloody tired of ls -l .. ; ls -l ../.. ; ls -l ../../.. and on and on .. :)
[04:28] <mason> Yep.
[04:29] <Neo4> mason: errors with wrong files http://pix.toile-libre.org/?img=1517372972.png
[04:31] <mkoninckx>  I (mkoninckx) own /home/mkoninckx, /home/mkoninckx/.ssh/, and /home/mkoninckx/.ssh/authorized_keys/.
[04:31] <mason> mkoninckx: It's... a directory?
[04:31] <mkoninckx> ah no sorry that was a typo
[04:31] <mason> kk, good
[04:31] <mkoninckx> It's definitely a text file. I can open it with vi and see the public keys.
[04:32] <Neo4> mkoninckx: good
[04:32] <mkoninckx> Permissions are 755 on my home directory, 700 on .ssh and 600 on authorized_keys
[04:32] <mason> Alright, that should all be reasonable. And this is on Ubuntu?
[04:32] <mkoninckx> Yeah, 16.04 Server
[04:32] <mason> I'd say "run restorecon" if the server were EL
[04:32] <Neo4> mkoninckx: now you set up it, and you can access server without input password use it
[04:32] <Neo4> ssh username@ip-of-server -i /path/to/privet/key
[04:33] <mason> Neo4: that's client side, and his error is server side
[04:33] <Neo4> mkoninckx: than if it will work good, you can turn off access to server using password
[04:33] <Neo4> mason: yes, I confused
[04:33] <mkoninckx> Neo4, when I do that, I get a password prompt.
[04:34] <mkoninckx> For comparison, I have another user set up on this server that I've set up pubkey authentication for and it works fine. I don't get the same error messages in the logs, and I get no password prompt.
[04:34] <Neo4> mkoninckx: it means your privet can is not right
[04:34] <sarnold> mkoninckx: is it in an encrypted mount?
[04:34] <mason> Neo4: It means his authorized_keys file is wrong.
[04:35] <mason> mkoninckx: Hey, you haven't turned on chrooting, have you?
[04:35] <Neo4> or yes, authorized_keys wrong
[04:35] <mkoninckx> sarnold, I think I may have enabled that when installing the server, yes. Is there a good way to check?
[04:35] <mason> Ah!
[04:35] <mason> mkoninckx: mount should show you what's what and where
[04:35] <sarnold> mkoninckx: maybe something like mount | grep ecryptfs   ?
[04:35] <Neo4> mkoninckx: one of two authorized_keys wrong or you type wrong path to privet key
[04:36] <mason> Neo4: No, it's not anything to do with his client, at all.
[04:36] <mkoninckx> I can see it in the output of mount: /home/.ecryptfs/mkoninckx/.Private on /home/mkoninckx type ecryptfs
[04:37] <mkoninckx> I was expecting that to be transparent to anything running on the machine, but I'm getting the feeling that was wrong.
[04:37]  * mason bows out and leaves it to sarnold, having only ever used LUKS partition-wide.
[04:38] <Neo4> mkoninckx: simply on server put your public key in folder /.ssh/authorized_keys . and then you are able to login using privet key ssh user@ip -i /path-to-privet-key , check yourself where you have made error or repeat it
[04:38] <Neo4> one more time
[04:38] <sarnold> mkoninckx: feel free to ignore Neo4 for the moment
[04:39] <sarnold> mkoninckx: this advice looks useful https://askubuntu.com/questions/809186/ssh-public-key-authentication-not-automounting-encrypted-drive -- but it's annoyingly terse
[04:39] <Neo4> :)
[04:40] <sarnold> this is a bit better but hilariously gives advice to reboot in the middle for no reason https://unix.stackexchange.com/a/186285/7064
[04:40] <sarnold> mkoninckx: but this might not really be pleasant -- you're going to need the password in order to decrypt the key used for the ecryptfs mount
[04:40] <mkoninckx> sarnold, I understand the advice in the askubuntu link
[04:40] <sarnold> mkoninckx: alright, good good :)
[04:42] <mkoninckx> Thanks for your help!
[04:42] <sarnold> mkoninckx: wait a sec
[04:42] <sarnold> mkoninckx: check the other user!
[04:42] <mkoninckx> ?
[04:43] <sarnold> you said you've got another user account on the system where pubkey auth works fine
[04:43] <mkoninckx> Oh, yes
[04:43] <sarnold> make sure it still works
[04:43] <sarnold> or fails
[04:43] <sarnold> as you expect :D
[04:43] <mkoninckx> I created the other user on the machine after it started, and I don't have that home directory under an encrypted mount.
[04:43] <mkoninckx> Which is I guess why it would work.
[04:44] <sarnold> yeah
[04:44] <sarnold> you'll have to symlink or handle its authorized_keys similar to your account
[04:44] <sarnold> same for everyone else on the machine
[04:49] <mkoninckx> OK. I think I read that askubuntu article a bit fast. What I'm planning to do is just make the changes to sshd_config and copy, not symlink, the appropriate authorized_keys files into the right places.
[04:49] <mkoninckx> Is there a reason not to do that?
[04:50] <sarnold> once you change the sshd config file, it's going to be looking in a different spot for the authorized_keys files for EVERYONE
[04:50] <mkoninckx> Yes, I'm expecting that.
[04:50] <sarnold> okay :)
[04:50] <sarnold> then you're probably prepared for what that means for all the other users on the system
[04:50] <mkoninckx> I should be clear - this is not, like, a serious production server or something. It's just a cast-off Dell desktop I'm running a Minecraft server off for my friends.
[04:51] <mkoninckx> The second user is also me, it's just the user for running the Minecraft server.
[04:51] <sarnold> so the stakes are even higher :)
[04:51] <mkoninckx> :)
[04:51] <sarnold> it's just that this moment it's obvious what needs to be done; in another six months, it'll be way less obvious.
[04:51] <sarnold> so better to find surprises right now and deal with it
[04:51] <mkoninckx> Right, don't get me wrong, I appreciate the double-checking!
[04:53] <mkoninckx> Thanks for the help, guys. Last time I did this it was an AWS micro instance, so I got a lot of this config done for me behind the scenes.
[04:53] <sarnold> it probably didn't have ecryptfs in place :)
[04:53] <mkoninckx> Almost certainly. I guess this is one of those instances of knowing enough to shoot yourself in the foot, but not enough to un-shoot yourself in the foot
[04:54] <sarnold> right :)
[04:54] <sarnold> the error message is unhelpful and yet very helpful .. *why* does the file not exist if you're sure it's there... gotta get creative to figure out why you can see it once you're logged in but sshd can't see it :)
[04:55] <mkoninckx> Actually, that makes me curious - why can't sshd see the file, but I can once I'm connected?
[04:55] <mkoninckx> I guess I should rephrase
[04:56] <mkoninckx> What's different about sshd that it can't see the files that are mounted? I assumed that was transparent and from the perspective of sshd shouldn't be different than the files actually being written there
[04:56] <sarnold> the file doesn't exist until you login; then the ecryptfs PAM module unlocks the secret key, and mounts your own home directory / filesystem
[04:57] <sarnold> so it might have even worked if you were logged in locally and then ssh'd in.
[04:59] <mkoninckx> Ah, that makes sense.
[05:00] <cpaelzer> good morning
[05:02] <sarnold> hey cpaelzer :) must be time for me to go make dinner, hehe
[05:03] <cpaelzer> yep, I'm glad to serve as an alarm bell sarnold :-)
[05:04] <sarnold> :D
[05:48] <tanuki> How stable is 18.04?
[06:52] <andol> tanuki: At this point, approximately 74% stable.
[08:45] <lordievader> Good morning
[10:45] <johan_hedin> hi.. i am not where to find apache logs
[11:02] <funabashi> hi guys ist possible i can see what a guy have done atfter he removed/clean bash_history ?
[11:23] <hateball> johan_hedin: /var/log/ usually
[11:31] <johan_hedin> hateball: how can i check that both php5 and php 7 version installed on server ?
[11:32] <johan_hedin> as sererver admin tells us that two version running on server
[11:32] <hateball> johan_hedin: what version of Ubuntu is this?
[11:32] <johan_hedin> its centos
[11:33] <hateball> So... why are you asking in #ubuntu-server ? :|
[11:33] <johan_hedin> and centos group banned me .. dont know why..
[11:33] <johan_hedin> well command is same i think
[11:34] <hateball> They dont have the same package managers or repositories, how would it be the same?
[11:48] <johan_hedin> hateball:
[11:48] <johan_hedin> can you we run php5 for a specific folder?
[11:49] <johan_hedin> can we do something in apache host file that we can run php5 for specific folder ?
[11:52] <hateball> johan_hedin: you're better off asking in #httpd
[12:56] <coreycb> jamespage: hmm nova dep8 tests are failing due to this: https://paste.ubuntu.com/26494870/
[13:09] <coreycb> jamespage: in journalctl this error shows up right before the use_tpool error: nova-scheduler.service: Failed to change ownership of session keyring: Permission denied
[14:26] <coreycb> jamespage: ok i narrowed the nova failure down to this patch. the error goes away when it's reverted: https://github.com/openstack/nova/commit/910008e2ef5dae1698ff7db791f4816c728c8bd0
[16:44] <rbasak> powersj: available for HO?
[16:44] <powersj> rbasak: sure
[16:44] <rbasak> powersj: still in standup HO
[17:07] <mason> Stand-up meetings always remind me of https://www.youtube.com/watch?v=nvks70PD0Rs
[17:09] <mason> It's not quite as good as the "MongoDB is web scale" video, but it's not bad.
[17:09] <dpb1> or "the website is down"
[17:10] <mason> heh
[17:11] <Nivex> or IPv6 and NATs
[17:11] <mason> That one doesn't ring a bell. Looking.
[17:11] <Nivex> https://www.youtube.com/watch?v=v26BAlfWBm8
[17:11] <mason> ty
[17:19] <Ussat> OMG, have not watched "the website is down" in a while.....love that
[18:09] <dpb1> speaking of mongodb, this one is funny: https://sookocheff.com/post/opinion/the-five-stages-of-nosql/
[22:24] <nacc_> powersj: hit a snafu with my in-snap testing idea
[22:25] <nacc_> tox assumes it can write to where the snap's tox.ini resides
[22:25] <nacc_> i wonder if we should just drop tox
[22:26] <nacc_> (from the snap in-snap testing)
[22:26] <powersj> given tox is only running pylint and pytest and you are running very specific versions of those on a very specific version of python I don't find tox as useful for the project
[22:26] <nacc_> yeah
[22:26] <nacc_> that's what i'm thinking righ tnow
[23:43] <nacc> powersj: ok, got it mostly working, i thinkn
[23:43] <nacc> rbasak: sigh, 3 of your tests fail in the snap
[23:43] <nacc> rbasak: a) you assume you can call dpkg-buildpackage :)
[23:44] <nacc> rbasak: is that just to be sure it's buildable?
[23:47] <nacc> rbasak: https://paste.ubuntu.com/26497869/
[23:47] <nacc> we coulld innclude gcc in the snap, but i'd really rather not :)
[23:55] <rbasak> nacc: no, dpkg-buildpackage is needed to actually build the dsc from a Debian source tree
[23:55] <rbasak> Though perhaps dpkg-deb directly might be sufficient for our cases
[23:56] <nacc> rbasak: i think both will end up requiring gcc
[23:56] <nacc> it is a static check, iirc
[23:56] <rbasak> I don't think dpkg-deb needs gcc
[23:57] <nacc> rbasak: oh it's not perl?
[23:57] <nacc> it's really dpkg-architecture that needs gcc, iirc
[23:58] <rbasak> Perhaps we could stub something out
[23:59] <nacc> rbasak: and i expect the first failure might be related, since it's all from the source builder/