Why I am not worried about the lack of a default firewall in F21 Workstation

So one of the proposals for Fedora 21 is that the Workstation Product will not ship with a firewall. Normally I would be up in arms about something like this (I expect someone can find my emails in the past) but not this time. It might be the mai-tais and my vacation talking, but I look at many of these changes to the Workstation as product differentiation points. If Fedora Workstation does X, Y, and Z then the Xedora product can aim at not doing those.

Maybe Xedora is an OS for people who are tired old grumpy system administrators who the world has passed by. Maybe it will come with E19 and FVWM2 desktops with a firewall and a E-toolkit configurator for firewalld, maybe it will be KDE and QT configuration tools for items that the Workstation isn't aiming at. Then both groups can get what they want without a lot of squabbling and wasted Email trying to convince each other items that the other side feels are strawmen arguments.

Anyway, my mai-tai has arrived. Have fun.


SSH Key Magic for pkgs and fedorahosted (or how to not cause false logins)

So every couple of hours, I check the Fedora Project's servers logs to see if we have had failed logins, bad logins, etc. Sometimes people decide that they really really want to see if they can log in as someone else using '123456' or something. Its all fun and games until your atmosphere gets sucked into space (or something). One of the problems I see a lot though is that developers may get denials getting into fedorahosted.org or pkgs.fedoraproject.org due to the fact that they have multiple SSH public private keys.

Unless told otherwise, most ssh clients do not have a heuristic to know which public/private key to use for which site.. and so will have to play 20 questions to see if any of them work. If you have a lot of keys, this can result in you being denied access because your client tried 4 keys and didn't get the right one. Those 4 keys might get logged as seperate failed attempts which can make it look like someone is trying to break into an account, and then I need to send an email to make sure it was X really trying to log into fedorahosted.org at 4 am in the morning.

There is a way to avoid this problem by editing your .ssh/config file to know the appropriate key for each server (or set of servers). I use a variant of the following to cut down the problems.

Host  *.fedorahosted.org *fedorapeople.org *.fedoraproject.org
    User X
    IdentityFile ~/.ssh/id_fedora_rsa.pub
ForwardAgent no ForwardX11 no Port 22 KeepAlive yes HashKnownHosts no GSSAPIAuthentication no VerifyHostKeyDNS yes ControlMaster no

To explain the lines:

  1. The Host configuration option says for the following hosts the following settings are to be used.
  2. Set the account name to X. [EG change this to match the account you use.
  3. Use the specific public key in this file for this system. This is actually the most important line and should cut down the failed attempts per user.
  4. Do not forward my ssh credentials. I do this to cut off possible forwarding attacks where an malevolent host can leapfrog to other machines that id_fedora_rsa would be trusted.
  5. Do not forward X11. The boxes I log into don't normally run X11 so this is more about cutting down a "hey can I run X11?" question from my client to the server.
  6. Use port 22. I am being pedantic here because I have it set to other ports for some other boxes in my .ssh/config.
  7. KeepAlive is turned on because I am on wireless and sometime things quit talking.
  8. Don't hash my known hosts.. mainly because I find I need to read where I have been as much as someone who might break into my account.
  9. None of these systems use kerberos so turning off GSSAPI means its anotehr set of "Hey can I?" questions not asked during login.
  10. If possible verify the hosts public key in ssh. Not really useful without a signed DNS.. but someday :).
  11. Don't use controlmaster for this host. Multiplexing is good when you need it, but I don't generally need it. I have it here as another 'Can I?' which may slow down login for some connections.
Anyway, if you connect up your hosts with your keys, you can make sure your client isn't trying to authenticate your Fedora account with your GNOME, KDE, School, Home, etc etc keys.

Fell off the Internet.

Well that was fun and exciting.. I fell off the Internet for 8 months. Nothing broken, just a bunch of little things which took up my time.

  1. CentOS and Red Hat are now co-habitating. This was a project that came out of the blue early last summer and I was told to treat with utmost secrecy. So that cut down what I could say about anything. 
  2. Dog attacks aren't fun. I had an unfortunate case where my dog and another dog got into a fight and I tried to break it up. Scariest 10 minutes of my life. I am glad I only got out of it with a couple of bites and no one else was hurt. That took much of November out of my life.
  3. If you are over 35 years old, get your flu shot. There are multiple versions of the flu which affect people over 35 much worse than people under that age. Also anti-viral drugs work better than I thought and I didn't come down with pneumonia versus the other people I knew who came down with this version.
  4. Losing a best friend takes a lot out of you. You are missed Seth.

Anyway, I am back and should have a couple of posts in me before I fall off the internet again.


Danger, Will Robinson Danger!!! Don't miss the Fedora 20 naming elections

With all the summer conferences going on (FLOCK, FOSDEM, GUADEC, KDE-academy, etc etc) people are running behind on announcing things. The Naming election for Fedora 20 is now live. Vote for one of the following names:

