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

Aus wiki.archlinux.de
Zeile 32: Zeile 32:
Wie hier zu sehen ist, wird man zuerst gefragt, wo der Schlüssel gespeichert werden soll (wobei es bei der Standarteingabe 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.
Wie hier zu sehen ist, wird man zuerst gefragt, wo der Schlüssel gespeichert werden soll (wobei es bei der Standarteingabe 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.


== 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_dsa.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_dsa.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_dsa.pub >> ~/.ssh/authorized_keys
Zeile 49: Zeile 49:
  $ 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_dsa':


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



Version vom 20. Oktober 2010, 20:09 Uhr

Was sind SSH-Schlüsselpaare?

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 1024 -t dsa

Dabei wird ein 1024 Bit langer (-b 1024) Schlüssel des Typs DSA (-t dsa) erzeugt. Stattdessen kann auch ein Schlüsselpaar des Typs RSA erzeugt werden. Dabei genügt die Option -t rsa (ohne -b), da die Standardlänge mit 2048 Bit lang genug sein sollte.

Achtung: Ein DSA-Schlüssel muss exakt 1024 Bit lang sein, wogegen ein RSA-Schlüssel zwischen 768 und 4096 Bit lang sein kann.

Ein ähnlicher Output wie dieser sollte folgen:

Generating public/private dsa key pair.
Enter file in which to save the key (/home/mith/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mith/.ssh/id_dsa.
Your public key has been saved in /home/mith/.ssh/id_dsa.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 Standarteingabe 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_dsa.pub user@archlinux.de:

Dies kopiert den öffentlichen Schlüssel mit dem Namen id_dsa.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_dsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_dsa.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_dsa':

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

Remember key passphrases

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.

ssh-agent

ssh-agent is the default agent included with OpenSSH.

$ 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;

When you run Vorlage:Codeline, it will print out what environment variables it would use. To make use of these variables, run the command through the Vorlage:Codeline command.

$ eval `ssh-agent`
Agent pid 2157

You can add this to Vorlage:Filename so that it will be run whenever you open a session:

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

Note the correct quotes, the first ones are single quotes, where as the second are backticks!

Now that the Vorlage:Codeline is running, we need to tell it that we have a private key and where that is.

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

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?

The only downside is that a new instance of Vorlage:Codeline needs to be created for every new console (shell) you open, that means you have to run Vorlage:Codeline every time again on each console. There is a workaround to that with a program or rather a script called keychain which is covered in the next section.

Using GnuPG Agent

The GnuPG agent, distributed with the Vorlage:Package Official 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.

To start using GPG agent for your SSH keys you should first start the gpg-agent with the Vorlage:Codeline option. Example (don't forget to make the file executable): Vorlage:File

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 Vorlage:Filename 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 Vorlage:Filename file. The following example would have gpg-agent cache your keys for 3 hours:

 # Cache settings
 default-cache-ttl 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...:

 # 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

Using keychain

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.

Install keychain from the extra repo:

# pacman -S keychain

Create the following file and make it executable: Vorlage:File

Or

Vorlage:File

Or

Append

eval `keychain --eval --agents ssh id_dsa`

to your Vorlage:Filename or Vorlage:Filename.

Vorlage:Tip

If necessary, replace Vorlage:Filename with Vorlage:Filename. For those using a non-Bash compatible shell, see Vorlage:Codeline or Vorlage:Codeline for details on other shells.

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.

Using ssh-agent and x11-ssh-askpass

You need to start the ssh-agent everytime you start a new Xsession. The ssh-agent will be closed when the X session ends.

Install x11-ssh-askpass which will ask your passphrase everytime you open a new Xsession:

# pacman -S x11-ssh-askpass

Prepend this into your Vorlage:Filename:

eval `/usr/bin/ssh-agent`
SSH_ASKPASS=/usr/lib/openssh/x11-ssh-askpass ssh-add < /dev/null
# then the end of the file with for example "exec dwm"

GNOME Keyring

If you use the GNOME desktop, the Gnome Keyring tool can be used as an SSH agent. Visit the Gnome Keyring article.

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 ~/.ssh 700
$ chmod ~/.ssh/id_rsa 600

Für den SSH-Server:

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

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

# /usr/sbin/sshd -d

Nützliche Links und Informationen