rsh-problem

[hugin grímnirson]

ich habe da 3 rechner:
10.0.0.101 u 102 mit win2000, cygwin-tools installiert (gleiche version auf beiden rechnern)
10.0.0.103 läuft mit suse 8.1, rshd im inetd aktiviert

meine /etc/hosts.equiv enthält den rechnernamen der linux-box und die ip-adressen der windows-rechner (wie es halt in der man-page steht), die /etc/hosts ist auch brav ausgefüllt (obwohl die theoretisch nix damit zu tun haben sollte, aber was solls).

ich habe KEINE .rhost-files in den entsprechenden user-verzeichnissen angelegt.

ich starte als die bash am 10.0.0.102, gebe "rsh 10.0.0.103 dir" ein -> funzt
am 101 jedoch: permission denied.

dazu aus der /var/log/messages:

Mar 17 03:54:34 suse in.rshd[4961]: connect from 10.0.0.102 (10.0.0.102)
Mar 17 03:54:34 suse pam_rhosts_auth[4961]: allowed to hugin@HXw.HX as hugin
Mar 17 03:54:34 suse in.rshd[4962]: hugin@HXw.HX as hugin: cmd='dir'

Mar 17 03:54:50 suse in.rshd[4967]: connect from 10.0.0.101 (10.0.0.101)
Mar 17 03:54:50 suse pam_rhosts_auth[4967]: denied to hugin@HXs.HX as hugin: access not allowed
Mar 17 03:54:50 suse in.rshd[4967]: rsh denied to hugin@HXs.HX as hugin: Permission denied.
Mar 17 03:54:50 suse in.rshd[4967]: rsh command was 'dir'

alle meine versuche den fehler zu finden waren hoffnungslos, bis ich in meiner verzweiflung mal die ip vom 101er-rechner auf 102 eingestellt habe -> siehe da, es funktioniert.
kaum zurückgestellt auf 101 wieder das alte problem.

ergo:
in der konfig der linux-box muß wo der hund drinnen sein, BLOSS WO???

bitte sagt mir wer, in welche datei ich die 102er-ip eingetragen habe (ich weiß es nämlich echt nicht [mehr?] ) und die 101er nicht.

[hugin grímnirson]

hab den fehler gefunden.
die 101er ip ist in der letzten zeile der /etc/hosts.equiv gestanden und ich hab keine abschließende neue zeile gemacht, wodurch sie offensichtlich nicht eingelesen wurde.

aaaargh .... diese blödheit hat mich jetzt stunden gekostet ...

so, jetzt geh ich schlafen
gute nacht

[Lotussteve]

Hallo!

Gut wenn du es lösen konntest, nur eine Frage:

Gibt es einen bestimmten Grund warum du rsh und nicht ssh hernimmst?



Ciao,

Steve

[hugin grímnirson]

ja
nachdem ssh jedesmal die eingabe eines passwortes verlangt, ist es ihmo für ein webfrontend sonderlich geeignet

rsh ist halt die einzige möglichkeit die ich kenne, bei der man nicht das passwort eingeben muß (wenn man halt die ips RICHTIG in der hosts.equiv einträgt ).

da das ganze bloß in meinem netzwerk und auf einem rechner läuft, bei sicherheit keine tragende rolle spielt, kann ich das risiko denke ich eingehen.

[Lotussteve]

Original geschrieben von hugin grímnirson
nachdem ssh jedesmal die eingabe eines passwortes verlangt, ist es ihmo für ein webfrontend sonderlich geeignet

Hallo Hugin!

Dir ist schon bewusst daß man bei SSH mittels Schlüsselaustausches sich auch ohne Passwort anmelden kann?

z.B.:

http://www.phys.ufl.edu/cms/emu/fast...between_2.html
http://www.rescomp.berkeley.edu/abou...OWTO.html#toc2


Ciao,

Steve

[spunz]

http://www.linux-user.de/ausgabe/200...nswergirl.html

Passwortlos

Will man den Datenabgleich beispielsweise über einen Cronjob automatisieren (vgl. "Diener auf die Minute", LU 12/2000 S. 80ff.), wird die Passworteingabe zum Problem. Es lässt sich lösen, wenngleich Sicherheitsfanatiker/innen ein Auge zudrücken sollten.

Das Stichwort heißt Public-Key-Kryptographie: Man hat ein Schlüsselpaar, von dem man den einen Schlüssel geheim hält und den anderen öffentlich verteilt. Authentifizierung ist nur dann möglich, wenn beide -- geheimer und öffentlicher Schlüssel -- zusammen kommen. Wie wir der Manpage zu ssh entnehmen können, unterstützt unsere gewählte Übertragungsmethode dies.

