Manage Passwords, Encryption Keys, and More with Seahorse

You've got half a dozen passwords for work, encryption keys, and SSH keys — how do you keep them all straight? If you're on Linux, you have an excellent option in the form of Seahorse. It's easy to use, and you'll be able to tackle all your credentials with little effort.

You've got half a dozen passwords for work, encryption keys, and SSH keys — how do you keep them all straight? If you're on Linux, you have an excellent option in the form of Seahorse. It's easy to use, and you'll be able to tackle all your credentials with little effort.

Generally speaking, most average users assume a password is nothing more than something that gets in their way of getting to their "stuff" quickly. Most Linux users, on the other hand, know that passwords are the keys to the kingdom and encryption keys are keys to the universe. Like me, many Linux users have passwords and encryption keys for multiple uses. Because of this, a tool for the management of those keys can make life so much easier. One such tool is Seahorse. Seahorse is the GNOME application charged with managing encryption keys and passwords and I want to demonstrate how both passwords and encryption keys can be easily managed with this tool.

Although Seahorse was intended to be used on the GNOME desktop, it can be used with other desktops (such as KDE or Enlightenment). However, since Seahorse was created for GNOME it will not properly integrate into KDE applications. That is fine, because encryption and secure shell keys as well as passwords can still be easily managed. If Seahorse is not already installed (It should be found in the Start > Settings menu in KDE and Applications > Accessories in GNOME) simply open up the Add/Remove Software tool, search for Seahorse, and install.

Since most all users deal with passwords, the first (and most logical) place to start is password management. Seahorse is an incredible tool for the management of passwords. What can be done?

Store passwords.Remove a password from cache.Add details about a password.Create a new password.Create new password keyrings.

The default keyring is the Login keyring, which is where keys are stored. When Seahorse is fired up it will offer a very simple interface (see Figure 1). From that one main pane, expand the keyring entry to list out all of the various passwords that are stored. This may, at first, seem like a glaring security issue in and of itself, since no password has been entered to reach this point. Fear not, this keyring can be (and should be) locked and unlocked. To lock the keyring, do the following:

More than one keyring can be retained within Seahorse for further expansion.

Right click the target keyring.Select Lock from the menu.If you have not added a lock password, add one when prompted.

To unlock the keyring, follow the same steps, only select Unlock and then enter the locking password. It is also possible to change the keyring password, but the old password will be required to to do. If you are going to take advantage of Seahorse, I highly recommend you lock all keyrings with strong passwords.

Adding a password to this keyring will highlight how important it is to have that keyring locked. So, assuming the keyring lives in a locked state, here is the process for adding a password:

Click File > New.From the new window, select Stored Password and click Continue.In Add Password window select the keyring this password should belong to from the drop-down.Give the password a description.Enter the password in the password field.Click the Add button.

The password has been successfully saved. Now, to view that password, follow these steps:

Right click the keyring and click Unlock.Enter the unlock password and click OK.Expand the keyring to view the newly created password.Double click the password entry to be viewed.In the new window (see Figure 2) expand the Password field.To view the password check the box for Show password.

The next time this password entry is opened, the Show password check box will once again be unchecked.

Encryption keys is where Seahorse really shines. Not only can encryption keys be created and managed from within Seahorse, so to can secure shell keys. These two features along make Seahorse worth using.

In order to create a PGP encryption key, follow these steps:

Open Seahorse.Click File > New.In the resulting window, select PGP Key and click Continue.Fill out the settings in the new window (Name, Email Address, Comment).If advanced options (such as Encryption type, Key strength, and Expiration date) are needed, expand the Advanced section and fill out that information.Click Create.Type and confirm the passphrase to be used for the key and click OK.Do some work on your computer to help with the generating of the random seed and wait for the key to be created.

One that is done, go back to the Seahorse main window and click on the Personal Keys tab (see Figure 3), to see all personal keys managed by Seahorse.

From this tab keys can be signed, exported, and more.

Signing an encryption key allows the recipient of the key to verify the authenticity of the key. To digitally sign a key, do the following:

Select the key to sign from the Personal Keys tab.Click the Sign Key button in the toolbar.Fill out the necessary information in resulting window (making sure to select how carefully the key has been checked and the correct signer for the key.)Enter the passphrase for the key.Click OK.

The key is now signed. It is possible to sign a key with multiple email addresses. But the only addresses available to sign with will be those that are already associated with keys in Seahorse. This can be helpful if more than one key is associated with one user (but different email addresses).

