OpenSSH-Problem

DeeDee0815

DeeDee0815

Doppel-As
Hi,

ich habe ein Problem mit kdesvn unter Ubuntu 8.10: Ich möchte mit kdesvn auf ein svn+ssh-SVN-Repository zugreifen. Leider merkt sich weder OpenSSH noch kdesvn das Kennwort, daher taucht ununterbrochen ein OpenSSH-Kennwortdialog auf, was zur Unbenutzbarkeit führt. Das gleichzeitige "laufenlassen" von KWallet, was ja unter GNOME, was ich verwende, nicht standartmäßig läuft, bringt keine Besserung.

Vielen Dank für etwaige Lösungsvorschläge,
DeeDee0815
 
Kenn mich mit den appls jetzt nicht so aus, aber aus dem Bauch heraus:
hostbased keys oder pubkeys für passwortlosen ssh benutzen??
 
.... und wenn dann der Key selbst eine Passphrase hat (ein _MUSS_ IMHO), nutzt man ssh-agent mit ssh-add als "Sitzungsspeicher".
 
.... und wenn dann der Key selbst eine Passphrase hat (ein _MUSS_ IMHO), nutzt man ssh-agent mit ssh-add als "Sitzungsspeicher".

Guten Tag,

auf den Server habe ich keinen Einfluss, daher ist die Sache mit den SSH-Keys nicht denkbar, wobei ich da tatsächlich auch eine Passparse nutzen würde.

Das mit dem ssh-agent hört sich da in der Tat gut an. Aber leider komme ich damit nicht weiter: Wärest Du bereit, mir kurz zu schreiben, wie man da einen Host und ein Kennwort hinzufügt?

Danke schonmal euch beiden,
DeeDee0815
 
Google führt nicht zu Krebs und Wikipedia macht nicht impotent.

Außerdem

man ssh-agent
man ssh-add

Außerdem kannst du auch subversion in der Shell benutzen, was SEHR GUT funktioniert. Ein KDE-Programm unter Gnome zu nutzen, nur um extra Subversion zu benutzen ist nicht unbedingt ratsam. Auch hier hilft dir Wikipedia.
 
Zuletzt bearbeitet von einem Moderator:
Google führt nicht zu Krebs und Wikipedia macht nicht impotent.
[...]
Außerdem kannst du auch subversion in der Shell benutzen, was SEHR GUT funktioniert. Ein KDE-Programm unter Gnome zu nutzen, nur um extra Subversion zu benutzen ist nicht unbedingt ratsam. [...]

Ich weiß nicht, was solche Leute wie Du in einem Forum wollen. Sich an ihrer eigenen Arroganz ergötzen? Meinst Du ich stelle hier eine Frage, weil ich selbst weiterkomme? Meinst Du, ich stelle eine Frage zu kdesvn, weil ich ssh auf der Kommandozeile benutzen will? Ich danke Dir zwar für Deine Antwort, aber ein Verweis auf eine Websuche und Wikipedia bringt wirklich gar nichts, außer dass Du mich versuchst runterzumachen, das lasse ich mir nicht bieten.

Leider hat mir keine Websuche geholfen und auch die man-pages helfen mir nicht weiter. Ich weiß nicht, wie man im ssh-agent bitteschön Kennwörter speichern soll.

MfG DeeDee0815
 
Zuletzt bearbeitet:
Schau dir doch mal die Suchergebnisse an. Man kann in ssh-agent nur das Kennwort des SSh-Schlüssels speichern. Man muss für SSH mit Keyfile auch nix am Server ändern. Es hat einen Sinn, dass cinhtau eine spezielle Suche verlinkt hat.

NoXqs und Rain_Maker haben deine Lösung eigentlich schon gepostet, von da aus solltest du wieder weiterkommen.
 
Hi,

Man kann in ssh-agent nur das Kennwort des SSh-Schlüssels speichern.
und das ist sein Punkt, er hat nur Passwort Zugriff und hat keine administrativen Rechte auf dem Server.

Man muss für SSH mit Keyfile auch nix am Server ändern.
Nicht? Das verstehe ich nicht, wie willst du denn Zugriff per Keyfiles auf einem Server einrichten auf dem du die ssh config nicht veraendern kannst (ergo dort auch deinen Key nicht hinterlegen kannst)? IMHO ist die Aussage einfach falsch, aber ich lasse mich gern eines besseren belehren.

