Mounting a Fritzbox NAS share on *nix

Since I had some trouble mounting the share of a AVM Fritzbox 7270 on my FreeNAS box, I did some research how to do it. The solution was quite easy after I figured why he was whining that he couldn’t find the server (turned out the VPN caused a problem with the NetBIOS resolution). The required share name was also one thing that irritated me since normally you can see that name when you browser the CIFS server. Here actually not, but this is nothing you can’t change with a bit of “smbutil view //server”. In the end the command to successfully mount the share on FreeBSD and Linux is as following:

mount_smbfs -W <workgroup> [-I <fritzbox ip>] //[username@]<fritzboxip>/FRITZ.NAS /mnt/<target directory>

Example: mount_smbfs -W WORKGROUP -I 192.168.178.1 //myuser@192.168.178.1/FRITZ.NAS /mnt/fritznas

It’s quite simple. The parameter “-I” is optional, same goes for the username. Set those as needed and fitting to your settings on the Fritzbox itself. If you need a username/password, he will ask for the password interactive. For how to setup this mount command without password prompt check the manual of smb.conf.

flattr this!

Transfer mail encrypted between the servers with postfix

When I was looking at mailheaders again (it became kind of a hobby, and this proves you learn from it^^) I was noticing one of my incoming mails was transfered via ESMTPS. So far I knew SMTP and ESMTP but ESMTPS was appearently a new. Turned out it was ESMTP via secure transportlayer, or like RFC 3848 defines it: “The new keyword ‘ESMTPS’ indicates the use of ESMTP when STARTTLS is also successfully negotiated to provide a strong transport”. So I became curious, how can I do that too? After a bit searching I came across the setting smtp_tls_security_level in postfix and yes, after setting it to ‘may’ it did the trick. So now if the server supports STARTTLS he opens a encrypted connection with the remote server for the transfer. You need to set a bit more to make it working without any errors, here is what you need to do on a Ubuntu 10.04 (Debian and others should work similar):

sudo postconf -e 'smtp_tls_security_level = may'
sudo postconf -e 'smtp_tls_loglevel = 1'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo service postfix restart

We set only smtp_tls_security_level to ‘may’ cause otherwise with ‘encrypt’ the remote server is forced to support STARTTLS, if he does not the transfer fails. So with may encryption gets used when supported. Loglevel 1 gives you a short notice when a safe connection was established and what cipher got used. Like this:

Mar 14 00:22:08 utgard postfix/smtp[11397]: setting up TLS connection to gmail-smtp-in.l.google.com[173.194.70.26]:25
Mar 14 00:22:08 utgard postfix/smtp[11397]: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.70.26]:25: TLSv1 with cipher RC4-SHA (128/128 bits)
Mar 14 00:22:09 utgard postfix/smtp[11397]: 6A591E6C2C3: to=, relay=gmail-smtp-in.l.google.com[173.194.70.26]:25, delay=0.9, delays=0.01/0.03/0.13/0.73, dsn=2.0.0, status=sent (250 2.0.0 OK 1331680929 s26si2913819weq.13)

And last but not least, we need to set the path to where he can find the ca-certificates to validate the remote servers certificate. Otherwise we get a entry saying a untrusted connection gets used, means he encrypts but can’t verify the remote identity. In Ubuntu (Debian) inside the chroot path of postfix lies a file containing all ca-certificates, we just need to point postfix to it. The normal path is not accessable from inside the chroot. Thanks to Alain Kelder to point this out. With all that done, our server is good and enabled to send out his outgoing mail to other smtp servers using a secure transport layer. You can go even further and for example force encryption for specific servers on a per-site basis. But since thats not the scope of this article, please refer to the postfix TLS documentation for that. There you find also information how to optimise the encryption by disabling/enabling ciphers and similar.

flattr this!

Make amavis-new speak German with you

By concidence I came across a translation of the amavis-new templates for it’s messages in German and a guide how to set those translations up. The translated templates you can download from http://fblan.de/postfix/amavis/de_DE/. The install instruction works on Debian/Ubuntu, on other OSes please check where the entry in the config lies. And here is how to install them (requires root):

