SSH-Authentifizierung mit Schlüsselpaaren: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
Pjotr (Diskussion | Beiträge)
33 Bearbeitungen
Die Seite wurde neu angelegt: „= What are SSH Keys? = By using SSH Keys (a public and private key to be precise), you can easily connect to a server, or multiple servers, without having to ent…“
 
KKeine Bearbeitungszusammenfassung
 
(23 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
= What are SSH Keys? =
{{righttoc}}
Wenn man [[SSH]]-Schlüsselpaare (einen öffentlichen und privaten Schlüssel) benutzt, kann man einfach und sicher eine SSH-Verbindung zu einem Server herstellen, ohne ein Passwort für eines der Systeme eingeben zu müssen.


By using SSH Keys (a public and private key to be precise), you can easily connect to a server, or multiple servers, without having to enter your password for each system.
Es ist möglich, diese Schlüssel ohne ein Passwort einzurichten, jedoch ist es sicherer, eines zu benutzen, für den Fall, dass ungewollt ein Dritter an diesen Schlüssel kommt. Deshalb beschreibt diese Anleitung auch, wie man das benutzte Passwort sicher auf seinem System speichern kann.


It is possible to setup your keys without a passphrase, however that is unwise as if anyone gets hold of your key they can use it. This guide describes how to setup your system so that passphrases are remembered securely.
=== Ein Schlüsselpaar erzeugen ===


== Generating SSH Keys ==
Wenn OpenSSH noch nicht installiert worden ist, muss dies jetzt nachgeholt werden:


If you don't already have OpenSSH installed, install it now as it is not installed by default on Arch.
# pacman -S openssh
 
Danach kann das Schlüsselpaar mit folgendem Befehl erzeugt werden:
 
$ ssh-keygen -b 4096


# pacman -S openssh
Dabei wird ein 4096 Bit langer (<code>-b 4096</code>) Schlüssel erzeugt. 4096 ist die maximale Länge eines Schlüssels.


The keys can then be generated by running the ssh-keygen command as a user:
Ein ähnlicher Output wie dieser sollte folgen:


$ ssh-keygen -b 1024 -t dsa
  Generating public/private rsa key pair.
  Generating public/private dsa key pair.
  Enter file in which to save the key (/home/mith/.ssh/id_rsa):
  Enter file in which to save the key (/home/mith/.ssh/id_dsa):
  Enter passphrase (empty for no passphrase):
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Enter same passphrase again:
  Your identification has been saved in /home/mith/.ssh/id_dsa.
  Your identification has been saved in /home/mith/.ssh/id_rsa.
  Your public key has been saved in /home/mith/.ssh/id_dsa.pub.
  Your public key has been saved in /home/mith/.ssh/id_rsa.pub.
  The key fingerprint is:
  The key fingerprint is:
  x6:68:xx:93:98:8x:87:95:7x:2x:4x:x9:81:xx:56:94 mith@middleearth
  x6:68:xx:93:98:8x:87:95:7x:2x:4x:x9:81:xx:56:94 mith@middleearth


It will prompt you for a location (which you should leave as the default), however the passphrase is the important bit! You should already be aware of the criteria that make a good passphrase.
Wie hier zu sehen ist, wird man zuerst gefragt, wo der Schlüssel gespeichert werden soll (wobei es bei der Standardeingabe belassen werden sollte). Danach kommt die wichtigste Eingabe: das Passwort. Was ein sicheres Passwort ist, kann in diesem [http://de.wikipedia.org/wiki/Passwort Wikipedia-Artikel] nachgelesen werden.
 
So what did we just do? We generated a 1024 bit long ({{Codeline|-b 1024}}) public/private dsa ({{Codeline|-t dsa}}) key pair with the {{Codeline|ssh-keygen}} command.
 
If you want to create a RSA key pair instead of DSA just use {{Codeline|-t rsa}} (do not specify key length "-b" as default key length for RSA is 2048 and is sufficient).
 
{{Note|A DSA key has to be exactly 1024 bits as per specification. A RSA key can be between 768 bits and 4096 bits.}}


== Copying the keys to the remote server ==  
=== Übertragen der Schlüssel zum SSH-Server ===  


Now you have generated the keys you need to copy them to the remote server. By default, for OpenSSH, the public key needs to be concatenated into {{Filename|~/.ssh/authorized_keys}}.
Nachdem die benötigten Schlüsselpaare erzeugt wurden, müssen deren öffentlichen Schlüssel zum SSH-Server übertragen werden. Standardmäßig werden diese unter '''~/.ssh/authorized_keys''' gespeichert.


  $ scp ~/.ssh/id_dsa.pub mith@metawire.org:
  $ scp ~/.ssh/id_rsa.pub user@archlinux.de:


This copies the public key ({{Filename|id_dsa.pub}}) to your remote server via {{Codeline|scp}} (note the {{Codeline|:}} at the end of the server address). The file ends up in the home directory, but you can specify another path if you like.
Dies kopiert den öffentlichen Schlüssel mit dem Namen ''id_rsa.pub'' in den Home-Ordner des Users ''user'' auf dem Server ''archlinux.de''.


Next up, on the remote server, you need to create the {{Filename|~/.ssh}} directory if it doesn't exist and concatenate the key {{Filename|authorized_keys}} file:
Nun muss sich zuerst auf dem SSH-Server eingeloggt und dann die Schlüssel in das richtige Verzeichnis kopiert werden. In unserem Beispiel existieren die Ordner dafür noch nicht und müssen zuerst angelegt werden:


  $ ssh mith@metawire.org
  $ ssh user@archlinux.de
  mith@metawire.org's password:
  user@archlinux.de's password:
  $ mkdir ~/.ssh
  $ mkdir ~/.ssh
  $ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
  $ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
  $ rm ~/id_dsa.pub
  $ rm ~/id_rsa.pub
  $ chmod 600 ~/.ssh/authorized_keys
  $ chmod 600 ~/.ssh/authorized_keys


The last two commands remove the public key from the server (which isn't needed now), and sets the correct permissions on the authorized_keys file.
Die letzten beiden Kommandos löschen den öffentlichen Schlüssel vom Server (was nicht unbedingt notwendig ist) und setzen die richtigen Rechte für die ''authorized_keys''-Datei.


If you now disconnect from the server, and attempt to reconnect, you should be asked for the passphrase of the key:
Wenn man sich nun vom Server ausloggt und versucht sich wieder einzuloggen, sollte man für das Passwort des Schlüsselpaares gefragt werden:


  $ ssh mith@metawire.org
  $ ssh user@archlinux.de
  Enter passphrase for key '/home/mith/.ssh/id_dsa':
  Enter passphrase for key '/home/user/.ssh/id_rsa':


If you are unable to login with the key, double check the permissions on the {{Filename|authorized_keys}} file.
Wenn das Login scheitert, sollte man zuerst überprüfen, ob die Rechte für ''authorized_keys'' richtig gesetzt wurden.


Also check the permissions on the {{Filename|~/.ssh}} directory, which should have write permissions off for 'group' and 'other'. Run the following command to disable 'group' and 'other' write permissions for the {{Filename|~/.ssh}} directory:
Weiterhin könnten die Rechte des Ordners '''~/.ssh''' falsch sein. Dieser sollte keine Schreibberechtigung für 'group' und 'other' haben. Um dies richtig zu stellen, muss folgender Befehl ausgeführt werden:
  $ chmod go-w ~/.ssh
  $ chmod go-w ~/.ssh


= Remember key passphrases =
== Schlüssel-Passwort speichern ==


Now you can login to your servers by using a key instead of a password, but how is this any easier, as you still need to enter the key passphrase? The answer is to use a SSH agent, a program which remembers the passphrases of your keys! There a number of different tools available, so have a read through and choose the one which seems best for you.
Nun da alles so konfiguriert ist, dass ein Schlüssel anstatt eines Passworts zum einloggen auf den SSH-Server verwendet werden kann, wir an dieser Stelle erklärt, wie das Passwort im SSH-Agent oder anderen Passwort-Managern gespeichert werden kann.


== ssh-agent ==
=== SSH-Agent nutzen ===


ssh-agent is the default agent included with OpenSSH.
Der ''SSH-Agent'' ist das Standard Tool für diese Aufgabe. Es wir automatisch mit OpenSSH installiert.


  $ ssh-agent
  $ ssh-agent
Zeile 73: Zeile 71:
  echo Agent pid 2148;
  echo Agent pid 2148;


When you run {{Codeline|ssh-agent}}, it will print out what environment variables it would use. To make use of these variables, run the command through the {{Codeline|eval}} command.
Wird der ''SSH-Agent'' ausgeführt, gibt er die benutzten Umgebungsvariablen aus. Um diese Variablen zu verwenden, startet man den Agenten durch das ''eval'' Kommando:


  $ eval `ssh-agent`
  $ eval `ssh-agent`
  Agent pid 2157
  Agent pid 2157


You can add this to {{Filename|/etc/profile}} so that it will be run whenever you open a session:
Dies kann der '''/etc/profile''' hinzugefügt werden, damit es bei jeder Session gestartet wird:


  # echo 'eval `ssh-agent`' >> /etc/profile
  # echo 'eval `ssh-agent`' >> /etc/profile


Note the correct quotes, the first ones are single quotes, where as the second are backticks!
Achtung: Es müssen die richtigen Anführungszeichen benutzt werden, am besten kopiert man das Original.


Now that the {{Codeline|ssh-agent}} is running, we need to tell it that we have a private key and where that is.
Nun, da der SSH-Agent läuft, muss man ihm mitteilen, dass man einen Privaten Schlüssel besitzt und wo dieser sich befindet.


  $ ssh-add ~/.ssh/id_dsa
  $ ssh-add ~/.ssh/id_rsa
  Enter passphrase for /home/user/.ssh/id_dsa:
  Enter passphrase for /home/user/.ssh/id_rsa:
  Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
  Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)


We were asked for our passphrase, entered it, that's all. Now you can login to your remote server without having to enter your password while your private key is password-protected. Sweet isn't it?
Nun wird das Passwort abgefragt und auch gleich gespeichert und schon kann man sich ohne Passwort, jedoch mit einem Passwort geschützten Schlüsselpaar, auf seinem SSH-Server anmelden.


The only downside is that a new instance of {{Codeline|ssh-agent}} needs to be created for every new console (shell) you open, that means you have to run {{Codeline|ssh-add}} every time again on each console. There is a workaround to that with a program or rather a script called [http://www.gentoo.org/proj/en/keychain/index.xml keychain] which is covered in the next section.
Das einzige Problem das bleibt ist, dass für jede neue SSH-Verbindung, die aufgebaut werden soll, auch eine neue SSH-Agent-Instanz gestartet werden muss. Abhilfe dafür kann ein Alias oder das Programm ''Keychain'' im nächsten Absatz schaffen.


=== Using GnuPG Agent ===
==== GnuPG-Agent nutzen ====


The [[GnuPG]] agent, distributed with the {{Package Official|gnupg2}} package, has OpenSSH agent emulation. If you use GPG you might consider using its agent to take care of all of your keys. Otherwise you might like the PIN entry dialog it provides and its passphrase management, which is different from keychain.
Der ''GnuPG-Agent'' befindet sich im Paket ''gnupg2'' und bietet eine SSH-Agent-Emulation. Wenn man diesen benutzen will, dann wird man ihn wahrscheinlich für alle seine Schlüsselpaare verwenden wollen. Außerdem könnte der PIN-Eingabedialog und dessen Passwort-Manager, welche sich von ''Keychain'' unterscheiden, von Interesse sein.


To start using GPG agent for your SSH keys you should first start the gpg-agent with the {{Codeline|--enable-ssh-support}} option. Example (don't forget to make the file executable):
Um den GPG-Agenten für SSH-Schlüssel zu benutzen, muss dieser mit der '''--enable-ssh-support''' Option gestartet werden. Beispiel (das Script muss natürlich ausführbar sein):
{{File|name=/etc/profile.d/gpg-agent.sh|content=<nowiki>
#!/bin/sh


envfile="${HOME}/.gnupg/gpg-agent.env"
#!/bin/sh
if test -f "$envfile" && kill -0 $(grep GPG_AGENT_INFO "$envfile" | cut -d: -f 2) 2>/dev/null; then
    eval "$(cat "$envfile")"
envfile="${HOME}/.gnupg/gpg-agent.env"
else
if test -f "$envfile" && kill -0 $(grep GPG_AGENT_INFO "$envfile" | cut -d: -f 2) 2>/dev/null; then
    eval "$(gpg-agent --enable-ssh-support --daemon --write-env-file "$envfile")"
    eval "$(cat "$envfile")"
fi
else
</nowiki>}}
    eval "$(gpg-agent --enable-ssh-support --daemon --write-env-file "$envfile")"
fi


Once gpg-agent is running you can use ssh-add to approve keys, just like you did with plain ssh-agent. The list of approved keys is stored in the {{Filename|~/.gnupg/sshcontrol}} file. Once your key is approved you will get a PIN entry dialog every time your passphrase is needed. You can control passphrase caching in the {{Filename|~/.gnupg/gpg-agent.conf}} file. The following example would have gpg-agent cache your keys for 3 hours:  
Wenn der GPG-Agent läuft, kann mit ''ssh-add'', wie im vorherigen Beispiel, der gewünschte Schlüssel hinzugefügt werden. Die Liste der hinzugefügten Schlüssel wird unter '''~/.gnupg/sshcontrol''' gespeichert. Sobald ein hinzugefügter Schlüssel benötigt wird, erscheint eine PIN-Eingabeaufforderung. Der PIN kann für einen selbst gewählten Zeitraum zwischengespeichert werden. Für eine Speicherdauer von drei Stunden editiert man die Datei '''~/.gnupg/gpg-agent.conf''' wie folgt:


   # Cache settings
   # Cache settings
Zeile 116: Zeile 113:
   default-cache-ttl-ssh 10800
   default-cache-ttl-ssh 10800


Other useful settings for this file include the PIN entry program (GTK, QT or ncurses version), keyboard grabbing and so on...:
Andere nützliche Einstellungen für diese Datei, wie das benutzte Toolkit (GTK, QT oder ncurses), ''Keyboard Grabbing'' und anderes:


   # Environment file
   # Environment file
Zeile 129: Zeile 126:
   pinentry-program /usr/bin/pinentry-gtk-2
   pinentry-program /usr/bin/pinentry-gtk-2


=== Using keychain ===
==== Keychain benutzen ====


[http://www.funtoo.org/en/security/keychain/intro/ Keychain] manages one or more specified private keys. When initialized it will ask for the passphrase for the private key(s) and store it. That way your private key is password protected but you won't have to enter your password over and over again.
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] kümmert sich um einen oder mehrere Private Schlüssel. Wenn Keychain gestartet wird, fragt es das Passwort ab und speichert dieses zwischen, so dass es pro Sitzung nur einmal eingegeben werden muss.


Install keychain from the extra repo:
Keychain aus [extra] installieren:
   
   
  # pacman -S keychain
  # pacman -S keychain


Create the following file and make it executable:
Nun muss die folgende Datei '''/etc/profile.d/keychain.sh''' erstellt und ausführbar gemacht werden:
{{File|name=/etc/profile.d/keychain.sh|content=<nowiki>
eval `keychain --eval --nogui -Q -q id_rsa`
</nowiki>}}
 
Or


{{File|name=/etc/profile.d/keychain.sh|content=<nowiki>
eval `keychain --eval --nogui -Q -q id_rsa`
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_dsa
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh
</nowiki>}}


Or
Oder


Append
  /usr/bin/keychain -Q -q --nogui ~/.ssh/id_rsa
  eval `keychain --eval --agents ssh id_dsa`
<nowiki>[[ -f $HOME/.keychain/$HOSTNAME-sh ]]</nowiki> && source $HOME/.keychain/$HOSTNAME-sh
to your {{Filename|.bashrc}} or {{Filename|.bash_profile}}.


{{Tip| If you want greater security replace -Q with --clear but will be less convenient.}}
Oder man fügt
eval `keychain --eval --agents ssh id_rsa`
der ''.bashrc'' oder ''.bash_profile'' hinzu.


If necessary, replace {{Filename|~/.ssh/id_dsa}} with {{Filename|~/.ssh/id_rsa}}. For those using a non-Bash compatible shell, see {{Codeline|keychain --help}} or {{Codeline|man keychain}} for details on other shells.
Für mehr Sicherheit kann das '''-Q''' durch ein unpraktischeres '''--clear''' ersetzt werden.


Close your shell and open it again. Keychain should come up and if it's your first run it will ask your for the passphrase of the specified private key.
Nach einem Neustart der Shell sollte Keychain gestartet werden und sofern es der erste Start der Sitzung ist, nach einem Passwort fragen.


=== Using ssh-agent and x11-ssh-askpass ===
==== SSH-Agent und X11-SSH-Askpass benutzen ====


You need to start the ssh-agent everytime you start a new Xsession. The ssh-agent will be closed when the X session ends.
Für diese Methode muss der SSH-Agent direkt beim Starten einer neuen XSession mit gestartet werden. Er wird automatisch mit der XSession beendet.


Install x11-ssh-askpass which will ask your passphrase everytime you open a new Xsession:
Zuerst installiert man das Paket x11-ssh-askpass. Dieses wird bei jedem Start einer XSession nach dem Passwort fragen:


  # pacman -S x11-ssh-askpass
  # pacman -S x11-ssh-askpass


Prepend this into your {{Filename|~/.xsession}}:
Folgendes muss an den Anfang der ''~/.xsession''


  eval `/usr/bin/ssh-agent`
  eval `/usr/bin/ssh-agent`
  SSH_ASKPASS=/usr/lib/openssh/x11-ssh-askpass ssh-add < /dev/null
  SSH_ASKPASS=/usr/lib/openssh/x11-ssh-askpass ssh-add < /dev/null
  # then the end of the file with for example "exec dwm"
  # dann folgt das Ende der Datei mit z.B. "exec dwm"
 
== Troubleshooting ==
Wenn der SSH-Server die benutzten Schlüssel ignoriert, sollte erst einmal richtig gestellt werden, dass die richtigen Rechte vergeben wurden.
 
Für den Client-Computer:


== GNOME Keyring ==
$ chmod 755 ~/
If you use the [[GNOME]] desktop, the [[Gnome Keyring]] tool can be used as an SSH agent. Visit the [[Gnome Keyring]] article.
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_rsa


= Troubleshooting =
Für den SSH-Server:
If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.


For the local machine:
$ chmod 755 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys


$ chmod ~/ 755
Wenn das nicht weiterhilft, sollte SSH im Debug-Modus gestartet und der Output beachtet werden:
$ chmod ~/.ssh 700
$ chmod ~/.ssh/id_rsa 600


For the remote machine:
# /usr/sbin/sshd -d


$ chmod ~/ 755
=== openssh 6.5 ===
$ chmod ~/.ssh 700
$ chmod ~/.ssh/authorized_keys 600


Failing this, run the sshd in debug mode and monitor the output while connecting:
Wenn das Einlogen nicht funktioniert bezüglich Schlüssel mus die folgende Datei  # /etc/ssh/ssh_config  (die Client config)
angepasst werden IdentityFile muss auf den privatekey zeigen!


  # /usr/sbin/sshd -d
  IdentityFile ~/.ssh/....


= Useful Links / Information =
== Weblinks ==
* [http://www.arches.uga.edu/~pkeck/ssh/ HOWTO: set up ssh keys]
* [http://www.arches.uga.edu/~pkeck/ssh/ HOWTO: set up ssh keys] {{sprache|en}}
<!-- Not Found + [http://particle.phys.uvic.ca/doc_sshkey.html ] -->
<!-- Not Found + [http://particle.phys.uvic.ca/doc_sshkey.html ] -->
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc.html OpenSSH key management, Part 1]
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc.html OpenSSH key management, Part 1] {{sprache|en}}
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ OpenSSH key management, Part 2]
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ OpenSSH key management, Part 2] {{sprache|en}}
* [http://www-106.ibm.com/developerworks/library/l-keyc3/ OpenSSH key management, Part 3]
* [http://www-106.ibm.com/developerworks/library/l-keyc3/ OpenSSH key management, Part 3] {{sprache|en}}
* [http://kimmo.suominen.com/docs/ssh/ Getting started with SSH]
* [http://kimmo.suominen.com/docs/ssh/ Getting started with SSH] {{sprache|en}}
* Manual Pages: [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html ssh-keygen(1)]
* [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Manual Pages] {{sprache|en}}
 
 
[[Kategorie:Sicherheit]]
[[Kategorie:Netzwerk]]
[[Kategorie:Server]]

Aktuelle Version vom 4. Januar 2022, 10:01 Uhr

Wenn man SSH-Schlüsselpaare (einen öffentlichen und privaten Schlüssel) benutzt, kann man einfach und sicher eine SSH-Verbindung zu einem Server herstellen, ohne ein Passwort für eines der Systeme eingeben zu müssen.

Es ist möglich, diese Schlüssel ohne ein Passwort einzurichten, jedoch ist es sicherer, eines zu benutzen, für den Fall, dass ungewollt ein Dritter an diesen Schlüssel kommt. Deshalb beschreibt diese Anleitung auch, wie man das benutzte Passwort sicher auf seinem System speichern kann.

Ein Schlüsselpaar erzeugen

Wenn OpenSSH noch nicht installiert worden ist, muss dies jetzt nachgeholt werden: 

# pacman -S openssh

Danach kann das Schlüsselpaar mit folgendem Befehl erzeugt werden: 

$ ssh-keygen -b 4096

Dabei wird ein 4096 Bit langer (-b 4096) Schlüssel erzeugt. 4096 ist die maximale Länge eines Schlüssels.

Ein ähnlicher Output wie dieser sollte folgen: 

Generating public/private rsa key pair.
Enter file in which to save the key (/home/mith/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mith/.ssh/id_rsa.
Your public key has been saved in /home/mith/.ssh/id_rsa.pub.
The key fingerprint is:
x6:68:xx:93:98:8x:87:95:7x:2x:4x:x9:81:xx:56:94 mith@middleearth

Wie hier zu sehen ist, wird man zuerst gefragt, wo der Schlüssel gespeichert werden soll (wobei es bei der Standardeingabe belassen werden sollte). Danach kommt die wichtigste Eingabe: das Passwort. Was ein sicheres Passwort ist, kann in diesem Wikipedia-Artikel nachgelesen werden.

Übertragen der Schlüssel zum SSH-Server

Nachdem die benötigten Schlüsselpaare erzeugt wurden, müssen deren öffentlichen Schlüssel zum SSH-Server übertragen werden. Standardmäßig werden diese unter ~/.ssh/authorized_keys gespeichert. 

$ scp ~/.ssh/id_rsa.pub user@archlinux.de:

Dies kopiert den öffentlichen Schlüssel mit dem Namen id_rsa.pub in den Home-Ordner des Users user auf dem Server archlinux.de.

Nun muss sich zuerst auf dem SSH-Server eingeloggt und dann die Schlüssel in das richtige Verzeichnis kopiert werden. In unserem Beispiel existieren die Ordner dafür noch nicht und müssen zuerst angelegt werden: 

$ ssh user@archlinux.de
user@archlinux.de's password:
$ mkdir ~/.ssh
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_rsa.pub
$ chmod 600 ~/.ssh/authorized_keys

Die letzten beiden Kommandos löschen den öffentlichen Schlüssel vom Server (was nicht unbedingt notwendig ist) und setzen die richtigen Rechte für die authorized_keys-Datei.

Wenn man sich nun vom Server ausloggt und versucht sich wieder einzuloggen, sollte man für das Passwort des Schlüsselpaares gefragt werden: 

$ ssh user@archlinux.de
Enter passphrase for key '/home/user/.ssh/id_rsa':

Wenn das Login scheitert, sollte man zuerst überprüfen, ob die Rechte für authorized_keys richtig gesetzt wurden.

Weiterhin könnten die Rechte des Ordners ~/.ssh falsch sein. Dieser sollte keine Schreibberechtigung für 'group' und 'other' haben. Um dies richtig zu stellen, muss folgender Befehl ausgeführt werden: 

$ chmod go-w ~/.ssh

Schlüssel-Passwort speichern

Nun da alles so konfiguriert ist, dass ein Schlüssel anstatt eines Passworts zum einloggen auf den SSH-Server verwendet werden kann, wir an dieser Stelle erklärt, wie das Passwort im SSH-Agent oder anderen Passwort-Managern gespeichert werden kann.

SSH-Agent nutzen

Der SSH-Agent ist das Standard Tool für diese Aufgabe. Es wir automatisch mit OpenSSH installiert. 

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2148; export SSH_AGENT_PID;
echo Agent pid 2148;

Wird der SSH-Agent ausgeführt, gibt er die benutzten Umgebungsvariablen aus. Um diese Variablen zu verwenden, startet man den Agenten durch das eval Kommando: 

$ eval `ssh-agent`
Agent pid 2157

Dies kann der /etc/profile hinzugefügt werden, damit es bei jeder Session gestartet wird: 

# echo 'eval `ssh-agent`' >> /etc/profile

Achtung: Es müssen die richtigen Anführungszeichen benutzt werden, am besten kopiert man das Original.

Nun, da der SSH-Agent läuft, muss man ihm mitteilen, dass man einen Privaten Schlüssel besitzt und wo dieser sich befindet. 

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

Nun wird das Passwort abgefragt und auch gleich gespeichert und schon kann man sich ohne Passwort, jedoch mit einem Passwort geschützten Schlüsselpaar, auf seinem SSH-Server anmelden.

Das einzige Problem das bleibt ist, dass für jede neue SSH-Verbindung, die aufgebaut werden soll, auch eine neue SSH-Agent-Instanz gestartet werden muss. Abhilfe dafür kann ein Alias oder das Programm Keychain im nächsten Absatz schaffen.

GnuPG-Agent nutzen

Der GnuPG-Agent befindet sich im Paket gnupg2 und bietet eine SSH-Agent-Emulation. Wenn man diesen benutzen will, dann wird man ihn wahrscheinlich für alle seine Schlüsselpaare verwenden wollen. Außerdem könnte der PIN-Eingabedialog und dessen Passwort-Manager, welche sich von Keychain unterscheiden, von Interesse sein.

Um den GPG-Agenten für SSH-Schlüssel zu benutzen, muss dieser mit der --enable-ssh-support Option gestartet werden. Beispiel (das Script muss natürlich ausführbar sein): 

#!/bin/sh

envfile="${HOME}/.gnupg/gpg-agent.env"
if test -f "$envfile" && kill -0 $(grep GPG_AGENT_INFO "$envfile" | cut -d: -f 2) 2>/dev/null; then
    eval "$(cat "$envfile")"
else
    eval "$(gpg-agent --enable-ssh-support --daemon --write-env-file "$envfile")"
fi

Wenn der GPG-Agent läuft, kann mit ssh-add, wie im vorherigen Beispiel, der gewünschte Schlüssel hinzugefügt werden. Die Liste der hinzugefügten Schlüssel wird unter ~/.gnupg/sshcontrol gespeichert. Sobald ein hinzugefügter Schlüssel benötigt wird, erscheint eine PIN-Eingabeaufforderung. Der PIN kann für einen selbst gewählten Zeitraum zwischengespeichert werden. Für eine Speicherdauer von drei Stunden editiert man die Datei ~/.gnupg/gpg-agent.conf wie folgt: 

 # Cache settings
 default-cache-ttl 10800
 default-cache-ttl-ssh 10800

Andere nützliche Einstellungen für diese Datei, wie das benutzte Toolkit (GTK, QT oder ncurses), Keyboard Grabbing und anderes: 

 # Environment file
 write-env-file /home/username/.gnupg/gpg-agent.info
 
 # Keyboard control
 #no-grab
   
 # PIN entry program
 #pinentry-program /usr/bin/pinentry-curses
 #pinentry-program /usr/bin/pinentry-qt4
 pinentry-program /usr/bin/pinentry-gtk-2

Keychain benutzen

Keychain kümmert sich um einen oder mehrere Private Schlüssel. Wenn Keychain gestartet wird, fragt es das Passwort ab und speichert dieses zwischen, so dass es pro Sitzung nur einmal eingegeben werden muss.

Keychain aus [extra] installieren: 

# pacman -S keychain

Nun muss die folgende Datei /etc/profile.d/keychain.sh erstellt und ausführbar gemacht werden: 

eval `keychain --eval --nogui -Q -q id_rsa`

Oder 

/usr/bin/keychain -Q -q --nogui ~/.ssh/id_rsa
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh

Oder man fügt 

eval `keychain --eval --agents ssh id_rsa`

der .bashrc oder .bash_profile hinzu.

Für mehr Sicherheit kann das -Q durch ein unpraktischeres --clear ersetzt werden.

Nach einem Neustart der Shell sollte Keychain gestartet werden und sofern es der erste Start der Sitzung ist, nach einem Passwort fragen.

SSH-Agent und X11-SSH-Askpass benutzen

Für diese Methode muss der SSH-Agent direkt beim Starten einer neuen XSession mit gestartet werden. Er wird automatisch mit der XSession beendet.

Zuerst installiert man das Paket x11-ssh-askpass. Dieses wird bei jedem Start einer XSession nach dem Passwort fragen: 

# pacman -S x11-ssh-askpass

Folgendes muss an den Anfang der ~/.xsession 

eval `/usr/bin/ssh-agent`
SSH_ASKPASS=/usr/lib/openssh/x11-ssh-askpass ssh-add < /dev/null
# dann folgt das Ende der Datei mit z.B. "exec dwm"

Troubleshooting

Wenn der SSH-Server die benutzten Schlüssel ignoriert, sollte erst einmal richtig gestellt werden, dass die richtigen Rechte vergeben wurden.

Für den Client-Computer: 

$ chmod 755 ~/ 
$ chmod 700 ~/.ssh 
$ chmod 600 ~/.ssh/id_rsa

Für den SSH-Server: 

$ chmod 755 ~/ 
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Wenn das nicht weiterhilft, sollte SSH im Debug-Modus gestartet und der Output beachtet werden: 

# /usr/sbin/sshd -d

openssh 6.5

Wenn das Einlogen nicht funktioniert bezüglich Schlüssel mus die folgende Datei # /etc/ssh/ssh_config (die Client config) angepasst werden IdentityFile muss auf den privatekey zeigen! 

IdentityFile ~/.ssh/....

Weblinks

Abgerufen von „https://wiki.archlinux.de/index.php?title=SSH-Authentifizierung_mit_Schlüsselpaaren&oldid=23508“