SSH: if your public keys do not get accepted by the remote side, but (you think) they are in your remote authorized keys file, …

… check, whether the remote side considers authorized_keys or authorized_keys2:

# supposedly only one of them exists:
$ fgrep AuthorizedKeysFile /etc/ssh/sshd_config /etc/sshd_config
AuthorizedKeysFile .ssh/authorized_keys

This is certainly just one possible reason, if public keys do not get accepted by the remote side.

For a couple of weeks I got asked the remote password instead, and I did not understand why. My local public key was properly listed in the remote .ssh/authorized_keys2, but only today I took the time to investigate the issue, and I got reminded of this well-known reason: my remote .ssh/authorized_keys2 simply did not get considered at all. The remote ssh looks at my remote .ssh/authorized_keys, because it got set up like that – see above!

the Emacs tramp mailing list and gmane

• http://dir.gmane.org/gmane.emacs.tramp
• http://lists.gnu.org/pipermail/tramp-devel

my new "mobile NAS": Synology DS112+

DS112+ Products - Synology Inc. Network Attached Storage

Installation procedure from CD-ROM:

• you are starting with a DiskStation with a bare disk, i.e. no DSM (the DS Management system)
• mount the supplied CD-ROM
• mount DSAssistant-SYNOLOGY_….dmg from the CD-ROM
• run the assistant App from there
• the assistant App helps you installing the DSM, either from a  DSM_DS112+_….pat file (around 40 MB large) on the CD-ROM (it comes with DSM-4.1) or from a file you download from the Synology website (bleeding edge: DSM-4.3)
• that includes formatting the hard disk

Installation procedure following following the quick set up leaflet:

• surf to find.synology.com
• it is meant to discover all reachable Synology DiskStations
• in this situation it does not find the DiskStation in question (running a DSM)
• it points you to DSAssistant-SYNOLOGY_….dmg, to be downloaded from the Synology website
• mount the downloaded DSAssistant-SYNOLOGY_….dmg
• run the assistant App from there
• …

Because I had temporary trouble accessing the supplied CD-ROM, I had to download the DSAssistant…, but I used the DSM-4.1 on the CD-ROM. That decision was unreasonable and done a little too fast, as I seriously intended to operate using DSM-4.3. So in the meantime I downloaded DSM-4.3, and after having set up DSM-4.1 entirely and properly, I set up DSM-4.3.

Further steps:

• setting up a personal user account
• allowing SSH access
• SSH log-in in using the root account
• modifying /etc/passwd to allow shell login for the user accounts in question (the resp. record has a "nologin" instead of a proper shell path)

Further steps:

• I followed the instructions listed in my own "my new NAS (…): Synology DS213+" (taken from somewhere else and my own experience)
• install the ipkg installation system
• install a proper rsync through ipkg; I will have to call this rsync as /opt/bin/rsync from now on
• "standard standard" installation is broken for the DS112+, but the wiki page describes the actual standard procedure including a fix in some bootstrap.sh
• commenting out the standard PATH setting in ~root/.profile and ~MY_ACCOUNT/.profile
• my first personal rsync-s to the DiskStation

my new NAS (and so much more): Synology DS213+

DS213+ Products - Synology Inc. Network Attached Storage

The box makes itself known as diskstation.local resp. DiskStation on my LAN. (Reliability …)

Of course it deserves a "1 Gbit/s" on my FRITZ!Box.

The box's OS is BusyBox; here are a few more details:


DiskStation> uname -a
Linux DiskStation 2.6.32.12 #2668 SMP Tue Dec 11 13:01:16 CST 2012 ppc GNU/Linux synology_qoriq_213+


I enabled SSH access for my personal user account rather soon, but the SSH login was not instantly successful. I tried "ssh -v", and from there the login seriously looked, as if it was almost successful. My web research wasn't successful either. Rather desperately I enabled "telnet access"; I tried to log in, and this was the result:

login: can't run /sbin/nologin: No such file or directory

It was clear then, that the default shell in the /etc/passwd entry for my user account was in my way /sbin/nologin so far. I made /bin/ash the default shell and everything was fine. Of course, I disabled telnet access again thereafter. And of course, once I added "nologin" to my web query, I found a few articles describing the issue.

