Inhalt

Inhaltsverzeichnis

  1. Übersicht
  2. Beispiele
  3. Login mit Key, ohne Passwort
  4. ssh-agent in der .bashrc
  5. Sicherstellen, dass sshd immer läuft
  6. Abwehr von automatisierten Einbruchsversuchen
  7. Tunnelbau mit ssh
  8. Zugriffe aus der "Windows"-Welt
  9. sftp Frontends
  10. Mounten entfernter Datei-Systeme mit dem shfs
  11. Wofür ssh nicht gedacht ist
  12. ssh-keygen Generieren/erzeugen von ssh Keys (RSA1, RSA2 und DSA)
  13. Tipps + Tricks
  14. Optionen
  15. Links
  16. Fragen

Übersicht

SSH dient dem sicheren Zugriff auf entfernte Rechner. Über SSH kann eine Terminalsitzung oder eine Xsession geöffnet werden, aber auch Daten sicher kopiert werden.

OpenSSH ist eine kompatible, freie OpenSource-Implementierung der originalen ssh (Secure Shell). Man kann damit problemlos telnet, rsh, rcp, ftp und andere veraltete und unsichere Dienste ersetzen oder zusätzlich absichern (siehe auch UnsichereProtokolle).

Homepage: http://www.openssh.com/de/

Lizenz: BSD

Weitere Tools: LUFS und SHFS - Filesystem mounten über SSH

Bestandteile:

Weitere Bestandteile:

Einsatzmöglichkeiten:

Vorteil:

Beispiele

Login mit Key, ohne Passwort

Wenn man nicht immer das Passwort beim Login auf Rechner remotehost eintippen will, kann man auch Folgendes machen:

Zuerst braucht man ein Schlüsselpaar, falls man noch keines hat, kann man sich so eines generieren: 

localuser@localhost:~ > ssh-keygen -b 2048 -t rsa

/!\ Ein vorhandenes Schlüsselpaar wird damit überschrieben.

Das Kommando generiert einen 2048 Bit langen RSA-Key für SSH Protokoll Version 2 - die Standardlänge von 1024 Bit wird nicht mehr als unumstritten sicher betrachtet.

Anmerkung: 2048 Bit ist übrigens nicht doppelt so sicher wie 1024 Bit, sondern 2^1024 mal sicherer (ausgerechnet ist das eine Dezimalzahl mit mehr als 300 Stellen!).

Danach muss man den öffentlichen Schlüssel auf den entfernten Rechner übertragen: 

# ssh-copy-id -i .ssh/id_rsa.pub remoteuser@remotehost.example.net

oder (wenn man noch kein ssh-copy-id hat) 

remoteuser@remotehost:~ > ssh-keygen -b 2048 -t rsa
localuser@localhost:~ > ssh remoteuser@remotehost.example.net \
"umask 077; mkdir -p .ssh; cat >> .ssh/authorized_keys" <.ssh/id_rsa.pub

Die umask dient dazu, dass der ssh-Key den Mode 0600 bekommt, weil sonst der sshd die Datei nicht akzeptiert.

Auf dem Remotesystem wird dann der lokale öffentliche Schlüssel in die Datei ~/.ssh/authorized_keys aufgenommen. Ebenso wird in der lokalen Datei ~/.ssh/known_hosts der öffentliche Schlüssel des Remotesystems aufgenommen.

Falls localuser ein anderer Username als remoteuser ist (also so wie im Beispiel oben), dann braucht man noch folgenden Eintrag in der lokalen ssh-Config: 

# ~/.ssh/config
Host remote
 Hostname remotehost.example.net
 User remoteuser
# ForwardX11 yes         #  nur wenn man jedes mal auf dem Remotesystem X11-Programme starten will.
# HostKeyAlias remote    #  nur für spezielle Fälle ;)
# Port 42                #  nur für spezielle Fälle ;)

Danach sollte dann ein einfaches ssh remote (ohne domain, ohne remoteuser, ohne Passwort) reichen, um sich einzuloggen. Falls es nicht funktioniert und er immer noch ein Passwort wissen will, evtl. im Config-File des Servers überprüfen, ob PubkeyAuthentication aktiviert ist!

Sollte der Verbindungsaufbau lange dauern, muss höchstwahrscheinlich in der Datei /etc/ssh/sshd_config der Wert
  GSSAPIAuthentication yes
auf
  GSSAPIAuthentication no
gesetzt und anschließend der sshd neu gestartet werden

/!\ Es ist nicht ungefährlich, einen Key ohne Passphrase zu verwenden, denn dann kann jeder, der sich irgendwie den Key verschafft, auf dem Server mit den Rechten des Key-Besitzers arbeiten. Solange der Rechner, auf dem der Key liegt, dessen eigener ist und er sich sicher ist, dass da sonst keiner drangeht, mag das noch angehen, aber was ist, wenn es ein fremder Rechner (Uni, Arbeitgeber, etc.) ist? Oder jemand es schafft, auf seinem Rechner ein rootkit zu installieren? Schon hat jemand anderes Zugriff auf den Key - und da er nicht mit einer Passphrase geschützt ist, kann er ihn sofort verwenden. Eine sicherere Alternative dazu bietet sshagent, beschrieben in http://www-106.ibm.com/developerworks/opensource/library/l-keyc.html?dwzone=opensource und den darauf folgenden Artikeln.

Siehe auch http://www.schlittermann.de/ssh.

ssh-agent in der .bashrc