sudo -i
mkdir /etc/amavis/de_DE
cd /etc/amavis/de_DE
wget http://fblan.de/postfix/amavis/de_DE/charset
wget http://fblan.de/postfix/amavis/de_DE/template-dsn.txt
wget http://fblan.de/postfix/amavis/de_DE/template-spam-admin.txt
wget http://fblan.de/postfix/amavis/de_DE/template-spam-sender.txt
wget http://fblan.de/postfix/amavis/de_DE/template-virus-admin.txt
wget http://fblan.de/postfix/amavis/de_DE/template-virus-recipient.txt
wget http://fblan.de/postfix/amavis/de_DE/template-virus-sender.txt

Once you took care of that, we need to edit the file /etc/amavis/conf.d/30-template_localization. Comment out the old line “read_l10n_templates(‘en_US’, ‘/etc/amavis’);” and place a new line with “read_l10n_templates(‘de_DE’, ‘/etc/amavis’);” below. After a restart amavis now sends out his reports in German instead of English. And do not forget to do a logout after the amavis restart, we don’t wanna act as root longer then necessary! ;-)

The guide is from o-o-s.de and the translation from fblan.de, thanks to both!

And should the fblan.de webpage down for some reason, I have a local copy for download here.

flattr this!

Mounting an iOS 5.0.1 device on Ubuntu – how to fix it

After you upgraded your iOS device to 5.0.1 you probably get an error like “Unhandled Lockdown Error (-15)”. The problem is the shipped libimobiledevice which don’t like iOS 5 devices. To fix it do the following:

  • In a terminal type: “sudo apt-get install ifuse libimobiledevice-utils” (without the ” :)
  • Unlock iDevice from device’s lock screen (only needed the first time), plug it in
  • In the terminal type: “idevicepair unpair && idevicepair pair”
  • Unplug the iDevice
  • Make sure the lock screen is still unlocked
  • Plug it back in

After that it works fine, even with a locked iDevice (iPhone in my case). Most information for this article came from an article over at askubuntu.com.

flattr this!

One-Time-Passwords with Google-Authenticator


Today I want to show you how to set up Google-Authenticator so make your remote login more secure then before. It offers us to secure our login with a HOTP (counter-based, HMAC-based OTP) or TOTP (time-based) tokens as an additional challenge before you can login. Basically even IF someone spots your password, without a fresh token he can’t login. But no worries, in case you loose your cell (which is used as our token-generator, supported is iOS, Android and BlackBerry) he also give us 5 extra tokens for emergency’s.

 

A word for those maybe thinking “Urk, its from Google”. Yes it is, BUT its not dependent or require you to have anything from the Google services. It’s a opensource implantation of the known algorithms, and like the WordPress plugin shows, nicely can be integrated into various apps. Also its quite cost-effective as most have anyway a smartphone today.

So let’s start with the installation, I did it on a Ubuntu Lucid 10.04. We need to build it the packages “gcc mercurial libpam0g-dev subversion git-core”. Additional we should install “libqrencode”, but as it’s not available from the repository’s we just build it from the source, so we need also “git” to checkout the source from GitHub. libqrencode is to display a QR code on the terminal, saving us the typing of the initial code for the token generator.

$: sudo apt-get update ; sudo apt-get install -yy gcc mercurial libpam0g-dev git-core subversion

Once we’re done that, lets check the mercurial version as its crucial to checkout the Google-Authenticator source-code. You do that with “hg –version”. If the version is bigger then 1.5 then all is OK but if the version is smaller then that, we need to upgrade it to one bigger then 1.5. To do so, just go to the Ubuntu FTP Server and grab the package “mercurial-common_*.deb” and the “mercurial_*_amd64.deb” or “mercurial_*_i386.deb” depending on your system. Install them with:

$: sudo dpkg -i mercurial*.deb

That takes care of mercurial, lets move on with the preparations. Next we install libqrencode:

$: git clone https://github.com/fukuchi/libqrencode.git
$: cd libqrencode
$: ./autogen.sh
$: ./configure --prefix=/usr
$: make
$: sudo make install

With that libqrencode is in place. We need to install it in /usr instead of /usr/local, cause otherwise google-authenticator won’t find it. On we go with building the pam-module:

$: hg clone https://code.google.com/p/google-authenticator/
$: cd google-authenticator/libpam
$: make
$: sudo make install

