Hallo Liste, ich habe ein problem mit der SSH Authorisierung. Ich habe 2 Server, Server 1 soll sich ohne passwort eingabe mit dem Username backup auf server 2 einloggen können, dazu erzeuge ich also auf server 1 einen ssh key mittels ssh-keygen -t rsa gebe eine passphrase ein, public und private key werden erzeugt, nun übertrage ich den public auf server 2 das homeverzeichniss des users backup auf server 2 ist /var/backup der key liegt nun in /var/backup ich verschiebe ihn nach /var/backup/.ssh und gebe ein cat rootkey.pub << authorized_keys nun steht der key also in der file doch wnen ich nun auf server 1 eingebe ssh backup@server2 dann will er nach wir vor das passwort haben. Habe ich etwas falsch gemacht oder muss ich irgendwie den "ssh cache" löschen? Stehe derzeit etwas auf dem schlauch. Das ganze hat den Sinn das ich in einem Backupscript per rsync dateien übertragen will, ich aber nichts nachts um 3 an den rechner gehen will um das passwort eingeben will, und ein user mit blank passwort ist nun wahrlich die schlechteste Lösung ;) Vielen dank Gruß Alex ------- Alexander Jäger
Hallo,
Am Mo 29.08.2005 12:05 schrieb Alex@fuemmbf.de
ich habe ein problem mit der SSH Authorisierung. Ich habe 2 Server, Server 1 soll sich ohne passwort eingabe mit dem Username backup auf server 2 einloggen können, dazu erzeuge ich also auf server 1 einen ssh key mittels ssh-keygen -t rsa gebe eine passphrase ein, public und private key werden erzeugt, nun übertrage ich den public auf server 2 ... dann will er nach wir vor das passwort haben. ...
wenn du dem erstellten Key eine Passphrase gibst, muss sie auch jedes Mal bei Benutzung eingegeben werden. Um Server1 automatisch einloggen zu können, darf keine Passphrase gesetzt werden... Gruß Martin
ich habe ein problem mit der SSH Authorisierung. Ich habe 2 Server, Server 1 soll sich ohne passwort eingabe mit dem Username backup auf server 2 einloggen können, dazu erzeuge ich also auf server 1 einen ssh key mittels ssh-keygen -t rsa gebe eine passphrase ein, public und private key werden erzeugt, nun übertrage ich den public auf server 2 ... dann will er nach wir vor das passwort haben. ...
wenn du dem erstellten Key eine Passphrase gibst, muss sie auch jedes Mal bei Benutzung eingegeben werden. Um Server1 automatisch einloggen zu können, darf keine Passphrase gesetzt werden...
Gruß Martin
habe es nun auch mit leerer passphrase versucht, leider funktioniert es dennoch nicht. Da ich bissher per root dn key erzeugt hatte, habe ich nun auf server 1 auch einen user backup angelegt, aber auch bei anlegen eines keys mit diesem benutzer (diesmal mit leerer passphrase) kommt weiterhin die Passwort abfrage. Die "Anleitung" bei den FAQs habe ich genauso gelesen wie auch das hier: http://www.trash.net/faq/ssh.shtml aber irgendwie will das nicht so wie ich will. Gruß Alex
Alexander Jäger schrieb:
habe es nun auch mit leerer passphrase versucht, leider funktioniert es
dennoch nicht. Da ich bissher per root dn key erzeugt hatte, habe ich nun auf server 1 auch einen user backup angelegt, aber auch bei anlegen eines keys mit diesem benutzer (diesmal mit leerer passphrase) kommt weiterhin die Passwort abfrage.
Die "Anleitung" bei den FAQs habe ich genauso gelesen wie auch das hier: http://www.trash.net/faq/ssh.shtml aber irgendwie will das nicht so wie ich will.
Gruß Alex
Hallo Alex, Du mußt noch einige Einstellungen vornehmen, wenn Du Dich per PublicKey anmelden willst. Hast Du in der im Thread genannten FAQ angeschaut ".... am System per ssh-Key anmelden.....? Gruß Axel
Am Montag, 29. August 2005 13:03 schrieb Alexander Jäger:
habe es nun auch mit leerer passphrase versucht, leider funktioniert es dennoch nicht. Da ich bissher per root dn key erzeugt hatte, habe ich nun auf server 1 auch einen user backup angelegt, aber auch bei anlegen eines keys mit diesem benutzer (diesmal mit leerer passphrase) kommt weiterhin die Passwort abfrage.
Wie hast du ihn denn abgelegt? in der Datei "authorized_keys" im .ssh-Verzeichnis des gewünschten Users? Gruß Martin
Am Montag, 29. August 2005 13:03 schrieb Alexander Jäger:
habe es nun auch mit leerer passphrase versucht, leider funktioniert es dennoch nicht. Da ich bissher per root dn key erzeugt hatte, habe ich nun auf server 1 auch einen user backup angelegt, aber auch bei anlegen eines keys mit diesem benutzer (diesmal mit leerer passphrase) kommt weiterhin die Passwort abfrage.
Wie hast du ihn denn abgelegt? in der Datei "authorized_keys" im .ssh-Verzeichnis des gewünschten Users?
Gruß Martin
Hallo Martin, ja die Datei liegt auf server2 in /vat/backup/.ssh/ " backup@server2:~/.ssh> cat authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA7zDdaFUpIv4hOsd3cUzRbJWg7MQcLudaDCHqBDodVSr5bYRB c+to6SZYqdQR0kHK13al8dOfznDXXf4iAVXGA7lJ9ZcnnFDXtqHvwN7su6r8D+0aUokBWFAOeigK HYg1EoFjD/j7Zk5hFOwg0+9UMqsiDSzkwD11b/ST5G9xtNE= backup@h561178 Das ist der Inhalt
Hallo
ein solch nerviges Problem hatte ich auch einmal. Prüfe die Rechte des .ssh - Verzeichnisses. Es muss 600 sein. Grüsse Bernhard
das hatte ich auch schon gedacht, mit 600 hatte ich es probiert, aber selbst mit 777 keine Veränderung, Passwort wird nach wie vor verlangt Gruß Alex
Alexander Jäger schrieb:
Hallo Martin, ja die Datei liegt auf server2 in /vat/backup/.ssh/ " backup@server2:~/.ssh> cat authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA7zDdaFUpIv4hOsd3cUzRbJWg7MQcLudaDCHqBDodVSr5bYRB c+to6SZYqdQR0kHK13al8dOfznDXXf4iAVXGA7lJ9ZcnnFDXtqHvwN7su6r8D+0aUokBWFAOeigK HYg1EoFjD/j7Zk5hFOwg0+9UMqsiDSzkwD11b/ST5G9xtNE= backup@h561178
Das ist der Inhalt
das hatte ich auch schon gedacht, mit 600 hatte ich es probiert, aber selbst mit 777 keine Veränderung, Passwort wird nach wie vor verlangt
Gruß Alex
wie rufst Du ssh auf? ssh -i /home/..user../.ssh/transfer.key? Gruß Axel
server2:/var/backup/.ssh # ll total 16 drwxrwxrwx 2 backup www 4096 Aug 29 13:50 . drwx---r-x 3 backup www 4096 Aug 29 13:45 .. -rwx------ 1 backup www 224 Aug 29 13:50 authorized_keys -rw----r-- 1 backup www 224 Aug 29 12:42 backuptest.pub in der sshd.config wurde PubkeyAuthentication auf yes gesetzt, danach sshd reloaded, oder muss er danach restartet werdne? Gruß Alex
Hallo,
Axel Birndt schrieb:
Hallo Martin, ja die Datei liegt auf server2 in /vat/backup/.ssh/
mach mal bitte auf Server 2 in /home/backup/.ssh ein "ll"
Gruß Martin
Am Mo, den 29.08.2005 schrieb Alexander Jäger um 18:27:
server2:/var/backup/.ssh # ll total 16 drwxrwxrwx 2 backup www 4096 Aug 29 13:50 . drwx---r-x 3 backup www 4096 Aug 29 13:45 .. -rwx------ 1 backup www 224 Aug 29 13:50 authorized_keys -rw----r-- 1 backup www 224 Aug 29 12:42 backuptest.pub
in der sshd.config wurde PubkeyAuthentication auf yes gesetzt, danach sshd reloaded, oder muss er danach restartet werdne?
Ich glaube, das die Dateirechte für die Datei authorized_keys nicht stimmt. Denn die muss die Rechte 0600 haben. Bye Michael -- Windows NT: Vaporware of the desperate and scared. ________________________________________________________________________ http://macbyte.info/ ICQ #151172379 http://dattuxi.de/
Michael Raab schrieb:
Am Mo, den 29.08.2005 schrieb Alexander Jäger um 18:27:
server2:/var/backup/.ssh # ll total 16 drwxrwxrwx 2 backup www 4096 Aug 29 13:50 . drwx---r-x 3 backup www 4096 Aug 29 13:45 .. -rwx------ 1 backup www 224 Aug 29 13:50 authorized_keys -rw----r-- 1 backup www 224 Aug 29 12:42 backuptest.pub
in der sshd.config wurde PubkeyAuthentication auf yes gesetzt, danach sshd reloaded, oder muss er danach restartet werdne?
Ich glaube, das die Dateirechte für die Datei authorized_keys nicht stimmt. Denn die muss die Rechte 0600 haben.
Und sie muss (glaube ich) für root lesbar sein... Gruß Martin
Hallo Hans-Martin, hallo Michael, hallo Alexander, hallo Leute, Am Montag, 29. August 2005 18:50 schrieb Hans-Martin Flesch:
Michael Raab schrieb:
Am Mo, den 29.08.2005 schrieb Alexander Jäger um 18:27:
server2:/var/backup/.ssh # ll drwxrwxrwx 2 backup www 4096 Aug 29 13:50 .
~/.ssh ist also für *alle* schreibbar. Das dürfte die Ursache für das Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700. [...]
in der sshd.config wurde PubkeyAuthentication auf yes gesetzt, danach sshd reloaded, oder muss er danach restartet werdne?
reload müsste eigentlich reichen. Außerdem ist die Anmeldung per PubKey üblicherweise per Default möglich - Du hättest also nichtmal etwas anpassen müssen ;-) [...]
Und sie muss (glaube ich) für root lesbar sein...
Für root sind alle Dateien lesbar - unabhängig von ihren Zugriffsrechten ;-) Falls der SSH-Key immer noch nicht akzeptiert wird, schiebe mal ~/.ssh auf beiden Rechnern beiseite und probier das Ganze nochmal mit folgender Anleitung, die bisher immer funktioniert hat: 9.3. Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner? http://suse-linux-faq.koehntopp.de/q/q-ssh-keygen.html Zum Thema "Absicherung des Keys mit Passphrase" vs. "Eingabe der Passphrase" empfehle ich ebenfalls einen Blick in die FAQ: 9.4. Wie geht SSH ohne Passwort? http://suse-linux-faq.koehntopp.de/q/q-ssh-without_passwd.html Darin wird auch auf keychain hingewiesen - für einen Backup-Cronjob halte ich das allerdings für deutlich oversized. Ich setze auf einem Rechner zwecks Backup eine Kombination selbstgeschriebener Scripte ein: - ein Startscript, das einen ssh-agent startet - statt stdout per "eval" auszuführen, leite ich es in eine Datei /root/.ssh-agent-config um. - ein kleines Script, um die Passphrase (für die Dauer der Uptime) freizuschalten. Inhalt: ein eval-Aufruf (siehe unten) und ein Aufruf von ssh-add Im Freischalt-Script und im Backup-Script brauchst Du dann nur ein eval `cat /root/.ssh-agent-config´ (Da fällt mir gerade ein, dass source /root/.ssh-agent-config auch gehen müsste.) Mit dieser Konstruktion ist die Passphrase während der Uptime des Rechners verfügbar und muss nicht neu eingegeben werden. Nach einem Reboot (egal ob beabsichtigt, wegen Stromausfall oder auch wegen Diebstahl) ist der SSH-Key erstmal wieder gesperrt. Komplette Scripte auf Anfrage ;-) Gruß Christian Boltz -- 2.-5.9.2005: Weinfest in Insheim Bei der Landjugend: Liquid, AH-Band und Deafen Goblins Mehr Infos: www.Landjugend-Insheim.de
Hallo, ich weiß nicht, ob das Problem noch akut ist, aber: Am Mittwoch, 31. August 2005 00:08 schrieb Christian Boltz:
Hallo Hans-Martin, hallo Michael, hallo Alexander, hallo Leute,
Am Montag, 29. August 2005 18:50 schrieb Hans-Martin Flesch:
Michael Raab schrieb:
Am Mo, den 29.08.2005 schrieb Alexander Jäger um 18:27:
server2:/var/backup/.ssh # ll drwxrwxrwx 2 backup www 4096 Aug 29 13:50 .
~/.ssh ist also für *alle* schreibbar. Das dürfte die Ursache für das Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.
was mich hier wundert, ist dass das ll in /var/backup/.ssh gemacht wurde und eben nicht in ~/.ssh - oder ist /var/backup das Home-Verzeichnis des Backup-Users?
Und sie muss (glaube ich) für root lesbar sein...
Für root sind alle Dateien lesbar - unabhängig von ihren Zugriffsrechten ;-)
Stimmt - war an einer Stelle aus der man-Page zu sshd ins Straucheln geraten... Martin
Guten Morgen Liste, hallo Hans, Hallo Michael,
Am Mittwoch, 31. August 2005 00:08 schrieb Christian Boltz:
Hallo Hans-Martin, hallo Michael, hallo Alexander, hallo Leute,
Am Montag, 29. August 2005 18:50 schrieb Hans-Martin Flesch:
Michael Raab schrieb:
Am Mo, den 29.08.2005 schrieb Alexander Jäger um 18:27:
server2:/var/backup/.ssh # ll drwxrwxrwx 2 backup www 4096 Aug 29 13:50
~/.ssh ist also für *alle* schreibbar. Das dürfte die Ursache für das Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.
sowohl 700 als auch 755 funktionierte nicht
was mich hier wundert, ist dass das ll in /var/backup/.ssh gemacht wurde und eben nicht in ~/.ssh - oder ist /var/backup das Home-Verzeichnis des Backup-Users?
ja ist es
Ich hab jetzt gerade noch mal bei mir geschaut, meine keys (dsa) stehen alle in der authorized_keys2. Ich bin mir jetzt nicht sicher, aber kann es sein, dass authorized_keys nur für das veraltete, unsichere und standardmässig deaktivierte ssh1 verwendet wird, während für ssh2 die authorized_keys2 genutzt wird? Ansonsten wirf auch auf /var/log/messages, während des loginversuchs, ich hatte mal das Problem, dass die Rechte des .ssh Verzeichnisses zu großzügig gewählt waren, ssh hat darauf hin verweigert die authorized_keys2 daraus zu verwenden.
habe jetzt auf 700 geändert, problem besteht weiterhin, auch eine umbenennung funktioniert nicht ssh backup@server2 -v-v gibt folgendes aus: server1:~ # ssh backup@server2 -v-v OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to server2 [81.169.142.181] port 22. debug1: Connection established. debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.7.1p2 debug1: match: OpenSSH_3.7.1p2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2 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 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 'server2' is known and matches the RSA host key. debug1: Found key in /root/.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,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive wobei der private key zu dem passenden key in der authorized_keys der key rootkey.pub ist, welcher korrekt in /root/.ssh und heißt "rootkey" was ich jetzt auch mal versucht habe "rootkey" in d"identity" umzubenennen, funktioniert auch nich, langsam verzweifle ich ... Gruß Alex
Hallo, Alexander Jäger schrieb:
wobei der private key zu dem passenden key in der authorized_keys der key rootkey.pub ist, welcher korrekt in /root/.ssh und heißt "rootkey" was ich jetzt auch mal versucht habe "rootkey" in d"identity" umzubenennen, funktioniert auch nich, langsam verzweifle ich ...
benenne mal die authorized_keys in authorized_keys2 um. Jedenfalls git es bei diese Datei für die Protokollversion 2. Vielleicht hilft das ja... Martin
Hallo,
Alexander Jäger schrieb:
wobei der private key zu dem passenden key in der authorized_keys der key rootkey.pub ist, welcher korrekt in /root/.ssh und heißt "rootkey" was ich jetzt auch mal versucht habe "rootkey" in d"identity" umzubenennen, funktioniert auch nich, langsam verzweifle ich ...
benenne mal die authorized_keys in authorized_keys2 um. Jedenfalls git es bei diese Datei für die Protokollversion 2.
Vielleicht hilft das ja...
Martin
nein, das hat leider auch nicht geholfen, es kann aber nicht damit zusammen hängen das ich für dn user so ein "ungewöhnliches Homeverzeichniss" gewählt habe Der User backup ist mitglied der Gruppe sshd und www Gruß Alex
On Wednesday 31 August 2005 08:41, Alexander Jäger wrote:
oder ist /var/backup das Home-Verzeichnis des Backup-Users?
ja ist es
ssh backup@server2 -v-v gibt folgendes aus: [...] debug1: identity file /root/.ssh/identity type -1
Diese beiden Aussagen machen mit stutzig. Kann es sein, dass Deine ganzen Versuche mit dem .ssh Verzeichnis an der falschen Stelle gemacht wurden? Du scheibst immer von /var/backup/.ssh aber beim login verwendet ssh offensichtlich die Dateien aus /root/.ssh Du solltest Dir also entweder /root/.ssh genauer ansehen und die Tipps anwenden, die Du schon bekommen hast oder dafür sorgen, dass ssh nicht dort hin sondern nach /var/backup/ssh schaut. Warum es das nicht tut, kann ich Dir leider nicht sagen. Gruß, Achim
Achim Schaefer schrieb:
On Wednesday 31 August 2005 08:41, Alexander Jäger wrote:
oder ist /var/backup das Home-Verzeichnis des Backup-Users?
ja ist es
ssh backup@server2 -v-v gibt folgendes aus: [...] debug1: identity file /root/.ssh/identity type -1
Ich vermute, dass diese Ausgabe von Server 1 stammt - dann macht sie Sinn, wenn er sich als root@server1 per ssh mit backup@server2 verbinden will. Dann wird im Homeverzeichnis des Benutzers root auf Server1 im Verzeichnis .ssh der entsprechende privat-Key gesucht und mit dem in authorized_keys abgelgten public-Key des Benutzers backup auf Server2 verglichen... Gibt /var/log/messages auf Server2 etwas her? Erhöhe doch dort auch einmal den Debug-Level des sshd... Martin
Hallo Hans-Martin, hallo Michael, hallo Alexander, hallo Leute,
Am Montag, 29. August 2005 18:50 schrieb Hans-Martin Flesch:
Michael Raab schrieb:
Am Mo, den 29.08.2005 schrieb Alexander Jäger um 18:27:
server2:/var/backup/.ssh # ll drwxrwxrwx 2 backup www 4096 Aug 29 13:50 .
~/.ssh ist also für *alle* schreibbar. Das dürfte die Ursache für das Problem sein. Reduziere die Rechte mal auf 755 oder sogar 700.
hat leider nicht gewirkt
[...]
in der sshd.config wurde PubkeyAuthentication auf yes gesetzt, danach sshd reloaded, oder muss er danach restartet werdne?
reload müsste eigentlich reichen. Außerdem ist die Anmeldung per PubKey üblicherweise per Default möglich - Du hättest also nichtmal etwas anpassen müssen ;-)
nein, der entsprechende config punkt war mittels # auskommentiert
[...]
Und sie muss (glaube ich) für root lesbar sein...
Für root sind alle Dateien lesbar - unabhängig von ihren Zugriffsrechten ;-)
Falls der SSH-Key immer noch nicht akzeptiert wird, schiebe mal ~/.ssh auf beiden Rechnern beiseite und probier das Ganze nochmal mit folgender Anleitung, die bisher immer funktioniert hat:
9.3. Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner? http://suse-linux-faq.koehntopp.de/q/q-ssh-keygen.html
Zum Thema "Absicherung des Keys mit Passphrase" vs. "Eingabe der Passphrase" empfehle ich ebenfalls einen Blick in die FAQ:
9.4. Wie geht SSH ohne Passwort? http://suse-linux-faq.koehntopp.de/q/q-ssh-without_passwd.html
Darin wird auch auf keychain hingewiesen - für einen Backup-Cronjob halte ich das allerdings für deutlich oversized. Ich setze auf einem Rechner zwecks Backup eine Kombination selbstgeschriebener Scripte ein: - ein Startscript, das einen ssh-agent startet - statt stdout per "eval" auszuführen, leite ich es in eine Datei /root/.ssh-agent-config um. - ein kleines Script, um die Passphrase (für die Dauer der Uptime) freizuschalten. Inhalt: ein eval-Aufruf (siehe unten) und ein Aufruf von ssh-add
Im Freischalt-Script und im Backup-Script brauchst Du dann nur ein eval `cat /root/.ssh-agent-config´ (Da fällt mir gerade ein, dass source /root/.ssh-agent-config auch gehen müsste.)
Mit dieser Konstruktion ist die Passphrase während der Uptime des Rechners verfügbar und muss nicht neu eingegeben werden. Nach einem Reboot (egal ob beabsichtigt, wegen Stromausfall oder auch wegen Diebstahl) ist der SSH-Key erstmal wieder gesperrt.
Komplette Scripte auf Anfrage ;-)
Gruß
Christian Boltz
da wäre ich nicht abgeneigt wnen ich mal in die scripte reinlinsen dürfte, wobei es mich wirklich wundert, warum der einfach nicht den key akzeptieren will Gruß und nochmal danke für die bissherige Mühen Alexander
On Monday 29 August 2005 12:05, Alex@fuemmbf.de wrote:
Hallo Liste,
ich habe ein problem mit der SSH Authorisierung. Ich habe 2 Server, Server 1 soll sich ohne passwort eingabe mit dem Username backup auf server 2 einloggen können, dazu erzeuge ich also auf server 1 einen ssh key mittels ssh-keygen -t rsa
gebe eine passphrase ein,
das ist dein Fehler ;-)
public und private key werden erzeugt, nun übertrage ich den public auf server 2 das homeverzeichniss des users backup auf server 2 ist /var/backup der key liegt nun in /var/backup ich verschiebe ihn nach /var/backup/.ssh und gebe ein cat rootkey.pub << authorized_keys nun steht der key also in der file doch wnen ich nun auf server 1 eingebe ssh backup@server2 dann will er nach wir vor das passwort haben. Habe ich etwas falsch gemacht oder muss ich irgendwie den "ssh cache" löschen?
Stehe derzeit etwas auf dem schlauch. Das ganze hat den Sinn das ich in einem Backupscript per rsync dateien übertragen will, ich aber nichts nachts um 3 an den rechner gehen will um das passwort eingeben will,
das waere in dem Sinne die passphrase
und ein user mit blank passwort ist nun wahrlich die schlechteste Lösung ;)
wohl wahr
Vielen dank
hoffe geholfen haben zu koennen
Gruß Alex
LG, Benni -- Benjamin Zeller Ing.-Büro Hohmann Bahnhofstr. 34 D-82515 Wolfratshausen Tel.: +49 (0)8171 347 88 12 Mobil: +49 (0)160 99 11 55 23 Fax: +49 (0)8171 910 778 mailto: zeller@ibh-wor.de www.ibh-wor.de
Alex@fuemmbf.de wrote:
ich habe ein problem mit der SSH Authorisierung. Ich habe 2 Server, Server 1 soll sich ohne passwort eingabe mit dem Username backup auf server 2 einloggen können, [...]
Das ist eine FAQ! http://suse-linux-faq.koehntopp.de/q/q-ssh-without_passwd.html CU, Th.
Hallo ein solch nerviges Problem hatte ich auch einmal. Prüfe die Rechte des .ssh - Verzeichnisses. Es muss 600 sein. Grüsse Bernhard Am Montag, 29. August 2005 12:05 schrieb Alex@fuemmbf.de:
Hallo Liste,
ich habe ein problem mit der SSH Authorisierung. Ich habe 2 Server, Server 1 soll sich ohne passwort eingabe mit dem Username backup auf server 2 einloggen können, dazu erzeuge ich also auf server 1 einen ssh key mittels ssh-keygen -t rsa gebe eine passphrase ein, public und private key werden erzeugt, nun übertrage ich den public auf server 2 das homeverzeichniss des users backup auf server 2 ist /var/backup der key liegt nun in /var/backup ich verschiebe ihn nach /var/backup/.ssh und gebe ein cat rootkey.pub << authorized_keys nun steht der key also in der file doch wnen ich nun auf server 1 eingebe ssh backup@server2 dann will er nach wir vor das passwort haben. Habe ich etwas falsch gemacht oder muss ich irgendwie den "ssh cache" löschen?
Stehe derzeit etwas auf dem schlauch. Das ganze hat den Sinn das ich in einem Backupscript per rsync dateien übertragen will, ich aber nichts nachts um 3 an den rechner gehen will um das passwort eingeben will, und ein user mit blank passwort ist nun wahrlich die schlechteste Lösung ;)
Vielen dank
Gruß Alex ------- Alexander Jäger
Am Montag, 29. August 2005 12:05 schrieb Alex@fuemmbf.de:
cat rootkey.pub << authorized_keys ^^ sicher, dass das so rum funktioniert? Du willst Doch den rootkey.pub an das authorized_keys file anhängen und nicht umgekehrt.
-- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
cat rootkey.pub << authorized_keys ^^ sicher, dass das so rum funktioniert? Du willst Doch den rootkey.pub an das authorized_keys file anhängen und nicht umgekehrt.
sorry, war ein Tippfehler n der Mail, in der shell habe ich es natürlich richtig rum gemacht, der key steht ja auch in der authorized_keys file drin, aber irgendwie scheint er nicht zu wollen, oder muss ssh neu gestartet werden, damit die änderung in der config richtig angenommen wird, bzw gibt es keinen command mit dem ich sehen kann, wie ssh gerade läuft, bzw was ssh als auth anerkennt Gruß Alex
Hallo, Alexander Jäger schrieb:
oder muss ssh neu gestartet werden, damit die änderung in der config richtig angenommen wird, bzw gibt es keinen command mit dem ich sehen kann, wie ssh gerade läuft, bzw was ssh als auth anerkennt
Gruß Alex
eigentlich sollte "rcsshd reload" ausreichen - aber wenn Du eine neue sshd_config testen willst, ohne Gefahr zu laufen, Dich auszusperren, starte mit "/usr/sbin/sshd -p <AndererPortAlsDerErsteSshd> -f <configFile>" eine zweite Instanz auf einem neuen Port. Mit "-d", "-d -d" oder "-d -d -d" erhöhst Du den Loglevel, vielleicht geben die Meldungen ja Aufschluss über die Ursache Deines Problems. Grüße, Felix
Am Dienstag, 30. August 2005 11:37 schrieb Alexander Jäger:
cat rootkey.pub << authorized_keys
^^ sicher, dass das so rum funktioniert? Du willst Doch den rootkey.pub an das authorized_keys file anhängen und nicht umgekehrt.
sorry, war ein Tippfehler n der Mail, in der shell habe ich es natürlich richtig rum gemacht, der key steht ja auch in der authorized_keys file drin, aber irgendwie scheint er nicht zu wollen,
Ich hab jetzt gerade noch mal bei mir geschaut, meine keys (dsa) stehen alle in der authorized_keys2. Ich bin mir jetzt nicht sicher, aber kann es sein, dass authorized_keys nur für das veraltete, unsichere und standardmässig deaktivierte ssh1 verwendet wird, während für ssh2 die authorized_keys2 genutzt wird? Ansonsten wirf auch auf /var/log/messages, während des loginversuchs, ich hatte mal das Problem, dass die Rechte des .ssh Verzeichnisses zu großzügig gewählt waren, ssh hat darauf hin verweigert die authorized_keys2 daraus zu verwenden. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Alex@fuemmbf.de schrieb:
Hallo Liste,
ich habe ein problem mit der SSH Authorisierung.
......
Vielen dank
Gruß Alex ------- Alexander Jäger
also ich lese jetzt hier schon die ganze Zeit mit, aber wo Dein eigentliches Problem liegt ist mir grad etwas abhanden gekommen. Ein Tipp der Dir vielleicht noch weiterhilft: http://kai.iks-jena.de/scpsftp/ssh-rssh-sftp.html --> Abschnitt "sshd_config anpassen" http://www2.uibk.ac.at/zid/software/unix/linux/ssh-publickey.html http://unix-docu.uibk.ac.at/zid/software/unix/ssh/unix-use.html --> hier "3.2 Einrichten der Public Key Benutzerauthentifizierung" vielleicht hilft es Dir ja Gruß Axel
Alex@fuemmbf.de wrote: ...
doch wnen ich nun auf server 1 eingebe ssh backup@server2 dann will er nach wir vor das passwort haben. ...
Passwort oder Passphrase? Versuch's mal mit ssh -v backup@server2 Mit mehr -vv gibt's mehr Debug-Ausgabe. Außerdem bitte mal in das syslog des sshd (auf server2) schauen, ob der was meckert. -- Viele Grüße ------------------------------------------------------------------------ Michael Behrens
participants (13)
-
Achim Schaefer -
Alex＠fuemmbf.de -
Alexander Jäger
-
Axel Birndt -
Benjamin Zeller -
Bernhard Bühler -
Christian Boltz -
Felix Nawroth -
Hans-Martin Flesch -
Manfred Tremmel -
Michael Behrens -
Michael Raab -
Thomas Hertweck