Um sich den Umgang mit dem SSH-agenten zu vereinfachen, ruft man ihn über eine Funktion in der .bashrc auf. 

    sa()
{
    if ps -o "%p %c" -u `id -u` |grep ssh-agent; then
        set $(ps -o "%p %c" -u $(id -u)|grep ssh-agent )
        SSH_AGENT_PID=$1
        export SSH_AGENT_PID
        SSH_AUTH_SOCK=$(find /tmp/ -type s -name "agent.$(( $1 - 1 ))" -uid $(id -u))
        export SSH_AUTH_SOCK
        echo "ssh-agent lief bereits"
    else
        eval $(ssh-agent )
        ssh-add ~/.ssh/id_rsa
        echo "ssh-agent wurde gestartet"
    fi
}

Sicherstellen, dass sshd immer läuft

Übersetzt aus der LinuxGazette #78:

Mit OpenSSH kann man den sshd so konfigurieren, dass er direkt von init gestartet wird. Dies geht mit einem Eintrag in /etc/inittab mit der "respawn"-Direktive und der sshd-Option -D (don't detach): 

# Auszug vom Ende der /etc/inittab
ss:12345:respawn:/usr/sbin/sshd -D

Dies stellt sicher, dass ein sshd-Dämon immer am Laufen gehalten wird, selbst unter extremen Bedingungen (wie Speichermangel) oder wenn ein achtloser Administrator aus Versehen per killall den laufenden Dämon killt. So lange init funktionieren kann, wird es einen sshd am Laufen halten (genauso wie es auch die getty-Prozesse am Laufen hält).

Dies ist besonders nützlich für außer Haus untergebrachte Server (Colocation), die keine (zuverlässige) serielle Console haben. Es kann einem so eine längere Fahrt oder diesen frustrierenden, zeitraubenden und peinlichen Anruf bei den Rechenzentrumsleuten ersparen.

Abwehr von automatisierten Einbruchsversuchen

Steht ein SSH-Server offen im Internet, versuchen es einige immer wieder, eine User/Passwort-Kombination zu erraten, um den Server z.B. als Spam-Schleuder nutzen zu können. Das kann effektiv durch folgende iptable Befehle verhindert werden: 

iptables -A INPUT -p tcp --dport 22 -m recent --set --name ssh --rsource
iptables -A INPUT -p tcp --dport 22 -m recent ! --rcheck --seconds 60 --hitcount 4 --name ssh --rsource -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --syn -j DROP

Außerdem kann eingeschränkt werden, wer ssh nutzen darf. Dazu ist in der Datei /etc/ssh/sshd_config einzufügen, wer das sein soll nach dem Schlüsselwort AllowUsers 

AllowUsers root testuser

Tunnelbau mit ssh

Wenn man UnsichereProtokolle verwenden muss, kann man einen ssh-Tunnel zur Absicherung verwenden (außer bei ftp):

ssh-Zusatzoptionen:

-g
erlaubt nicht nur localhost die Verwendung des weitergeleiteten Ports, sondern gibt ihn global frei - Vorsicht!
-N
nur Port-Weiterleitung, keine Kommandos auf Serverseite ausführen
-f
SSH-Client im Hintergrund ausführen, nachdem die Authentifizierung abgeschlossen ist
-C

schaltet Kompression ein - empfehlenswert für langsame Verbindungen und hohes Datenaufkommen (z.B. X11)

-X
X11-Forwarding einschalten - ssh kümmert sich dann um xauth, $DISPLAY usw.
-x
X11-Forwarding ausschalten

Eine weitere Möglichkeit sichere Tunnel zu graben ist stunnel.

Ich habe nach einem Weg gesucht, per ssh einen Rechner hinter einer Firewall fernwartbar zu halten. Dies soll auch funktionieren, wenn die Verbindung neu aufgebaut wird, eventuell mit anderer IP. Folgendes Vorgehen funktioniert, für Verbesserungen bin ich dankbar --ThomasKalka

Zugriffe aus der "Windows"-Welt

Ein paar SSH-Clients für "Windows" werden unter /ZugriffVonWindows vorgestellt.

sftp Frontends

Wem sftp zu spartanisch ist, der kann eines der folgenden Frontends verwenden:

Mounten entfernter Datei-Systeme mit dem shfs

Man kann mit dem (Secure) SHell FileSystem SHFS auch ganze Datei-Systeme via ssh mounten.

Wofür ssh nicht gedacht ist

ssh-keygen Generieren/erzeugen von ssh Keys (RSA1, RSA2 und DSA)

Die maximale Schlüsselange beträgt 32768 Bit.

Tipps + Tricks

Man kann dann in den entsprechenden Logs Einträge wie folgenden sehen:  Failed password for illegal user test from 218.93.124.211 port 52084 ssh2 

Optionen

-b Bit
(numerischer Wert bis max. 32768 Bits)
-f
Dateiname
-l
Gibt den Fingerprint des Keys aus
-p
ändern der Passphrase eines privaten Keys
-t type
mögliche Werte rsa1 (Protocol 1) , dsa und rsa (Protocol 2)
-C
neuer Kommentar
-D Reader
Liest einen privaten RSA-Key von einem Smartcardreader
-N
neue Passphrase
-P
alte Passphrase
-U Reader
Lädt einen privaten RSA Key in einen Smartcardreader

Fragen

KategorieProtokoll

OpenSSH (zuletzt geändert am 2014-03-31 19:17:24 durch rzbrk)