Sorry eigentlich sollte das ein neuer Thread werden, hatte wohl nicht geklappt. Hier nochmal das neue Thema:
- Login auf fernen PC per SSH nicht ohne Passwort möglich
ich habe folgendes kleines Problem: Und zwar wünsche ich mir Dateien mittels rsync zwischen meinem Desktop-PC und meinem Laptop zu synchronisieren. Insgesamt sind mehrere Ordner zu synchronisieren was meines erachtens mit rsync nicht möglich ist. Also muss ich rsync oft hintereinander aufrufen um eine vollständige Synchronisation zu erreichen. Das an sich ist nicht so nervig obwohl ich es auch gerne ändern will - wenn jemand ne Idee hat: bitte melden - Das nervige ist das er mich jedesmal nach dem Passwort fragt, dass ich jedesmal (ca. 6 mal) eingeben muss.
Nun gibt es ja die Möglichkeit rsync -e ssh aufzurufen um eine Verbindung per SSH zu ermöglichen.
Ich wollte ssh so konfigurieren, dass es mich nicht mehr nach dem Passwort fragt, also eine Authorisierung per DSA-Schlüsselpaar ermöglicht und dieses dem ssh-agent übergeben. Habe nun die Anleitung unter http://www.schlittermann.de/doc/ssh durchgeführt und auch noch andere Anleitungen und die manpages von ssh usw. gelesen. Das starten einer ssh Sitzung von meinem Desktop auf den Laptop funktioniert trotzdem nicht ohne Passwort.
Was kann da schief gelaufen sein?
Am Dienstag, 10. Oktober 2006 16:24 schrieb Josef Spillner:
Dazu hast du sicherlich lokal einen SSH-Schlüssel angelegt (id_dsa und id_dsa.pub) und dann id_dsa.pub als Nutzer login@server an ~/.ssh/authorized_keys2 angehangen.
Genau das hab ich gemacht nur, dass ssh offensichtlich nicht das Schlüsselpaar verwendet sondern immer noch nach dem Passwort fragt. Obwohl ich in der /etc/ssh/sshd_config eingetragen habe: AllowPasswordAuthentication no UsePAM no # Mit Passwort meine ich nicht die Abfrage nach der Passphrase für den Zugang zum privaten DSA-SChlüssel.
Wenn jemand ne Idee hat, wie man die Synchronisation mehrerer Ordner auch anders lösen kann -> Ich bin für jeden Vorschlag dankbar.
Viele Grüße
Emanuel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Emanuel,
Wenn jemand ne Idee hat, wie man die Synchronisation mehrerer Ordner auch anders lösen kann -> Ich bin für jeden Vorschlag dankbar.
Dein SSH-Problem kann ich nicht lösen, hab aber 2 Vorschläge:
1. Wenn du ein Passwort mehrmals nutzen willst, kannst du die Abfrage doch per Script machen, welches dieses dann an die Befehle weiterreicht. Das Problem hatte ich mit meinen verschlüsselten Platten auch.
Ein Script a'la #!/bin/sh echo "Bitte Passwort eingeben:" stty -echo read pw stty echo rsync 1 -pwd $pw rsync 2 -pwd $pw
sollte helfen. (Hab jetzt die rsync- oder ssh-Syntax nicht im Kopf, aber die kann man ja leicht im Manual nachschlagen.
2. Schau dir mal unison an: http://www.cis.upenn.edu/~bcpierce/unison/
Damit synchronisiere ich seit ca. einem Jahr meinen (Windows-Laptop) und mein Debian-System und bin sehr zufrieden. Bin mir jetzt nicht sicher, ob er in einer Konfig-Datei mehrere unterschiedliche Verzeichnisse zulässt, aber wenn nicht, kannst du dir ja ein Verzeichnis anlegen und alle gewünschten Syncronisations-Verzeichnisse als Symlinks drunter anlegen...
Viele Grüße
Martin
Am Dienstag, 10. Oktober 2006 20:43 schrieb Martin Körner:
- Wenn du ein Passwort mehrmals nutzen willst, kannst du die Abfrage
doch per Script machen, welches dieses dann an die Befehle weiterreicht. Das Problem hatte ich mit meinen verschlüsselten Platten auch.
rsync bietet soweit ich in den manpages gesehen habe nur diese Option um das Passwort einzulesen: --password-file=FILE read password from FILE Das würde ja bedeuten ich muss mein Passwort im Klartext in einer Datei abspeichern, die rsync dann auslesen kann. Ich bin zwar newbie, aber das scheint mir doch ein bisschen sehr riskant zu sein oder?
Ein Script a'la #!/bin/sh echo "Bitte Passwort eingeben:" stty -echo read pw stty echo rsync 1 -pwd $pw rsync 2 -pwd $pw
Eine solche syntax wäre natürlich die Lösung: Das Passwort wird nur einmal eingegeben und nicht gespeichert. Aber leider bietet - denke ich - rsync diese Möglichkeit nicht siehe oben.
- Schau dir mal unison an: http://www.cis.upenn.edu/~bcpierce/unison/
Unison bricht bei mir mit dem Fehler ab:
~$ unison Contacting server... ssh: connect to host 172.127.0.2 port 22: No route to host Fatal error: Lost connection with the server
kannst du dir ja ein Verzeichnis anlegen und alle gewünschten Syncronisations-Verzeichnisse als Symlinks drunter anlegen...
Geht das auch mit rsync? Wenn ja verfolgt er die Symlinks auch auf dem Zielrechner in das Verzeichnis auf das sie Verweisen. Oder kopiert es mir dann nur die Symlinks. Anm.: Hab das mit den harten und weichen Links noch nicht so wirklich verstanden. Was geschieht denn genau wenn ich einen Symlink kopiere??
Danke für die Hilfe
Emanuel
Emanuel Goscinski news-for-emu@web.de (Di 10 Okt 2006 21:46:36 CEST):
Am Dienstag, 10. Oktober 2006 20:43 schrieb Martin Körner:
~$ unison Contacting server... ssh: connect to host 172.127.0.2 port 22: No route to host Fatal error: Lost connection with the server
Du bist Dir aber sicher, daß Du RSYNC über SSH machen willst, wenn es nicht mal eine SSH-Verbindung zum entfernten Host gibt?
kannst du dir ja ein Verzeichnis anlegen und alle gewünschten Syncronisations-Verzeichnisse als Symlinks drunter anlegen...
Geht das auch mit rsync? Wenn ja verfolgt er die Symlinks auch auf dem Zielrechner in das Verzeichnis auf das sie Verweisen. Oder kopiert es mir dann nur die Symlinks.
RSYNC hat etliche Optionen bezüglich der Behandlung von Symlinks, je nach dem, ob sie nach außerhalb des zu syncenden Baumes zeigen, oder ob nicht und so weiter...
Best regards from Dresden Viele Grüße aus Dresden Heiko Schlittermann
On 10.10.06 Emanuel Goscinski (news-for-emu@web.de) wrote:
Am Dienstag, 10. Oktober 2006 20:43 schrieb Martin Körner:
Moin,
- Schau dir mal unison an:
Unison bricht bei mir mit dem Fehler ab:
~$ unison Contacting server... ssh: connect to host 172.127.0.2 port 22: No route to host Fatal error: Lost connection with the server
Ich würde sagen Fehler auf Layer 3. Stell erstmal sicher, daß Deine Büchse weiß, wie Sie zum remote Host kommt, dann reden wir über den Rest.
H.
Martin Körner s0100685@mail.inf.tu-dresden.de (Di 10 Okt 2006 20:43:22 CEST):
- Wenn du ein Passwort mehrmals nutzen willst, kannst du die Abfrage
doch per Script machen, welches dieses dann an die Befehle weiterreicht. Das Problem hatte ich mit meinen verschlüsselten Platten auch.
Ein Script a'la #!/bin/sh
...
RSYNC kann das Passwort aus einer Datei lesen, aber nur, wenn es auf der anderen Seite einen RSYNCD gibt, wenn SSH als Transport-Medium eingesetzt wird, kann auch RSYNC nicht helfen. Dann ist es ja Aufgabe der SSH, nach dem Passwort zu fragen (oder auch nicht, wenn Du das hinbekommst).
Best regards from Dresden Viele Grüße aus Dresden Heiko Schlittermann
Emanuel Goscinski news-for-emu@web.de (Di 10 Okt 2006 20:07:13 CEST):
Ich wollte ssh so konfigurieren, dass es mich nicht mehr nach dem Passwort fragt, also eine Authorisierung per DSA-Schlüsselpaar ermöglicht und dieses dem ssh-agent übergeben. Habe nun die Anleitung unter http://www.schlittermann.de/doc/ssh durchgeführt und auch noch andere Anleitungen und die manpages von ssh usw. gelesen. Das starten einer ssh Sitzung von meinem Desktop auf den Laptop funktioniert trotzdem nicht ohne Passwort.
Bist Du sicher, daß er nach dem Passwort für nutzer@remote-host fragt, oder nach Deiner Passphrase (die, mit der Du Deinen privaten Schlüssel gesichert hast)?
Was kann da schief gelaufen sein? Am Dienstag, 10. Oktober 2006 16:24 schrieb Josef Spillner:
Dazu hast du sicherlich lokal einen SSH-Schlüssel angelegt (id_dsa und id_dsa.pub) und dann id_dsa.pub als Nutzer login@server an ~/.ssh/authorized_keys2 angehangen.
Genau das hab ich gemacht nur, dass ssh offensichtlich nicht das Schlüsselpaar verwendet sondern immer noch nach dem Passwort fragt. Obwohl ich in der /etc/ssh/sshd_config eingetragen habe: AllowPasswordAuthentication no UsePAM no # Mit Passwort meine ich nicht die Abfrage nach der Passphrase für den Zugang zum privaten DSA-SChlüssel.
Ach so ... (Hier in dieser Liste ist es überlich, *hinten* anzuhängen, nicht vorne...., dann hätte ich Deine Antwort auf das vom Josef eher gelesen.)
Bist Du sicher, daß Deine authorized_keys2 auch gelesen wird? Einige ssh-Server gucken nur nach der auhorized_keys (guck' die mal die atime der ~/.ssh/authorized_keys* nach dem vergeblichen Versuch an).
Du hast den public Key in das ~/.ssh/authorized* des Nutzers gelegt, der Du auch auf der Gegenseite werden willst?
Also bei ssh nutzt Du dann hans@remote-host und hast also in ~hans/.ssh/auth.... den Schlüssel?
Deine Schlüssel sind lokal 0600 und das .ssh ist auch 0700? Und alles gehört Dir?
Was sagt ssh -v hans@remote-host?
Best regards from Dresden Viele Grüße aus Dresden Heiko Schlittermann
Am Mittwoch, 11. Oktober 2006 00:51 schrieb Heiko Schlittermann:
Bist Du sicher, daß Deine authorized_keys2 auch gelesen wird? Einige ssh-Server gucken nur nach der auhorized_keys (guck' die mal die atime
Was ist die "atime" und wie betrachte ich sie?
der ~/.ssh/authorized_keys* nach dem vergeblichen Versuch an).
Nun ja wenn ich die Schlüssel mit ssh-copy-id -i an mein Notebook schicke wird die Datei authorized_keys erstellt und der Schlüssel angehängt. Ich vermute mal, dass das korrekt gemacht wird.
Du hast den public Key in das ~/.ssh/authorized* des Nutzers gelegt, der Du auch auf der Gegenseite werden willst?
Ja es gibt nur einen Nutzer auf beiden Computern (ich nutze Kubuntu also gibt es auch keinen root)
Also bei ssh nutzt Du dann hans@remote-host und hast also in ~hans/.ssh/auth.... den Schlüssel?
Ja
Deine Schlüssel sind lokal 0600 und das .ssh ist auch 0700? Und alles gehört Dir?
Ich weiß nicht wie ich das überprüfen kann, habe aber: chmod 700 /home/emu/.ssh chmod 600 /home/emu/.ssh/* ausgeführt. Die Rechte müssten also korrekt sein.
Was sagt ssh -v hans@remote-host?
Folgendes: emu@emu-desktop:~$ ssh -v emu@emus-notebook OpenSSH_4.2p1 Debian-7ubuntu3.1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to emus-notebook [172.127.0.2] port 22. debug1: Connection established. debug1: identity file /home/emu/.ssh/identity type -1 debug1: identity file /home/emu/.ssh/id_rsa type -1 debug1: identity file /home/emu/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.2p1 Debian-7ubuntu3.1 debug1: match: OpenSSH_4.2p1 Debian-7ubuntu3.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'emus-notebook' is known and matches the RSA host key. debug1: Found key in /home/emu/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/emu/.ssh/identity debug1: Trying private key: /home/emu/.ssh/id_rsa debug1: Trying private key: /home/emu/.ssh/id_dsa debug1: Next authentication method: password emu@emus-notebook's password: ## ##Wie du siehst fragt er hier nach dem Password. Was dann schließlich ##funktioniert. ## debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 Linux emus-notebook 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux
The programs included with the Ubuntu system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Oct 11 10:42:07 2006 from emu-desktop emu@emus-notebook:~$ exit logout debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 Connection to emus-notebook closed. debug1: Transferred: stdin 0, stdout 0, stderr 37 bytes in 13.8 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.7 debug1: Exit status 0 emu@emu-desktop:~$
On 11.10.06 Emanuel Goscinski (news-for-emu@web.de) wrote:
Am Mittwoch, 11. Oktober 2006 00:51 schrieb Heiko Schlittermann:
Moin,
Bist Du sicher, daß Deine authorized_keys2 auch gelesen wird? Einige ssh-Server gucken nur nach der auhorized_keys (guck' die mal die atime
Was ist die "atime"
Die access time: wann wurde auf das File das letzte Mal lesend zugegriffen?
und wie betrachte ich sie?
ls -lau
der ~/.ssh/authorized_keys* nach dem vergeblichen Versuch an).
Nun ja wenn ich die Schlüssel mit ssh-copy-id -i an mein Notebook schicke wird die Datei authorized_keys erstellt und der Schlüssel angehängt. Ich vermute mal, dass das korrekt gemacht wird.
ssh-copy-id kannte ich noch nicht. Danke Heiko.
Deine Schlüssel sind lokal 0600 und das .ssh ist auch 0700? Und alles gehört Dir?
Ich weiß nicht wie ich das überprüfen kann, habe aber: chmod 700 /home/emu/.ssh chmod 600 /home/emu/.ssh/* ausgeführt. Die Rechte müssten also korrekt sein.
Auf dem Remote Host?
Was sagt ssh -v hans@remote-host?
Folgendes: emu@emu-desktop:~$ ssh -v emu@emus-notebook OpenSSH_4.2p1 Debian-7ubuntu3.1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to emus-notebook [172.127.0.2] port 22. debug1: Connection established. debug1: identity file /home/emu/.ssh/identity type -1 debug1: identity file /home/emu/.ssh/id_rsa type -1 debug1: identity file /home/emu/.ssh/id_dsa type -1
<snip>
debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey
^^^^^^^^^
debug1: Trying private key: /home/emu/.ssh/identity debug1: Trying private key: /home/emu/.ssh/id_rsa debug1: Trying private key: /home/emu/.ssh/id_dsa debug1: Next authentication method: password emu@emus-notebook's password:
Vom Ansatz gut. Wird denn der richtige pub-key nach Remote kopiert, also der der zu einem der Priv-Keys in einem der 3 Files gehört?
H.
Am Mittwoch, 11. Oktober 2006 11:56 schrieb Hilmar Preusse:
On 11.10.06 Emanuel Goscinski (news-for-emu@web.de) wrote:
Am Mittwoch, 11. Oktober 2006 00:51 schrieb Heiko Schlittermann:
Moin,
Bist Du sicher, daß Deine authorized_keys2 auch gelesen wird? Einige ssh-Server gucken nur nach der auhorized_keys (guck' die mal die atime
Die Accestime der authorized_keys stimmt nicht mit dem letzten ssh-Verbindungsversuch überein. Folglich: Die authorized-keys wird nicht eingelesen. Obwohl in der /etc/ssh/sshd_config zu lesen ist:
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys
Deine Schlüssel sind lokal 0600 und das .ssh ist auch 0700? Und alles gehört Dir?
Ich weiß nicht wie ich das überprüfen kann, habe aber: chmod 700 /home/emu/.ssh chmod 600 /home/emu/.ssh/* ausgeführt. Die Rechte müssten also korrekt sein.
Auf dem Remote Host?
Ja
Was sagt ssh -v hans@remote-host?
Folgendes:
<snip>
debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey
^^^^^^^^^debug1: Trying private key: /home/emu/.ssh/identity debug1: Trying private key: /home/emu/.ssh/id_rsa debug1: Trying private key: /home/emu/.ssh/id_dsa debug1: Next authentication method: password emu@emus-notebook's password:
Vom Ansatz gut. Wird denn der richtige pub-key nach Remote kopiert, also der der zu einem der Priv-Keys in einem der 3 Files gehört?
Ja devinitiv, ich habe die id_dsa.pub nochmal mit der Zeile in der authorized-keys verglichen. Sie stimmen überein.
H.
Danke für die Hilfe und viele Grüße
Emanuel
Hi Emanuel,
On Wed, Oct 11, 2006 at 14:20:34 +0200, Emanuel Goscinski wrote:
Die authorized-keys wird nicht eingelesen. Obwohl in der /etc/ssh/sshd_config zu lesen ist:
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys
Okay, das ist die Serverseite. Deine vorigen Debug-Meldungen via "ssh -v" bezogen sich aber auf die Clientseite. Dort muss der ssh-Client eine der Dateien ~/.ssh/id_rsa oder ~/.ssh/id_dsa einlesen. Wie sieht die /etc/ssh_config bzw. ~/.ssh/config auf Clientseite aus, insbesondere der Eintrag "IdentityFile"?
Gruss, Chris
Am Mittwoch, 11. Oktober 2006 15:18 schrieb Christian Perle:
Hi Emanuel,
On Wed, Oct 11, 2006 at 14:20:34 +0200, Emanuel Goscinski wrote:
Die authorized-keys wird nicht eingelesen. Obwohl in der /etc/ssh/sshd_config zu lesen ist:
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys
Okay, das ist die Serverseite. Deine vorigen Debug-Meldungen via "ssh -v" bezogen sich aber auf die Clientseite. Dort muss der ssh-Client eine der Dateien ~/.ssh/id_rsa oder ~/.ssh/id_dsa einlesen.
Sehe ich das richtig, dass die Datei /etc/ssh/sshd_config für den ssh-Server zuständig ist, und die Datei /etc/ssh/ssh_config (~/.ssh/config existiert bei mir nicht) für den Client?? Wenn ja auf welcher Seite läuft der Server und auf welcher der Client? Ist folgende Tabelle dann korrekt? Das ist etwas verwirrend für mich, da die Computer nebeneiander stehen und schließlich von beiden Seiten auf den jeweils anderen Computer zugegriffen werden soll.
Desktop --------------------> Notebook PC-an dem ich Sitze --------------------> entfernter Computer Zugriff per ssh-Server ----------------------> auf ssh-Client
Wie sieht die /etc/ssh_config bzw. ~/.ssh/config auf Clientseite aus, insbesondere der Eintrag "IdentityFile"?
Bis auf die # Ciphers - Zeile sind die Dateien auf dem Notebook und auf dem Desktop identisch.
Desktop ssh_config: Host * # ForwardAgent no # ForwardX11 no # ForwardX11Trusted yes # RhostsRSAAuthentication no # RSAAuthentication yes # PasswordAuthentication yes # HostbasedAuthentication no # BatchMode no # CheckHostIP yes # AddressFamily any # ConnectTimeout 0 # StrictHostKeyChecking ask # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa # Port 22 # Protocol 2,1 # Cipher 3des # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc # EscapeChar ~ SendEnv LANG LC_* HashKnownHosts yes
Gruss, Chris
Gruß
Emanuel
Hallo Emanuel,
On Wed, Oct 11, 2006 at 15:57:52 +0200, Emanuel Goscinski wrote:
Sehe ich das richtig, dass die Datei /etc/ssh/sshd_config fuer den ssh-Server zustaendig ist, und die Datei /etc/ssh/ssh_config (~/.ssh/config existiert bei mir nicht) fur den Client??
Ja, wobei natuerlich die /etc/ssh/sshd_config auf der Serverseite (Rechner, auf den Du Dich remote einloggen willst) und die /etc/ssh/ssh_config auf der Clientseite (Rechner, von dem aus Du Dich woanders einloggst).
Desktop --------------------> Notebook PC-an dem ich Sitze --------------------> entfernter Computer Zugriff per ssh-Server ----------------------> auf ssh-Client
Nein, Client (PC) -------------> Server (Notebook). Bei Secure Shell ist ssh der Client und sshd der Server.
Gruss, Chris
On 11.10.06 Emanuel Goscinski (news-for-emu@web.de) wrote:
Am Mittwoch, 11. Oktober 2006 15:18 schrieb Christian Perle:
Moin,
Okay, das ist die Serverseite. Deine vorigen Debug-Meldungen via "ssh -v" bezogen sich aber auf die Clientseite. Dort muss der ssh-Client eine der Dateien ~/.ssh/id_rsa oder ~/.ssh/id_dsa einlesen.
Sehe ich das richtig, dass die Datei /etc/ssh/sshd_config für den ssh-Server zuständig ist, und die Datei /etc/ssh/ssh_config (~/.ssh/config existiert bei mir nicht) für den Client??
Sollte.
Wenn ja auf welcher Seite läuft der Server und auf welcher der Client?
Client ist immer der Rechner, der die Verbindung eröffnet. Also "von" dem Du irgendwohin willst. Server ist die Kiste, die die Verbindung annehmen soll. Ich glaube Du brauchst etwas solides Grundlagenwissen....
H.
Am Mittwoch, 11. Oktober 2006 17:12 schrieb Hilmar Preusse:
Ich glaube Du brauchst etwas solides Grundlagenwissen....
Ich bin gerade dabei es mir anzueignen.
Also die Verbindung funktioniert jetzt teilweise. Vom Notebook kann ich auf den Desktop ohne Eingabe des Passwortes zugreifen. Leider funktioniert das nicht umgekehrt obwohl client und server auf beiden Seiten jeweils identisch konfiguriert sind - zumindest was sshd_config und ssh_config angeht. In der ssh_config war der Eintrag IdentityFile auskommentiert.
Naja wieso es jetzt auf der einen Seite nicht funktioniert kann ich nicht mehr lokalisieren.
Auf jeden Fall schonmal vielen Dank für die Hilfe
Gruß
Emanuel
On 11.10.06 Emanuel Goscinski (news-for-emu@web.de) wrote:
Moin,
Naja wieso es jetzt auf der einen Seite nicht funktioniert kann ich nicht mehr lokalisieren.
Du mußt für die Rückverbindung auch wieder einen private/public Key generieren. Hast Du das getan?
H.
Am Donnerstag, 12. Oktober 2006 11:37 schrieb Hilmar Preusse:
Du mußt für die Rückverbindung auch wieder einen private/public Key generieren. Hast Du das getan?
Ja. Wie gesagt, die Systeme sind identisch konfiguriert (natürlich mit unterschiedlichen Schlüsseln aber die Konfiguration ist identisch).
Gruß Emanuel
Hilmar Preusse hille42@web.de (Do 12 Okt 2006 11:37:50 CEST):
On 11.10.06 Emanuel Goscinski (news-for-emu@web.de) wrote:
Moin,
Naja wieso es jetzt auf der einen Seite nicht funktioniert kann ich nicht mehr lokalisieren.
Du mußt für die Rückverbindung auch wieder einen private/public Key generieren. Hast Du das getan?
Wieso neue private/public Keys. Was ist falsch, immer das selbe Schlüsselpaar zu nutzen?
Heiko
On 12.10.06 Heiko Schlittermann (hs@schlittermann.de) wrote:
Hilmar Preusse hille42@web.de (Do 12 Okt 2006 11:37:50 CEST):
Moin,
Du mußt für die Rückverbindung auch wieder einen private/public Key generieren. Hast Du das getan?
Wieso neue private/public Keys. Was ist falsch, immer das selbe Schlüsselpaar zu nutzen?
Eigentlich nicht viel...
H.
Am Mittwoch, den 11.10.2006, 10:52 +0200 schrieb Emanuel Goscinski: Hallo Emanuel
... debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/emu/.ssh/identity debug1: Trying private key: /home/emu/.ssh/id_rsa debug1: Trying private key: /home/emu/.ssh/id_dsa debug1: Next authentication method: password emu@emus-notebook's password: ## ##Wie du siehst fragt er hier nach dem Password. Was dann schließlich ##funktioniert. ##
Du hast auch den privaten Teil des Schlüssels local an den ssh-agent übergeben ?
$ssh-add ausführen
Gruß Gerd
Am Mittwoch, den 11.10.2006, 10:52 +0200 schrieb Emanuel Goscinski: Hallo Emanuel
Hab das mal bei mir schnell nachvollzogen $ ssh-keygen -b 2048 -t dsa $ ssh-copy-id -i .ssh/id_dsa.pub user@zielhost
Was sagt ssh -v hans@remote-host?
Folgendes: emu@emu-desktop:~$ ssh -v emu@emus-notebook OpenSSH_4.2p1 Debian-7ubuntu3.1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to emus-notebook [172.127.0.2] port 22. debug1: Connection established. debug1: identity file /home/emu/.ssh/identity type -1 debug1: identity file /home/emu/.ssh/id_rsa type -1 debug1: identity file /home/emu/.ssh/id_dsa type -1
sieht so aus als fehle der key ^^^^^^
da steht bei mir z.B.: .ssh/id_dsa type 2
Gruß Gerd
Hallo,
On Wed, Oct 11, 2006 at 13:12:47 +0200, Gerd Goehler wrote:
debug1: identity file /home/emu/.ssh/identity type -1 debug1: identity file /home/emu/.ssh/id_rsa type -1 debug1: identity file /home/emu/.ssh/id_dsa type -1
sieht so aus als fehle der key ^^^^^^da steht bei mir z.B.: .ssh/id_dsa type 2
Zumindest schlaegt key_load_public() fehl. Siehe ssh.c, ganz am Ende, dort wird obige Debug-Meldung erzeugt. Man kann bei ssh die -v Option auch mehrfach angeben und erhaelt dadurch mehr Debug-Meldungen.
Gruss, Chris
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Emanuel Goscinski -
Gerd Goehler -
Heiko Schlittermann -
Hilmar Preusse -
Martin Körner