Wenn man in der Datei ~alice/.ssh/authorized_keys den mit ssh_keygen erzeugten Public-Key des Users bob einfügt und bob ist in der Gruppe, zu der die Datei ~alice/.ssh/authorized_keys gehört (typischerweise auch alice), dann darf die Datei ~alice/.ssh/authorized_keys keine Gruppen-Schreibrechte haben, sonst kann sich bob nicht passwortlos als alice anmelden. Das ergibt Sinn, man muss aber erst einmal drauf kommen. Am Besten setzt man die Rechte der authorized_keys-Dateien eh auf 600 (chmod 600 ~/.ssh/authorized_keys oder chmod go-rwx ~/.ssh/authorized_keys).

Wofür man solches wissen muss? Angenommen, einer Gruppe von Usern soll erlaubt werden, ein ganz konkretes Programm auch als User alice und nicht nur in der Gruppe alice ausführen zu dürfen, dann lässt sich dafür das viel (und oft aus falschen Gründen) gescholtene sudo nutzen, indem in /etc/sudoers vermittels sudo visudo

%alice ALL=(alice) NOPASSWD:/home/alice/bin/asalice.sh

eingetragen wird. Damit wird dafür gesorgt, dass Mitglieder der Gruppe alice (%alice) das Programm ~alice/bin/asalice.sh mit

sudo -u alice /home/alice/bin/asalice.sh

ausführen dürfen. Dabei muss natürlich darauf geachtet werden, dass in asalice.sh keine Sicherheitslöcher beispielsweise durch less entstehen. (! in less ermöglicht beliebige Shell-Kommandos - dann als User alice).

So vermeidet man, dass einer Gruppe von Usern für einzelne Aufgaben gleich der gesamte User-Account per ssh freigegeben werden muss, und ermöglicht sehr feingranulare Administrationsrechte, so dass passwortlos und daher automatisierbar, Skripte unter dem User alice ausgeführt werden können.

Wenn der User bob Ubuntu-typisch auch noch in der Gruppe sudo ist und dadurch Root-Rechte hat, muss der spezifischere Eintrag (%alice) nach dem allgemeineren (%sudo) stehen, sonst funktioniert der Aufruf nicht passwortlos.

Mit der Kombination ssh, git, sudo, Gruppen und Usern lassen sich recht komfortable und dennoch sichere Administrationskonzepte bauen.

Ein ähnliches Ergebnis erzielt man, indem in der Datei authorized_keys vor dem jeweiligen Schlüssel, der mit ssh-rsa beginnt,

command="auszufuehrendesprogramm"

in der gleichen Zeile eingetragen wird. Soll z.B. wieder bob passwortlos auf dem Server - diesmal als claire - nur ein spezielles Programm auführen dürfen, sieht das in der authorized_keys-Datei bei claire etwa so aus:

command="/home/claire/bin/asclaire_via_ssh.sh" ssh-rsa AAAA ....

Das Programm asclaire_via_ssh.sh wird dasjenige sein, das in jedem Falle ausgeführt wird, egal welches Programm als Argument an ssh übergeben wird. In dem Skript kann dann über die Variable SSH_ORIGINAL_COMMAND unterschieden werden, was konkret zu tun ist.

#!/bin/bash
#name: asclaire_via_ssh.sh
[ "$SSH_ORIGINAL_COMMAND" == 'list' ] && /home/claire/bin/list
[ "$SSH_ORIGINAL_COMMAND" == 'depl' ] && /home/claire/bin/depl

So kann nun bob per ssh das Programm asclaire_via_ssh.sh von seinem Account - auch von seinem lokalen Rechner aus, wenn die Public-Key Infrastruktur entsprechend eingerichtet ist - aufrufen, indem er scheinbar list oder depl aufruft:

ssh claire@server list
#hello bob incarnated as claire
#this is a list of available commands
list
depl

Auf den Namen als Remote-User lässt sich nicht direkt zugreifen. Jedoch lässt sich vermittels

command="/home/claire/bin/sshasclaire.sh",\
environment="REMOTE_USER=bob" ssh-rsa AAAA ....

eine passende Umgebung aufsetzen, wenn in der Konfiguration in /etc/ssh/sshd_conf die Zeile

PermitUserEnvironment yes

eingetragen ist.