Cherry Ice Cream
Santa Claus

I am voting for Santa Claus!


Remembering Seth Vidal

I have been trying to write a memory of Seth, but like everyone else have been going through periods anger, denial, and depression. At this point I am at the depression side so figured I had better just post what I can and try to move on.

Seth was my best friend online. He would call and make sure I was handling stress, and he always seemed to be able to look at a bad situation and find a way we could make it better. That is something I really will miss in the months ahead.

I first met Seth Vidal in late 2001 except I didn't realize it until he told me years later. I had left Red Hat in May after 4 years of startup work and had taken a couple of months off to learn that I wasn't a freelance consultant (especially if I couldn't ask people to pay me). I needed a job but the dotCom crash had happened and no one was hiring for Linux or Unix administrators. Duke University had an opening in their physics department and since I had an Astrophysics degree.. I figured it was a good match. I got called in and sat in a room where people were being marched in and out at 15 minute intervals. When it was finally my turn, I walked into a room where a very weary Seth and someone else were sitting there looking like they had been doing interviews for days. Turned out that wasn't too far off. Seth's first words were pretty much:
"I will be totally honest with you. We had over a thousand applicants for this job, and after the University filtering process got it down to 400 interviews. We have been doing this for days. You like a lot of people are waaaay overqualified for this gig. So in 5 minutes or less, why should we hire you?"

Completely cut to the chase. I could tell that the other person in the interview wasn't comfortable with the "truthiness" of it all but was way too tired from doing interviews back to back to put up a fight on it anymore. Seth then went on about what the job really covered over what was advertised, and that mostly it was to be a buffer between various Phd's, grad students, and post-docs and scarce resources. "I can see you have done this before, but quite frankly you could get paid a lot more doing it somewhere else."

I don't remember much about the interview than that.. in fact Seth remembered more of what I said and what I did than I could when he told me about it years later. What I did remember was that by the end of the interview I realized that I wasn't being led around. I had gotten the straight dope and that I was probably not going to be happy in the position. [I further realized this when I went to work for a different University years later and how "layered" stories could be about conditions.]

Years later I would run into Seth in various places and would finally work with him on the Fedora Infrastructure Team. I learned a lot from him even when I infuriated him at times... we had our good times working together, we had our "Lets just agree to disagree and come back later on this." times, and we had out "Are me? Fan--tastic. Want me to quit now or after you finish that sentence." times. Always to the point which I will miss terribly.

That is all.


Be careful of where you put your SSH private keys.

One of the semi-regular security checks we in Fedora Infrastructure do on various servers is to look for uploaded private .ssh keys. These are a problem because as much as we can not and do not guarantee the privacy of those keys on our servers.

In general we find 4-5 keys every couple of months and about 50% of the time they have no encryption key on them. This means that if the key had been found by a third party, they could use them without any problems in getting access to any server the public key has been placed in an .ssh/authorized_keys file. And while I have not tested the passwords on the encrypted id_rsa keys, I have tested some private created ones and found that the brute forcing is a lot faster than what is possible against the sha512crypt() used to encrypt Fedora passwords.

With this in mind, it is always important to make sure your SSH private keys remain

  1. on hardware that you control and not uploaded to services in the cloud.
  2. password encrypted with a password at least 10 characters in length and not easily guessable. [Using passwords like "fedoraproject", "password", "sshpassword", or the favourite "123456" are not hard to find or guess by an attacker]

If you have a hard time coming up with a password use the program pwqgen from the passwdqc package
[smooge@seiji-wlan ~]$ for ((i=0; i<10; i++)); do /usr/bin/pwqgen random=65; done bias Blaze Crook Primal Shore Borrow tilt Macro Beef leo Growth Reside Dolly prompt openly Crawl sigh Boyish thrill lake Past Urgent Carbon Orient Wrap root Arm Book Candy iowa chalk Plasma Champ Active motion Pause border Retina Mrs storm fault Mouth Xerox inward snatch advert apex Mature Akin play Chose the line you like the best.

Fedora 19 has been released

So Fedora 19 RC3 was made the official Fedora 19 release last week. I know I was going to post more about installs and such, but I really didn't find an install issue that was blog-worthy after the Beta. Not that they didn't exist (for the 2000 people about to reply "You missed Bugzilla #xxxx") they just didn't affect the 2->3 systems I have been reinstalling every week.

I had been wanting to do a set of blog posts on using GNOME Classic, but Stephen Gallagher covered that with a better series than what I had put into the "to be published when finished" sections.

I started to use KDE instead of GNOME Classic in order to get an idea of what other desktops are like. So far it has been a LOT easier to use than I expected and the people on Freenode's #fedora-kde  have been very helpful in getting me around various stumbling blocks. I don't know if it will be my permanent desktop... I am really not a big fan of 3 D effects and such and prefer just simple XFCE/FVWM2 window management.

Anyway please try Fedora 19. It is a very nice and polished release.