Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
centos:ssh-install [12.11.2016 21:04. ] – [Erzeugung eines Schlüssel] django | centos:ssh-install [13.11.2016 16:46. ] – [Zielverzeichnis anlegen und öffentlichen Schlüssel kopieren] django | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Secure Shell - ssh ====== | ====== Secure Shell - ssh ====== | ||
- | {{: | + | {{: |
===== openSSH - Programmsuite ===== | ===== openSSH - Programmsuite ===== | ||
Zeile 1011: | Zeile 1011: | ||
===== ssh in der Praxis ===== | ===== ssh in der Praxis ===== | ||
- | Auch wenn das Passwort | + | Auch wenn Passworte |
- | Einfacher geht dies über asymetrische | + | |
- | ==== Erzeugung | + | - Wir werden Key-basierte Anmeldungen verwenden und **__keine__** Anmeldungen mit Passwort |
- | Als erstes erzeugen | + | |
- | < | + | |
- | Generating public/ | + | |
- | Enter file in which to save the key (/ | + | |
- | Enter passphrase (empty for no passphrase): | + | |
- | Enter same passphrase again: | + | |
- | Your identification has been saved in / | + | |
- | Your public key has been saved in / | + | |
- | The key fingerprint is: | + | |
- | 2b: | + | |
- | Oder die Erstellung eines [[http:// | ||
- | $ ssh-keygen -t ed25519 -o -a 100 -C django@nausch.org -f ~/ | ||
+ | Zum Erstellen eines Schlüsselpaares nutzen wir das Programm **ssh-keygen**. Einen Überberlick über die möglichen Optionen erhalten wir beim Abruf der zugehörigen **manpage**. | ||
+ | # man ssh-keygen | ||
- | Die // | + | < |
- | Nun liegen in dem Verzeichnis **/ | + | NAME |
- | < | + | |
- | insgesamt 24 | + | |
- | -rw------- 1 django django 3311 22. Apr 22:11 id_rsa | + | |
- | -rw-r--r-- 1 django django | + | |
- | **id_rsa** enthält den privaten Schlüssel und sollte auf keinen Fall weitergegeben werden und darf auch __nur__ für den Nutzer selbst lesbar sein! **id_rsa.pub**, der öffentliche Schlüssel, dagegen muss auf den Zielrechner kopiert werden. | + | SYNOPSIS |
- | ==== Zielverzeichnis anlegen und öffentlichen Schlüssel kopieren | + | |
- | Auf dem Zielrechner legen wir nun das Verzeichnis **.ssh** an und schützen es entsprechend. | + | |
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | [-K checkpt] [-W generator] | ||
+ | | ||
+ | [-V validity_interval] [-z serial_number] file ... | ||
+ | ssh-keygen -L [-f input_keyfile] | ||
+ | ssh-keygen -A | ||
+ | | ||
+ | ssh-keygen -Q -f krl_file file ... | ||
- | [django@zielhost django]$ mkdir .ssh | + | DESCRIPTION |
- | | + | |
+ | RSA keys for use by SSH protocol version 1 and DSA, ECDSA, ED25519 or RSA keys for use by SSH pro‐ | ||
+ | tocol version 2. The type of key to be generated is specified with the -t option. If invoked | ||
+ | | ||
- | Den öffentlichen Schlüssel kopieren wir dann wie folgt auf das Zielsystem: | + | |
- | [django@host | + | the MODULI GENERATION section for details. |
- | Anschließend wird der Schlüssel in die Datei authorized_keys kopiert. Diese Datei kann mehrere Schlüssel enthalten, daher ist das doppelte Umleitungszeichen wichtig, um eine evt. existierende Datei nicht versehentlich zu überschreiben. Somit wird der neue Schlüssel in die Datei hinzugefügt: | + | |
- | | + | given keys have been revoked by one. |
- | Zu guter Letzt passen wir noch die Berechtigungen an und löschen die nicht mehr benötigte **id_rsa.pub** | + | |
- | [django@zielhost .ssh]$ chmod 600 authorized_keys | + | |
- | [django@zielhost .ssh]$ rm id_rsa.pub | + | |
- | <WRAP round info>Das Kopieren des Public-Keys auf unseren Zielhost mit Anpassen der Dateiberechtigungen kann man natürlich auch einfacher vornehmen. Man benutzt hierzu einfach den Befehl **ssh-copy-id** aus dem Paket //**openssh-clients**//. | + | |
+ | | ||
+ | | ||
+ | | ||
- | $ ssh-copy-id -i ~/.ssh/id_rsa.pub testhost.intra.nausch.org | + | |
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | of characters you want. Good passphrases are 10-30 characters long, are not simple sentences or | ||
+ | | ||
+ | very bad passphrases), | ||
+ | meric characters. | ||
- | Die Angabe '' | + | There is no way to recover a lost passphrase. |
- | '' | + | must be generated and the corresponding public key copied to other machines. |
- | </WRAP> | + | |
- | ==== authorized_keys | + | For RSA1 keys, there is also a comment field in the key file that is only for convenience to the |
- | <WRAP round tip>Bei der Einführung von SSH Version | + | user to help identify the key. The comment can tell what the key is for, or whatever is useful. |
+ | The comment is initialized to “user@host” when the key is created, but can be changed using the -c | ||
+ | | ||
+ | |||
+ | After a key is generated, instructions below detail where the keys should be placed to be acti‐ | ||
+ | | ||
+ | |||
+ | The options are as follows: | ||
+ | |||
+ | | ||
+ | | ||
+ | bits for the key type, and default comment. | ||
+ | | ||
+ | |||
+ | -a rounds | ||
+ | When saving a new-format private key (i.e. an ed25519 key or any SSH protocol 2 key when | ||
+ | the -o flag is set), this option specifies the number of KDF (key derivation function) | ||
+ | | ||
+ | tance to brute-force password cracking (should the keys be stolen). | ||
+ | |||
+ | When screening DH-GEX candidates ( using the -T command). | ||
+ | of primality tests to perform. | ||
+ | |||
+ | | ||
+ | |||
+ | -b bits | ||
+ | | ||
+ | bits and the default is 2048 bits. Generally, 2048 bits is considered sufficient. | ||
+ | keys must be exactly 1024 bits as specified by FIPS 186-2. | ||
+ | | ||
+ | 521 bits. Attempting to use bit lengths other than these three values for ECDSA keys will | ||
+ | | ||
+ | |||
+ | -C comment | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | for the passphrase if the key has one, and for the new comment. | ||
+ | |||
+ | -D pkcs11 | ||
+ | | ||
+ | | ||
+ | the CERTIFICATES section for details). | ||
+ | |||
+ | | ||
+ | one of the formats specified by the -m option. | ||
+ | This option allows exporting OpenSSH keys for use by other programs, including several com‐ | ||
+ | | ||
+ | |||
+ | -F hostname | ||
+ | | ||
+ | This option is useful to find hashed host names or addresses and may also be used in con‐ | ||
+ | | ||
+ | |||
+ | -f filename | ||
+ | | ||
+ | |||
+ | -G output_file | ||
+ | | ||
+ | -T option) before use. | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | tions within the specified file; the original content is moved to a file with a .old suf‐ | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | the CERTIFICATES section for details. | ||
+ | |||
+ | -I certificate_identity | ||
+ | | ||
+ | for details. | ||
+ | |||
+ | | ||
+ | by the -m option and print an OpenSSH compatible private (or public) key to stdout. | ||
+ | |||
+ | -J num_lines | ||
+ | Exit after screening the specified number of lines while performing DH candidate screening | ||
+ | using the -T option. | ||
+ | |||
+ | -j start_line | ||
+ | Start screening at the specified line number while performing DH candidate screening using | ||
+ | the -T option. | ||
+ | |||
+ | -K checkpt | ||
+ | Write the last line processed to the file checkpt while performing DH candidate screening | ||
+ | using the -T option. | ||
+ | been processed if the job is restarted. | ||
+ | ware, including several commercial SSH implementations. | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | RSA and DSA keys ssh-keygen tries to find the matching public key file and prints its fin‐ | ||
+ | | ||
+ | | ||
+ | |||
+ | -M memory | ||
+ | | ||
+ | | ||
+ | |||
+ | -m key_format | ||
+ | | ||
+ | key formats are: “RFC4716” (RFC 4716/SSH2 public or private key), “PKCS8” (PEM PKCS8 public | ||
+ | key) or “PEM” (PEM public key). The default conversion format is “RFC4716”. | ||
+ | |||
+ | -N new_passphrase | ||
+ | | ||
+ | |||
+ | -n principals | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | -O option | ||
+ | | ||
+ | | ||
+ | user certificates are: | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | user when the certificate is used for authentication. | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | At present, no options are valid for host keys. | ||
+ | |||
+ | | ||
+ | than the more compatible PEM format. | ||
+ | force password cracking but is not supported by versions of OpenSSH prior to 6.5. Ed25519 | ||
+ | keys always use the new private key format. | ||
+ | |||
+ | -P passphrase | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | | ||
+ | |||
+ | -R hostname | ||
+ | | ||
+ | | ||
+ | |||
+ | -r hostname | ||
+ | Print the SSHFP fingerprint resource record named hostname for the specified public key | ||
+ | | ||
+ | |||
+ | -S start | ||
+ | | ||
+ | |||
+ | -s ca_key | ||
+ | | ||
+ | tion for details. | ||
+ | |||
+ | When generating a KRL, -s specifies a path to a CA public key file used to revoke certifi‐ | ||
+ | cates directly by key ID or serial number. | ||
+ | | ||
+ | |||
+ | -T output_file | ||
+ | Test DH group exchange candidate primes (generated using the -G option) for safety. | ||
+ | |||
+ | -t type | ||
+ | | ||
+ | and “dsa”, “ecdsa”, | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | -V validity_interval | ||
+ | | ||
+ | a single time, indicating that the certificate is valid beginning now and expiring at that | ||
+ | time, or may consist of two times separated by a colon to indicate an explicit time inter‐ | ||
+ | | ||
+ | MMSS format or a relative time (to the current time) consisting of a minus sign followed by | ||
+ | a relative time in the format described in the TIME FORMATS section of sshd_config(5). | ||
+ | end time may be specified as a YYYYMMDD date, a YYYYMMDDHHMMSS time or a relative time | ||
+ | | ||
+ | |||
+ | For example: “+52w1d” (valid from now to 52 weeks and one day from now), “-4w: | ||
+ | from four weeks ago to four weeks from now), “20100101123000: | ||
+ | 12:30 PM, January 1st, 2010 to 12:30 PM, January 1st, 2011), “-1d: | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | -W generator | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | -z serial_number | ||
+ | | ||
+ | from others from the same CA. The default serial number is zero. | ||
+ | |||
+ | When generating a KRL, the -z flag is used to specify a KRL version number. | ||
+ | |||
+ | MODULI GENERATION | ||
+ | | ||
+ | | ||
+ | but memory intensive process. | ||
+ | sive process). | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | # ssh-keygen -G moduli-2048.candidates -b 2048 | ||
+ | |||
+ | By default, the search for primes begins at a random point in the desired length range. | ||
+ | be overridden using the -S option, which specifies a different start point (in hex). | ||
+ | |||
+ | Once a set of candidates have been generated, they must be screened for suitability. | ||
+ | | ||
+ | (or a file specified using the -f option). | ||
+ | |||
+ | # ssh-keygen -T moduli-2048 -f moduli-2048.candidates | ||
+ | |||
+ | By default, each candidate will be subjected to 100 primality tests. | ||
+ | the -a option. | ||
+ | | ||
+ | tor values are 2, 3, and 5. | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | CERTIFICATES | ||
+ | | ||
+ | | ||
+ | | ||
+ | (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certifi‐ | ||
+ | cate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and | ||
+ | much simpler, format to the X.509 certificates used in ssl(8). | ||
+ | |||
+ | | ||
+ | to servers, whereas host certificates authenticate server hosts to users. | ||
+ | | ||
+ | |||
+ | $ ssh-keygen -s / | ||
+ | |||
+ | The resultant certificate will be placed in / | ||
+ | | ||
+ | |||
+ | $ ssh-keygen -s / | ||
+ | |||
+ | The host certificate will be output to / | ||
+ | |||
+ | It is possible to sign using a CA key stored in a PKCS#11 token by providing the token library | ||
+ | using -D and identifying the CA key by providing its public half as an argument to -s: | ||
+ | |||
+ | $ ssh-keygen -s ca_key.pub -D libpkcs11.so -I key_id host_key.pub | ||
+ | |||
+ | In all cases, key_id is a "key identifier" | ||
+ | used for authentication. | ||
+ | |||
+ | | ||
+ | | ||
+ | set of principals: | ||
+ | |||
+ | $ ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub | ||
+ | $ ssh-keygen -s ca_key -I key_id -h -n host.domain user_key.pub | ||
+ | |||
+ | | ||
+ | | ||
+ | when presented from particular source addresses or may force the use of a specific command. | ||
+ | list of valid certificate options, see the documentation for the -O option above. | ||
+ | |||
+ | | ||
+ | of certificate start and end times. | ||
+ | will not be considered valid. | ||
+ | | ||
+ | |||
+ | For certificates to be used for user or host authentication, | ||
+ | | ||
+ | |||
+ | KEY REVOCATION LISTS | ||
+ | | ||
+ | ify keys or certificates to be revoked using a compact format, taking as little as one bit per cer‐ | ||
+ | | ||
+ | |||
+ | KRLs may be generated using the -k flag. This option reads one or more files from the command line | ||
+ | and generates a new KRL. The files may either contain a KRL specification (see below) or public | ||
+ | keys, listed one per line. Plain public keys are revoked by listing their hash or contents in the | ||
+ | KRL and certificates revoked by serial number or key ID (if the serial is zero or not available). | ||
+ | |||
+ | | ||
+ | | ||
+ | ing the complete original certificate on hand. A KRL specification consists of lines containing | ||
+ | one of the following directives followed by a colon and some directive-specific information. | ||
+ | |||
+ | | ||
+ | | ||
+ | not including zero and may be expressed in decimal, hex or octal. | ||
+ | are specified separated by a hyphen, then the range of serial numbers including and between | ||
+ | each is revoked. | ||
+ | the -s option. | ||
+ | |||
+ | id: key_id | ||
+ | | ||
+ | fied on the ssh-keygen command line using the -s option. | ||
+ | |||
+ | key: public_key | ||
+ | | ||
+ | lic key. | ||
+ | |||
+ | sha1: public_key | ||
+ | | ||
+ | |||
+ | KRLs may be updated using the -u flag in addition to -k. When this option is specified, keys | ||
+ | | ||
+ | |||
+ | It is also possible, given a KRL, to test whether it revokes a particular key (or keys). | ||
+ | flag will query an existing KRL, testing each key specified on the commandline. | ||
+ | on the command line has been revoked (or an error encountered) then ssh-keygen will exit with a | ||
+ | | ||
+ | |||
+ | FILES | ||
+ | ~/.ssh/ | ||
+ | Contains the protocol version 1 RSA authentication identity of the user. This file should | ||
+ | not be readable by anyone but the user. It is possible to specify a passphrase when gener‐ | ||
+ | ating the key; that passphrase will be used to encrypt the private part of this file using | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | file should be added to ~/.ssh/authorized_keys | ||
+ | in using RSA authentication. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | a passphrase when generating the key; that passphrase will be used to encrypt the private | ||
+ | part of this file using 128-bit AES. This file is not automatically accessed by ssh-keygen | ||
+ | but it is offered as the default file for the private key. ssh(1) will read this file when | ||
+ | a login attempt is made. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | The contents of this file should be added to ~/ | ||
+ | the user wishes to log in using public key authentication. | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | | ||
+ | file should be added to ~/ | ||
+ | in using RSA authentication. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | a passphrase when generating the key; that passphrase will be used to encrypt the private | ||
+ | part of this file using 128-bit AES. This file is not automatically accessed by ssh-keygen | ||
+ | but it is offered as the default file for the private key. ssh(1) will read this file when | ||
+ | a login attempt is made. | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | The contents of this file should be added to ~/ | ||
+ | the user wishes to log in using public key authentication. | ||
+ | | ||
+ | |||
+ | / | ||
+ | | ||
+ | |||
+ | ENVIRONMENT | ||
+ | | ||
+ | The reseeding of the OpenSSL random generator is usually done from / | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | SEE ALSO | ||
+ | | ||
+ | |||
+ | The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006. | ||
+ | |||
+ | AUTHORS | ||
+ | | ||
+ | bell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt and Dug Song removed many bugs, re-added | ||
+ | newer features and created | ||
+ | sions 1.5 and 2.0. | ||
+ | |||
+ | BSD | ||
+ | </ | ||
+ | |||
+ | Bevor wir uns die Entscheidung treffen können, welchen Schlüssel-Typ wir erzeugen wollen, müssen wir überlegen, von welchem System wir aus auf unseren Linux/ | ||
+ | |||
+ | Hier empfiehlt es sich auf den beteiligten System zu überprüfen, | ||
- | ==== Interoperabilität ==== | ||
=== Liste der unterstützten Cipher === | === Liste der unterstützten Cipher === | ||
# ssh -Q cipher | # ssh -Q cipher | ||
Zeile 1106: | Zeile 1577: | ||
umac-128-etm@openssh.com</ | umac-128-etm@openssh.com</ | ||
- | === Liste der unterstütznen | + | === Liste der unterstützten |
# ssh -Q key | # ssh -Q key | ||
< | < | ||
Zeile 1138: | Zeile 1609: | ||
gss-group1-sha1- | gss-group1-sha1- | ||
gss-group14-sha1-</ | gss-group14-sha1-</ | ||
+ | |||
+ | |||
+ | ==== Erzeugung eines Schlüsselpäärchens | ||
+ | === RSA Key === | ||
+ | Im ersten Beispiel erzeugen wir uns einen 4096er RSA-Schlüssel für die Authentifizierung: | ||
+ | $ ssh-keygen -b 4096 -t rsa -C django@nausch.org -f ~/ | ||
+ | |||
+ | < | ||
+ | Enter passphrase (empty for no passphrase): | ||
+ | Enter same passphrase again: | ||
+ | Your identification has been saved in / | ||
+ | Your public key has been saved in / | ||
+ | The key fingerprint is: | ||
+ | 44: | ||
+ | The key's randomart image is: | ||
+ | +--[ RSA 4096]----+ | ||
+ | | ... | | ||
+ | | o.o . | | ||
+ | | +.o o | | ||
+ | | ..+= . | | ||
+ | | | ||
+ | | + . | | ||
+ | | +.. . | | ||
+ | | . *E | | ||
+ | | ++=o | | ||
+ | +-----------------+</ | ||
+ | |||
+ | |||
+ | Die // | ||
+ | |||
+ | Nun liegen in dem Verzeichnis **/ | ||
+ | # ll ~/ | ||
+ | < | ||
+ | -rw-r--r--. 1 django django | ||
+ | |||
+ | **id_rsa4096_dmz** enthält den privaten Schlüssel und sollte auf keinen Fall weitergegeben werden und darf auch __nur__ für den Nutzer selbst lesbar sein! **id_rsa4096_dmz.pub**, | ||
+ | |||
+ | === ED25519 Key === | ||
+ | Ob man in Zeiten von Überwachungsphantasten bei einer NSA oder BND, noch solhcen Schlüssel einsetzen kann und mag, muss natürlich jeder Admin für sich sekbst entscheiden. Auf solche Schlüssel muss man aber nicht mehr zwingend zurückgreifen, | ||
+ | $ ssh-keygen -t ed25519 -o -a 100 -C django@nausch.org -f ~/ | ||
+ | |||
+ | < | ||
+ | Enter passphrase (empty for no passphrase): | ||
+ | Enter same passphrase again: | ||
+ | Your identification has been saved in / | ||
+ | Your public key has been saved in / | ||
+ | The key fingerprint is: | ||
+ | a3: | ||
+ | The key's randomart image is: | ||
+ | +--[ED25519 | ||
+ | | *o | | ||
+ | | o + +. | | ||
+ | | + = o | | ||
+ | | * o | | ||
+ | | + . S | | ||
+ | | + = o | | ||
+ | | = + | | ||
+ | | Eo o | | ||
+ | | ...o . | | ||
+ | +-----------------+</ | ||
+ | |||
+ | Die // | ||
+ | |||
+ | Nun liegen in dem Verzeichnis **/ | ||
+ | # ll ~/ | ||
+ | < | ||
+ | -rw-r--r--. 1 django django | ||
+ | |||
+ | **id_ed25519_dmz** enthält den privaten Schlüssel und sollte auf keinen Fall weitergegeben werden und darf auch __nur__ für den Nutzer selbst lesbar sein! **id_ed25519_dmz.pub**, | ||
+ | ==== Zielverzeichnis anlegen und öffentlichen Schlüssel kopieren | ||
+ | Auf dem Zielrechner legen wir nun das Verzeichnis **.ssh** an und schützen es entsprechend. | ||
+ | |||
+ | [django@zielhost django]$ mkdir .ssh | ||
+ | [django@zielhost django]$ chmod 700 .ssh | ||
+ | |||
+ | Den öffentlichen Schlüssel kopieren wir dann wie folgt auf das Zielsystem; hatten wir uns einen RSA-key erstellt verwenden wir folgenden Aufruf: | ||
+ | | ||
+ | bzw. bei einem ed25519 Schlüssel: | ||
+ | | ||
+ | |||
+ | Anschliessend wird der Schlüssel in die Datei authorized_keys kopiert. Diese Datei kann mehrere Schlüssel enthalten, daher ist das doppelte Umleitungszeichen wichtig, um eine evt. existierende Datei nicht versehentlich zu überschreiben. Somit wird der neue Schlüssel in die Datei hinzugefügt: | ||
+ | $ cat key.pub >> authorized_keys | ||
+ | Zu guter Letzt passen wir noch die Berechtigungen an und löschen die nicht mehr benötigte **id_rsa.pub** | ||
+ | $ chmod 600 authorized_keys | ||
+ | $ rm key.pub | ||
+ | |||
+ | <WRAP round info>Das Kopieren des Public-Keys auf unseren Zielhost mit Anpassen der Dateiberechtigungen kann man natürlich auch einfacher vornehmen. Man benutzt hierzu einfach den Befehl **ssh-copy-id** aus dem Paket // | ||
+ | |||
+ | * RSA-Key < | ||
+ | * ed25519-Key < | ||
+ | |||
+ | Mit der Angabe '' | ||
+ | </ | ||
+ | ==== authorized_keys vs. authorized_keys2 ==== | ||
+ | <WRAP round tip>Bei der Einführung von SSH Version 2 kam die Datei '' | ||
+ | |||
===== ssh-Daemon ===== | ===== ssh-Daemon ===== |