Fighting with passwords have always been one of my favorite battles in the past and unfortunately the former always won. I never liked using the root user that much for administering a machine and made a massive use of sudo, I won’t list all the benefits of using sudo, but the following wiki page has a pretty nice overview of them.
Said that, when using sudo it’s definitely ideal to combine a strong password that is also easy to remember and type again when prompted. Sadly strong passwords that are also easy to remember can be considered an oxymoron. How hard would it be to recall a 30+ chars long password? Honestly that would be close to impossible for an human being but what if a little software available on the major GNU/Linux distributions could handle that for us? That’s where pass comes handy, but what is pass? from the pass manpage itself:
pass is a very simple password store that keeps passwords inside gpg2(1) encrypted files inside a simple directory tree residing at ~/.password-store. The pass utility provides a series of commands for manipulating the password store, allowing the user to add, remove, edit, synchronize, generate, and manipulate passwords.
I’m sure that a lot of you guys have been looking for a tool like this one for ages: pass allows you to generate very strong passwords with pwgen, GPG encrypt them with your GPG Key, store them safely on your disk and make them available whenever you need them with a single command. But let’s move to the practice, give the following steps a try and enjoy how powerful your pass setup will be.
First setup
Install the software:
yum/apt-get install pass
Generate a GPG Key if you don’t have one already, a detailed guide can be found here. Initialize your passwords storage. (GPGKEYID can be retrieved by running gpg –list-keys and then looking for a line similar to this one: pub 4096R/B3A6223D 2012-06-25)
pass init GPGKEYID
Generate your first password and call it ‘sudo_password’ given you are going to make use of it as your brand new sudo password. (we want it at least 30+ chars long)
pass generate sudo_password 30
(Optional) Create as much passwords as you need and make sure to save them with unique names, that way you will be able to identify what a password is used for easily.
pass generate gmail_password 30
Additional maintenance commands on your password database
Look at the existing passwords on your database.
pass ls
Result:
Password Store
├── gmail_password
├── sudo_password
└── root_password
Manually edit a password.
pass edit password_name
Remove a password from your database.
pass rm password_name
Copy a password on your clipboard and paste it.
pass -c password_name
Are you wondering if pass supports a VCS? Yeah, it does, it currently allows you to manage your passwords database with Git, so that each applied change to the database will be tracked through a VCS so that you won’t forget when and how you updated a specific password.
Today I’ll be working out how to properly configure DNSSEC on a BIND9 installation, I’ll also make sure to give you all the needed instructions to properly verify if a specific domain is being correctly covered by DNSSEC itself. In addition to that a few more details will be provided about adding the relevant SSHFP‘s entries on your DNS zone files to be able to automatically verify the authenticity of your domain when connecting to it with SSH avoiding any possible MITM attack.
First of all, let’s create the Zone Signing Key (ZSK) which is the key that will be responsible to sign any other record on the zone file which is not a DNSKEY record itself:
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE gnome.org
Note: the dnssec-keygen binary file should be part of bind97 (RHEL 5) or bind (RHEL6) package according to yum whatprovides:
RHEL 5:
32:bind97-9.7.0-17.P2.el5_9.2.x86_64 : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
Repo : rhel-x86_64-server-5
Matched from:
Filename : /usr/sbin/dnssec-keygen
RHEL 6:
32:bind-9.8.2-0.17.rc1.el6.3.x86_64 : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
Repo : rhel-x86_64-server-6
Matched from:
Filename : /usr/sbin/dnssec-keygen
Then, create the Key Signing Key (KSK), which will be used to sign all the DNSKEY records:
dnssec-keygen -a RSASHA1 -b 2048 -n ZONE -f KSK gnome.org
Creating the above keys can take several minutes, when done copy the public keys to the zone file this way:
cat Kgnome.org*.key >> gnome.org
When done you can clean out the useless bits from the zone file and just leave the DNSKEY records (which are not commented out as you will notice)
An additional and cleaner way of accomplishing the above is to use the INCLUDE rule on the zone file itself as follows:
Once that is done you can go ahead and sign the zone file. As of myself I’m making use of the do-domainscript taken from the Fedora Infrastructure Team’s repositories. If you are going to use it yourself, make sure to adjust all the relevant variables to match your setup, especially keyspath, region_zones, template_zone, signed_zonesand AREA. The do-domain script also checks your zone file through named-checkzonebefore signing it.
If instead you don’t want to use the script above, you can sign the zone file manually in the following way:
By default, the above command will append ‘.signed’ to the file name, you can modify that behaviour by appending the ‘-f’ flag to the dnssec-signzone call. The ‘-N INCREMENT’ will increment the serial number automatically making use of the RFC 1982 arithmetics while the ‘-e’ flag will extend the zone signature end date from the default 30 days to 35. (this way we can safely run a monthly cron job that will sign the zone file automatically)
You can make use of the following script to achieve the above:
#!/bin/sh
SIGNZONE="/usr/sbin/dnssec-signzone"DNSSEC_KEYS="/srv/dnssec-keys"NAMEDCHROOT="/var/named/chroot"ZONEFILES="gnome.org"cd$NAMEDCHROOTfor ZONE in $ZONEFILES;do$SIGNZONE -K $DNSSEC_KEYS -e +3024000 -f $ZONE.signed -N INCREMENT $ZONEdone/sbin/service named reload
Once the zone file has been signed just make sure to include it on named.conf and restart named:
zone "gnome.org"{file "gnome.org.signed";};
When you’re done with that we should be moving ahead adding a DS record for our domain at our domain registrar. My example is taken from the known gandi.net registrar.
Select KSK (257) and (RSA/SHA-1) on the dropdown list and paste your public key on the box. You will find the public key you need on one of the Kgnome.org*.key files, you should look for the DNSKEY 257 entry as ‘dig DNSKEY gnome.org‘ shows:
105;; WE HAVE MATERIAL, WE NOW DO VALIDATION
106;; VERIFYING DS RRset for org. with DNSKEY:59085: success
107;; OK We found DNSKEY (or more) to validate the RRset
108;; Ok, find a Trusted Key in the DNSKEY RRset: 19036109;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success
110111;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS
Bonus content: Adding SSHFP entries for your domain and verifying them
You can retrieve the SSHFP entries for a specific host with the following command:
When retrieved just add the SSHFP entry on the zone file for your domain and verify it:
ssh -oVerifyHostKeyDNS=yes -v subdomain.gnome.org
Or directly add the above parameter into your /etc/ssh/ssh_config file this way:
VerifyHostKeyDNS=yes
And run ‘ssh -v subdomain.gnome.org’, the result you should receive:
debug1: Server host key: RSA 00:39:fd:1a:a4:2c:6b:28:b8:2e:95:31:c2:90:72:03
debug1: found 1 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_rsa_verify: signature correct
I wanna be really honest, getting back home from this year’s GUADEC has been very painful for me but not because of the trip back home. I had such a very good time at Brno that I actually wanted to stay there for way more days! I must admit that I’ve been missing the italian food for a while until Mattias Bengtsson suggested me to try having a dinner at the “Flavours” indian restaurant. The result was simply amazing and I’ve been falling in love with the indian food we ate that evening so much that we went there again the day after.
I had a lot of expectations from my very first GUADEC and I was very excited to meet all the people I’ve been contributing with during all these years. Meeting people up in person is fundamental and reminds you the fact that there is a human being with its own feelings and emotions behind a computer and that’s actually why I spent a lot of my time during the event speaking and hanging out with people, finding out their personal interests, their hobbies, the things they love doing on their free time.
During the event, I had the great pleasure to present two talks:
the GNOME Infrastructure, the presentation is available here and the video is viewable at the following page.
a little resume of what we’ve been doing on the GNOME Sysadmin team during this last year at the GNOME Foundation’s Annual General Meeting. (AGM)
… and meet a lot of friends:
Mattias Bengtsson, you’ve been the greatest room mate of all times! Thanks for all your hints!
Andreas Nilsson and Fabiana Simões, thanks for all your kind words, I’ll keep doing my best to provide you all the resources and work you need to make things happen!
Sriram Ramkrishna, you don’t know how much I enjoyed our nightly discussions and walks around the city centre, missing those times already!
Allan Day and Jon McCann, it’s been truly amazing meeting you guys and hearing how much enthusiast you are about me and my work, thanks a *lot*!
Paul Frields, it’s been an absolute pleasure meeting you and your wife, I will never forget how you presented me to her at the Starobrno Brewery: “He’s like the Kevin Fenzi of the GNOME Infrastructure!“. That’s one of the greatest compliments someone can ever receive given the amount of work Kevin does on the Fedora Infrastructure. I’m also glad that we could remember Seth together during my talk, thanks for coming!
My italian friends, Flavia, Paolo, Emanuele,** Giovanni** and Alessandro!
Tobias Mueller, glad we were finally able to meet in person! Thanks for your nano sessions!
All the indian interns, Saumya Dwivedi, Saumya Pathak, Sindhu Sundar, Shivani Poddar who are definitely doing an amazing job! I was completely impressed by your talks and projects!
Ekaterina, David, Karen, Marina, Owen, Rui, Alberto: all you guys are simply great! It’s really unfortunate we weren’t able to spend a lot of time together during the event!
Overall the whole event has been a blast, thanks to the GNOME Foundation making this possible by sponsoring my attendance at the event! I’m looking forward to Strasburg 2014 already and last but not least I’m preparing the greatest bid of all times for GUADEC 2015 to happen in Italy. Stay tuned!
Overall the whole event has been a blast, thanks to the GNOME Foundation making this possible by sponsoring my attendance at the event! I’m looking forward to Strasburg 2014 already and last but not least I’m preparing the greatest bid of all times for GUADEC 2015 to happen in Italy. Stay tuned!
It’s been two years since my latest blog post about my Linux desktop and many things have changed since then. I completely moved all my machines to GNOME 3, switched my main editor from nano to vim and my terminal multiplexer from screen to tmux. What didn’t change at all except for a tweaks on the theme is my Irssi setup.
Switching from nano to vim has been a pain at first, nano is really a straightforward editor, it does what you actually need from a CLI editor but while it works just fine when modifying configuration or text files, it’s a bit limiting when it comes to programming. Vim on the other hand is highly customizable in every single part also thanks to its huge amount of plugins. Honestly I admit I spent several hours watching videos, reading documentation, trying out key bindings and I’m not completely used to vim to be as much productive I would like to be with it.
What I found to be the common error of vim’s newcomers is their willingness to look around the web for a complete vimrc configuration file, full of key bindings, custom settings and personalizations. That’s definitely something you should avoid when learning to use vim, the perfect vimrc doesn’t objectively exist, each of us should spend some time investigating what is the best configuration for your needs and build a vimrc accordingly time by time.
It will probably take months to have a complex vimrc file matching your needs completely, until then you won’t be able to define your vimrc to be “ultimate”. And that’s actually why wgetting someone else’s vimrc and copying it to your home folder won’t make you an expert of vim, it’ll probably make your life harder when trying a specific action with the stock settings will result in something you wouldn’t have expected thanks to a particular key binding on the vimrc you downloaded.
The other tool that definitely improved my productivity is Tmux given the huge amount of open terminals I had every day during my sysadmin’s duties at GNOME. Each day usually started with one or two open terminals mainly meant for random maintenance issues, after a few hours the amount of open terminals jumped to around 30.
I haven’t been blogging so much in the past months as I actually promised myself I would have but given the fact a lot has been done on the GNOME Infrastructure lately it’s time for me to announce all the updates we did since my latest blog post. So here we come with all the items we’ve been looking at recently:
Our main LDAP istance was moved from a very ancient machine (which unfortunately died with a broken disk a few weeks ago) to a newer box that currently contains several other admin tools like Mango and Daily Reports. (a little script written by Owen Taylor for creating and storing several reports mainly related to backups and SSL certificates expiration dates) In addition to migrating our LDAP master to a newer machine, we did configure and setup replication to an LDAP slave to share a bit the load and most of all to link all the external (machines outside the RH’s internal network) machines to it.
A lot of efforts have been spent in the so-called “Puppet-ization” (Puppet allows you to reproduce a complete environment with just a few commands, it’s very very handy in the case of host’s migrations) and several new modules are now stored into our internal Puppet repository. Specifically all the Iptables rules are currently managed in a centralized way, each node has its own rules and policies, finally there’s no need to ssh into each machine to retrieve the information we need for a specific firewall. In addition to the Iptables class, also Cobbler, Owncloud, Jabberd, Denyhosts and several other modules have been properly configured and currently reside in Puppet.
Another item that had top priority on the list was setting up another “webapps” virtual machine to migrate several services from one of the existing ancient machines to it. I can finally tell that the GNOME Infrastructure has get rid of all the old machines, all the services have been migrated to newer machines and most of all all the services are currently being served through SSL. (git, planet, www.gnome.org, l10n, guadec.org, bugzilla, blogs, developer, help, people, news etc.) In regard of SSL and Bugzilla, we’ve configured our Bugzilla istance to serve attachments through a secondary domain which will look like: https://bug-id.bugzilla-attachments.gnome.org, this to prevent cross-site scripting attacks in a better way than what we did before.
We’ve also spent some time working on our Nagios istance hosted at https://nagios.gnome.org. We’ve improved it dramatically by adding several new checks and covering all the services we currently take care of but that’s not all. Event Handlers have been setup to help us addressing problems right after they occur on our web servers. The Nagios event handlers are currently configured to read the status of a specific Nagios service and in the case the status is set to CRITICAL, they restart httpd once, which is usually enough in the case of random Apache’s timeouts. But that’s again not all. A public view for Nagios is now ready, every single GNOME contributor and developer should be able to check the current status of all the services we maintain just by loggin in with the username “anonymous” and the password “anonymous” at nagios.gnome.org.
Our wiki was upgraded to the latest MoinMoin release, at the moment of writing, version 1.9.7. This release introduces stronger password hashes, please make sure to update your password as soon as you can to strenghten the security of your account. It was also clear that live.gnome.org was behaving a bit sluggish lately, we spent some time cleaning up spammers, old and deleted pages and things started flushing way better. More details about the cleanup can be found at https://mail.gnome.org/archives/foundation-list/2013-May/msg00098.html. (we cleaned up around 23000 spammers!)
The most exciting things I usually love to announce are new services. While I always prefer keeping the number of maintained services as low as possible it was time for the GNOME Infrastructure to broaden its horizons satisfying the requests coming from the community and the developers involved into the project. I won’t spend any more word about this since I’m sure you are all waiting for me to list the new services, so here they are:
A completely new Jabber service hosted at jabber.gnome.org and accessible by all the GNOME Foundation members requesting access to it. More details about it can be found at https://live.gnome.org/Sysadmin/Jabber.
GNOME is extensively using IRC as its main communication tool, thus we’ve improved our Services IRC Bot to use a plugin called MeetBot. Having a meeting and storing the logs in a public web server is currently possible with a really minor effort of learning a few commands to administer the plugin correctly. If you are going to have a meeting and you want to make use of MeetBot, make sure that Services is there, and give a look at http://meetbot.gnome.org/Manual.html.
Do you want to be always up-to-date with the status of the GNOME Infrastructure? and are you actually wondering what’s the best way to do so? if yes, you should probably have a look at http://status.gnome.org. This service makes use of Fedora-Status by Patrick Uiterwijk and allows the GNOME Sysadmin Team to let everyone know whether there is a problem with any of the services listed in the page. This service, together with the public view for Nagios and the brand new infrastructure-announce@gnome.org mailing list will definitely help everyone finding out what’s going on, where and how long it’ll take for the issue to be fixed.
It took me a lot of pain having the KGB IRC Collaboration bot packaged into the EPEL repositories but I finally managed to set it up on the GNOME Infrastructure. KGB has become very handy since the time Cia.vc closed its hosting and it’s available for anyone requesting access to it at irc.gnome.org. If you are looking for Git commit notifications of a specific module directly on your IRC channel, this is what you want :-)
An Owncloud instance is also available, more reading about what are the requirements for requesting access to it at the following link.
An Etherpad istance is also available at https://etherpad.gnome.org to all the GNOME Teams that need it! Please drop me an e-mail at if you are interested. (Pad’s creation is currently disabled for preventing spam)
Build.gnome.org has been revived and it’s currently hosting an OSTree istance. GNOME Daily images are costantly being generated, interested in testing one the those images? give this article a look.
That’s all for now! See you all at GUADEC and thanks everyone for all the hints, suggestions and mails you’ve been sending me in the past months! And a special thanks to Ekaterina Gerasimova for taking the time to brainstorm with me suggesting new features and improvements over the GNOME Infrastructure!
