Expat-IT Tech Bits




Search this site:


/ (289)
  Admin/ (123)
    Apache/ (10)
      HTTPS-SSL/ (4)
      PHP/ (3)
      performance/ (2)
    Cherokee/ (1)
    LAN/ (4)
    LVM/ (6)
    Monitoring/ (2)
      munin/ (2)
    SSH/ (6)
    SSL/ (1)
    Samba/ (1)
    VPN-options/ (7)
      OpenVPN/ (1)
      SSH-Proxy/ (3)
      Tinc/ (1)
      sshuttle/ (1)
    backups/ (17)
      SpiderOak/ (1)
      backuppc/ (5)
      dirvish/ (1)
      misc/ (6)
      rdiff-backup/ (1)
      rsync/ (1)
      unison/ (2)
    commandLine/ (24)
      files/ (8)
      misc/ (10)
      network/ (6)
    crontab/ (1)
    databases/ (15)
      MSSQL/ (2)
      MySQL/ (8)
      Oracle/ (3)
      PostgreSQL/ (1)
    dynamicDNS/ (2)
    email/ (11)
      Dovecot/ (1)
      deliverability/ (1)
      misc/ (1)
      postfix/ (7)
      puppet/ (1)
    iptables/ (3)
    tripwire/ (1)
    virtualization/ (9)
      VMware/ (1)
      virtualBox/ (8)
  Coding/ (14)
    bash/ (1)
    gdb/ (1)
    git/ (3)
    php/ (5)
    python/ (4)
      Django/ (2)
  Education/ (1)
  Hosting/ (27)
    Amazon/ (18)
      EBS/ (3)
      EC2/ (10)
      S3/ (1)
      commandline/ (4)
    Godaddy/ (2)
    NearlyFreeSpeech/ (3)
    Rackspace/ (1)
    vpslink/ (3)
  Linux/ (31)
    Android/ (1)
    Awesome/ (3)
    CPUfreq/ (1)
    China/ (2)
    Debian/ (8)
      APT/ (3)
      WPA/ (1)
    audio/ (1)
    encryption/ (3)
    fonts/ (1)
    misc/ (6)
    remoteDesktop/ (1)
    router-bridge/ (3)
  SW/ (45)
    Micro$soft/ (1)
    browser/ (2)
      Chrome/ (1)
      Firefox/ (1)
    business/ (28)
      Drupal/ (9)
      KnowledgeTree/ (6)
      Redmine/ (2)
      SugarCRM/ (7)
      WebERP/ (2)
      WordPress/ (1)
      eGroupware/ (1)
    chat/ (1)
    email/ (1)
    fileSharing/ (2)
      btsync/ (1)
      mldonkey/ (1)
    graphics/ (2)
    research/ (2)
    website/ (6)
      blog/ (6)
        blosxom/ (3)
        rss2email/ (1)
        webgen/ (1)
  Security/ (15)
    IMchat/ (2)
    circumvention/ (2)
    cryptoCurrency/ (1)
    e-mail/ (4)
    greatFirewall/ (1)
    hacking/ (1)
    password/ (1)
    privacy/ (2)
    skype/ (1)
  Services/ (1)
    fileSharing/ (1)
  TechWriting/ (1)
  xHW/ (14)
    Lenovo/ (1)
    Motorola_A1200/ (2)
    Thinkpad_600e/ (1)
    Thinkpad_a21m/ (3)
    Thinkpad_i1300/ (1)
    Thinkpad_x24/ (1)
    USB_audio/ (1)
    scanner/ (1)
    wirelessCards/ (2)
  xLife/ (17)
    China/ (9)
      Beijing/ (5)
        OpenSource/ (3)
    Expatriation/ (1)
    Vietnam/ (7)


  • 2019/06
  • 2016/07
  • 2016/05
  • 2016/02
  • 2016/01
  • 2015/12
  • 2015/11
  • 2015/06
  • 2015/01
  • 2014/12
  • 2014/11
  • 2014/10
  • 2014/09
  • 2014/07
  • 2014/04
  • 2014/02
  • 2014/01
  • 2013/12
  • 2013/10
  • 2013/08
  • 2013/07
  • 2013/06
  • 2013/05
  • 2013/04
  • 2013/02
  • 2013/01
  • 2012/12
  • 2012/10
  • 2012/09
  • 2012/08
  • 2012/07
  • 2012/06
  • 2012/05
  • 2012/04
  • 2012/03
  • 2012/01
  • 2011/12
  • 2011/11
  • 2011/10
  • 2011/09
  • 2011/08
  • 2011/07
  • 2011/06
  • 2011/05
  • 2011/04
  • 2011/02
  • 2010/12
  • 2010/11
  • 2010/10
  • 2010/09
  • 2010/08
  • 2010/07
  • 2010/06
  • 2010/05
  • 2010/04
  • 2010/03
  • 2010/02
  • 2010/01
  • 2009/12
  • 2009/11
  • 2009/10
  • 2009/09
  • 2009/08
  • 2009/07
  • 2009/06
  • 2009/05
  • 2009/04
  • 2009/03
  • 2009/02
  • 2009/01
  • 2008/12
  • 2008/11
  • 2008/10
  • 2008/09
  • Subscribe XML RSS Feed

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

    This site has no ads. To help with hosting, crypto donations are accepted:
    Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
    Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs

    Fri, 27 Jan 2012

    /Admin/SSH: Passwordless Authentication with SSH

    How to use SSH keys to login to your server without giving a password -- perhaps contra-inuitively, this kind of passwordless login is usually more, not less, secure then a password login. (Not to mention convenient and time-efficient....)

    Say we want to login to server.com from our desktop without a password. The rdiff-backup wiki provides a somewhat obtuse and hard-to-read article[1] on the subject. For the basics, I prefer to start with this article[2].

    On your desktop, run:

    ssh-keygen -b 4096 -t rsa -f /home/username/.ssh/id_rsa
    Do not enter a pass-phrase!! Leave it blank

    (Note: we are creating a 4096 bit key here as recommended by nearlyfreespeech.net[3]. It is possible that some situations will require a 1024 bit key, and this key will not be useable in that situation. It is possible to have multiple keys, which may be invoked by the "ssh -i" option, for instance.)

    Now copy the public key "id_rsa.pub" to root@server.com:

    scp /home/username/.ssh/id_rsa.pub root@server.com:

    Go to server.com and append the new key to the authorized_keys:

    ssh server.com
    cd /root/.ssh/
    cat ../id_rsa.pub >> authorized_keys

    Restrict access to these keys on both your desktop and your root@server:

    chmod -R go-rwx ~/.ssh

    Test to verify you are not prompted for a password. In a terminal on your desktop, try a verbose ssh to server.com:

    ssh -v root@server.com

    If there are problems and you are prompted for a password (you should not be) the -v output should give you some clues.

    In some situations, one can make SSH key logins even more secure. For instance, on server.com, add some security directives to a particular key in /root/.ssh/authorized_keys by pre-pending the following:

    command="rdiff-backup --server --restrict-read-only/",no-port-forwarding,no-X11-forwarding,no-pty
    ie. in /root/.ssh/authorized_keys the key in qestion now contains the following, ALL ON ONE LINE, and note the single space before "ssh-rsa":
    command="rdiff-backup --server --restrict-read-only /",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AA ... uqdswe= user@desktop

    "no-pty" explicitly forbids terminal priveleges. "command" here restricts the session to running one and only one command: "rdiff-backup --server --restrict-read-only".

    Now if you try to ssh to root@server.com from a terminal, your terminal will just lock-up and stop responding. If you really do want to allow this (a terminal ssh to root@server.com without a password) just remove the "command" and "no-pty" directives from the server.com /root/.ssh/authorized_keys file.

    Note that this will only work from the account "username" on your desktop machine where you have generated a /home/username/.ssh/id_rsa file and then passed the public key to server.com. Trying to ssh from any other desktop account to root@server.com will result in a password prompt.

    [1] http://wiki.rdiff-backup.org/wiki/index.php/UnattendedRdiff
    [2] http://linuxgazette.net/104/odonovan.html
    [3] https://members.nearlyfreespeech.net/ckoen/support/faq?q=SSHKeys#SSHKeys

    posted at: 01:51 | path: /Admin/SSH | permanent link to this entry

    Fri, 20 Jan 2012

    /Admin/VPN-options/OpenVPN: Basic OpenVPN as an Internet Gateway

    Aka. How to bore through the Great Firewall if you do not want to use an SSH tunnel.

    This[1] is the OpenVPN documentation, but it is not altogether straight-forward to read, and it is missing some necessary detail.

    This[2] will get OpenVPN basically working and connected for you. First create your keys:

    cd /usr/share/doc/openvpn/examples/easy-rsa/2.0 . ./vars ./clean-all ./build-ca ./build-key server ./build-key <client> ./build-dh

    Here I would add a warning from [1] that when creating your certificates above you must enter something at the "Common Name" prompt. My first time I just accepted all the defaults and got a connection error when I tried to start OpenVPN on my client. The second time, with a "Common Name" on the server certificates, everything just worked.

    Then distribute the keys to server and client(s) per the references.

    This will get the VPN client to the VPN server. However, we want to route *all* network traffic on the client through VPN and out to the internet. There are two components to this: some additional OpenVPN configuration, and some routing configuration on the server. On my VPN server, this is my /etc/openvpn/server.conf:

    port 1348
    proto udp
    dev tap
    ca ca.crt
    cert server.crt
    key server.key # This file should be kept secret
    dh dh1024.pem
    server # vpn subnet
    ifconfig-pool-persist ipp.txt
    keepalive 10 120
    user nobody
    ; group nobody
    verb 10
    mute 20
    client-config-dir ccd "route"
    ; push "route" # home subnet
    push "redirect-gateway def1"
    push "dhcp-option DNS"

    This should be the same as in [2] except that "group nobody" line did not work on my Ubuntu Lucid server for some reason, and the last two "push" lines are what is needed on the server end to tell connecting clients to redirect all network traffic to the VPN. (Though I am not convinced that last dhcp line is having any effect on my Debian box at the moment....) Also, per [1], note that if your network interface is DHCP, it may die periodically because it is unable to communicate with your DHCP server.

    On my VPN client, this is my /etc/openvpn/client.conf:

    dev tap
    proto udp
    resolv-retry infinite # this is necessary for DynDNS
    user nobody
    ; group nobody
    ca ca.crt
    cert x60s.crt
    key x60s.key
    verb 4
    mute 20

    which is the same as in [2], except for commenting out "group nobody", which did not work on my Debian Testing client machine.

    Now for routing on the server. What a PITA. I tried at some length to get raw iptables to do the job, but in the end turned to my old faithful, firehol. Here is my /etc/firehol/firehol.conf on my server, which enables the routing of traffic between tap0 (VPN) and eth0 (internet):

    version 5
    # interface eth0 internet
    interface eth0 internet
       protection strong 10/sec 10
       server "https http icmp ssh"  accept
       server openvpn accept
       server ident reject with tcp-reset
       client all   accept
    interface tap0 vpn
       server all   accept
       client all   accept
    router internet2vpn inface eth0 outface tap0
       masquerade reverse
       client all      accept
       server ident    reject with tcp-reset

    (After the fact, I ran into this[3] very interesting post....)

    [1] http://www.openvpn.net/index.php/open-source/documentation/howto.html
    [2] https://www.debian-administration.org/article/Connecting_to_office_network_using_OpenVPN_tunnel
    [3] http://www.hermann-uwe.de/blog/howto-using-openvpn-on-debian-gnu-linux

    posted at: 04:58 | path: /Admin/VPN-options/OpenVPN | permanent link to this entry

    /Linux/misc: Running and Installing Debian from a USB Stick

    So unbelievably easy[1]:

    cat debian.iso > /dev/sdX

    I grabbed the latest net install[2] ISO, did the above, popped it into my new laptop, hit F12 during boot to get the boot menu, and picked the USB option. Never had such a swift and painless install....


    And then there was Ubuntu Lucid. Not so easy. The ISO will not boot from USB per the above. After a bit of flailing around, it seems the easiest way (and so far the only way) that has worked for me is to use usb-creator, which is packaged with Lucid. And only works with X, there is no console version.

    Yes, that means you need a running Lucid desktop to do this. Lame. The package that needs to be installed is usb-creator-gtk. Note that you can invoke it from the following menu:

    System --> Administration --> Startup Disk Creator

    but that did not work for me either, there were errors. What I did was installed the sux package, logged into root in a terminal by invoking sux, and then invoked usb-creator-gtk as root. Then it worked, and the USB stick booted.

    [1] http://www.debian.org/releases/stable/i386/ch04s03.html.en
    [2] http://www.debian.org/CD/netinst/

    posted at: 02:51 | path: /Linux/misc | permanent link to this entry

    Sun, 15 Jan 2012

    /Admin/virtualization/virtualBox: Debian Host and Guest

    At least on Debian, there is one thing that is constantly breaking in my VirtualBox (VB) installation: missing kernel headers. The symptom is, that after a new kernel comes in, VB suddenly will not work any longer. It seems particulary insidious on the guest Debian OS, because "all" that stops working are certain conveniences, like (what I was just sorely missing) the ability to copy and paste between host and guest OS. I found it very easy to assume that something was just broken, when in fact all that was missing was the kernel headers package.

    So once and for all, here is the drill for getting VB working properly on both host and guest....

    On the host, this is the list of modules I have installed:


    On the host, if VB is not working and

    modprobe vboxdrv

    does not find your VB kernel driver, ie.

    FATAL: Module vboxdrv not found.

    you are almost certainly missing headers, ie. there should be a headers package installed that exactly matches your current kernel:


    Install it and all should be well. On the Debian guest OS, things are only slightly different. Here are my current VB modules on the guest:


    if you cannot copy and paste between host and guest (my recent symptom) and the vboxguest kernel module is missing, same drill: install your headers. Then:

    /etc/init.d/virtualbox-guest-utils start

    and now

    # ps -ef | grep -i vbox
    clayton     1641     1  0 18:47 ?        00:00:00 /usr/bin/VBoxClient --clipboard
    clayton     1650     1  0 18:47 ?        00:00:00 /usr/bin/VBoxClient --display
    clayton     1655     1  0 18:47 ?        00:00:00 /usr/bin/VBoxClient --seamless

    you can see all the things that were not working perfectly before. ("Clipboard" being the shared clipboard whose absence meant my copying and pasting was not working.)

    One final tweak to get sound working on the guest OS:

    apt-get install pulseaudio pavucontrol

    Then start pavucontrol, and in the output section, turn off the mute button. (I did try installing a couple of simpler mixers to see what was going on, but they would not even start for some reason. And in any case, in my experience, pulseaudio works well and I do not mind having it around.)

    posted at: 02:10 | path: /Admin/virtualization/virtualBox | permanent link to this entry