SCP works; "rsync over ssh" (with my personal user account) does not work yet:

$ rsync -va --rsh='ssh -l root' /etc/motd diskstation:tmp/ # works$ rsync -va /etc/motd diskstation:tmp/ # fails
sending incremental file list
ERROR: module is read only
rsync error: syntax or usage error (code 1) at main.c(1034) [Receiver=3.0.8]
rsync: connection unexpectedly closed (9 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.8]

Fiddling with /etc/ssh/sshd_config – I really don't know, what to change in order to overcome this obstacle.

Perl is not part of its standard equipment, but Python apparently is,

Through their Download Center I found this FTP server link. You can find various software for their boxes on their. There are also Perl installation packages, but the ones I tried are not for the current firmware release of "my" box, and in a way I am not up for an upgrade to beta software for my NAS.

(For now I summarised here everything I have tried so far, so I will be able to procede from here.)

A few more links:

• http://forum.synology.com/wiki
• http://forum.synology.com/wiki/index.php/What_kind_of_CPU_does_my_NAS_have
• http://www.synology-wiki.de/index.php/Welchen_Prozessortyp_besitzt_mein_System%3F (this article gives us an IPKG link for the DS213+)

There are suggestions on the wiki(s) to install ipkg (yet another packaging system, not officially supported by Synology), and to install another rsync through ipkg. I may consider this, but I am not yet sure. I am quite able to use rsync (over ssh) as user root, but I am not with my personal account. I have no clue, what rights it needs, to allow my personal account to work as smoothly as user root. (To Be Solved!)

To be continued …

Emacs + putty + TRAMP = you can edit your UNIX files remotely on Windows

TRAMP User Manual

TRAMP extends the capabilities of the emacs "directory editor" (dired) to allow you to also deal with remote files. "Remote" as in:

• you can reach the file or directory through ssh
• or sftp
• or ftp
• or …

SSH on Windows – PuTTY:
On Windows platforms it can make use of the PuTTY family of utilities in order to achieve ssh and sftp tasks.

The TRAMP user manual recommends using scpc resp. pscpc instead of ssh resp. (just) plink for dealing with large files [Link]. I suggest you go for this recommendation anyway. Really! I mean it! According to my experience (having tried various ways resp. methods) plink resp. plinkx occasionally corrupt files, and you avoid that using the TRAMP method pscp, which is actually a nice combination of plinkx and PuTTY pscp, i.e. you are passing a named saved session rather than a host name to it. ("THE manual" does not mention this bit, but you should be aware of it.)

On the Windows PC at my customer's site I am not able to modify my system environment.
The putty directory is not put on PATH by the system, I am doing it within my .emacs.

Still: For some reason tramp does not search its tramp-copy-program on PATH, and at least pscp does not get found that way. The error message goes like this:

Cannot find copy program: pscp.

I found the variable tramp-methods and changed the resp. tramp-copy-program assoc to have pscp with its absolute path as its value instead of just pscp. tramp-methods cannot be "customized". add-to-list always only ends to the end of the list, so just adding a new try with a full-path-pscp would not have helped, so I rather changed .../emacs/lisp/net/tramp-loaddefs.el. Quick and dirty, I know. I will find a more appropriate way occasionally, I promise.

Update 2013-01-15: tramp paths with ports:
Occasionally "sitting" on a VM (VirtualBox) host I copy / access files living in a VM Linux guest, whose SSH port is forwarded to the VM host's port 2222.
VM-host $ env RSYNC_RSH='ssh -p 2222' rsync -vaz diary localhost:diary_
This is a useful emacs/tramp access path for those files:
/scpx:localhost#2222:diary

scpx and sshx as opposed to scp and ssh (without the 'x' in the end) seem to accept a port number within these emacs/tramp access paths.

Update 2013-04-30: problem with preserving emacs tramp file permissions:
Somebody else experiences this problem as well [link].

Update 2013-04-30 evening:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/pscp-filemodes.html : I think, this doesn't concern TRAMP, as TRAMP has its own means to enquire and set file modes.

Update 2013-10-__:
Found "vc-handled-backends" and reduced it on my Windows emacs / tramp / putty platform.