The public keys can also be exported (in the form of .asc files) which can then be handed out to those who need to send encrypted email which can then be decrypted with that encryption key's private key. These keys should only be handed out to trusted users.

Many users like to publish their public keys so they are easier to distribute. Seahorse has a built in mechanism for publishing keys (so nothing is really necessary outside of simply creating the keys, signing the keys, and then publishing the keys. To publish keys click Remote > Sync and Publish Keys. From the new window click on the Key Servers button and then, from the Key Servers Preferences window, select the Keyserver the key should be published to (from the drop-down), click Close, and finally click Sync. All keys should then be available on the Keyserver selected.

Secure Shell is one of the best tools for remotely logging into Linux/UNIX machines because it is far more secure than telnet. But even with that extra security, it's always best to add yet another layer. This can be achieved with the help of secure shell keys that can be handled by Seahorse. Here are the steps:

Open Seahorse.Click File > New.From the resulting window select Secure Shell Key.Give the key a description and click Create And Setup.Enter (and confirm) a passphrase for the key and click OK.In the new window enter the address (IP or FDQN) of the machine to receive the key and the login name on the remote machine.

If all went as planned, instead of a password prompt, a bash prompt should appear ready for work. This, of course, requires that public keys are guarded, otherwise the obvious security hole will make itself quite apparent. There is a known bug in Seahorse that affects some installations and causes the originating machine to not be able to send the ssh key to the target (during creation.) The development team is aware of this bug and will (hopefully) have it fixed soon. If that bug rears it's ugly head, as a temporary stop-gap, use ssh-copy-id username@address where username is the remote username and address is either the IP address or domain of the recipient.

The reality is, no matter how many security tools are used, if they are not used wisely those tools will not help much. Even when employing encryption caution must be used to ensure keys do not wind up in the wrong hands. But when encryption is used properly, it is a great tool that will lend a level of security otherwise not found. And, when encryption is needed, thankfully there are tools like Seahorse to make the management of those keys a cinch.

View the original article here

Using Firewall Builder Settings to Manage Firewalls

Last week we looked at managing rules in Firewall Builder. In the last installment of our series on Firewall Builder, I'll take a look at managing firewall settings with the Firewall Builder.

We've covered quite a bit already about Firewall Builder This week, I want to open up the Firewall Settings window to illustrate how much further a Firewall can be flexed, stretched, and configured — all from a single, user-friendly window.

As should be expected, getting to the settings window is simple — so long as it's not overlooked. What I'm talking about is not the Firewall Builder Preferences. The settings I am referring to actually apply to individual firewalls. So, in order to reach the settings window, a firewall must be open within Firewall Builder. Once the firewall is open (double click on the firewall to edit it),

When the Firewall Settings button is clicked, it will open the settings window only for the currently open firewall.

The Firewall Settings button is located near the center of the window. Click that button to get to the settings in question. Let's examine this window, tab by tab.

The compiler tab (see Figure 2), as the name implies, deals with the compiling settings for the firewall. There are a few options, in particular, that I want to point out. The first option is 'Assume firewall is part of "any"'. If this option is checked, rules that are configured with "Any" in the Source or Destination fields will also generate rules for traffic destined to or from the firewall. In iptables this will result in a rule being added to either the OUTPUT or INPUT rule chain.

The configuration options here will be automatically compiled into the firewall in question.

Another important option is 'Always permit ssh access from the management workstation with this address'. This helps prevent situations where a user cuts off their access to the firewall because there isn't a rule allowing SSH access to the firewall itself. If this option is enabled, enter either a single IP address or a network using CIDR notation (e.g. 192.168.1.0/24). When the firewall is compiled, Firewall Builder will automatically add a rule permitting SSH access to the firewall from this IP address or network at the top of the generated rules.

The Installer Tab has three settings that you should pay close attention to. The first is the option "Directory on the firewall where script should be installed". This should match a directory that exists on the firewall where the firewall script should be run. Typically for iptables firewalls the directory is either /etc/ or /etc/fw (if this directory has been created on the firewall).

The second setting to pay attention to is the username. This is the username that will be used when Firewall Builder connects to the firewall to install the generated firewall script. If the username configured in the installer tab does not have administrative rights, the installation will fail. So in this section, enter a username that does have admin rights and can actually install firewall rules (if the user can use the iptables command, that user most likely has rights enough.) If the username setting is left blank the user will be prompted to enter the username when they run the install wizard.

Finally, in the installation tab, there is the additional command line parameters for both ssh and scp options. This is an incredibly helpful should ssh and/or scp use alternative ports. Should that be the case, simply add something like -p 2222 to instruct ssh to use non-standard port 2222 (instead of standard port 22).

The next tab that should be of use is the Prolog/Epilog. This tab allows for the addition of script commands in bash format to be added either to the beginning or to the end of a firewall script. For example, the amount of traffic being served up by an HTTP server can be controlled by using the Traffic Control command (tc). The commands would need to be added to the epilog (end) of the firewall as shown in Figure 3.

 

Prolog scripts can be added in three different locations, whereas Epilog scripts can only be added to the end. Make sure that the commands entered can be run as a bash shell script without any errors.

Finally, the Script Tab offers a number of setting options, of which there are four settings to pay close attention to. It is important to note that this tab directly effects the script generated for the firewall being configured and not the machine that Firewall Builder is running on. The first is "Configure Interfaces of the firewall machine." If this option is not checked the script generated will not include shell code necessary to manage IP Addresses. By default this is on.

The next option in the Script tab is for VLAN interfaces. If the checkbox for "Configure VLAN interfaces" is checked the script generated by Firewall Builder can create and remove VLAN interfaces for the firewall. If left unchecked, this feature will not be available. In other words, if VLAN interfaces are necessary, make sure this check box is checked. This same option is available for bridged interfaces. If the firewall to be installed needs to configure any bridge interfaces, the check box for "Configure bridged interfaces" must be checked, otherwise bridged interfaces will not be available to the firewall machine.

Finally, "Use iptables-restore to activate policy" is the last option I will deal with. There are two ways in which generated scripts can be loaded:

Using iptables command: This command will load the rules of a firewall one at a time.Using iptables-restore: This command will activate the rules of the firewall all at once.

The biggest difference between the two methods, with regard to Firewall Builder, is that the iptables-restore is a much faster process. This can make a significant difference when the firewall becomes longer and more complicated. If, on the other hand, a firewall is short and basic, the standard method of running iptables commands line-by-line will work just fine.

I have only scratched the surface of the Firewall Builder Firewall's Settings window. Although I have touched on many of the more important options, it would behoove you to comb through all of the tabs to make sure there aren't options available that would make a difference in a particular firewall. But the settings options illustrated here are those that most users will want to at least examine for their firewall rules, before they are compiled and installed.

View the original article here

Manage you iPod with Floola

Have you ever wanted to extract songs from your iPod or to modify you playlists  when away from your computer? The major problem you’ll face is that your iPod can only be managed by a single installation of iTunes.

So if you plug it on you kitchen computer instead of the office computer for instance, you won’t be able play/extract/upload/modify anything on you iPod as it can only be “synced” with your office computer.

Floola is the perfect solution for bypassing this limitation. It can extract song from and to your iPod, add/modify playlists and smart playlists, manage podcasts, videos, lyrics, artwork, etc… virtually anything iTunes can do!

This freeware is available for Linux, Mac and Windows, and best of all it’s portable : it doesn’t require any software installation. Just leave the executable files on you iPod and you’ll always be carring a universal iTune alternative with you, which you’ll be able to run and use to manage your iPod from any computer!

View the original article here

Weekend Project: Manage Bugs with Mantis

All kinds of organizations need bug trackers. Whether it's software developers, Web site developers, or just organizations with significant IT needs, bugs must be tracked. (And, you know, fixed.) To that end, there are plenty of bug tracking tools available, but none that are open source and as easy to install and manage as Mantis Bug Tracker. This weekend, get started tracking bugs with Mantis!

Since the installation of Mantis is such an easy (and well documented) task, I want to focus on the management and flow of the work done within the tool. This means managing projects as well as reporting and managing the flow of reported bugs. The only assumption made will be that Mantis is already up and running.

Before bugs can be reported, there must be a project to report bugs on. In order to manage projects log into Mantis as the administrative user and then click on the Manage link. From this new page (see Figure 1), click on the Manage Projects link.Obviously, all Mantis management is tackled from this page, so make sure whoever has the key to this kingdom knows what they are doing — or should, anyway.

From within the Manage Projects page all that is necessary is to click the Create New Project button. From within the new page, the following information is necessary:

Project Name: Human Readable name for project. This is the only field that is required.Status: Choose from development, release, stable, obsolete.View Status: Choose from public or private.Inherit Global Categories: On or off.Upload File Path: Path for file upload. This path must be readable and writable by the web server and does not (nor should) need to be within the document root or the Mantis directory.Description: Human readable description of project.

Below the Description there are other fields that can be filled out. Per-project categories can be created on this page. Per-project categories are very important and useful to make the flow of bugs easier to follow. Getting as granular as possible in the categorization will not only make it easier for developers and admins to follow the flow of information, it will also make it much easier for reporters to report bugs (and be more specific when doing so.) Use this only if there will be categories that are only related to this particular project. The main categories are global and can be used by all projects.

There is one small hiccup with creating the categories at this point. When a category is created, it's always smart to assign that category to a user. But if no users have been created, this isn't possible. To really make the most out of the system, each category should be assigned a lead so all notifications can be funneled to the proper person. So, instead of creating Categories next, migrate over to users and create the users that will serve as the heads of the various categories. Don't worry, the project can be modified later, after users have been created. Naturally, this won't be necessary on a Mantis installation that already contains the necessary users.

The managing of users is a fairly straight-forward task, but it's one that's quite important. When users are created they are assigned an access level which dictates their effective permissions within Mantis. So, it should go without saying, to pay close attention to the access level of a new user. To create said new user click on (from the Mantis home page) Manage > Manage Users. From the Manage Users page, click the Create New Account button and fill out the necessary information:

Username: The username the user will log in with.Real Name: The human readable name of the user.E-mail: E-mail address for the user.Access Level: Choose from viewer, reporter, updater, developer, manager, or administrator.Enabled: Check to enable to user. Uncheck to temporarily disable the user.Protected: When an account is protected its attributes can not be changed.

With the users created, now it's possible to assign categories to those users to further refine how Mantis is used.

Go back to the Manage Projects page. From this page it is possible to create Global Categories. As mentioned earlier, Global Categories are available to all projects, so do not create categories here that relate to a specific project. To create a category simply type the category name in the field to the left of the Add Category button and click Add Category. This will add the category, but will not assign the category to a user. In order to assign a category to a user click the Edit button associated with the category, which will open that category up for editing (see Figure 2).

 

At this point the category name can also be changed.

To assign the category to a user, just select the user from the drop-down and then click Update Category. With the project, categories, and users created it is now possible for users to report bugs against the project.

As crucial as categories are to the ability for reports and manages to work the flow of information, email alerts are, without a doubt, the single most important feature of Mantis for quick response to issues. These alerts make those who need to know aware when bugs are reported and/or have status changes. This feature, of course, requires a working SMTP server configured in the config_inc.php configuration file. With that in place, do the following:

Go to the Mantis main page.Click on the Manage link.Click on the Manage Configuration link.Click on the E-mail Notifications link.Configure Access Levels for each user type (See Figure 3.)Click Update Configuration.

Settings highlighted in green override all others. Settings in blue are project-specific.

The flow of bug tracking can range from the fairly simple to the very complex. This will be dictated on how detailed bugs become, how frequent bugs are reported, and how granularly those bugs are managed. Regardless of how complex your bug reporting can get, this is how Mantis manages the flow of bugs:

User logs onto Mantis site.User reports issue for a particular project, making sure to select either a Global or Project-specific category.Notification is sent to Project Manager (or whoever is configured to receive notifications.)Manager (or administrator) of project confirms bug and assigns bug to developer.Developer resolves bug and sets bug status to resolved.Manager (or administrator) can then close bug when resolution is confirmed.

As is shown in Figure 4, it is very easy to access quite a large amount of information about a bug. Each blue link is clickable and will reveal different aspects about an individual but, a category, a user, a project, and more.

 

In this example there are two projects with a bug attached, Mobuntu and WidgetOne.

A user with the correct permissions could click on any of the listed bugs and view, edit, promote, demote, assign, and much more. Bugs can even have their status changed in batches by checking off all the bugs to be changed and then selecting the new status from the drop-down (below the bug listing window). Once the new status is selected, click the OK button to update. Depending the change, a new window may be opened for user interaction (such as with an assigning of bugs.)

Different companies will use Mantis differently. Some will be able to function with just the very basics, whereas others will depend upon a highly detailed usage. Regardless of how it is used, it is important to know that Mantis Bug Tracker offers numerous ways to manage the flow of bugs in and out of the system.

View the original article here