LPI-Zertifizierung mit der UNIX-AG LPI 102 - Kapitel 4 ... linux/files/LPI/LPI_102-4_ LPI-Zertifizierung

  • View
    3

  • Download
    0

Embed Size (px)

Text of LPI-Zertifizierung mit der UNIX-AG LPI 102 - Kapitel 4 ... linux/files/LPI/LPI_102-4_...

  • LPI-Zertifizierung mit der UNIX-AG

    LPI 102 - Kapitel 4 - USB, Secure Shell, and File Sharing

    Christoph R. Hartel

    13. Januar 2004

    www.unix-ag.uni-kl.de/~pglinux/lpi.html

  • Gliederung

    Interessante Kombination ;-)

    1. SSH --> Anknuepfen an letzte Woche --> hohe Bedeutung

    2. NFS

    (3. USB) --> Zeitlicher Rahmen :( --> Test-Umgebung aufwaendig --> Deswegen:

    Linux USB Project www.linux-usb.org

  • SSH

  • SSH Intro Wozu SSH? --> Interaktive Logins Frueher:

    � telnet � rsh Problem: � Daten (insbes. Passwoerter) unverschluesselt uebertragen

    ==> Unsicher Loesung: � SSH (Secure Shell) � Uebertragung erfolgt verschluesselt � Weitere Sicherheitsmechanismen (Auth mit Keys, etc.)

  • OpenSSH Es gibt mehrerere Implementierungen. Unter Linux vor allem verbreitet und fuer LPI relevant: � OpenSSH

    � Freie Implementierung � Unterstuetzt SSH1 + 2 Protokoll � Aktuelle Version: 3.7.1 � www.openssh.org

  • SSH Client Verbindung aufbauen

    $ ssh @

    z.B. $ ssh crh@sushi.unix-ag.uni-kl.de oder $ ssh crh@131.246.89.13

    Bei identischem Username reicht: $ ssh

  • SSH Client (Beispiel 1)

    Nach Verbindungsaufbau normale Shell auf entferntem Rechner :-)

    Verbindung beenden mit 'exit' oder CTRL+D

    $ ssh crh@sushi.unix-ag.uni-kl.de crh@sushi.unix-ag.uni-kl.de's password: Linux sushi 2.4.24-sushi0 #1 SMP Wed Jan 7 14:56:54 CET 2004 i686 GNU/Linux ... crh@sushi:~$

  • SSH Client (Beispiel 2)

    Aber: bei erstem Verbindungsaufbau zu Host passiert folgendes:

    $ ssh crh@sushi.unix-ag.uni-kl.de The authenticity of host 'sushi.unix-ag.uni-kl.de (131.246.89.13)' can't be established. RSA key fingerprint is 43:86:54:ce:b4:28:4d:74:5c:76:3a:d0:0c:e4:ae:3c. Are you sure you want to continue connecting (yes/no)?

  • SSH Client (Beispiel 2) ... Jeder Rechner hat bei SSH einen Host key

    ==> eindeutig identifizierbar

    crh@sushi:~$ cat /etc/ssh/ssh_host_rsa_key.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA126tYr4R3gmXSBeY8pt2gdAZxmNhnIUqR K9lxlaTxRfZxB9i5Q9Kc2m0IVOtcKcbGppX3cPC9mWmDA/desbB1guEDOLuc5 emNn1K0bXMtFyUhD9W7EsHTF5mDyjDj9GuV7thWG91dQX+PXNPcer5KThMaI3 qqYh70XEJveCUr/c=

  • SSH Client (Beispiel 2) ...

    Host key fingerprint wird lokal gespeichert (~/.ssh/known_hosts)

    Bei zukuenftigen Verbindungen, wird Key verglichen ==> Vermeidung von Attacken

    $ ssh crh@sushi.unix-ag.uni-kl.de The authenticity of host 'sushi.unix-ag.uni-kl.de (131.246.89.13)' can't be established. RSA key fingerprint is 43:86:54:ce:b4:28:4d:74:5c:76:3a:d0:0c:e4:ae:3c. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'sushi.unix-ag.uni- kl.de,131.246.89.13' (RSA) to the list of known hosts. crh@sushi.unix-ag.uni-kl.de's password: Linux sushi 2.4.24-sushi0 #1 SMP Wed Jan 7 14:56:54 CET 2004 i686 GNU/Linux ... crh@sushi:~$

  • SSH Daemon Gehoert bei meisten aktuellen Distris zur Standard-Installation

    Starten ueber Init-Script, z.B. bei Debian

    # /etc/init.d/ssh start

    Hoert auf Port 22, d.h. nach Start sollte etwa folgendes zu sehen sein: # netstat -tln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

  • SSHD Config Konfiguration erfolgt ueber File

    /etc/ssh/sshd_config

    Meistens bereits sinnvoll vorkonfiguriert. Details unter

    $ man sshd und $ man sshd_config

    Zum Testen neuer Configs oft hilfreich: Debug-Modus # sshd -d -p2222 debug1: sshd version OpenSSH_3.6.1p2 Debian 1:3.6.1p2-9 ... debug1: Bind to port 2222 on 0.0.0.0. Server listening on 0.0.0.0 port 2222.

  • SSHD Config Hinweise Hier einige wichtige Default-Einstellungen: # /etc/ssh/sshd_config

    # Daemon hoert auf alle Adressen der Machine # Wenn in mehreren Netzen oft sinnvoll, nur auf eine # Adresse zu binden (z.B. bei Firewall) ListenAddress 0.0.0.0

    # Nur Clients, die Protokoll 2 verwenden duerfen connecten Protocol 2

    # Root darf sich nicht direkt ueber SSH einloggen PermitRootLogin no

    # User mit leerem Passwort duerfen sich nicht einloggen PermitEmptyPasswords no

    # ...

  • SCP Dient zum Kopieren von Dateien ueber das Netzwerk

    Analog zum Copy-Befehl: $ scp Quell-File Ziel-File

    Erweitert um Angabe von User und Host (optional): $ scp @: @:

    also z.B.: crh@sushi:~$ scp myfile c_hartel@tombola.informatik.uni-kl.de:~/ c_hartel@tombola.informatik.uni-kl.de's password: myfile 100% 377KB 3.3MB/s 00:02 crh@sushi:~$

  • SCP Beispiele Oder etwas komplexer: crh@sushi:~$ scp \ c_hartel@tombola.informatik.uni-kl.de:~/myfile \ hartel@aixd1.rhrk.uni-kl.de:~/tmp/myfilewithnewname c_hartel@tombola.informatik.uni-kl.de's password: hartel@aixd1.rhrk.uni-kl.de's password: myfile 100% 377KB 3.3MB/s 00:02 crh@sushi:~$

    Natuerlich koennen auch ganze Verzeichnisse kopiert werden, mit: $ scp -r Quell-Dir Ziel-Dir (Achtung: kleines 'r', nicht wie bei 'cp -R'!) crh@sushi:~$ scp myDir hartel@aixd2.rhrk.uni-kl.de:~/ hartel@aixd2.rhrk.uni-kl.de's password: myfile 100% 377KB 3.3MB/s 00:02 anotherfile 100% 123KB 3.0MB/s 00:01 crh@sushi:~$

  • SSH + Keys Bisher Auth ueber Passwort: $ ssh crh@sushi.unix-ag.uni-kl.de crh@sushi.unix-ag.uni-kl.de's password: Nachteile:

    � Umstaendlich � Bei jeder Verbindung muss Passwort eingegeben werden

    � Umgang mit vielen Passwoertern problematisch � Passwoerter muessen sicher verwahrt werden

    � Unsicher � Passwort kann z.B. mitgelesen werden

    � Keine Unterscheidung auf User-Basis moeglich � z.B. bei Verlust von root-Passwort auf Server es an alle

    Berechtigten neu verteilt werden � Automatisierung problematisch

    � In Script muesste z.B. Passwort angegeben werden

  • SSH + Keys ... Loesung: Authentifizierung ueber Private/Public-Key Mechanismus

    D.h. User generiert sich Schluesselpaar und hinterlegt es auf Servern Resultat: � Nur noch ein sicherer Key statt vieler Passwoerter :-)

    Einrichtung: 1. Generierung von Schluesselpaar auf fuer User auf Client-Rechner 2. Konfigurieren von Client und Server(n) fuer Key Auth 3. Hinterlegen des oeffentlichen Schluessels auf Server(n)

  • Einrichtung von Key Auth Einrichtung (bei OpenSSH) unproblematisch :-)

    1. Generierung von Schluesselpaar durch User: $ cd ~/.ssh $ ssh-keygen -t rsa -f identity Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in identity. Your public key has been saved in identity.pub. The key fingerprint is: e6:fb:2c:53:e5:fd:0d:b3:60:4c:0d:f4:5d:07:da:ac crh@ws-crh-mobile

    Passwort ist optional und dient nur dem Schutz des Private Keys.

    Falls dieser z.B. bekannt wuerde, ist er durch Passwort immer noch geschuetzt.

    In manchen Faellen (z.B. Automatisierung) zweckmaessig, kein PW anzugeben.

  • Einschub: RSA vs. DSA SSH (v2) unterstuetzt 2 Arten von Schluesseln: DSA und RSA

    $ ssh-keygen -t {rsa|dsa}

    Welche ist sicherer? --> Grosses Streit-Thema ;)

    Beide haben Vor- und Nachteile: --> DSA ist schneller bei Schluesselgenerierung und Signierung --> RSA ist schneller bei Verifizierung

    Fuer Verwendung in SSH effektiv Geschmackssache.

    Wir beschraenken uns hier auf RSA Keys.

    Bei Interesse: --> Google liefert zahlreiche Infos zum Thema

  • Einrichtung von Key Auth ... Datei-Rechte sind kritisch!

    Wenn falsch gesetzt ==> Sicherheitsluecke!

    Daher wuerde sich OpenSSH weigern, Keys zu benutzen.

    $ ll -a ~/.ssh drwx--x--x 2 crh crh 136 Jan 8 22:07 ./ drwxr-xr-x 59 crh crh 4024 Jan 12 17:33 ../ -rw------- 1 crh crh 3311 Oct 13 09:27 identity -rw-r--r-- 1 crh crh 738 Oct 13 09:27 identity.pub -rw-r--r-- 1 crh crh 11084 Jan 8 22:23 known_hosts

    also: 711 fuer '~/.ssh' (SSH Client Config Dir) 600 fuer 'identity' (Private Key) 644 fuer 'identity.pub' (Public Key)

  • Einrichtung von Key Auth 2. Konfiguration von Client und Server(n)

    Key Auth muss auf allen Servern eingestellt sein:

    # /etc/ssh/sshd_config

    PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys

    # Optional PasswordAuthentication no

    # /etc/ssh/ssh/config

    IdentityFile ~/.ssh/identity # Bei Bedarf koennen weitere IdentityFile Eintraege angefuegt werden

    In Client Konfig muss nur Pfad zum Keyfile angegeben werden:

  • Einrichtung von Key Auth 3. Hinterlegung des oeffentlichen Schluessels auf Server(n)

    Der generierte oeffentliche Schluessel muss auf Server hinterlegt werden --> File '~/.ssh/authorized_keys'

    client$ scp ~/.ssh/identity.pub user@server:~/id_user.pub client$ ssh user@server ... server:~$ cat ~/id_user.pub >> ~/.ssh/authorized_keys

    Fertig :-)

    Ueberall, wo der Public Key hinterlegt ist, wird er verwen