Going live again in January.

I’ve been working hard to get the pages that are missing added, some existing pages updated, and some new content ready for go-live at the beginning of next year.  First post of the new year will be Monday, and will be an explanation of how things will work moving forward.  All new pages will go live around the same time.

Thank you for your patience while I got things in order, and took a break for the holiday season, as well.  Things should be better moving forward, and I’m ready to hit the ground running in the coming year.

Also, the DSH beta should be ready to go by middle of January.  Be looking for it.

Thanks again to everyone who stuck with me on this.

UnixSecLab

Hiatus Hump-Day – What

Today would normally be “Hacker-Tool Hump Day,” but I’ve decided I need a hiatus. I know this is sudden notice, but I’ve had no engagement since I started this blog. The only comments I’ve received have been spam, except possibly one, but that one doesn’t make sense in any context. The commenter has an AOL address, and listed his website as “Bing” in the U.K. If that’s you, and you honestly meant for me to respond to you, please comment on THIS post, not one that’s weeks old, and I might get back to you.

Zero engagement equals higher apathy, and with all that’s going on in the household at the moment, a break is warranted. Will I return? Absolutely. Sooner, if people read this and tell me to come back.

When I return, here’s what can be expected of this site:

1) There will be a working asciinema demonstration for each topic I cover that warrants it.
2) I will possibly go back and re-work prior posts to be re-posted with the above said asciinema recordings to bring clarity to my content.
3) I will untie the blog posts from the standard “sign up for my email list” form, and make the list be for special content and/or promotional offers.
4) What was that about promotional offers? Yeah. About that. I’ve got a product I’ve been working on for a while now that I need to re-focus on polishing up and posting as an available download for purchase. I’ll go ahead and mention that the topic is “Dancer’s Shell/Distributed Shell” which is an open source program for sending ssh remote commands to multiple end point servers. Most of the tutorials I have seen have put a focus on thing like working with nodes in a cluster. My focus is more about developing your own set of tools to manage systems in general. When it launches, this product will be in “Beta” for a limited number of customers. Those customers will get free updates to that product through “final copy” launch, and get a chance to purchase at a reduced price. The initial price for the beta will be in the $7 range. Based on feedback, this will only go up, not down, when it goes live.
5) I will also work on a product to help people go through the thought process for developing their own managed OpenSSH public key infrastructure, whether it uses the certificate authority, or not. It should help people to choose what will be most manageable for their needs, and cover the pros and cons of any given set up, including security risks.
6) I will also work on a product to help people take advantage of the power of TMUX, which is everything Screen should have been, but wasn’t. Just my opinion, of course. What order I develop these next two products (TMUX vs. Managed OpenSSH PKI) will depend on feedback from you, my readers.
7) I am going to go back to the basics, and re-vamp this site. It’s missing a few things that should be there and aren’t. I need to get an “About Me” page, start taking advantage of categories so content can be easily grouped together, and so on.

If you have been around, but haven’t commented and are now sad that I’m taking a break, you can comment and let me know that there are people out there that don’t beep and boop about how much their product can help me improve my blog. I don’t want or need the spam, but I would LOVE to get responses from real people who appreciate the content I’ve provided.

If you have topics you wish I would cover that I haven’t, comment as well. I have a list of stuff to cover, but feedback lets me know if I’m on the right track, or leaving you frustrated for not covering that one thing you really need to see.

So for now and until I get things un-cluttered and un-broken, thanks for the few I know have been reading, and thanks to those I might not know, either.

UnixSecLab

SSH Start to Finish Architecture – AuthorizedKeysCommand

Last week we brushed upon this briefly, but this week, I’ve stood up a scenario in my lab, and am digging into the details a bit deeper.

So to set this up, there are three systems involved, currently.
1) The windows 10 laptop with the “ubuntu on windows 10 on crack” option. Using the bash shell, I created an ssh key pair, and stopped there until everything else was ready.
2) The “target” system to log into. This is an OpenBSD server that I stood up to play with asciinema earlier this weekend, and decided to utilize for this particular lab. This is the machine that will be configured to use AuthorizedKeysCommand and AuthorizedKeysCommandUser instead of AuthorizedKeysFile. On this server, I created two new groups, and two new users:
groupadd testgrp
groupadd sshpub
useradd -m -g testgrp -G testgrp -c “Test User” -s /bin/ksh -d /home/testuser testuser
useradd -m -g sshpub -G sshpub -c “SSH Public Key Provider” -s /bin/ksh -d /home/sshpub sshpub

