LPI-Zertifizierung mit der UNIX-AG

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

Christoph R. Hartel <crh@unix-ag.uni-kl.de>

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 Projectwww.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 ClientVerbindung aufbauen

$ ssh <user>@<host>

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

Bei identischem Username reicht:$ ssh <host>

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.decrh@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.deThe 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.pubssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA126tYr4R3gmXSBeY8pt2gdAZxmNhnIUqRK9lxlaTxRfZxB9i5Q9Kc2m0IVOtcKcbGppX3cPC9mWmDA/desbB1guEDOLuc5emNn1K0bXMtFyUhD9W7EsHTF5mDyjDj9GuV7thWG91dQX+PXNPcer5KThMaI3qqYh70XEJveCUr/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.deThe 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)? yesWarning: 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 DaemonGehoert 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 -tlnActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address Statetcp 0 0 0.0.0.0:110 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:80 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:21 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:22 0.0.0.0:* LISTENtcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

SSHD ConfigKonfiguration 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 -p2222debug1: 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 HinweiseHier 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 connectenProtocol 2

# Root darf sich nicht direkt ueber SSH einloggenPermitRootLogin no

# User mit leerem Passwort duerfen sich nicht einloggenPermitEmptyPasswords no

# ...

SCPDient 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 <user1>@<host1>:<path1> <user2>@<host2>:<path2>

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:02crh@sushi:~$

SCP BeispieleOder etwas komplexer:crh@sushi:~$ scp \c_hartel@tombola.informatik.uni-kl.de:~/myfile \hartel@aixd1.rhrk.uni-kl.de:~/tmp/myfilewithnewnamec_hartel@tombola.informatik.uni-kl.de's password:hartel@aixd1.rhrk.uni-kl.de's password:myfile 100% 377KB 3.3MB/s 00:02crh@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:02anotherfile 100% 123KB 3.0MB/s 00:01crh@sushi:~$

SSH + KeysBisher Auth ueber Passwort:$ ssh crh@sushi.unix-ag.uni-kl.decrh@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-Rechner2. Konfigurieren von Client und Server(n) fuer Key Auth3. Hinterlegen des oeffentlichen Schluessels auf Server(n)

Einrichtung von Key AuthEinrichtung (bei OpenSSH) unproblematisch :-)

1. Generierung von Schluesselpaar durch User:$ cd ~/.ssh$ ssh-keygen -t rsa -f identityGenerating public/private rsa key pair.Enter passphrase (empty for no passphrase): <password>Enter same passphrase again: <password>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. DSASSH (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 ~/.sshdrwx--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 Auth2. Konfiguration von Client und Server(n)

Key Auth muss auf allen Servern eingestellt sein:

# /etc/ssh/sshd_config

PubkeyAuthentication yesAuthorizedKeysFile %h/.ssh/authorized_keys

# OptionalPasswordAuthentication 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 Auth3. 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.pubclient$ ssh user@server...server:~$ cat ~/id_user.pub >> ~/.ssh/authorized_keys

Fertig :-)

Ueberall, wo der Public Key hinterlegt ist, wird er verwendet:crh:~$ ssh root@192.168.3.4Enter passphrase for key '/home/crh/.ssh/identity:...Have a lot of fun... ;)~#

NFS

NFS IntroNFS = Network File Sharing

Wozu?--> Gemeinsamer, transparenter Zugriff auf Dateien im LANz.B. um Home-Verzeichnisse auf mehreren Rechner verfuegbar zu machen

--> siehe SCI / RHRK

Wie?--> Zuerst muss NFS Server eingerichtet werden--> Auf Server koennen dann Dateisysteme “exportiert” werden--> Danach kann Client diese Exports wie lokale Dateisysteme mounten :-)

z.B.$ mount 192.168.3.4:/home /mnt

Historie:--> NFS unter Unix/Linux schon lange verbreitet--> Aktuell in Version 3 (verfuegbar ab Kernel 2.2.18)

NFS & SicherheitNFS wurde entwickelt, um in 'secure, trusted LANs' zu arbeiten, also prinzipiell:

--> Wir vertrauen allen Clients im LAN--> Das Netzwerk ist sicher gegen Eindringen von aussen

d.h. fuer uns:--> Bei Konfiguration Sicherheitsaspekte immer im Auge behalten

Besonders problematisch:--> NFS arbeitet auf der Grundlage einheitlicher User-/Gruppen-Ids(1)

--> d.h. auf allen Clients muessen die gleichen Ids vorhanden sein

--> z.B. User, der auf Client Root-Rechte hat, greif auch als Root auf Server zu...

(1) Zur Synchronisation der Ids, etc. gibt es spezielle Dienste wie NIS (Network Information Service) --> Google ;-)

NFS SetupIm Kernel muss NFS Support aktiviert sein

“File Sytems” / “Network File Systems”:<*> NFS file system support[*] Provide NFSv3 client support<*> NFS server support[*] Provide NFSv3 server support

Danach einfache, zentrale Konfiguration:--> '/etc/exports':--> Enthaelt je eine Zeile pro exportiertem Verzeichnis

Wichtige Einschraenkung unter Linux:--> Export nur fuer ein lokales Verzeichnis pro Dateisystem erlaubt!--> also z.B. kein gemeinsamer Export von /usr und /home, wenn auf 1 Dateisystem

NFS ExportsAchtung: Zwischen IP und und runden Klammern darf kein Leerzeichen stehen!

# /etc/exports

# Alle Clients im angegebenen Netz duerfen 're-writable'# mounten, root-User wird nach anonymous gemappt./home 192.168.1.0/24(rw,root_squash)

# Nur bestimmter Host darf mounten, read-only,# root darf direkt zugreifen/root 192.168.1.42(ro,no_root_squash)

# Nur Hosts aus der angegebenen Domain duerfen mounten,# anonymous User wird gemappt auf id 100/usr *.unix-ag.uni-kl.de(rw,root_squash,anonuid=100)

Fuer weitere Optionen--> $ man exports

NFS startenZum Starten des NFS Servers existieren meist Init-Scripte, z.B.

# /etc/init.d/nfs start

Um Aenderungen am Exports-File nach dem Server-Start zu uebernehmen einfach:

# exportfs -ra

NFS besteht aus einer Reihe interagierender Dienste (z.B. fuer File Locking, Mounts, etc.)

Uebersicht aller laufenden Programme kann mit 'rpcinfo' erzeugt werden, z.B.:

# rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 32768 status 100024 1 tcp 32768 status ...

NFS ClientsBenutzung von NFS auf Client-Seite einfach.

Analog zum mounten lokaler Dateisysteme

Lokal: # mount /dev/hda3 /mnt

NFS: # mount 192.168.3.4:/home /mnt

Mounten innerhalb von Dateisystemen:

Wenn z.B. '/home' exportiert wird, koennen wir auch Unterverzeichnisse mounten:

# mount 192.168.3.4:/home/tux /mnt/user1# mount 192.168.3.4:/home/dau /mnt/user2...

--> Somit Umgehung der Linux-Beschraenkung (1 Verzeichnis pro Dateisystem)