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, 21 Dec 2012

    /Admin/SSH: SSH Port Forwarding

    So I have this beast of a windows program called XenCenter that is fairly necessary for administering a Citrix XenServer. It connects to port 443 on the Xen host, which is not normally exposed with a public IP. And I do not have a working VPN to this machine. Once again, SSH to the rescue:

    ssh -t -L *:443:localhost:11111 user@hostname1 ssh -L *:11111:localhost:443 user@hostname2

    This is the most general case, and can be chained through more then two hosts. Note that the hostname or IP address between the two port specs is always relative to the remote host. Which is to say, the first localhost is on hostname1, and the second is on hostname2. Also note that user@hostname can be replaced with a locally defined Host from ~/.ssh/config, and can include the full array of ssh options like -p and -i. And finally, the *: allows connections from anywhere, not just localhost. The first one is obviously necessary because I am running this SSH on my Linux desktop, and then connecting to it with XenCenter from a Windows VM. (Not sure why the second *: is necessary....)

    Because 443/https traffic is already encrypted, the above can be simplified with little loss of security:

    ssh -L *:443:hostname2:443 user@hostname1
    Which is to say, hostname1 will forward traffic directly to port 443 on hostname2, assuming no firewalls intervene.

    posted at: 07:22 | path: /Admin/SSH | permanent link to this entry

    Sat, 08 Sep 2012

    /Admin/SSH: One-Step Multihop SSH

    (Well, at least two hops is reliably working for me....)

    A common headache, particularly for those of us who live in China: the necessity of ssh'ing first into an intermediate machine, thence to the final destination machine. Even with SSH keys, this gets ugly to setup, and uglier to maintain in the face of frequent disconnections. Unless we can find a way to login from destop through intermediate machine to destination machine, all in one entirely passwordless step.

    The secret is to leverage SSH agent. First add AT LEAST any keys you will need after the first hop to your local desktop ssh agent, ie.

    ssh-add /home/myuser/clients/clientname/id_rsa
    Then chain two or more ssh logins together as follows:
    autossh -A -t user@intermediate-server.com ssh ubuntu@

    (In this case, the is on a private network behind a router without a public IP. intermediate-server.com is on the same private network, with a public IP.)

    autossh will automatically reconnect an disconnected SSH session. (Works best with login via SSH key.)
    -A forwards your desktop SSH agent through the first hop to the second hop.
    -t forces pseudo-tty allocation

    All hops before the destination need both -A and -t.

    In my ~/.bashrc I put this:

    alias ssh-tszz1="ssh-add /home/myuser/clients/clientname/id_rsa && autossh -A -t user@intermediate-server.com ssh ubuntu@"

    so that I can login to ubuntu@ in any terminal, by simply invoking:


    It would be more elegant to have everything configured in ~/.ssh/config, perhaps with the ProxyCommand directive and nc, but so far no success with this.

    Note that I have found the second ssh fails for some reason if there is a port number, which I found an extra pair of quotes to fix. Ie. the above, with port number 1212 added, becomes:

    alias ssh-tszz1="ssh-add /home/myuser/clients/clientname/id_rsa && autossh -A -t user@intermediate-server.com 'ssh -p 1212 ubuntu@'"

    To add a third SSH hop:

    alias ssh-tszz1="ssh-add /home/myuser/clients/clientname/id_rsa && autossh -A -t user@im-server1.com 'ssh -A -t user@im-server2.com ssh ubuntu@'"

    Note the second use of the "-A -t" switches, on the second ssh hop. Of course, one can make succeeding hops simpler by populating the .ssh/config file on intermediate servers, and using a alias Host from .ssh/config instead of fully specifying the ssh parameters in the original invocation, as I am doing here.

    [1] http://sshmenu.sourceforge.net/articles/transparent-mulithop.html
    [2] http://apple.stackexchange.com/questions/37184/ssh-a-doesnt-properly-enable-forwarding-of-authentication-agent-connection

    posted at: 08:07 | path: /Admin/SSH | permanent link to this entry

    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, 26 Aug 2011

    /Admin/SSH: Some SSH Tricks

    You can re-use existing SSH connections by adding this to ~/.ssh/config file:

    Host *
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p

    Thereafter, after you login and open a connection to an SSH server, if you open another connection from another terminal, it will re-use the first connection. No need to login again, no need to wait for the connection to be re-negotiated. Over a slow, long-distance SSH connection, this can slow the wait time from tens of seconds to two seconds. This applies to SCP transfers as well. Much saved time.

    If you have a long list of servers you log into regularly, particularly on non-standard ports, these connections can also be aliased in the ~/.ssh/config file:

    Host my-chosen-alias
      Hostname server.com
      IdentityFile /path/to/id_rsa
      User root
      Port 10122
    Thereafter, "ssh my-chosen-alias" will connect to root@server.com on port 10122. Unfortunately SCP does not seem to respect these aliases, or at least I have not found out how to make that work. But this is a way, for instance, to transparently get backuppc[1] to connect to a backup client using a non-standard port.

    [1] http://blog.langex.net/index.cgi/Admin/backups/backuppc/

    posted at: 06:22 | path: /Admin/SSH | permanent link to this entry

    Thu, 16 Jul 2009

    /Admin/SSH: SSH Constantly Connecting: ServerAliveInterval

    I cannot believe I put up with this for so long: in the past when I connected to servers outside China, the SSH session would consistently disconnect after the terminal had been idle for only a very few minutes. This was very consistent, far more then "every once in a while". (I am guessing there was some Great FireWall-related foul play involved....)

    Thanks to Donncha[1] I have an elegant one-line solution by adding the following to /etc/ssh/ssh_config:

    ServerAliveInterval 60
    This causes my ssh client to send a "keep alive" message to the server after 60 seconds of inactivity. Only if the server fails to respond is the connection broken. Even in China, this seems to be quite efficient at keeping my international ssh connections open for hours at a time.

    [1] http://ocaoimh.ie/how-to-fix-ssh-timeout-problems/

    posted at: 08:06 | path: /Admin/SSH | permanent link to this entry

    Mon, 02 Feb 2009

    /Admin/SSH: Controlling Multiple Machines with Cluster SSH

    If you find yourself doing exactly the same set of steps on more then one machine, then Cluster SSH[1] is an option. Its very simple to get started. In ~/.csshrc define the set(s) of workstations that you would like to control:

    clusters = <tag1> <tag2> <tag3> <tag1> = host1 host2 host3 <tag2> = user@host4 user@host5 host6 <tag3> = <tag1> <tag2>

    Then execute "cssh tag1" and three terminals, one each for tag1, tag2, and tag3 will appear, plus the cssh control window. Any text typed into the control window will be echoed in all terminals.

    If passwordless authentication has not been configured for the remote boxes, then you will have to enter a password in each terminal at the start.

    [1] http://sourceforge.net/projects/clusterssh/

    posted at: 04:11 | path: /Admin/SSH | permanent link to this entry