Archiv:Ssh mit Zertifikaten absichern - Versionsgeschichte

Tommes: Tommes verschob die Seite Ssh mit Zertifikaten absichern nach Archiv:Ssh mit Zertifikaten absichern

2025-03-15T07:36:04Z

Tommes verschob die Seite Ssh mit Zertifikaten absichern nach Archiv:Ssh mit Zertifikaten absichern

← Nächstältere Version	Version vom 15. März 2025, 07:36 Uhr
(kein Unterschied)

imported>Cyorps: Reload-Befehl von sshd ab DSM 5.0 eingefügt/angepasst

2015-03-14T22:39:27Z

Reload-Befehl von sshd ab DSM 5.0 eingefügt/angepasst

← Nächstältere Version		Version vom 14. März 2015, 22:39 Uhr
Zeile 100:		Zeile 100:

	== Testlauf ==		== Testlauf ==
	Zum Testen des Ganzen müsst ihr erstmal den ssh Daemon neustarten. Dazu loggt ihr Euch am Besten via telnet als root mit Admin Passwort auf der DS ein und ruft das entsprechende Startscript des Daemons auf		Zum Testen des Ganzen müsst ihr erstmal den ssh Daemon neustarten. Dazu loggt ihr Euch am Besten via telnet als root mit Admin Passwort auf der DS ein und ruft das entsprechende Startscript des Daemons auf:
			Vor der DSM-Version 5.0
	<pre>		<pre>
	$ sh /usr/syno/etc.defaults/rc.d/S95sshd.sh restart		$ sh /usr/syno/etc.defaults/rc.d/S95sshd.sh restart
			</pre>
			Ab der DSM-Version 5.0
			<pre>
			$ synoservicectl --reload sshd
	</pre>		</pre>
	Alternativ kann in der Weboberfläche auch ssh ab- und wieder angewählt werden (jeweils auch übernehmen!).		Alternativ kann in der Weboberfläche auch ssh ab- und wieder angewählt werden (jeweils auch übernehmen!).

imported>Johayek: /* Von DiskStation zu DiskStation */

2015-01-30T06:19:04Z

Von DiskStation zu DiskStation

← Nächstältere Version		Version vom 30. Januar 2015, 06:19 Uhr
Zeile 204:		Zeile 204:

	=== Von DiskStation zu DiskStation ===		=== Von DiskStation zu DiskStation ===
	Will man sich mit <code>ssh</code> von einer DiskStation auf einer anderen einloggen und dabei Schlüsselpaare einsetzen, kann man diese Anleitung befolgen. Hierbei muss man ~~den~~ jeweils den Unix-Teil der Konfiguration ausführen.		Will man sich mit <code>ssh</code> von einer DiskStation auf einer anderen einloggen und dabei Schlüsselpaare einsetzen, kann man diese Anleitung befolgen. Hierbei muss man dann jeweils den Unix-Teil der Konfiguration ausführen.

imported>CptGambit: /* Mac OS X, Unix */

2014-02-09T11:04:52Z

Mac OS X, Unix

← Nächstältere Version		Version vom 9. Februar 2014, 11:04 Uhr
Zeile 64:		Zeile 64:

	Nachdem Erstellen der Public Keys muss man noch die Rechte der beiden Dateien ändern, da man sie sonst nicht auf die DS kopieren kann. (regulär werden die Public Keys mit 0644 angelegt, was aber zu wenig restriktiv ist)		Nachdem Erstellen der Public Keys muss man noch die Rechte der beiden Dateien ändern, da man sie sonst nicht auf die DS kopieren kann. (regulär werden die Public Keys mit 0644 angelegt, was aber zu wenig restriktiv ist)
	Andernfalls würde man die Fehlermeldung: "Permissions 0644 for '/Users/USERNAME/.ssh/id_rsa' are too open."		Andernfalls würde man die Fehlermeldung: ''Permissions 0644 for '/Users/USERNAME/.ssh/id_rsa' are too open.'' bekommen

	<pre>		<pre>