Now that the parts are in place we begin assembling them. Each user now must run “google-authenticator” once so he gets a key generated before we can activate it. The program generates a base32-encoded key you are to enter in you smartphone, and also here comes libqrencode into play. It generate us a nice handy QR code to shoot with the phone saving us the typing (yes, it works fine on a console, using ansi). Also you get the 5 emergency codes I mentioned earlier. Put them in a save place! Before we make the final changes and activate the new config, open a additional terminal just in case. It’s for the case that something get wrong, so you can look up whats wrong with your config, and so you still have access to the server. Now it gets time to edit the pam-configuration.

$: sudo nano /etc/pam.d/sshd

Now we have to decide if we want get asked for the token before or after the regular password. That determines if you insert the line “auth required pam_google_authenticator.so” before the or after the default line. In Ubuntu the line for the default auth is for example “@include common-account”. So insert it before or after that line, depending on how you like it better. I get asked for my token before the usual password, so I can anger the brute-force kids a bit. After that we edit the sshd_config to enable Challange-Response-Auth.

$: nano /etc/ssh/sshd_config

Here look for the line “ChallengeResponse no” and change the “no” to a “yes”. Now we’re ready to to restart the sshd, and it (should) work.

$: sudo service ssh restart (or sudo /etc/init.d/ssh restart)

Now try to login, and see if everything works. If not, check “/var/log/auth.log” for error-messages. If you only want to use 2-factor-auth only for a few users, then you find a patch here to disable the 2-factor-auth when there is no .google-authenticator file in the home-folder of the user.

If you should use public-key-auth, its a bit complicated. That comes from the fact that the OpenSSH daemon overrides the pam-config on public-key-auth, and so the token-auth won’t take place. For some of you this might be what you want, but for others wanting to combine both, it might be not what they want. I have a solution in one of my magazines here but I want to play first with it a bit, before I write here in detail about that.

Hope you could find something useful in this article. The applications for the cellphones can be found in the following places:

While looking for more information on the Blackberry client I just found something nice. There is a WordPress plugin that allows you to use this login-method with your blog to raise safety for you admin account. The plugin you can download here.

And for more information/references:

 

flattr this!

Finally working eMail

Laptop with a opened envelope on the screen that has written eMail on it.After ages I finally took on the fight with my fear of mail-servers and got it working. Found a nice guide on Linode.com that was a great help to figure out various things. I optimized it at some points, and thanks to the book “Das Postfix Buch – Sichere Mailserver mit Linux” (german) from Peer Heinlein I did manage it. Now its adding more features like spam-assassin, virus-scanning, and more. But yea, I’m happy that I conquered my fear, but yea, I’m quite unhappy with the documentation of the dovecot/postfix. It could be improved a lot, but sadly I lack (yet) the knowledge to do so. Without that guide I certainly would have run into a bit trouble, since some points are a confusing without a hint how to work with it. But yea, made it and I will blog also about how I implanted the upcoming features, so you guys can also use it if you also think on setting up a mailserver.

Helpful tools for checking your mailserver are these:

abuse.net/relay.html Mail Relay Testing -Check your mailserver if it can be missused as a open-relay to send spam.

www.mxtoolbox.com Various tools from check your domain’s mx record to checking the servers SPF response.

flattr this!

Backup your server to Amazon S3 (simple storage service)

Today I did setup backupninja together with dt-s3-backup to backup my server gpg-encrypted to Amazon’s S3 storage. It’s a quite cost-effective way to back up things and can easily be automated. I used the good tutorial at Marcin Gryszko’s blog for setup. It’s quite good, so I only will add here some tips to get around problems and to improve safety a bit.

One thing is, and this helps also with the Deja-Backup tool for Ubuntu/Debian, often a python lib is missing to let duplicity (the backup program used here and also in the back of Deja-backup) work with S3. So if there is whining from duplicity that it can’t access S3, you need to install the package “python-boto”.

Also you want to make an own user for the backup process at S3. After a bit research I found on Random Musings Blog the help with the IAM policy stuff I wanted (as it’s not really simple in my eyes). When you add your backup user, add a policy like this (with your bucket name in it):