Was wir tun müssen, ist, zunächst einmal den Schlüssel für den Rechner zu generieren, der das Backup-Skript ausführt. Beinahe hätten wir's erraten: Der Befehl dazu heißt ssh-keygen ("ssh-key generation" -- Erzeugen des ssh-Schlüssels).

[trish@lillegroenn ~]$ ssh-keygen
Generating RSA keys: ..................ooooooO.................ooooooO
Key generation complete.
Enter file in which to save the key (/home/trish/.ssh/identity): [Enter]
Enter passphrase (empty for no passphrase): [Enter]
Enter same passphrase again: [Enter]
Your identification has been saved in /home/trish/.ssh/identity.
Your public key has been saved in /home/trish/.ssh/identity.pub.
The key fingerprint is:
f7:68:22:9f:a3:be:37:7c:7f:92:c2:fb:a1:86:ff:fe trish@lillegroenn.troll.no


Wer seinen geheimen Schlüssel in der vorgeschlagenen Datei ~/.ssh/identity abspeichern will, bestätigt einfach nur mit der Enter-Taste, anderenfalls ist ein Dateiname, am besten mit Pfad fällig.

Kritisch wird es bei der Frage nach dem Passwort: Normalerweise würden wir eins setzen, um den privaten Key zu schützen, aber dann müssten wir ja auch wieder eins eingeben -- ein unendlicher Kreis. Daher beißen wir diesmal in den sauren Apfel und tippen wiederum nur Enter. Auch bei der letzten Bitte um Wiederholung des (nunmehr leeren) Passworts gilt es, nichts als Enter einzugeben. Wem der passwortlose Key nicht geheuer ist, kann die Sicherheit immerhin dadurch erhöhen, dass er oder sie des Öfteren einen neuen Key generiert und verteilt.

Den öffentlichen Schlüssel (abgespeichert mit der Endung .pub) nehmen wir jetzt und übertragen ihn auf den Backuprechner -- natürlich über SecureShell (also mit scp oder per Copy&Paste, während man mit ssh eingeloggt ist). Er muss jedenfalls in die dortige Datei ~/.ssh/authorized_keys eingetragen werden, z.B. so:

[trish@lillegroenn ~]$ cat ~/.ssh/identity.pub | ssh -v pjung@backup.linux-user.de cat - >> ~/.ssh/authorized_keys


Dieses umständliche Prozedere statt einem einfachen scp ~/.ssh/identity.pub pjung@backup.linux-user.de:~/.ssh/authorized_keys ist nötig, wenn ~/.ssh/authorized_keys auf backup.linux-user.de schon andere Schlüssel beherbergt. Durch das doppelte >> erreichen wir, dass die mit dem zweiten cat ausgegebene Standardeingabe zu ssh (symbolisiert durch ein -) ans Ende von ~/.ssh/authorized_keys angehängt wird.

Woher kommt diese Eingabe für ssh, die diese an das auszuführende Remote-Kommando cat - >> ~/.ssh/authorized_keys weitergibt? Hier ist die Pipe | verantwortlich, die die Ausgabe von cat ~/.ssh/identity.pub ins ssh-Kommando hinein geschubst.

Jetzt heißt es nur noch testen, ob das Skript tatsächlich ohne Passwort funktioniert. Wenn ja, steht einem Backup-Cronjob nichts mehr im Wege. (pju)

[hugin grímnirson]

Original geschrieben von Lotussteve
Dir ist schon bewusst daß man bei SSH mittels Schlüsselaustausches sich auch ohne Passwort anmelden kann?

wie mein voriges posting sowie meine handlungsweise zeigen: nein

aber ich hab eure tipps gleich umgesetzt und muß sagen, das funktioniert ja ziemlich genial. abgesehen von der zusätzlichen verschlüsselung (auf die ich zugegebenermaßen keinen sonderlichen wert lege *bittenichtschlagen* da bloß internes, privates netzwerk) erleichtert es die auswahl, als welcher user man sich anmeldet wesentlich (da man bei rsh meiner erfahrung nach nur als jener user zugriff bekommt, der man gerade ist; hier kann man jedoch den account dezitiert angeben) und spart mir somit einen guten teil an arbeit (gott sei dank, hab eh schon genug zeit unnötig mit rsh verschwendet )

VIELEN DANK meine herren!

[Lotussteve]

Original geschrieben von hugin grímnirson
1.) abgesehen von der zusätzlichen verschlüsselung (auf die ich zugegebenermaßen keinen sonderlichen wert lege *bittenichtschlagen* da bloß internes, privates netzwerk)

2.) VIELEN DANK meine herren!

Hallo!

ad 1.) Das mag schon stimmen, nur mache ich überall Verschlüsselung, lange Passwörter etc... so daß ich mich nirgends umgewöhnen muss oder mal nicht dran denke wenn es wichtig wäre, sondern es ist mir dann schon in Fleisch und Blut übergegangen.

ad 2.) de rien



Ciao,

Steve