[04:22] 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] The file does exist, but I guess the ssh service can't see it for some reason? [04:25] mkoninckx: Check ownership and permissions. [04:25] are you sure you checked on the server? [04:25] mason, good suggestion. I vaguely remember checking, but I'll do it again. [04:25] mkoninckx: And check ownership and permissions of /home/mkoninckx and /home/mkoninckx/.ssh too [04:25] sarnold, yes [04:26] namei -l /home/mkoninckx/.ssh/authorized_keys is probably the quickest way to find the missing step :) [04:26] mkoninckx: file doesn't exists, you need specify right path to key [04:27] Oh, neat. When did namei pop into existence? [04:27] Neo4: Nah, that'd be on the client side. [04:27] mason: dunno but I wish it'd been there two decades ago :) [04:28] cause I'm bloody tired of ls -l .. ; ls -l ../.. ; ls -l ../../.. and on and on .. :) [04:28] Yep. [04:29] mason: errors with wrong files http://pix.toile-libre.org/?img=1517372972.png [04:31] I (mkoninckx) own /home/mkoninckx, /home/mkoninckx/.ssh/, and /home/mkoninckx/.ssh/authorized_keys/. [04:31] mkoninckx: It's... a directory? [04:31] ah no sorry that was a typo [04:31] kk, good [04:31] It's definitely a text file. I can open it with vi and see the public keys. [04:32] mkoninckx: good [04:32] Permissions are 755 on my home directory, 700 on .ssh and 600 on authorized_keys [04:32] Alright, that should all be reasonable. And this is on Ubuntu? [04:32] Yeah, 16.04 Server [04:32] I'd say "run restorecon" if the server were EL [04:32] mkoninckx: now you set up it, and you can access server without input password use it [04:32] ssh username@ip-of-server -i /path/to/privet/key [04:33] Neo4: that's client side, and his error is server side [04:33] mkoninckx: than if it will work good, you can turn off access to server using password [04:33] mason: yes, I confused [04:33] Neo4, when I do that, I get a password prompt. [04:34] 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] mkoninckx: it means your privet can is not right [04:34] mkoninckx: is it in an encrypted mount? [04:34] Neo4: It means his authorized_keys file is wrong. [04:35] mkoninckx: Hey, you haven't turned on chrooting, have you? [04:35] or yes, authorized_keys wrong [04:35] sarnold, I think I may have enabled that when installing the server, yes. Is there a good way to check? [04:35] Ah! [04:35] mkoninckx: mount should show you what's what and where [04:35] mkoninckx: maybe something like mount | grep ecryptfs ? [04:35] mkoninckx: one of two authorized_keys wrong or you type wrong path to privet key [04:36] Neo4: No, it's not anything to do with his client, at all. [04:36] I can see it in the output of mount: /home/.ecryptfs/mkoninckx/.Private on /home/mkoninckx type ecryptfs [04:37] 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] 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] one more time [04:38] mkoninckx: feel free to ignore Neo4 for the moment [04:39] 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] :) [04:40] 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] 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] sarnold, I understand the advice in the askubuntu link [04:40] mkoninckx: alright, good good :) [04:42] Thanks for your help! [04:42] mkoninckx: wait a sec [04:42] mkoninckx: check the other user! [04:42] ? [04:43] you said you've got another user account on the system where pubkey auth works fine [04:43] Oh, yes [04:43] make sure it still works [04:43] or fails [04:43] as you expect :D [04:43] 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] Which is I guess why it would work. [04:44] yeah [04:44] you'll have to symlink or handle its authorized_keys similar to your account [04:44] same for everyone else on the machine [04:49] 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] Is there a reason not to do that? [04:50] 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] Yes, I'm expecting that. [04:50] okay :) [04:50] then you're probably prepared for what that means for all the other users on the system [04:50] 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] The second user is also me, it's just the user for running the Minecraft server. [04:51] so the stakes are even higher :) [04:51] :) [04:51] 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] so better to find surprises right now and deal with it [04:51] Right, don't get me wrong, I appreciate the double-checking! [04:53] 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] it probably didn't have ecryptfs in place :) [04:53] 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] right :) [04:54] 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] Actually, that makes me curious - why can't sshd see the file, but I can once I'm connected? [04:55] I guess I should rephrase [04:56] 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] 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] so it might have even worked if you were logged in locally and then ssh'd in. [04:59] Ah, that makes sense. [05:00] good morning [05:02] hey cpaelzer :) must be time for me to go make dinner, hehe [05:03] yep, I'm glad to serve as an alarm bell sarnold :-) [05:04] :D [05:48] How stable is 18.04? [06:52] tanuki: At this point, approximately 74% stable. [08:45] Good morning [10:45] hi.. i am not where to find apache logs [11:02] hi guys ist possible i can see what a guy have done atfter he removed/clean bash_history ? [11:23] johan_hedin: /var/log/ usually [11:31] hateball: how can i check that both php5 and php 7 version installed on server ? [11:32] as sererver admin tells us that two version running on server [11:32] johan_hedin: what version of Ubuntu is this? [11:32] its centos [11:33] So... why are you asking in #ubuntu-server ? :| [11:33] and centos group banned me .. dont know why.. [11:33] well command is same i think [11:34] They dont have the same package managers or repositories, how would it be the same? [11:48] hateball: [11:48] can you we run php5 for a specific folder? [11:49] can we do something in apache host file that we can run php5 for specific folder ? [11:52] johan_hedin: you're better off asking in #httpd [12:56] jamespage: hmm nova dep8 tests are failing due to this: https://paste.ubuntu.com/26494870/ [13:09] 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] 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] powersj: available for HO? [16:44] rbasak: sure [16:44] powersj: still in standup HO [17:07] Stand-up meetings always remind me of https://www.youtube.com/watch?v=nvks70PD0Rs [17:09] It's not quite as good as the "MongoDB is web scale" video, but it's not bad. [17:09] or "the website is down" [17:10] heh [17:11] or IPv6 and NATs [17:11] That one doesn't ring a bell. Looking. [17:11] https://www.youtube.com/watch?v=v26BAlfWBm8 [17:11] ty [17:19] OMG, have not watched "the website is down" in a while.....love that [18:09] speaking of mongodb, this one is funny: https://sookocheff.com/post/opinion/the-five-stages-of-nosql/ [22:24] powersj: hit a snafu with my in-snap testing idea [22:25] tox assumes it can write to where the snap's tox.ini resides [22:25] i wonder if we should just drop tox [22:26] (from the snap in-snap testing) [22:26] 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] yeah [22:26] that's what i'm thinking righ tnow === nacc_ is now known as nacc [23:43] powersj: ok, got it mostly working, i thinkn [23:43] rbasak: sigh, 3 of your tests fail in the snap [23:43] rbasak: a) you assume you can call dpkg-buildpackage :) [23:44] rbasak: is that just to be sure it's buildable? [23:47] rbasak: https://paste.ubuntu.com/26497869/ [23:47] we coulld innclude gcc in the snap, but i'd really rather not :) [23:55] nacc: no, dpkg-buildpackage is needed to actually build the dsc from a Debian source tree [23:55] Though perhaps dpkg-deb directly might be sufficient for our cases [23:56] rbasak: i think both will end up requiring gcc [23:56] it is a static check, iirc [23:56] I don't think dpkg-deb needs gcc [23:57] rbasak: oh it's not perl? [23:57] it's really dpkg-architecture that needs gcc, iirc [23:58] Perhaps we could stub something out [23:59] rbasak: and i expect the first failure might be related, since it's all from the source builder/