| 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:22 |
| 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:25 |
| 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:26 |
| 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:27 |
| sarnold | cause I'm bloody tired of ls -l .. ; ls -l ../.. ; ls -l ../../.. and on and on .. :) | 04:28 |
| mason | Yep. | 04:28 |
| Neo4 | mason: errors with wrong files http://pix.toile-libre.org/?img=1517372972.png | 04:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 | |
| 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:38 |
| 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:39 |
| 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:40 |
| mkoninckx | Thanks for your help! | 04:42 |
| sarnold | mkoninckx: wait a sec | 04:42 |
| sarnold | mkoninckx: check the other user! | 04:42 |
| mkoninckx | ? | 04:42 |
| 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:43 |
| 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:44 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| sarnold | so it might have even worked if you were logged in locally and then ssh'd in. | 04:57 |
| mkoninckx | Ah, that makes sense. | 04:59 |
| cpaelzer | good morning | 05:00 |
| sarnold | hey cpaelzer :) must be time for me to go make dinner, hehe | 05:02 |
| cpaelzer | yep, I'm glad to serve as an alarm bell sarnold :-) | 05:03 |
| sarnold | :D | 05:04 |
| tanuki | How stable is 18.04? | 05:48 |
| andol | tanuki: At this point, approximately 74% stable. | 06:52 |
| lordievader | Good morning | 08:45 |
| johan_hedin | hi.. i am not where to find apache logs | 10:45 |
| funabashi | hi guys ist possible i can see what a guy have done atfter he removed/clean bash_history ? | 11:02 |
| hateball | johan_hedin: /var/log/ usually | 11:23 |
| johan_hedin | hateball: how can i check that both php5 and php 7 version installed on server ? | 11:31 |
| 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:32 |
| 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:33 |
| hateball | They dont have the same package managers or repositories, how would it be the same? | 11:34 |
| johan_hedin | hateball: | 11:48 |
| johan_hedin | can you we run php5 for a specific folder? | 11:48 |
| johan_hedin | can we do something in apache host file that we can run php5 for specific folder ? | 11:49 |
| hateball | johan_hedin: you're better off asking in #httpd | 11:52 |
| coreycb | jamespage: hmm nova dep8 tests are failing due to this: https://paste.ubuntu.com/26494870/ | 12:56 |
| 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 | 13:09 |
| 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 | 14:26 |
| rbasak | powersj: available for HO? | 16:44 |
| powersj | rbasak: sure | 16:44 |
| rbasak | powersj: still in standup HO | 16:44 |
| mason | Stand-up meetings always remind me of https://www.youtube.com/watch?v=nvks70PD0Rs | 17:07 |
| 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:09 |
| mason | heh | 17:10 |
| 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:11 |
| Ussat | OMG, have not watched "the website is down" in a while.....love that | 17:19 |
| dpb1 | speaking of mongodb, this one is funny: https://sookocheff.com/post/opinion/the-five-stages-of-nosql/ | 18:09 |
| nacc_ | powersj: hit a snafu with my in-snap testing idea | 22:24 |
| 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:25 |
| 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 | 22:26 |
| === nacc_ is now known as nacc | ||
| 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:43 |
| nacc | rbasak: is that just to be sure it's buildable? | 23:44 |
| nacc | rbasak: https://paste.ubuntu.com/26497869/ | 23:47 |
| nacc | we coulld innclude gcc in the snap, but i'd really rather not :) | 23:47 |
| 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:55 |
| 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:56 |
| nacc | rbasak: oh it's not perl? | 23:57 |
| nacc | it's really dpkg-architecture that needs gcc, iirc | 23:57 |
| rbasak | Perhaps we could stub something out | 23:58 |
| nacc | rbasak: and i expect the first failure might be related, since it's all from the source builder/ | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
