Mehrere id_rsa auf einem Rechner?

rjkmöm

rjkmöm

Mitglied
Thread Starter
Dabei seit
25.02.2006
Beiträge
62
Reaktionspunkte
0
Hallo allerseits.
Von einem MacOSX.4 Server greifen wir per ssh / sftp auf andere Server zu, innerhalb und ausserhalb unseres Netzes. Bisher verwendeten wir den Standard id_rsa für solche Fälle. Diese haben 2048 Bit im Standard, wenn ich nicht irre. Nun haben wir den Fall, dass wir auf einen neu einzubindenden externen Server keinen Zugriff bekommen, obwohl unser public key dort hinterlegt ist. Es kam heraus, dass dort nur 1024 Bit Schlüssel akzeptiert werden. Nun zu meiner Frage: ist es möglich, zusätzlich ein weiteres id_rsa Pärchen anzulegen, mit nur 1024 Bit und anderem Namen, z. Bsp. id_rsa_meier und id_rsa_meier.pub? Die bestehenden Verbindungen sollen bleiben wie sie sind.
Danke und ciao.
 
... ist es möglich, zusätzlich ein weiteres id_rsa Pärchen anzulegen, mit nur 1024 Bit und anderem Namen, z. Bsp. id_rsa_meier und id_rsa_meier.pub? Die bestehenden Verbindungen sollen bleiben wie sie sind.
Danke und ciao.

Yep.

Code:
#> ssh-keygen -b 1024 -f keyfilename

Mehr Info?

Code:
#> man ssh-keygen

Zugriff erfolgt dann mit

Code:
ssh -i keyfilename servername
 
  • Gefällt mir
Reaktionen: rjkmöm
du musst dann halt das entsprechende id file beim ssh kommando angeben...
 
  • Gefällt mir
Reaktionen: rjkmöm
bei sftp kannst du nur eine ssh config angeben, in der dann das id file steht...
 
bei sftp kannst du nur eine ssh config angeben, in der dann das id file steht...

OK, ich habe mir jetzt eine weitere ssh_meier_config angelegt und die Änderungen gemacht (Host geändert (beschränkt auf diesen einen bestimmten), Identity file angepasst ~/.ssh/id_meier_rsa, # vor den zwei Zeilen entfernt). Jetzt frage ich mich nur, ob ich die Einstellungen nach Gebrauch wieder zurückstellen muss. Oder gelten diese Einstellungen nur für die sftp-Verbindung, die ich mit diesem config starte?

Getestet habe ich noch nicht, dazu muss das gegenüber erst mein neues id_meier_rsa.pub hinterlegen.
 
du rufst ja dann sftp mit -F ssh_config auf und das gilt dann nur für die sftp session...
 
du rufst ja dann sftp mit -F ssh_config auf und das gilt dann nur für die sftp session...

Das ist ja super, danke vielmals. Falls ich noch Probleme beim Testen habe, melde ich mich wieder :).

Schönen gewitterfreien Abend noch.
 
Leider geht es noch nicht, warum?

bei sftp kannst du nur eine ssh config angeben, in der dann das id file steht...

Guten Morgen.
Ich habe leider das befürchtete Problem. Der sftp-Server hat jetzt das neue public key file hinterlegt. Ich bekomme keine stabile Verbindung. Woran kann das liegen? Hier ist eine Kopie aus dem Terminal:
Code:
% sftp -vvv -F /Documents/Meier/ssh_meier_config user@sftp.domain.com
Connecting to sftp.domain.com...
OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Documents/Meier/ssh_meier_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to sftp.domain.com [111.22.333.44] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /Users/MacUser/.ssh/id_meier_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/MacUser/.ssh/id_meier_rsa type 1
ssh_exchange_identification: Connection closed by remote host
Connection closed
Auch ein Versuch mit dem Parameter -o bringt nichts:
Code:
sftp -vvv -oIdentityFile ~/.ssh/id_meier_rsa user@sftp.domain.com
Connecting to /Users/MacUser/.ssh/id_meier_rsa...
OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006
command-line line 0: Missing argument.
Connection closed
Angelegt habe ich die neuen Keys mit
Code:
ssh-keygen -b 1024 -t rsa -f id_meier_rsa

Was soll ich noch probieren? :confused: Liegt der Fehler vielleicht beim Gegenüber?

Ratlose Grüsse.

P.S. Natürlich habe ich die richtigen Namen und IPs verändert :D
 
ssh_exchange_identification: Connection closed by remote host
Connection closed

scheint als würde der remote die verbindung schliessen, weil der den key nicht mag...
 
scheint als würde der remote die verbindung schliessen, weil der den key nicht mag...

Ja, nur warum? Das Problem mit der Schlüssellänge ist ja gelöst, 1024 statt 2048 bit. Was könnte es noch sein, was soll ich dem Gegenüber sagen, was er noch tun soll?
Waren meine Aufrufe korrekt, also Parameter o.ä.?
Ciao.
 
mach halt noch ein paar v mehr dazu oder der soll in sein log file gucken...
vielleicht hat der auch den pub key nicht vernünftig in authorized_keys gepackt, muss ja als eine zeile...
 
...und das Thema geht weiter.

Tach allerseits.
Tja, ich bin noch nicht weit gekommen, obwohl viel versucht wurde. Ich will nicht zuviel erzählen, wäre viel zu lange.
Letzter Stand ist, dass mir die Gegenseite jetzt drei (3) Zertifikatdateien geschickt hat, die in das known_hosts file installiert werden sollen und die auf sich verweisen (chained certificates). Hat das schon mal jemand gemacht?
Ich nicht, ich bin ratlos. Ich bitte um Hilfe. :confused:

Hier ist der Originaltext der email der Gegenseite, die Zertifikatnamen habe ich verändert:
Here are the certificates that we provide to our clients to install in their Known_Hosts file in the Root folder.
Please note that Cert1 cert should be chained to Cert2 and in turn be chained to the Cert3. Customer has to rename the .txt to .cer if required.
 
in der known_host stehen doch nur die keys von den schon bekannten rechnern und dienen doch eigentlich nur dazu einen man-in-the-middle attack zu verhindern.
wenn sich der key ändert kriegt man halt das angezeigt und die frage, ob man connecten will oder nicht...

warum sollten die certs da rein?
 
in der known_host stehen doch nur die keys von den schon bekannten rechnern und dienen doch eigentlich nur dazu einen man-in-the-middle attack zu verhindern.
wenn sich der key ändert kriegt man halt das angezeigt und die frage, ob man connecten will oder nicht...
warum sollten die certs da rein?

Tja, das ist die Frage, die ich mir auch stelle.
Diese anfängliche Frage blieb von Anfang an aus, sehr ungewöhnlich. Es wurde immer versucht, direkt auf die Keys zuzugreifen. Wir haben es nicht geschafft, eine Anmeldung mit Kennwort zu starten, auch wenn am Server so eingestellt und/oder am Client per sftp-Parameter forciert. Der Server steht leider in England ohne meinen direkten Zugriff. Auch mein Ansprechpartner hat keinen direkten Zugriff, es geht immer über die IT dort.
 
Zurück
Oben Unten