This Howto describes a way to set up client and server to let Tomboy synchronize its notes with your SSH-server ‘myserver.com’, and optionally to share these notes across multiple clients. It is written for Linux clients (ubuntu 11.04) and a Linux server (ubuntu 10.04) with root access via ‘ssh’. However, it should work out similarly for other Linux derivates.
The seven easy steps I present here are:
- Create remote user ‘tomboy’
- Test new user ‘tomboy’ and create data directory
- Create and install private/public key
- Configure Tomboy
- Disable password-login for user ‘tomboy’ at server
- Configure Tomboy on additional clients
And here we go with the details (for user ‘peter’)…
At the client, the package ‘sshfs’ must be installed to allow Tomboy to connect via ssh at all:
peter@myclient:~$sudo apt-get install sshfs
- (Create remote user ‘tomboy’)
At the server, create a new user ‘tomboy’ including some home-directory.
peter@myserver:~$sudo adduser tomboy
In the interactive dialog, you might choose some silly password (we will disable it later anyway) and use defaults for all other values.
- (Test new user ‘tomboy’ and create data directory)
Test the new user login by logging into the server as ‘tomboy’. Create some directory ‘data’ as root directory for all Tomboy-data:
peter@myclient:~$ssh firstname.lastname@example.org tomboy@myserver:~$mkdir data
- (Create and install private/public key)
At the client, create a new private/public key pair by:
In the interactive dialog, choose as file ‘/email@example.com’. The password can be left empty, if it is ok that anyone who has the private key file can access the server as tomboy.
This generates two files: ‘/firstname.lastname@example.org’ and ‘/email@example.com’, corresponding to the private and the public key, respectively. We have to install the public key on the server. We might do this manually (by copy&paste into remote’s ‘~/.ssh/authorized_keys’ or by using the following tool at the client:
peter@myclient:~$ssh-copy-id -i ~/.firstname.lastname@example.org email@example.com
We use the silly password from above for this step.
- (Configure Tomboy)
Now we can already configure Tomboy (Properties…) to use ssh:
- if necessary, activate Add-Ins -> Synchronization -> SSH Sync Server Add-In
- at the sync-tab, type the servername (‘myserver.com’), the user (‘tomboy’) and the directory (‘data’)
- save the settings. The first sync process should quit successfully
- (Disable password-login for user ‘tomboy’ at server)
Finally (in fact, optionally), we might drop the ability to access ‘firstname.lastname@example.org’ via ssh by just a password at all, and require to have the private key installed. Therefore, on the server, edit ‘/etc/ssh/sshd_config’ as root and add to its end (!) the following lines:
Match User tomboy PasswordAuthentication no
This disables the password authentication for the tomboy user only. Note that this should be placed at the end, because *all lines* started from ‘Match User tomboy’ are ignored for any other user than tomboy.
Remotely load the changes to the ssh-server by:
peter@myserver:~$sudo /etc/init.d/ssh reload
On the client-side, you might have to re-login to let the changes take effect. You can check if a login is still possible, by:
This should login as tomboy at the server without prompting for a password (if none was set for the private key). Or, just try to sync again with tomboy.
- (Configure Tomboy on additional clients)
If you did not disable the password-login, you can enable Tomboy on additional clients to access your notes by performing the steps 1, 4 and 5 exactly as above. Otherwise, step 4 (creating a new private/public key pair on the additional client and adding its public key to the server for user ‘tomboy’) is no longer possible, since you can no longer login as ‘tomboy’ by password on the server to add the new public key.
However, instead of step 4, you can just re-use the same private key on all additional clients by placing a copy of both the private key and the public key files ‘~/.email@example.com[.pub]’ in the ‘~/.ssh’ directory of the additional client. You should make sure that the file permissons of the private key copy is still restricted to user-visibility (‘chmod 600 ~/.firstname.lastname@example.org’), since otherwise it is not accepted as a private key. The copy of the public key beside the private key is needed to auto-detect this key on ssh-login.
If you run into trouble, try manually adding this private key to the ssh-cache by ‘ssh-add ~/.email@example.com’, and check the verbose output of ssh by ‘ssh firstname.lastname@example.org -v’.
Further, it might be a good idea to backup the ‘/home/tomboy/data’ directory on the server-side once in a while (to a place where user ‘tomboy’ has no privileges) by some cronjob.