Synology: enable other users (beyond root) to ssh (DSM 5.x)

You want regular (unprivileged) users of your Synology DiskStation to be able to ssh in, just like the boss can.

I saw some complex and crappy way of doing this posted somewhere, that had some fiddly mkdir and changes of ssh options.
...All that crap is not necessary.

Here's what you actually need to do:

• (prerequisite: Your Synology is set up running fine with a DSM 5.x-series OS and you can browse/login to the admin interface.)
• Enable ssh service in the web interface:
• (RTFM)
• this means root and admin should work
• ssh admin@synology.real.ip.addr to test it
• ssh root@synology.real.ip.addr (with admin's password) to test it again
• Enable user home service (for everyone) in the web interface:
• log on to the Synology web interface
• open control panel
• select 'user'
• select 'advanced'
• under 'User Home", select the checkbox on for
• 'Enable user home service'
• (...this will create /volume1/homes and point /var/services/homes to this new dir, instead of the default fake one at /volume1/@fake_home_link when user home service is off.  The service also creates the dirs for each user.  This allows the /var/services/home/youruser to have somewhere decent to shell into.  Note that synology does some slick VFS settings to show different perms for /volume1/homes, dependent on whether you're root or not, so you might not notice that only root can ls in it)
• Create a user in the web interface:
• (RTFM)
• ...shouldn't matter what kind of user, I tested with a non-admin plain user.
• During "Assign shared folders permissions" portion of the user creation, use the web interface to ensure that the user's permissions are allowed read/write for homes.  This can also be done later.
• Note that ssh will work without the ~, but the session drops into /.
• Enable a shell for the user via CLI:
• (at this point you will already have to know some Linux...)
• ssh root@synology.real.ip.addr (the admin account will not work!)
• vi /etc/passwd
• set your user's shell to a suitable shell (which is actually busybox)
• (you don't have to restart anything)
• ssh youruser@synology.real.ip.addr
• ....voila.

Multi-Machine Magazine: a convention for networked filesystem schema

This was a sort of FHS-style dir convention I worked on a while back (2011), and have been using on a RHEL machine for a couple of years now.  Basically I wanted a place to put things might be shared in common by multiple VMs or hypervisors (like VM images).  Nowadays, I'd leave the distro's normal fs alone and use something like the OpenStack images service to worry about where these things go.  Also, other work has been done to make parts of the fs read-only to make things more instance-friendly.  So this whole idea is kind of obsolete.  It was an attempt to hierarchize that which cannot be done so.

So nobody should ever actually try what this draft says.  But I'm putting this up now (2014) in case it's ever interesting to anyone and catalyzes thought.  ...Which is unlikely.

There are some annoyances that can pop up, like how moving lots of important stuff like VM dirs can burn you when SELinux is running and mmm was created with a poor context.  But that's my fault, not SELinux's.  SELinux is great.

mmm

• mmm - Multi-Machine Magazine
  • A convention that may promote more useful network sharing of non-host-specific files.
  • Copyright and License: This document is licensed under the GNU FDL 1.3.
  • Abstract:
    • A personal convention is described that facilitates sharing of files among networked computers via migration of these files to designated physical volume and application of a novel path schema. A logically defined inversion of the migrated path allows allows utility of application or VM host commonality to emerge at the top level of a hierarchical directory tree. This is applied to an example schema for the hierarchical presentation of files and directories in the Linux® VFS.
  • Motivation:
    • Much configuration/convention needs to be accessed by multiple hosts/machines.
    • A significant subset of this information has appeared more recently due to increased use of VM guests and software repositories (mirrors) aboard Linux servers.
      • Especially for files/directories containing:
        • VM information (configurations, disk image files)
        • software repositories/metadata (yum caches, channel dumps)
        • certain types of build trees (i.e. mocks)
        • database files that may be used in more than one machine context
        • mail spools
        • enclave-wide security settings
    • This data is currently distributed in files that can seem scattered, due to a preexisting legacy directory schema adopted from Unix® (/home, /usr, /etc).
    • They could be collected by a more useful schema reflecting utility/purpose/application, however...
    • Parts of current filesystem schema may not work well as this collection place.
      • e.g. /var cannot be made nearly "machine-context-free":
        • /var/run -- holds machine dependent process information,
        • /var/lock -- ...same,
        • /var/spool/mail -- ...is really application-specific, not machine-specific.
      • e.g. /etc doesn't fit, either, as it contains a mixture of "app-machine-context", "machine-context", and "app-context".
        • /etc/qemu -- app-context, although much of /etc is host-specific data,
        • /etc/libvirt/qemu -- VM guest context, not host context,
        • /etc/sysconfig -- however, is machine-context, like much of /etc.
    • Therefore, designation of a new location for such files/directories can be helpful to users.
      • These files can be moved, and then symlinked back into their original places.
      • This designation and use can only be worthwhile if performed without significant disruption to the well-known (and FHS-specified) Linux filesystem tree.
    • Moreover, an analysis of file commonality indicates that creation of a convention of a new colocation affords an opportunity of utility. Filing the data in a manner that encourages collection by purpose (application) also enhances visibility to potential users. This is done by refactoring portions of the hierarchy according to purpose (machine-context-free application data) as opposed to a normal directory hierarchy (which has some machine-context-specific schema that can hide and scatter common data if applied past the symlink).
    • Moreover, such a new location will likely contain files with similar security ACLs, promoting a more fitting default file-creation ACL for that location. This utility is most especially noticed as useful among users of virtual machine images created (or moved to) directories that contain ACLs too restrictive for presentation to a hypervisor (even though the ACLs are generally appropriate).
  • Convention:
    • context -- part of a directory path/tree schema precipitated or influenced by machine (OS or filesystem specific) requirement or convention.
      • a path that reflects some combination of OS/distro/sw/version,
      • aka MCF -- Machine Context-Specific.
    • non-context -- may (perhaps somewhat needlessly) reflect some machine context, but could be structured more usefully if removed from the bounds of the machine-specific context,
      • aka MCF -- Machine Context-Free.
    • axis -- the segment of a machine-context pathname betwen the above that can be multi-machine-mapped
      • the most specific item common to all contexts
      • all elements before the chosen axis are machine-context-free
      • all elements after the chosen axis are machine-context-specific
      • e.g. for /var/cache/yum/x86_64/, [[move this below]]
        • the MCS part is '/var/cache',
        • the MCF part is 'x86_64/13' (due to the difference between how RHEL and Fedora map their yum caches),
        • thus, the axis is '/yum'.
        • Over time, standardization/convention causes fewer items to remain on the CS portion, and thereby become pivotable.
    • fixture -- the MCS part of a path, kept due to the differences in context.
    • pivot - the MCF part of a path.
    • tovip -- a fully-reversed MCF part of a path (please excuse my presumption of neologism for the reverse spelling of pivot).
    • mmmm -- a multi-machine mappable magazine (the thing whose name will be mmm)
      • the actual magazine containing actual data,
      • contents could be non-OS-specific,
      • contents could be non-app-version-specific,
      • could be a volume,
        • could contain a filesystem,
          • filesystem subdirs could be done as:
          • [dirname] -- mappable dirs,
          • [appname] -- common app or package names,
          • [axis]
            • elements before the axis are pivoted/reversed on the mmmm and appended to the axis
            • [/botdir/middir/topdir] is mapped into via symlink from machine context wanting a /topdir/middir/botdir when [botdir] is an [appname] axis
          • [OS_ver] -> [dirname]
          • [SW_ver] -> [dirname]
          • .mmm
            • a file describing specific available mappings
            • each mapping could describe OS- or software-version-specific mappings when non-eliminable
            • format (LON)
    • /mmm - a mapping for a set of axes (colloquially: a remapping)
      • top level pivot dir used in a machine context for mapping
      • could be a direct mount, i.e.:
        • /dev/sdn on /mmm
        • /dev/mapper/mmmm on /mmm
      • could be a symlink into an actual mount point, i.e.:
        • /mmm > /media/volname
          • when /dev/sdn on /media/volname
      • apps could symlink to the top axis, e.g.:
        • [pivot]/[axis]/[fixture] -> [mmm]/[axis]/[tovip]/[fixture]
        • /var/lib/libvirt -> /mmm/var/lib/libvirt
        • /var/lib/libvirt -> /mmm/libvirt/lib/var
        • /etc/libvirt -> /mmm/libvirt/etc
        • /var/cache/yum -> /mmm/yum/cache/var
        • /var/lib/yum -> /mmm/yum/lib/var
        • /var/cache/yum/x86_64/6Workstation/ -> /mmm/yum/cache/var/x86_64/6Workstation
  • Usage:
    • path/dir naming conventions:
      • for package repos:
        • [distro]/[distro-version]
        • /var/cache/yum/x86_64/13
      • for compatibility assemblies:
        • [arch]/[exe-ABI-format]/[exe-load/linkability-format]/[exe-dependent-library-matrix]