OpenSSH - Deny user specific options ?

[Lokke]

Moin !

Ich arbeite an einem Guide in dem auch OpenSSH vorkommt und bin gerade über etwas gestolpert, was mir irgendwie aufstößt...

/etc/ssh/sshd_config ist ja > ~/.ssh/config ...

Aber:

• /etc/ssh/ssh_config
  Port 1384
  
• User
  ssh -p 1249
  
• Server
  Connection on 1249 refused
  

Ich finde partout keine Doku, die aussagt, ob man spezifische Usercommands nicht in der /etc/sshd_config deny'en kann oder nicht ?

Gerade bzgl. StrictHostKeyChecking fände ich das eklatant wichtig...eher sogar bedenklich, wenn es das nicht gibt.

Könnte mir da wer weiterhelfen ?

Gruß

[Lokke]

/etc/ssh/ssh_config ist ja > ~/.ssh/config ...

fixed

[Jejerod]

Ich finde partout keine Doku, die aussagt, ob man spezifische Usercommands nicht in der /etc/sshd_config deny'en kann oder nicht ?

Gerade bzgl. StrictHostKeyChecking fände ich das eklatant wichtig...eher sogar bedenklich, wenn es das nicht gibt.

Warum sollte es das geben? Jeder kann den Client halt so Einstellen wie er möchte, wie bei jedem anderen Client (Browser, Mailclient...) eben auch.

Auch wenn es das geben würde, hält mich nichts davon ab ein modifiziertes ssh binary in mein $HOME zu packen und zu benutzen.

Auf welchen Wert würdest du StrictHostKeyChecking administrativ setzen wollen, und was möchtest du damit bezwecken?

[Lokke]

Warum sollte es das geben? Jeder kann den Client halt so Einstellen wie er möchte, wie bei jedem anderen Client (Browser, Mailclient...) eben auch.

Nun, ich sehe ein Werkzeug, das bzgl. Sicherheit ein gewisses Maß Aufmerksamkeit verlangt, nicht auf dem gleichen Level wie deine Beispiele.

Auch wenn es das geben würde, hält mich nichts davon ab ein modifiziertes ssh binary in mein $HOME zu packen und zu benutzen.

Was auf einem Arbeitsrechner schlicht nicht der Fall ist. Sicher: Jemand, der daran denkt, manuell ein Kommando wie -o StrictHostKeyChecking=ask zu übergeben, kann genauso gut daran denken, einfach nen eigenen SSH-Client mitzubringen, aber die Schwelle von "Kommando" zu "von extern nen Programm einspielen" ist eine andere.

Auf welchen Wert würdest du StrictHostKeyChecking administrativ setzen wollen, und was möchtest du damit bezwecken?

Salopp gesagt soll Mitarbeiter x ssh benutzen können, aber eben nur mit den in der globalen Config stehenden Vorgaben.

Falls das grundlegend nicht so gedacht ist - es müsste über ein Zwischenscript lösbar sein, richtig ?

[Jejerod]

Nun, ich sehe ein Werkzeug, das bzgl. Sicherheit ein gewisses Maß Aufmerksamkeit verlangt, nicht auf dem gleichen Level wie deine Beispiele.

Es ist eigentlich recht Gleichwertig. Du kannst eine Policy ausgeben das niemand bei SSL-Verbindungen im Browser unsichere Zertifikate akzeptiert, aber machen kann der User es dann immer noch. Selbiges gilt für Mailclients die mit SSL/TLS arbeiten. Bei verantwortungslosen Handeln ist halt jeder Client eine Gefahr.

Salopp gesagt soll Mitarbeiter x ssh benutzen können, aber eben nur mit den in der globalen Config stehenden Vorgaben.

Falls das grundlegend nicht so gedacht ist - es müsste über ein Zwischenscript lösbar sein, richtig ?

Mir würde da ein Wrapperscript und eine restricted bash vorschweben. Lässt sich dann auch wunderbar auf Mitarbeiter x eingrenzen, der Rest behält die volle bash. Müsste man sich aber im Detail angucken.

