Posted on

Using gpg-agent to write authenticating scripts

Sometimes you want to write a shell or other script, and that script is going to have to run under sudo. Under such conditions if the script does anything that requires authentication it will not act as expected. In plain terms it means that the regular popup for authentication will not appear. The tool maybe written in a way which deals with the problem and falls back on other authentication methods, and yet it may not. In any case what you really want is for your own authentication agent (the little program called gpg-agent which is running on almost every Linux distribution from the time you log in till the time you log out) will do the authentication. This saves you lots of clicking. Imagine that the script has to do something which requires authentication X number of times. If the script does not use an agent it will not be able to cache the pass-phrases and so you will have to retype the pass-phrase several times. It can also be the case that your authenticating agent already has your pass-phrase in it’s cache and you can save typing it yet another time.

Ok. So how do you do it? Well, in your original environment you have a variable called GPG_AGENT_INFO. This variable holds the details of how to connect to your authenticating agent. If you are running regular scripts then this variable, which is an environment variable, is automatically available to them. But if you run your scripts via ssh or sudo then it is not. Just make the variable available to those scripts. Obviously the users that these scripts will be running under will have to have the right level of permission to talk to your gpg agent. How do you make them available? One way is to pass this variable over the command line and turn it into an environment variable as soon as the script starts.

Posted on

Configuring ssh server for pubkey + password authentication

In a struggle to secure my home computer I did battle with the ssh server once again to configure it “just the way I want it” ™. I prefer pubkey + password since this ensures that if I lose the laptop/phone/whatever then the lucky finder will not find his/her way into my home computer.

So, without further fanfare here are various bits that need to be done.

Configuring the ssh server
edit /etc/ssh/sshd_config and use the following entries:
Protocol 2 # protocol 1 is outdated
PubkeyAuthentication yes # I want public key to be used for authentication (and possibly to be combined with a pass phrase)

And of course there a bunch of authentication protocols that are not needed:
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
PasswordAuthentication no
UsePAM no

Creating the keys
Still on the server in the home folder of the user you want to login remotely with, create the private/public pair using ssh-keygen -t dsa in ~/.ssh (the default location for ssh-keygen). You get two files: id_dsa (private key) and id_dsa.pub (public key).

I used dsa keys in this post and you can use rsa keys if you pass -t rsa to ssh-keygen.

In the same folder on the server create a file called authorized_keys which has the public key (it can just be a copy of id_dsa.pub but has the potential to contain many keys – possibly one per user that can connect to said account or one per roaming device).

When creating the key pair you will be prompted for a pass phrase. This is where you choose whether or not you will need a pass phrase (which acts as a password) in order to access this account. If you leave the pass phrase empty you’re allowing key only access with no password which is dangerous since if anyone gets a hold of your roaming device he/she can access your account with no extra data.

Distributing the keys
Copy the private key ~/.ssh/id_dsa to the roaming devices you want to access the server from (laptop, phone, whatever). If the roaming device is a Linux box then put the private key in the same location (~/.ssh/id_dsa) in the home folder of the user that wishes to access the server. If you are using some other ssl tool besides command line ssh on a Linux box to access the server then it should have a place where you plug the private key into. If it doesn’t have such a place then dump it. Putty (a widely used ssh client on windows) has an option to use a private key for connection.

Note:
While trying this out a lot of people seem to fail because they do all the experimentation on a desktop. In a desktop there is a system called ssh-agent which does the authentication for you in order to save you typing the same password multiple times. This agent is a problem when doing experimentation since it needs to be notified that you switched keys. So, every time you switch keys (regenerate the ~/.ssh/{id_dsa,id_dsa.pub} files) you need to run ssh-add to let the agent know this. Another option is not do all of the experimentation from a desktop but rather from a login shell (Ctrl+Alt+1 or whatever) so that the agent does not come into the game (which is complicated enough without it). Only after everything is setup re login to the graphical desktop and try everything out.

Posted on

WordPress and UNIX security (part 2)

In an effort to secure my blog I once again did battle with the mighty Word press. It seems that you can run a perfectly healthy blog with no write permissions by the HTTP server (usually www-data) to your service directory.

What do I suggest? Change owner ship to root on your blog area. When you know that you need to upload stuff to Word press then open the permissions on the relevant folders. This happens when you want to add or remove plug-ins, upload media, themes etc. After the relevant operation clamp down on security again. There are plugins (like xLanguage) that write all kinds of junk log files into the upload folder as part of their operation. Obviously you cannot use these if you want better security.

Advantages: better security.
Disadvantages: A little discomfort and the need to write very simple short script to do the chmod for you. The Inability to use certain brain dead plug-ins.

Posted on

WordPress and UNIX security

Here is what I found the hard way. Sometime you want WordPress to install plugins, themes and all and do not want to pass through an ssh or ftp connection in order to achieve this. Maybe you have your own machine and do not want to run or configure an ssh or ftp server (which is my situation). In that case you can choose to either install plugins and themes by hand (just unzip them to $WORDPRESS/wp-content/[plugins|themes]) or you can give wordpress permissions so it can do it for you. The disadvantage of giving WordPress permissions is ofcourse security since any one hacking into your server could have write access to the wordpress files themselves. In order to avoid this you can keep all your wordpress files owned as root.root (maximum security) and only change permissions for the duration of the installation of the plugin or theme.

Here is how to do this for a completely safe install:


    Turn off your world access to your web server. This can be done by bringing down your external network link by ifdown eth0. This step is only necessary if you are a security freak.
    chown -R [webuser].[webgroup] [wordpress]/wp-content/{plugins,themes}. Substitute webuser and webgroup for your web servers user and group. These are usually www-data on Debian based systems or could be gotten from ps -ef.
    Now perform your installation of plugins or themes from the local machine or from a remote machine if you have not followed the security step above.
    chown -R root.root [wordpress]/wp-content/{plugins,themes}. This will clamp down on security once again.

Please note that some weird WordPress plugins write to the web folder due to their regular operation. If you have such plugins and are worried about security then I urge you to dump them and find substitute plugins. If you cannot dump them then you probably cannot use any sane security practice for your blog.