imported>CptGambit: /* Mac OS X, Unix */

2014-02-09T11:03:59Z

Mac OS X, Unix

← Nächstältere Version		Version vom 9. Februar 2014, 11:03 Uhr
Zeile 62:		Zeile 62:
	==== Mac OS X, Unix ====		==== Mac OS X, Unix ====
	Unter unixoiden Betriebssystemen mit installiertem OpenSSH kann man das Kommandozeilenprogramm <code>ssh-keygen</code> zur Schlüsselgenerierung benutzen. Bei Mac OS X kann man dazu das Programm '''Terminal''' (im Order ''/Programme/Dienstprogramme'') ausführen und in der Shell den Befehl eingeben. <code>ssh-keygen</code> fragt nach einem Speicherort (voreingestellt ist ''~/.ssh/id_rsa'') und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix ''.pub'' erhält.		Unter unixoiden Betriebssystemen mit installiertem OpenSSH kann man das Kommandozeilenprogramm <code>ssh-keygen</code> zur Schlüsselgenerierung benutzen. Bei Mac OS X kann man dazu das Programm '''Terminal''' (im Order ''/Programme/Dienstprogramme'') ausführen und in der Shell den Befehl eingeben. <code>ssh-keygen</code> fragt nach einem Speicherort (voreingestellt ist ''~/.ssh/id_rsa'') und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix ''.pub'' erhält.

			Nachdem Erstellen der Public Keys muss man noch die Rechte der beiden Dateien ändern, da man sie sonst nicht auf die DS kopieren kann. (regulär werden die Public Keys mit 0644 angelegt, was aber zu wenig restriktiv ist)
			Andernfalls würde man die Fehlermeldung: "Permissions 0644 for '/Users/USERNAME/.ssh/id_rsa' are too open."

			<pre>
			$ chmod 0600 ~/.ssh/id_rsa*
			</pre>

	=== Public Key auf der DS eintragen ===		=== Public Key auf der DS eintragen ===

imported>EL Duderino: kategorisiert

2013-05-01T16:30:06Z

kategorisiert

← Nächstältere Version		Version vom 1. Mai 2013, 16:30 Uhr
Zeile 1:		Zeile 1:
			[[Kategorie:SSH]]
	Viele Dinge kann man über das Webinterface der DS erledigen. Doch manchmal muss man mit root Rechten etwas an der Konsole fummeln und da gibt es nur zwei Möglichkeiten des Zugriffs		Viele Dinge kann man über das Webinterface der DS erledigen. Doch manchmal muss man mit root Rechten etwas an der Konsole fummeln und da gibt es nur zwei Möglichkeiten des Zugriffs
	* telnet (Port 23)		* telnet (Port 23)

imported>EL Duderino: /* Public Key auf der DS eintragen */ wiki links

2013-04-26T22:22:18Z

Public Key auf der DS eintragen: wiki links

← Nächstältere Version		Version vom 26. April 2013, 22:22 Uhr
Zeile 63:		Zeile 63:

	=== Public Key auf der DS eintragen ===		=== Public Key auf der DS eintragen ===
	Zum Schluss muss man jetzt also diesen Public Key String in die authorized_keys Datei des jeweiligen Users bringen. Wenn ihr ihn in der Zwischenablage habt und ein Tool wie Putty benutzt, dann kann man den Inhalt der Zwischenablage mittels eines Rechtsklicks an die Position des Cursors einfügen. Öffnet also die Datei in einem Editor ~~Eurer~~ Wahl (bei mir fast immer nano) und fügt den Inhalt ein		Zum Schluss muss man jetzt also diesen Public Key String in die authorized_keys Datei des jeweiligen Users bringen. Wenn ihr ihn in der Zwischenablage habt und ein Tool wie Putty benutzt, dann kann man den Inhalt der Zwischenablage mittels eines Rechtsklicks an die Position des Cursors einfügen. Öffnet also die Datei in einem [[Vergleich von Texteditoren\|Editor]] eurer Wahl (bei mir fast immer [[nano]]) und fügt den Inhalt ein
	<pre>		<pre>
	$ nano -w ~/.ssh/authorized_keys		$ nano -w ~/.ssh/authorized_keys