{
  "Statement": [
    {
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::bucket_name_here"
    },
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::bucket_name_here/*"
    }
  ]
}

That way we limit our user to only access our backup bucket, and so can separate our backup buckets from each-other, so if one gets compromised it not affect other buckets/our main user. This also works good with Deja-backup.

With this it should be quite easy to set up an automated backup to Amazon S3. My thank goes out to the two blog’s as they were a great help and finally let me get things started! I hope this collection of hints help you, too. As a word for those probably saying “S3 ? Cloud? Isn’t it insecure?”. Well, we counter the problem of possible spying on our data by using gpg encryption with a password, and if you use a 30-50 random char&number password it should be so strong that even a computer cluster should get trouble breaking it in reasonable time.

flattr this!

Gitosis and Git, another installation guide

Sure you found already lots of guides on how to set up gitosis, but here I wanna focus on something I required as I wanted to use a ssh-key different from the usual ~/.ssh/id_rsa. As hardly any page mentioned how to do it, I thought I show the different ways to do so and how to install gitosis in general. So lets begin, I use for the guide a Ubuntu 10.04 LTS but switch package manager/package name and it should work on your Linux distro too, as the rest is the same as far as I can tell.

First off we start with installation of gitosis:

$# sudo apt-get install gitosis

Now we need a ssh-key. Unless you already prepared one, you can produce one like this on your local machine and upload it to the server via scp after you created it:

$# ssh-keygen -t rsa -C "admin@gitosis" -f ~/.ssh/gitosis_on_server
$# scp ~/.ssh/gitosis_on_server.pub master@myserver.de:/home/master/

I add here the “-f ” parameter of ssh-keygen, as this is the point which my installation guide wanna go on, specifically to use a ssh-keyfile that not have the usual name id_rsa. Feel free to change the filename to your like, and not forget to set the proper user/server etc. for scp ;) . I will go on with the key called “gitosis_on_server”. The -C option is for setting the name we use later to refer to this specific key in the options.
That done we’re good for initializing gitosis master repository which will serve us as place for the auth-keys and configuration for the repository to come. To do so, we issue the following command on our server:

$# sudo -H -u gitosis gitosis-init < ~/gitosis_on_server.pub

That creates the master repository, and once that’s done we come to the interesting part. Now we either set the $GIT_SSH environment variable to a ssh command line that give your git the identify key, or like I did, edit our /etc/ssh/ssh_config a bit. Basically we define a hostentry and on the side we save us some typing that way later on, so I go here for this solution.

$# sudo nano /etc/ssh/ssh_config

Scroll down there until you reached the end, and then add the following (with your data added of course, only let the user stay as “gitosis”! ;) :

Host               gitosis-host
HostName           myserver.com
IdentityFile       ~/.ssh/gitosis_at_server
User               gitosis

With that git knows when we give it the server gitosis-host that it should use the data from this entry in the ssh_config (also makes it easy for normal ssh connection, less typing). Anyway, back to gitosis. Now we clone the repository we just created to our local machine:

$# git clone ssh://gitosis-host/gitosis-admin.git

Then he ask you for the password for the ssh-key we created earlier (if you set one, and you should to improve security!). If you should encounter an error during this that’s like this:

Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Then you most likely restricted ssh access on the server to specific groups/users, so add gitosis to the list of allowed users or add the gitosis user to the required group. If all went ok, then we can add new users/repositorys using the repository we just created. To do so, open the gitosis.conf in the folder we cloned and add entrys like this:

[group myrepo]
writable = myrepo
members = admin@gitosis

Then commit and push (!!). Do not forget the pushing, otherwise it don’t work and yea, I forgot it too and was quite irritated until I realized it. Once it’s pushed and so on the server, lets clone it and push some files into it.

$# git clone ssh://gitosis-host/myrepo.git
$# echo 'testing here' > testfile.txt
$# git add .
$# git commit -m 'adding testfile'
$# git push origin master
$# git push

So, now we want to add another user? No problem, just generate a new key with a different user@computer (here we do user1@desktop). Then we add it to the gitosis.conf in our admin repository clone like this:

[group myrepo]
writable = myrepo
members = admin@gitosis user1@desktop

And now we copy over the public keyfile. Pay attention, the public keyfile must be named like the user we just added plus “.pub”. The keyfile gets copied into/keydir/. In the example it looks like/keydir/user1@desktop.pub. That done, push it and you’re done. Now the new user can checkout it, and if thats you, just make another entry in the ssh_config, and then use the new host to clone it.

Hope I didn’t confuse you too much on the way. This guide uses parts from Ivan Kuznetsov’s guide, the help with the ssh came from the ssh manpage.

flattr this!