Persoenlich wuerde ich allerdings auch einfach einen anderen Client benutzen, ich mag aber auch kdesvn nicht besonders. ;)
Meinereiner nutzt meistens Subclipse und den svn Command Line Client (oder TortoiseSVN unter Windows).

Edit:
Ah, ich sehe jetzt erst dass du schriebst dass du kdesvn unter Gnome nutzt. Da muss ich dann cinhtau allerdings zustimmen, das macht eigentlich keinen Sinn, es gibt ja nun wirklich keinen Mangel an svn Clients.

mfg,
bytepool
 
Zuletzt bearbeitet:
Ich weiß nicht, was solche Leute wie Du in einem Forum wollen. Sich an ihrer eigenen Arroganz ergötzen?

ohne Worte, aber im Gegensatz zu dir informiere ich mich erst, bevor ich eine Frage stelle

Meinst Du ich stelle hier eine Frage, weil ich selbst weiterkomme?

Denke nicht. Sieht man ja.

Meinst Du, ich stelle eine Frage zu kdesvn, weil ich ssh auf der Kommandozeile benutzen will?

Nein. Du stellst die Frage weil du zu "faul" bist svn unter der Konsole zu benutzen und daher eine grafische Oberfläche vorziehst. Außerdem habe ich dir Alternativen aufgezeigt.

Ich danke Dir zwar für Deine Antwort, aber ein Verweis auf eine Websuche und Wikipedia bringt wirklich gar nichts, außer dass Du mich versuchst runterzumachen, das lasse ich mir nicht bieten.

Uuuhhhhh, das macht mir aber Angst.

Leider hat mir keine Websuche geholfen und auch die man-pages helfen mir nicht weiter. Ich weiß nicht, wie man im ssh-agent bitteschön Kennwörter speichern soll.

Wie wäre es mit Lesen? Wie wäre es mit Nachdenken? Hättest du dich ernsthaft mit dem Thema ssh und Authentifizierung mit ssh-keys beschäftigt, würdest du wissen, dass dein Ansatz falsch ist. Ohne Einflußnahme auf den Server, kannste die Geschichte vergessen.

Ich zitiere mal aus der man-page

ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA).

Was ist wohl an dem Satz missverständlich?

Und zu deinem Problem gibt es mehrere Ansätze. Aber die kannste dir selber finden. Um sachlich zu bleiben: Muss mich Leuten mit Konsumentenhaltung (schön alles mit dem goldenen Kochlöffel) - also wie dir - nicht abgeben. Um es eins klar zu stellen: Es ist ok im Forum bei Problemen Fragen zu stellen. Aber ich erwarte auch ein wenig Eigeninitiative von den Bittstellern.
 
Zuletzt bearbeitet von einem Moderator:
Nicht? Das verstehe ich nicht, wie willst du denn Zugriff per Keyfiles auf einem Server einrichten auf dem du die ssh config nicht veraendern kannst (ergo dort auch deinen Key nicht hinterlegen kannst)? IMHO ist die Aussage einfach falsch, aber ich lasse mich gern eines besseren belehren.

Weil das nicht in der Config angepasst wird. Die (Public-)Keys müssen im Homeverzeichnis in der ~/.ssh/authorized_keys hinterlegt werden und das wars. Da kann man in der Regel drauf zugreifen. Die ssh-Standard Konfiguration lässt dieses Verfahren zu.
 
Man muss für SSH mit Keyfile auch nix am Server ändern.

Da liegt bei euch beiden (bytepool und du) ein Missverständnis vor. Der Subversion-Server auf dem sshd läuft - da hat der TE keinen Einfluß darauf.

auf den Server habe ich keinen Einfluss, daher ist die Sache mit den SSH-Keys nicht denkbar,

Die conf vom sshd muss - wie du richtig festgestellt hast, nicht geändert werden, wenn die im Default ssh-keys akzeptieren.

Nur kann er auch nicht die ~/.ssh/authorized_keys vom Server bearbeiten, bzw. seinen Schlüssel hinzufügen. Das ist das was bytepool sagt. Übrigens stammt das Zitat Google .... Wikipedia ... vom evil Rainmaker.
 