Zeile 70:		Zeile 70:
	</pre>		</pre>
	==== Mac OS X, Unix ====		==== Mac OS X, Unix ====
	Die Methode mit der Zwischenablage funktioniert auch hier, aber es ist viel eleganter, eine [~~http~~://de~~.wikipedia.org/wiki/Pipe_%28Informatik%29~~ Pipe] zur Übertragung des Public Key zu benutzen.		Die Methode mit der Zwischenablage funktioniert auch hier, aber es ist viel eleganter, eine [[wikipedia:de:Pipe (Informatik)\|Pipe]] zur Übertragung des Public Key zu benutzen.
	<pre>		<pre>
	$ cat ~/.ssh/id_rsa.pub \|ssh BenutzerName@NameOderIPderDiskStation "cat >> .ssh/authorized_keys"		$ cat ~/.ssh/id_rsa.pub \|ssh BenutzerName@NameOderIPderDiskStation "cat >> .ssh/authorized_keys"

imported>EL Duderino: /* Vorarbeiten für SSH mit Schlüsseln */

2012-12-14T15:50:00Z

Vorarbeiten für SSH mit Schlüsseln

← Nächstältere Version		Version vom 14. Dezember 2012, 15:50 Uhr
Zeile 9:		Zeile 9:

	== Vorarbeiten für SSH mit Schlüsseln ==		== Vorarbeiten für SSH mit Schlüsseln ==
	Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. '''Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.''' Sollte etwas schief gehen und telnet vorher nicht aktiviert worden sein, kann man bei neueren Versionen des DSM (> 4.0) sehr wahrscheinlich in der Weboberfläche nachholen, aber sicher ist sicher.		Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. '''Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.''' Sollte etwas schief gehen und telnet vorher nicht aktiviert worden sein, kann man das zwar bei neueren Versionen des DSM (> 4.0) sehr wahrscheinlich in der Weboberfläche nachholen, aber sicher ist sicher.

	=== Voraussetzungen ===		=== Voraussetzungen ===

imported>EL Duderino: Kleinere Präzisierungen, streamlining

2012-12-14T14:16:58Z

Kleinere Präzisierungen, streamlining

← Nächstältere Version		Version vom 14. Dezember 2012, 14:16 Uhr
Zeile 2:		Zeile 2:
	* telnet (Port 23)		* telnet (Port 23)
	* ssh (Port 22)		* ssh (Port 22)
	telnet ist okay wenn man aus dem LAN auf den Server zugreifen will, denn es ist nicht verschlüsselt ~~und damit werden~~ Login Daten unverschlüsselt übermittelt. Für Zugriffe von außerhalb des LAN ist es ~~jedoch~~ aus ~~Gründen der Sicherheit~~ nicht zu empfehlen.		telnet ist okay wenn man aus dem LAN auf den Server zugreifen will, denn es ist nicht verschlüsselt (wobei unter anderem Login-Daten unverschlüsselt übermittelt werden). Für Zugriffe von außerhalb des LAN ist es damit aus Sicherheitsgründen nicht zu empfehlen.

	Da kommt dann ssh zum Zuge. Dieses Protokoll verlangt eine Verschlüsselung. Auf der DS wird dazu OpenSSH eingesetzt. Der entscheidende Vorteil liegt auf der Hand: Die gesamte Verbindung vom Aufbau bis zum Ende ist durchgehend verschlüsselt. Dabei bietet ssh die klassische Anmeldung mit Username und Passwort, aber auch die Methode via Username und Private Key.		Da kommt dann ssh zum Zuge. Dieses Protokoll verlangt eine Verschlüsselung. Auf der DS wird dazu OpenSSH eingesetzt. Der entscheidende Vorteil liegt auf der Hand: Die gesamte Verbindung vom Aufbau bis zum Ende ist durchgehend verschlüsselt. Dabei bietet ssh die klassische Anmeldung mit Username und Passwort, aber auch die Methode via Username und Private Key.

	Setzt man die Private Key Methode ein, kann man OpenSSH auf der DiskStation so konfigurieren, dass es nicht mehr möglich ist mit Passwort auf die DS zuzugreifen. Damit laufen '''alle''' [http://de.wikipedia.org/wiki/Brute-Force-Methode Brute Force Attacken] ins Leere.		Setzt man die Private Key Methode ein, kann man OpenSSH auf der DiskStation so konfigurieren, dass es nicht mehr möglich ist mit Passwort auf die DS zuzugreifen. Damit laufen '''alle''' [http://de.wikipedia.org/wiki/Brute-Force-Methode Brute Force Attacken] ins Leere. Dieser Artikel erklärt, wie man die DiskStation und den Client konfigurieren kann, um sich (auch ausschließlich) mit einem Private Key auf der DiskStation anmelden zu können. Hier vorgestellte Clients sind einmal Windows mit Putty, und unixoide Betriebssysteme wie Mac OS X und Linux.

	== Vorarbeiten für SSH mit Schlüsseln ==		== Vorarbeiten für SSH mit Schlüsseln ==
	Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. '''Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.''' ~~Zumindest mit~~ DSM 4.~~1 ist das nicht nötig, da man~~ in der Weboberfläche ~~telnet bei Bedarf ein- und ausschalten kann.~~		Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. '''Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.''' Sollte etwas schief gehen und telnet vorher nicht aktiviert worden sein, kann man bei neueren Versionen des DSM (> 4.0) sehr wahrscheinlich in der Weboberfläche nachholen, aber sicher ist sicher.
	~~Ich würde trotzdem empfehlen den telnet Zugang im Voraus zu aktivieren und auch zu testen~~. ~~Nichts wäre übler als wenn man erst wenn SSH nicht mehr startet merkt, dass telnet sich (aus welchen Gründen auch immer) im DSM nicht aktvieren lässt ;-)~~

	=== Voraussetzungen ===		=== Voraussetzungen ===
Zeile 49:		Zeile 48:

	=== Schlüssel erstellen ===		=== Schlüssel erstellen ===
			Nun muss ein Schlüsselpaar erzeugt werden. Hier unterscheiden sich die Clients.
	==== Windows ====		==== Windows ====
	[[Bild:Ssh_key_1.jpg\|left\|thumb\|200px\|Erstellen eines Public-Private Key Pairs]]		[[Bild:Ssh_key_1.jpg\|left\|thumb\|200px\|Erstellen eines Public-Private Key Pairs]]
Zeile 60:		Zeile 60:
	<span style="display:block;clear:both;"></span>		<span style="display:block;clear:both;"></span>
	==== Mac OS X, Unix ====		==== Mac OS X, Unix ====
	~~Bei~~ unixoiden Betriebssystemen kann man das Kommandozeilenprogramm <code>ssh-keygen</code> zur Schlüsselgenerierung benutzen. Bei Mac OS X dazu das Programm '''Terminal''' ausführen und in der Shell den Befehl eingeben. ~~Das Programm~~ fragt nach ~~dem~~ Speicherort (voreingestellt ist ''~/.ssh/id_rsa'') und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix ''.pub'' erhält.		Unter unixoiden Betriebssystemen mit installiertem OpenSSH kann man das Kommandozeilenprogramm <code>ssh-keygen</code> zur Schlüsselgenerierung benutzen. Bei Mac OS X kann man dazu das Programm '''Terminal''' (im Order ''/Programme/Dienstprogramme'') ausführen und in der Shell den Befehl eingeben. <code>ssh-keygen</code> fragt nach einem Speicherort (voreingestellt ist ''~/.ssh/id_rsa'') und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix ''.pub'' erhält.

	=== Public Key auf der DS eintragen ===		=== Public Key auf der DS eintragen ===
Zeile 70:		Zeile 70:
	</pre>		</pre>
	==== Mac OS X, Unix ====		==== Mac OS X, Unix ====
	~~Benutzern einer Shell steht~~ mit ~~einer~~ [http://de.wikipedia.org/wiki/Pipe_%28Informatik%29 Pipe] ~~eine relativ elegant Möglichkeit offen, den~~ Public Key zu ~~übertragen~~.		Die Methode mit der Zwischenablage funktioniert auch hier, aber es ist viel eleganter, eine [http://de.wikipedia.org/wiki/Pipe_%28Informatik%29 Pipe] zur Übertragung des Public Key zu benutzen.
	<pre>		<pre>
	$ cat ~/.ssh/id_rsa.pub \|ssh BenutzerName@~~NameDerDiskStation~~ "cat >> .ssh/authorized_keys"		$ cat ~/.ssh/id_rsa.pub \|ssh BenutzerName@NameOderIPderDiskStation "cat >> .ssh/authorized_keys"
	<<Passwort-Abfrage>>		<<Passwort-Abfrage>>
	</pre>		</pre>
	Wichtig ist, den '''Public Key''' zu kopieren, erkennbar am Suffix ''.pub''. Dabei müssen ''BenutzerName'' und ''~~NameDerDiskStation~~'' (und gegebenenfalls ''~/.ssh/id_rsa.pub'') durch die passenden Werte ersetzt werden.		Wichtig ist, den '''Public Key''' zu kopieren, erkennbar am Suffix ''.pub''. Dabei müssen ''BenutzerName'' und ''NameOderIPderDiskStation'' (und gegebenenfalls ''~/.ssh/id_rsa.pub'') durch die passenden Werte ersetzt werden.
	Benutzer von Linux können stattdessen auch ein Auge auf den Befehl <code>ssh-copy-id</code> werfen.		Benutzer von Linux können stattdessen auch ein Auge auf den Befehl <code>ssh-copy-id</code> werfen.

	Alternativ kann man auch <code>scp</code> benutzen. Der Public Key muss dann aber auf der DiskStation manuell eingetragen werden.		Alternativ kann man auch <code>scp</code> benutzen. Der Public Key muss dann aber auf der DiskStation manuell eingetragen werden.
	<pre>		<pre>
	$ scp ~/.ssh/id_rsa.pub BenutzerName@~~NameDerDiskStation~~:/Pfad/zum/Home/		$ scp ~/.ssh/id_rsa.pub BenutzerName@NameOderIPderDiskStation:/Pfad/zum/Home/
	$ ssh Benutzer@~~NameDerDiskStation~~		$ ssh Benutzer@NameOderIPderDiskStation
	<<Passwort-Abfrage>>		<<Passwort-Abfrage>>
	$ cat id_rsa.pub >> .ssh/authorized_keys		$ cat id_rsa.pub >> .ssh/authorized_keys
Zeile 88:		Zeile 88:

	=== Backup Zugang für alle Fälle ===		=== Backup Zugang für alle Fälle ===
	~~Mit DSM 4.1 ist das in der Regel nicht nötig.~~
	<span style="color:red;font-variant:small-caps;font-size:1.2em;border-color:red;border-style:dotted;display:block;padding:10px;">		<span style="color:red;font-variant:small-caps;font-size:1.2em;border-color:red;border-style:dotted;display:block;padding:10px;">
	Als Backup Zugang für alle SSH Experimente bietet sich telnet an. Wie man diesen Zugang aktiviert steht hier im Wiki, drum gehe ich nicht näher darauf ein. Der Backup Zugang ist wichtig, 1) weil es sein kann, dass die ssh Verbindung beim Aufrufen des ssh Startscripts abreist und der Dämon dann nicht neugestartet wird und 2) weil eine Fehlkonfig in der sshd_conf oder authorized_keys Datei den Start des SSH Dämons komplett verhindern könnte. Also ist es besser ein telnet-Hintertürchen zu haben, falls was schief geht.</span>		Als Backup Zugang für alle SSH Experimente bietet sich telnet an. Wie man diesen Zugang aktiviert steht hier im Wiki, drum gehe ich nicht näher darauf ein. Der Backup Zugang ist wichtig, 1) weil es sein kann, dass die ssh Verbindung beim Aufrufen des ssh Startscripts abreist und der Dämon dann nicht neugestartet wird und 2) weil eine Fehlkonfig in der sshd_conf oder authorized_keys Datei den Start des SSH Dämons komplett verhindern könnte. Also ist es besser ein telnet-Hintertürchen zu haben, falls was schief geht.</span>