I also created a new script: /usr/local/bin/query_ssh_pub.ksh with permissions 750 and owned by root:sshpub.
##############################################################################
#!/bin/ksh

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
HOSTNAME=$(hostname -s)
USER=${1}
ssh -i ~sshpub/.ssh/id_rsa sshpub@192.168.0.89 “/usr/local/bin/query_ssh_pub_keys.ksh ${USER} ${HOSTNAME}”
##############################################################################

3) The “query server” system to be a central repository of ssh keys for system accounts and/or human users (hypothetically.) I created the same sshpub user and group on this system, but added a new script: /usr/local/bin/query_ssh_pub_keys.ksh with permissions 750 and owned by root:sshpub as well.
##############################################################################
#!/bin/ksh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

if [ $# -ne 2 ]; then
exit 255
fi

USER=${1}
TARGET=${2}

echo ${USER} | grep -q -E -e ‘^[a-zA-Z0-9]+$’ || exit 255
echo ${TARGET} | grep -q -E -e ‘^[a-zA-Z0-9]+$’ || exit 255

ls /home/sshpub/key-store/ | grep -q “^${TARGET}\.${USER}\.pub\$” || exit 255
cat /home/sshpub/key-store/${TARGET}.${USER}.pub
##############################################################################

I generated an ssh key pair from sshpub on the “TARGET” server, then copied the public key file over to the “QUERY” server so that it could do a remote ssh call. If I were going to use a system like this in production, I would apply a few more sanity checks on all of the inputs, as well as consider a force command for this user either by sshd_config or by modifying the public key file, but that’s neither here, nor there. This is not an ideal way of retrieving the keys, but it demonstrates how it works in a simple manner.

Once everything was in place, I dropped a copy of the public key from the “CLIENT” laptop into /home/sshpub/key-store/asciicast.testuser.pub file on the “QUERY” server, then tested that all commands worked as intended.

Finally, I updated sshd_config to use the following entries on the “TARGET” server, and restarted sshd:
AuthorizedKeysCommand /usr/local/bin/query_ssh_pub.ksh
AuthorizedKeysCommandUser sshpub

After all of this was done, I was able to test that I could log in as “testuser” to the “TARGET” machine, and it retrieved the public key from the “QUERY” machine successfully, allowing login as expected.

The query script can call any service, really. You can call keys stored in LDAP, SQL, or any other database. The final returned result from the script should be zero or more public keys, and nothing else. The most common use of this is to query LDAP, and there are examples of an LDIF file for OpenLDAP floating around freely on the internet, if you choose to go that route. Just make sure your LDIF works for your particular LDAP service, and that you are able to sanitize the output to only present the keys in the end, when you query.

Later in the day on Monday, I may modify this post to include the asciinema player embedded to show off how this whole thing works. I’m still working on getting WordPress to let me do that, but it has gotten late on me.

I would like feedback if anyone likes this kind of thing, though. Just leave a comment!

Fun-Day Friday – Not really

I am exhausted. This on call week has been rough. Not “bad” or anything, just rough. The mobile alerting device has been pretty quiet for the most part, but when it does decide to go off, it likes to do so at short intervals right in the middle of my normal sleep window. Interrupted sleep makes me more tired than a total lack of sleep, so this is taking its toll.

You didn’t come to read my blog on that, though. So here’s some other sad news, though I can’t recall if I might have shared already. I did not complete NaNoWriMo this year. I had some issues one night that meant there was no way I would get my quota for the day in. I introspected about the coming week on that day, and made the executive decision that this year was not a good year to try. The days my family were gone visiting other friends and family, I spent home alone. I got quite a few Honey Do items taken care of in their absence, but not as many as I would have liked. They are back home, and routines that got disrupted from the trip are just now really starting to get back into a rhythm.

The one good thing I can report is that I’m re-focusing on a product I started around the same time I started this blog. My small e-book on Dancer’s shell/Distributed shell is getting another work over before I go live with it as a product. It’s going to be in the ten dollar range when it goes live, but it’ll also be a “beta” launch, so the folks that buy during the beta window will help me make it better. We’ll see how that goes.

I’m not sure how much interest there will be, but after that product is up, I’m going to start on a second one. I’m thinking either a product on sudo or tmux, but I’m undecided. If you have any interest in one over the other, let me know in the comments. I’ll also be asking on social media, so hopefully I’ll get enough responses to make a clear decision.

That’s all for now. Monday we get back to the SSH stuff, and dip our toes into the land of making public keys more manageable.