Zuletzt bearbeitet von einem Moderator:
Übrigens stammt das Zitat Google .... Wikipedia ... vom evil Rainmaker.

WUS?

*Ähm* ..... *hüstel* ... verdammt ... stimmt sogar:

http://unixboard.de/vb3/showthread.php?t=35693

"Ich hatte eine harte Jugend, Euer Ehren ......"

(Aber der verlinkte Thread war ja wirklich ein Paradebeispiel chronischer Merkbefreiung, dann noch verbunden mit "ich hab zwar keine Ahnung und keinen Bock mein Hirn oder zumindest meine Finger mit der Benutzung einer Suchmaschine anzustrengen, aber dafür habe ich immerhin einen eigenen vServer, ist das nicht toll?", da muss man auch mal ordentlich zulangen, sonst merken manche die Einschläge um sie herum nicht.)

//Nachtrag für die Nachwelt:

Ich habe das gerade mal spaßeshalber mit einem grml (bootoption ssh=<Passwort>) in einer VM getestet.

- Einloggen mit ssh grml@IP -p <Port> fragt nach dem Passwort, so weit, so gut.

- mit scp der Einfachheit halber meinen gesamten ~/.ssh/ vom Host (OS 11.1) in den Gast nach /home/grml/ kopiert.

Erneuter Versuch mit ssh grml@IP -p <port> fragt nach der Passphrase für den Key (da dachte ich, "Strike, dann ist das ja kein Problem"), anschließend wurde ich aber trotz korrekter Authentifizierung per key noch nach dem Passwort für den User grml gefragt.

Sofern der sshd von grml nicht von der default-konfiguration abweicht (nein, genauer nachgesehen habe ich da jetzt nicht, so groß war die Neugierde dann doch nicht) muss man also an anderer Stelle noch nacharbeiten, wenn dies nur in der globalen Konfigurationsdatei möglich ist, dann eben Pech gehabt.
 
Zuletzt bearbeitet von einem Moderator:
Da liegt bei euch beiden (bytepool und du) ein Missverständnis vor. Der Subversion-Server auf dem sshd läuft - da hat der TE keinen Einfluß darauf.

Wenn er svn+ssh nutzt, kann er sich zumindest einloggen. Das er den Server nicht anders konfigurieren kann ist klar, dass er kein Keyfile hochladen kann hat er nicht gesagt und sicher auch nicht probiert.
 
Hast völlig recht - das hat man davon, wenn man sich auf die Angaben der Leute verlässt bzw. ich so blauäugig war. Habe im schwachen Moment, selbst nicht nachgedacht. Das zeigt mir, dass er die Authentifzierung mit ssh-keys nicht verstanden hat. Ist mir gestern abend auch eingefallen, aber ist ja nicht mein Problem und du warst schneller.
 
Zuletzt bearbeitet von einem Moderator:
@RM: N bissl naiver Test, oder? Hattest Du in Deiner authorized_keys überhaupt den PublicKey (von der gleichen Maschiene ?) drin stehen? Rechte richtig?

Wenn das alles korrekt war, dann weicht die grml-Config offensichtlich doch ab ...
 
Hattest Du in Deiner authorized_keys überhaupt den PublicKey (von der gleichen Maschiene ?) drin stehen?

Latürnich, ich wurde ja auch ohne Fehlermeldung autorisiert, nur danach wollte er zusätzlich auch das Passwort des Users "grml" wissen.

Ich muss dazu sagen, daß in meinem ~/.ssh sowohl der pubkey als auch die authorized_keys für meinen Schlüssel liegen, weil bei mir auch ein SSHD läuft von dem ich ab und zu mal remote verbinde, also war da alles vorhanden, was benötigt wird.

Das selbe Spielchen habe ich schon einige Male gemacht, z.B. um auf meine im "Headless"-Modus laufenden VMs zu kommen (und auch für den Rückweg von der Maschine auf den Host).

Das hat auch immer funktioniert nur habe ich da nie das selbe getestet, sondern den SSHD eh immer zunächst auf "key-only" umgestellt.


Lego, aber auch das hätte man ja gemeldet bekommen.
 
Zurück
Oben