Zeile 100:		Zeile 99:
	Damit sollte der Daemon neugestartet sein und auf Anfragen warten.		Damit sollte der Daemon neugestartet sein und auf Anfragen warten.
	=== Windows ===		=== Windows ===
	Zum Testen der PubKey Anmeldung verwendet ihr am besten wieder Putty. Erstellt bei Putty und Hostname eine Verbindung in der Art '''~~user~~@~~IP_DER_DS~~''' und BEVOR ihr auf Verbinden klickt stellt ihr noch den Schlüssel für die Verbindung in Putty unter SSH-->Auth. Dort klickt ihr auf Browse und gebt den Pfad zum Privaten Schlüssel an. Wenn das gemacht ist, klickt ihr auf Connect und die Shell sollte den Username aus dem Hostnamen übernehmen. Dann sollte eine Abfrage nach dem Passwort des Private Key kommen.		Zum Testen der PubKey Anmeldung verwendet ihr am besten wieder Putty. Erstellt bei Putty und Hostname eine Verbindung in der Art '''BenutzerName@NameOderIPderDiskStation''' und BEVOR ihr auf Verbinden klickt stellt ihr noch den Schlüssel für die Verbindung in Putty unter SSH-->Auth. Dort klickt ihr auf Browse und gebt den Pfad zum Privaten Schlüssel an. Wenn das gemacht ist, klickt ihr auf Connect und die Shell sollte den Username aus dem Hostnamen übernehmen. Dann sollte eine Abfrage nach dem Passwort des Private Key kommen.
	=== Mac OS X, Unix ===		=== Mac OS X, Unix ===
	Hier kann man auf der Kommandozeile <code>ssh ~~user~~@~~IP_DER_DS~~ -i [Pfad zum Private Key]</code> ausführen. Ist der Private Key an der Standardstelle ''.ssh/id_rsa'', kann der Parameter <code>-i</code> samt Pfad auch entfallen. Beim ersten Ausführen kommt eine Passwortabfrage für den Private Key.		Hier kann man auf der Kommandozeile <code>ssh BenutzerName@NameOderIPderDiskStation -i [Pfad zum Private Key]</code> ausführen. Ist der Private Key an der Standardstelle ''~/.ssh/id_rsa'', kann der Parameter <code>-i</code> samt Pfad auch entfallen. Beim ersten Ausführen kommt eine Passwortabfrage für den Private Key.
	<span style="margin-top:20px;color:red;font-variant:small-caps;font-size:1.2em;border-color:red;border-style:dotted;display:block;padding:10px;">		<span style="margin-top:20px;color:red;font-variant:small-caps;font-size:1.2em;border-color:red;border-style:dotted;display:block;padding:10px;">
	Die Frage nach dem Passwort kommt nicht von der DS, sondern von Putty bzw. dem lokalen ssh. Das Passwort des Private Key wird natürlich nicht an die DS übermittelt sondern dient nur der lokalen Kontrolle des Schlüssels auf dem Client</span>		Die Frage nach dem Passwort kommt nicht von der DS, sondern von Putty bzw. dem lokalen ssh. Das Passwort des Private Key wird natürlich nicht an die DS übermittelt sondern dient nur der lokalen Kontrolle des Schlüssels auf dem Client</span>