Was ich eigentlich Denke: Wenn ein User verdächtigt wird das er unsauber arbeitet, dann kann man ihm nur den Zugang sperren. Man kann natürlich mit komplexen Workarounds allen das Leben schwerer machen; das dürfte aber nur dazu führen das noch mehr User versuchen das ganze zu umgehen. Ist mithin also eher Kontraproduktiv. Eine kurze Schulung des betroffenen Users warum die voreingestellten Werte gut und sinnvoll sind ist der bessere Weg.

Nur kenne ich die Situation nicht. Daher das nur als Anmerkung.

[Jejerod]

Mir würde da ein Wrapperscript und eine restricted bash vorschweben. Lässt sich dann auch wunderbar auf Mitarbeiter x eingrenzen, der Rest behält die volle bash. Müsste man sich aber im Detail angucken.

Shameless self-quote.

cd /bin

ln -s bash rbash

useradd -c "restricted user" -m -s /bin/rbash ruser

cd ~ruser

rm .profile .bashrc

Dann hat man schon mal einen restricted user. Bei mir hat dieser nur /usr/lib/restricted/bin im Pfad. Da hab ich dann mal ein ssh-wrapper reingeworfen:

#!/bin/sh

# this is /usr/lib/restricted/bin/ssh


function local_error {

        echo "error: $1"

        exit 255

}


CMDLINE=$*

# check if commandline contains evil options -o or -F

echo $CMDLINE | /usr/bin/egrep -- '(-o|-F)' > /dev/null && local_error "illegal commandline"


# exec ssh with system config to override ~/.ssh/config settings

/usr/bin/ssh -F /etc/ssh/ssh_config $*

Ergebnis:

ruser@host:~> /usr/bin/ssh user@target

-rbash: /usr/bin/ssh: Verboten:  `/' ist in Kommandonamen unzulässig.

ruser@host:~> ssh -F myconfig user@target

error: illegal commandline

ruser@host:~> ssh -o UserKnownHostsFile=/dev/null user@target

error: illegal commandline

ruser@host:~> ssh user@target

The authenticity of host ...

So oder ähnlich würde das wohl gehen.

[Lokke]

Es ist eigentlich recht Gleichwertig. Du kannst eine Policy ausgeben das niemand bei SSL-Verbindungen im Browser unsichere Zertifikate akzeptiert, aber machen kann der User es dann immer noch. Selbiges gilt für Mailclients die mit SSL/TLS arbeiten. Bei verantwortungslosen Handeln ist halt jeder Client eine Gefahr.

Darum kam bei mir ja die Frage auf - eine eigene Programmversion bringt man auf der Arbeit ja meist nicht mit (als Anwender).

Mir würde da ein Wrapperscript und eine restricted bash vorschweben. Lässt sich dann auch wunderbar auf Mitarbeiter x eingrenzen, der Rest behält die volle bash. Müsste man sich aber im Detail angucken.

Das war dann ja auch mein nächster Gedanke. Skript zwischenschalten, Käse gegessen.

Hat mich nur interessiert ob es halt auch "out the box" geht.

edit:

Sehe grad dass du schon was in die Richtung gepostet hast - ich danke

/edit

Was ich eigentlich Denke: Wenn ein User verdächtigt wird das er unsauber arbeitet, dann kann man ihm nur den Zugang sperren. Man kann natürlich mit komplexen Workarounds allen das Leben schwerer machen; das dürfte aber nur dazu führen das noch mehr User versuchen das ganze zu umgehen. Ist mithin also eher Kontraproduktiv. Eine kurze Schulung des betroffenen Users warum die voreingestellten Werte gut und sinnvoll sind ist der bessere Weg.

Das sowieso. Nur versuche ich meist User so weit wie möglich zu leiten, das minimiert später anfallende Arbeit

(Sowas geht natürlich nur bis zu einem gewissen Punkt)

Nur kenne ich die Situation nicht. Daher das nur als Anmerkung.

Die Situation gibt es nicht, war rein fiktiv.

Der Guide geht, wenn er auch sehr komplex wird, um die Einrichtung eines root-/SB-/Home-Servers.