Hallo!
Um beim Einloggen mit SSH kein Passwort anzugeben, sehe ich zwei Möglichkeiten:
- hostbased authentication - ssh-agent
Die erste Methode hat den Nachteil, dass der ssh client setuid root sein muss. Ein Bug im ssh Programm könnte also ein Sicherheitsproblem werden.
Die zweite Methode (ssh-agent) gefällt mir bis jetzt nicht, da jedes Programm auf meinen private key Zugreifen kann.
Sieht jemand noch andere Vor- und Nachteile?
Gruß,
Thomas
On Tue, 25 Mar 2003 08:09:23 +0100, Thomas Guettler wrote:
Die zweite Methode (ssh-agent) gefällt mir bis jetzt nicht, da jedes Programm auf meinen private key Zugreifen kann.
man ssh-agent:
The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, pri vate keys are not exposed to clients using the agent.
Reinhard
On Tue, Mar 25, 2003 at 08:23:09AM +0100, Reinhard Foerster wrote:
On Tue, 25 Mar 2003 08:09:23 +0100, Thomas Guettler wrote:
Die zweite Methode (ssh-agent) gefällt mir bis jetzt nicht, da jedes Programm auf meinen private key Zugreifen kann.
man ssh-agent:
The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, pri vate keys are not exposed to clients using the agent.
man ssh-agent:
A unix-domain socket is created and the name of this socket is stored in the SSH_AUTH_SOCK environment variable. The socket is made accessible only to the current user. *This method is easily abused by root or another instance of the same user.*
Alle Programme, die unter meiner UID laufen können auf den Private Key zugreifen.
Gruß,
Thomas
On Tue, 25 Mar 2003 08:34:22 +0100, Thomas Guettler wrote:
man ssh-agent:
The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, pri vate keys are not exposed to clients using the agent.
man ssh-agent:
A unix-domain socket is created and the name of this socket is stored in the SSH_AUTH_SOCK environment variable. The socket is made accessible only to the current user. *This method is easily abused by root or another instance of the same user.*Alle Programme, die unter meiner UID laufen können auf den Private Key zugreifen.
Es ist ein Unterschied, ob über den Socket der key direkt herausgegeben wird (wird er nicht), oder ob man lediglich über den Socket Authentisierungsanfragen an den ssh-agent weiterleiten kann. Beim ersten Fall wäre im Angriffsfall der key sofort weg und eine neuer müßte erzeugt werden. Beim 2. Fall kann nach Beheben des Lochs der alte Key weiterverwendet werden. Wer aber auf deinen ssh-sicket zugreifen kann, kann auch beim ssh-add schon dein Passwort abfangen. Insofern ist es ziemlich sinnfrei, den ssh-agent genauer zu untersuchen. Er macht nichts sicherer oder unsicherer sondern lediglich deine Arbeit bequemer.
Generell: Wenn du deinen eigenen Prozessen nicht vertraust, kannst du von diesem Rechner aus NIEMALS sicher auf einen anderen Rechner zugreifen. Das ist schon theoretisch unmöglich und somit in der Praxis erst recht. Dem Stück Hard- und Software, dem du dein Passswort anVERTRAUST mußt du also zwangsweise vertrauen oder du läßt es ganz.
Reinhard
On Tue, Mar 25, 2003 at 12:09:51PM +0100, Reinhard Foerster wrote:
On Tue, 25 Mar 2003 08:34:22 +0100, Thomas Guettler wrote:
man ssh-agent:
The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, pri vate keys are not exposed to clients using the agent.
man ssh-agent:
A unix-domain socket is created and the name of this socket is stored in the SSH_AUTH_SOCK environment variable. The socket is made accessible only to the current user. *This method is easily abused by root or another instance of the same user.*Alle Programme, die unter meiner UID laufen können auf den Private Key zugreifen.
Es ist ein Unterschied, ob über den Socket der key direkt herausgegeben wird (wird er nicht), oder ob man lediglich über den Socket Authentisierungsanfragen an den ssh-agent weiterleiten kann.
OK, jetzt habe ich es kapiert. Den entsprechenden Eintrag in "man ssh-agent" habe ich heute morgen überlesen:
The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, pri vate keys are not exposed to clients using the agent.
Generell: Wenn du deinen eigenen Prozessen nicht vertraust, kannst du von diesem Rechner aus NIEMALS sicher auf einen anderen Rechner zugreifen.
Ich traue niemanden. Ich dachte bisher jeder meiner Prozesse kann den Private Key per ssh-agent einsehen. Dem würde ich nicht vertrauen. So muss ich legendlich dem ssh-agent vertrauen. Das ist OK.
Gruß,
Thomas
Am 25. März 2003 schrieb Thomas Guettler:
Ich traue niemanden.
Das geht gar nicht.
Ich dachte bisher jeder meiner Prozesse kann den Private Key per ssh-agent einsehen.
Ja, jeder deiner Prozesse kann bei Bedarf deinen privaten ssh-key einsehen und du kannst es wahrscheinlich nicht verhindern und es hat nichts mit ssh-agent zu tun. Nochmal: Du darfst nur Binaries ausführen, denen du vertraust.
Torsten
On Tue, Mar 25, 2003 at 07:36:08PM +0100, Torsten Werner wrote:
Am 25. März 2003 schrieb Thomas Guettler:
Ich traue niemanden.
Das geht gar nicht.
Ich dachte bisher jeder meiner Prozesse kann den Private Key per ssh-agent einsehen.
Ja, jeder deiner Prozesse kann bei Bedarf deinen privaten ssh-key einsehen und du kannst es wahrscheinlich nicht verhindern und es hat nichts mit ssh-agent zu tun.
Das stimmt nicht. Der Private Key ist mit einer Passphrase verschlüsselt. Also kann dort keiner meiner Prozesse "reinschauen".
man ssh-agent:
""" The agent will never send a private key over its request channel. In- stead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, private keys are not exposed to clients using the agent. """
"request channel" ist für mich der Unix-Socket in SSH_AUTH_SOCK.
Operationen die einen privaten Schlüssel benötigen, werden vom ausgeführt --> Der Agent gibt den Schlüssel nicht her.
Gruß, Thomas
Am Mittwoch, dem 26. März 2003 um 08:13:02, schrieb Thomas Guettler:
Der Private Key ist mit einer Passphrase verschlüsselt.
Das ist an dieser Stelle witzlos. Jeder deiner Prozesse kann einfach alle anderen debuggen und ein Breakpoint auf das Ende der richtigen OpenSSL-Funktion setzen. Dann kann man direkt den dechiffrierten Schlüssel aus dem Speicher lesen. Und das kann außer dir genausogut root und dank vieler buggy Terminalemulatoren wahrscheinlich auch jeder andere pfiffige Benutzer, zu dem du in der Vergangenheit mal versehentlich ein 'su andereruser' gemacht hast.
Ergo, 'su andereruser' sollte beispielsweise nicht zu den vertrauenswürdigen Kommandos gehören. Das ist wesentlicher, als deine ursprüngliche Frage nach dem ssh-agent.
Ein anderer Weg wäre übrigens, die Passphrase mit einem Keyboardsniffer zu erschnüffeln und dann den Key einfach damit zu entschlüsseln.
Torsten
On Wed, 26 Mar 2003 08:13:02 +0100, Thomas Guettler wrote:
On Tue, Mar 25, 2003 at 07:36:08PM +0100, Torsten Werner wrote:
Ich traue niemanden.
Das geht gar nicht.
Eben.
Ich dachte bisher jeder meiner Prozesse kann den Private Key per ssh-agent einsehen.
Ja, jeder deiner Prozesse kann bei Bedarf deinen privaten ssh-key einsehen und du kannst es wahrscheinlich nicht verhindern und es hat nichts mit ssh-agent zu tun.
Das stimmt nicht. Der Private Key ist mit einer Passphrase verschlüsselt. Also kann dort keiner meiner Prozesse "reinschauen".
Doch. Torsten hat völlig recht. Jedes Programm, was du unter deiner UID startest, kann alles tun, was du auch selbst tun könntest. Wenn du dich lokal an einem Rechner anmeldest und per ssh sicher zu einem anderen Rechner willst, MUSST du massenhaft Software trauen. Jedes Stück beteiligte Software muß vertrauenswürdig sein, also eine sichere Kette von dir bis zum Zielrechner bilden. Da wären also mindestens: Kernel, login, bash (+alles, was die startskipte starten), ssh-add, ssh (und deren hostkeys), sshd + Kernel + shell auf Gegnerseite usw.
Ist auch nur ein ein einziger Teil in dieser Kette kompromittiert, ist die Sicherheit verloren.
ssh kann nur eins: Eine sichere (nicht abhörbare, nicht heimlich auf einen anderen Rechner umgelenkte) Verbindung zwischen zwei vertrauenswürdigen Systemen herstellen. Der Versuch, durch den Einsatz von ssh unter Beteiligung eines nicht vertrauenswürdigen Rechners irgendetwas sicherer zu machen, wird in jedem Fall scheitern.
Das in den Klammern sind übrigens die einzigen sicherheitsrelevanten Vorteile der ssh gegenüber telnet.
The agent will never send a private key over its request channel. In- stead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. This way, private keys are not exposed to clients using the agent. """
"request channel" ist für mich der Unix-Socket in SSH_AUTH_SOCK.
Ja.
Operationen die einen privaten Schlüssel benötigen, werden vom ausgeführt --> Der Agent gibt den Schlüssel nicht her.
Richtig. Nur fängst du mit deiner Sicherheitsüberlegung immer erst an dem Punkt an, wo der ssh-agent bereits läuft und den per passphrase freigeschalteten Key bereits hat. Bis du aber überhaupt zu diesem Punkt gekommen bist, kann es schon lange zu spät sein.
Reinhard
Hallo Thomas,
Am 25. März 2003 schrieb Thomas Guettler:
Die erste Methode hat den Nachteil, dass der ssh client setuid root sein muss. Ein Bug im ssh Programm könnte also ein Sicherheitsproblem werden.
Hmm.
Die zweite Methode (ssh-agent) gefällt mir bis jetzt nicht, da jedes Programm auf meinen private key Zugreifen kann.
Das kann jedes Programm, dass mit deiner uid läuft, sowieso (Tastatursniffer, ptrace). Du solltest keine Programme ausführen, denen du nicht vertraust.
Torsten
lug-dd@mailman.schlittermann.de
-
Reinhard Foerster -
Thomas Guettler -
Torsten Werner