Zeile 115:		Zeile 114:

	=== Passwort des Private Key speichern ===		=== Passwort des Private Key speichern ===
	Wenn man zu faul ist, das Passwort des Private Key ~~bei der Anmeldung~~ angeben zu müssen, gibt es Mittel und Wege		Wenn man zu faul ist, bei jeder Verbindung zur DiskStation das Passwort des Private Key angeben zu müssen, gibt es Mittel und Wege.
	==== Windows ====		==== Windows ====
	Hier kann man ein Tool wie Paegant (ist beim Putty zip File dabei) benutzen. Dort lädt man den Private Key und gibt zur Authentifizierung des Passwort an. Wenn man jetzt in Putty eine Verbindung auf '''~~user~~@~~IP_DER_DS~~''' öffnet landet man ohne weiteres direkt auf der Shell. Denn Putty arbeitet mit Peagant zusammen und holt sich die Schlüssel von dort. Damit wird es für Putty überflüssig nach dem PW zu fragen, hat Peagant ja bereits gemacht.		Hier kann man ein Tool wie Paegant (ist beim Putty zip File dabei) benutzen. Dort lädt man den Private Key und gibt zur Authentifizierung des Passwort an. Wenn man jetzt in Putty eine Verbindung auf '''BenutzerName@NameOderIPderDiskStation''' öffnet landet man ohne weiteres direkt auf der Shell. Denn Putty arbeitet mit Peagant zusammen und holt sich die Schlüssel von dort. Damit wird es für Putty überflüssig nach dem PW zu fragen, hat Peagant ja bereits gemacht.
	==== Mac OS X ====		==== Mac OS X ====
	~~Unter OS X~~ kann man im Terminal		Apple hat OpenSSH so erweitert, daß das Passwort des Private Key im benutzereigenen Schlüsselbund gespeichert werden kann (dieser ist mit dem Programm '''Schlüsselbundverwaltung''' im Ordner ''/Programme/Dienstprogramme'' einseh- und veränderbar). Dazu führt man im Terminal
	<pre>		<pre>
	$ ssh-add -K [Pfad zum Private Key]		$ ssh-add -K [Pfad zum Private Key]
	</pre>		</pre>
	~~ausführen~~. Ist der Private Key in ''.ssh/id_rsa'', kann die Pfadangabe entfallen. Das dann einzugebende Passwort des Private Key wird im Schlüsselbund '''Anmeldung''' gesichert.		aus. Ist der Private Key in ''~/.ssh/id_rsa'', kann die Pfadangabe entfallen. Das dann einzugebende Passwort des Private Key wird im Schlüsselbund '''Anmeldung''' gesichert und ist damit nach jedem Benutzer-Login ohne weitere Passwortabfrage verfügbar.

	== Hintergrund ==		== Hintergrund ==

imported>Jahlives: /* Vorarbeiten für SSH mit Schlüsseln */

2012-10-09T16:27:15Z

Vorarbeiten für SSH mit Schlüsseln

← Nächstältere Version		Version vom 9. Oktober 2012, 16:27 Uhr
Zeile 10:		Zeile 10:
	== Vorarbeiten für SSH mit Schlüsseln ==		== Vorarbeiten für SSH mit Schlüsseln ==
	Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. '''Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.''' Zumindest mit DSM 4.1 ist das nicht nötig, da man in der Weboberfläche telnet bei Bedarf ein- und ausschalten kann.		Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. '''Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.''' Zumindest mit DSM 4.1 ist das nicht nötig, da man in der Weboberfläche telnet bei Bedarf ein- und ausschalten kann.
			Ich würde trotzdem empfehlen den telnet Zugang im Voraus zu aktivieren und auch zu testen. Nichts wäre übler als wenn man erst wenn SSH nicht mehr startet merkt, dass telnet sich (aus welchen Gründen auch immer) im DSM nicht aktvieren lässt ;-)

	=== Voraussetzungen ===		=== Voraussetzungen ===