SSH/Hostkey/TMP

Secure SSH Tutorial Part 1: Host Key

Einführung

SSH, oder Secure SHell ist ein Programm und ein Netzwerkprotokoll.

Mit SSH ist es zum Beispiel möglich, sich auf einem anderen Computer einzuloggen und dort Programme auszuführen.
SSH ermöglicht eine sichere Verbindung zwischen zwei Rechnern durch Authentifizierung und Verschlüsselung.
Diese Artikelserie beschäftigt sich mit den Sicherheitsaspekten und mit nützlichen Features von SSH.
In den Artikeln wird eine freie Implementierung von SSH, OpenSSH benutzt.

Installation

Das OpenSSH Paket finden Sie unter www.openssh.com/, oder im Paketverzeichniss Ihrer Distribution.

Die meisten Distributionen installieren OpenSSH standardmässig oder fragen zumindest danach. * Debian Hier reicht ein apt-get install ssh.

RedHat RPM Wenn das Paketverwaltungssystem RPM installiert ist, müssen Sie das Paket (google: \"index of\" gnupg .rpm) nur herunterladen und es ausführen.

Sourcecode Sie suchen als erstes einen Mirrorserver unter www.openssh.com/portable.html aus und laden den aktuellsten Tarball (Datei mit der Endung "tar.gz") herunter.
Ich benutze in meinem Fall openbsd.md5.com.ar/pub/OpenBSD/OpenSSH/portable/, und openssh-4.1p1.tar.gz Als nächstes laden wir die Souces herunter und testen ob die Datei beschädigt ist:
Code:workstation:~# wget https://openbsd.md5.com.ar/pub/OpenBSD/OpenSSH/portable/openssh-4.1p1.tar.gz workstation:~# tar -xzvf openssh-4.1p1.tar.gz workstation:~# cd openssh-4.1p1 workstation:~# ./configure --sysconfdir=/etc workstation:~# make workstation:~# make install
Wenn Sie ein Problem mit der Installation haben, sollten Sie sich zuerst www.openssh.com/faq.html anschauen. ./configure schlägt fehl, wenn OpenSSL nicht installiert ist.
OpenSSL kann unter www.openssl.org/ herunterladen werden, unter hier finden Sie ein Tutorial zur Installation.

Host Keys und die Man-In-The-Middle Theorie Top

SSH ist ein Protokoll, das andere, nicht-verschlüsselte Protokolle ablösen soll: Telnet, FTP, RSH, ...

Diese Protokolle versenden alle Daten, auch Passwörter und andere kritische Daten, unverschlüsselt.
Ein Cracker an einer Schlüsselposition im Netzwerk kann alle unverschlüsselten Verbindungen abfangen, die Pakete loggen, austauschen und bekommt somit sämtliche sensible Daten, wie eben Passwörter und Logindaten, die besser verschlüsselt gehören.
SSH funktioniert nach den Prinzipien der Public-Key-Kryptographie, auch asymmetrische Verschlüsselung genannt.
D.h. der Server sendet zuerst seinen Public Key, der Client bekommt diesen und sendet seinen Public Key verschlüsselt zurück.
Die Nachrichten, die mit dem Public Key verschlüsselt wurden, können nur mit dem Private Key entschlüsselt werden und umgekehrt, deshalb ist diese Verbindung sicher.
Aber was passiert, wenn zwischen der Verbindung ein Proxy-Server steht und die Verbindung abgefangen wird? Der Proxy-Server schickt dem Client seinen Public Key und öffnet eine Verbindung zum SSH-Server.
Das ist das Problem der asymmetrischen Verschlüsselung und deshalb verwendet man in anderen Protokollen, wie beispielsweise HTTPS (Secure HTTP), Zertifikate.
Bei einem Zertifikat wird der Public Key des Zertifikatinhabers mit dem Private Key eines vertrauenswürdigen Servers signiert.
Mit dem Public Key des vertrauenswürdigen Servers kann man die Verschlüsselung überprüfen; dadurch wird gewährleistet, dass der Public Key zum Zertifikatinhabers passt.
Dies gilt nur, wenn der vertrauenswürdige Server vertrauenswürdig ist.
Der Public Key der großen Zertifikate-Server ist dem Client bekannt und wird vom Browser mitgeliefert.
Die Lösung mit den Zertifikaten wird bei SSH-Servern nicht benutzt, deshalb ist es wichtig, dass wir den Key des Servers kennen, wenn wir eine Verbindung mit ihm eingehen.
Schauen wir mal, was passiert, wenn wir zum ersten Mal zu einem Server verbinden:

Code:workstation:~# ssh my-ssh-server.com The authenticity of host 'my-ssh-server.com (127.0.0.1)' can't be established.

RSA key fingerprint is a6:33:ff:28:d6:fb:4b:66:16:b9:d1:b3:ea:58:77:a5.
Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'my-ssh-server.com'(RSA) to the list of known hosts.

Zuerst wird eine Verbindung zum Server aufgebaut; der schickt uns seinen Host-Key zurück.

Danach zeigt SSH den Fingerprint des Keys an, und fragt uns, ob wir den Fingerprint (Signatur des Keys) akzeptieren.
Wenn wir akzeptieren, speichert SSH den key in $HOME/.ssh/known_hosts und in einer globalen Datei, meistens /etc/ssh/known_hosts.
Wenn sich der Public Key des Servers ändert, zeigt uns SSH beim nächsten Mal eine Warnung an, dass sich der Key geändert hat.
Die Sicherheit der Verbindung wird also nur durch diesen Fingerprint gewährleistet.
Deshalb ist es wichtig, dass wir uns sicher sind, dass es der richtige Key zum Server ist.
Am besten ist es, wenn man den Fingerprint aufschreibt und immer dabei hat, wenn man sich von einem PC einloggt, der noch nie mit dem SSH-Server verbunden war oder den Key per HTTPS speichert.
SSH hat einen Parameter, mit dem man das Behandeln von falschen oder unbekannten Host Keys einstellen kann: StrictHostKeyChecking * StrictHostKeyChecking=no Diese Option bewirkt, dass SSH blindlings zum Server connected.
Sie fügt den Key automatisch lokal hinzu, und wenn der Key geändert wurde, gibt SSH eine Warnung aus und fügt den Key ohne danach zu fragen hinzu.
Meistens eine extrem schlechte Wahl.

StrictHostKeyChecking=ask Die Standard-Einstellung.
Wenn kein Key gefunden wird, wird der Fingerprint angezeigt, und nach Ihrem Einverständnis gefragt.
Wenn der Key geändert wurde, wird eine Warnung angezeigt:
Code: workstation:~# ssh -o stricthostkeychecking=my-ssh-server.com @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is a6:33:ff:28:d6:fb:4b:66:16:b9:d1:b3:ea:58:77:a5. Please contact your system administrator. Add correct host key in /home/simon/.ssh/known_hosts to get rid of this message. Offending key in /home/simon/.ssh/known_hosts:8 RSA host key for localhost has changed and you have requested strict checking. Host key verification failed.

StrictHostKeyChecking=yes Das ist die sicherste, aber auch unfreundlichste Option: Wenn kein Host Key lokal gespeichert ist, wird abgebrochen.

Ein veränderter Host Key muss nicht immer heißen, dass die Verbindung unsicher ist.

Der Server könnte beispielsweise
von der unsicheren Version SSH1 auf SSH2 gewechselt haben, oder der Rechner wurde neu aufgesetzt.

Host Key Varianten Top

SSH liefert mehrere Protokolltypen mit, generell SSHv1 (RSA), und SSHv2 (RSA oder DSA); ein SSH Server kann alle drei Algorithmen benutzen.

In der sshd_config tragen wir ein, welche Schlüssel wir verwenden wollen:

sshd_config:# Welche(s) Prokoll(e) wollen wir unterstützen (1, 2, oder 2 und 1) Protocol 2,1 # Host keys für SSH1 HostKey /etc/ssh/ssh_host_key # Host key für SSH2 HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa_key

Falls die Keys noch nicht generiert sind, generieren wir sie mit ssh-keygen:

Code:workstation:~# ssh-keygen -t rsa /etc/ssh/ssh_host_rsa_key workstation:~# ssh-keygen -t dsa /etc/ssh/ssh_host_dsa_key workstation:~# ssh-keygen -t rsa1 /etc/ssh/ssh_host_key

ssh-keygen erstellt zwei Dateien pro Schlüssel, die erste Datei enthält den Public- und den Private Key, die zweite Datei nur den Public Key.

Weitere Optionen Top

Es gibt noch ein paar andere Sicherheitsoptionen für den SSH Client, die in der globalen Datei /etc/ssh/ssh_config oder in der lokalen Datei $HOME/.ssh/config sind.

man ssh_config gibt über die Parameter genauer Auskunft.

Options:CheckHostIP: Testet ob die IP des Servers in der known_host Datei ist.

NoHostAuthenticationForLocalhost: Eine nützliche Option für Port Forwards, die das Testen des Host Keys auf localhost (127.0.0.1) unterbindet.

So, ich hoffe das erste Tutorial hat einen schönen Einblick in die Host Key-Verwaltung von SSH gegeben.

In Part 2 wird es wahrscheinlich um die Userverwaltung gehen.

Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?Editieren Versionen Linkpartnerschaft Top PrintversionHaben Sie einen Fehler gefunden? Dann klicken Sie doch auf Editieren, und beheben den Fehler, keine Angst, Sie können nichts zerstören, das Tutorial kann wiederhergestellt werden

Sprachenübersicht/Betriebssysteme/Linux/Security/Secure SSH Tutorial Part 1: Host Key

Secure SSH Tutorial Part 2: Identity/Pubkey Authentifizierung

Sprachenübersicht/Betriebssysteme/Linux/SecuritySecure SSH Tutorial Part 2: Identity/Pubkey AuthentifizierungDiese Seite wurde 28209 mal aufgerufen.Dieser Artikel wurde in einem Wikiweb System geschrieben, das heißt, Sie können die Artikel jederzeit editieren, wenn Sie einen Fehler gefunden haben, oder etwas hinzufügen wollen.Editieren Versionen Linkpartnerschaft Bottom Printversion

Keywords: SSH, secure, OpenSSH, Identity/Pubkey Authentifizierung, identity, pubkey, authentication

Vorwort Top

Im ersten Teil dieser Tutorialserie ging es um die sichere Verwaltung des Host-Schlüssels, dieser Teil beschäftigt sich mit Identity/Pubkey Authentifizierung unter SSH.

Einführung Top

OpenSSH - wenn ich in diesem Tutorial den Begriff SSH verwende, meine ich eigentlich immer OpenSSH - unterstützt einige nützliche Dinge zur Authentifizierung der Benutzer.

Wir schauen uns jetzt die "Identity/Pubkey Authentifizierung" an.
Bei dieser Methode ersetzen wir die normale Vorgehensweise, statische Passwörter zu benutzen, die mit einem Keylogger abgehört werden können.
Alles, was wir brauchen, ist ein Schlüsselpaar auf der Festplatte, mit dem wir uns authentifizieren.
Der SSH-Server hat die Identities/Pubkeys, welchen er vertraut, in einer Liste.
Vorteile: - Ein Keylogger reicht nicht mehr, da der private Key und die Passphrase benötigt werden - Bruteforce- und Directoryhacks funktionieren nicht mehr

Identity/Pubkey erstellen Top

Wie schon im ersten Teil erwähnt, gibt es drei Typen von Protokollen, die wir verwenden können:

Code: - RSA1 Parameter: -t rsa1 Standarddateiname: identity Protokoll: SSH 1 - RSA Parameter: -t rsa Standarddateiname: id_rsa Protokoll: SSH 2 - DSA Parameter: -t dsa Standarddateiname: id_dsa Protokoll: SSH 2

Wir erstellen das Schlüsselpaar wie gewohnt mit ssh-keygen:

Code: workstation:/home/simon# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/simon/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/simon/.ssh/id_rsa. Your public key has been saved in /home/simon/.ssh/id_rsa.pub. The key fingerprint is: 01:4a:69:4a:81:16:f2:b9:aa:41:da:55:af:dd:34:ce simon@workstation workstation: workstation:/home/simon# cd $HOME/.ssh/ workstation:~/.ssh# ls id_rsa id_rsa.pub

Jetzt sehen wir die zwei Dateien, die ssh-keygen erstellt hat: id_rsa, und id_rsa.pub.

Die erste Datei ist der Private Key und ist mit der Passphrase geschützt, die zweite Datei (.pub) ist der Public Key.

Identity/Pubkey zum Server hochladen Top

Jetzt schicken wir den Public Key dem Server, dazu verwenden wir scp, ein Tool von SSH, welches für Filetransfer gedacht ist:

Code: workstation:/# cd $HOME/.ssh/ workstation:/home/simon/.ssh# scp id_rsa.pub simon@ssh-server:id_rsa_workstation.pub Password: workstation:/home/simon/.ssh# ssh ssh-server -L simon Password: ssh-server:/ cd $HOME ssh-server:/home/simon# mkdir .ssh && chmod 700 .ssh && cd .ssh #Jetzt fügen wir die Datei hinzu, die wir hochgeladen haben ssh-server:/home/simon/.ssh# cat ../id_rsa_workstation.pub >> authorized_keys ssh-server:/home/simon/.ssh# chmod 600 authorized_keys ssh-server:/home/simon/.ssh# rm ../id_rsa_workstation.pub && exit

Identity/Pubkey Authentifizierung auf dem Server einstellen Top

Jetzt wollen wir auf dem SSH-Server einstellen, dass der Server Identity/Pubkey erlaubt.

Dazu editieren wir die sshd_config

sshd_config:#SSH version 1 Identity Authentifizierung RSAAuthentication yes #SSH version 2 Pubkey Authentifizierung PubkeyAuthentication yes #Der Aufbewahrungsort der Schlüssel, ohne führenden Slash liegen sie relativ zum Home-Verzeichnis. AuthorizedKeysFile .ssh/authorized_keys

Nach einem Neustart des Servers sollte der SSH-Server Identity/Pubkey Authentifizierung erlauben.

Jetzt können wir noch die normale Passwort-Authentifizierung abschalten:

sshd_config: PasswordAuthentication no UsePAM no

Nachdem wir jetzt alles vorbereitet haben, können wir den Unterschied ausprobieren:

Code: workstation:/# ssh ssh-server Enter passphrase for key '/home/simon/.ssh/id_rsa':

Mit dem Parameter -v können wir übrigens sehen, was passiert, wenn wir uns mit einem SSH-Server verbinden.

Schlüsselpaar auswählen Top

Mit dem Parameter -I <keyfile> können wir den Schlüssel auswählen, der für die Identity/Pubkey Authentifizierung verwendet wird:

Code: workstation:/# ssh -i ~/.ssh/ssh_key ssh-server Enter passphrase for key '/home/simon/.ssh/ssh_key':

Standardmäßig lässt sich das in der Datei ~/.ssh/config eintragen:

Code: Host ssh-server IdentityFile ~/.ssh/special_ssh_key

Ratschläge Top

Der angelegte Schlüssel sollte eine Passphrase benutzen, damit der Schlüssel geschützt ist, die Passphrase wird zum Entschlüsseln des Schlüssels benutzt, ohne diese Passphrase hat jeder, der an den Private Key kommt, vollständigen Zugriff auf den SSH-Server.

Wie man sich bei einem SSH-Server mit einer Passphrase einloggen kann, ohne ein Passwort eintippen zu müssen, wird wahrscheinlich im nächsten oder übernächsten Artikel gezeigt.
Bei älteren Versionen von ssh kann es vorkommen, dass authorized_keys für SSHv1 und authorized_keys2 für SSHv2 benutzt wird, ein Hardlink, der mit ln authorized_keys authorized_keys2 erzeugt wird, löst dieses Problem.

Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?Editieren Versionen Linkpartnerschaft Top PrintversionHaben Sie einen Fehler gefunden? Dann klicken Sie doch auf Editieren, und beheben den Fehler, keine Angst, Sie können nichts zerstören, das Tutorial kann wiederhergestellt werden

Sprachenübersicht/Betriebssysteme/Linux/Security/Secure SSH Tutorial Part 2: Identity/Pubkey Authentifizierung

Secure SSH Tutorial Part 3: Usage

Vorwort Top

Im ersten Teil dieser Tutorialserie ging es um die sichere Verwaltung des Host-Schlüssels, der zweite Teil beschäftigt sich mit Identity/Pubkey Authentifizierung unter SSH.

Dieser Teil soll den Umgang mit den Tools, die SSH zur Verfügung stellt lehren, und basiert auf den ersten zwei Tutorials.

ssh - remote login program Top

ssh ist ein Programm, mit dem man sich mit einem anderen Computer verbindet, und ihn fernsteuert.

ssh wurde entwickelt um Programme wie z.B rlogin, oder rsh mit einem verschlüsselten Protokoll zu ersetzen.
ssh unterstüzt auch X11 forwarding, damit kann man die grafische Ausgabe von Linux übertragen.
Hier ist eine Auflistung der für uns relevanten Parameter: ssh [-p Port] [-l login_name] [user@]hostname [command] Falls command angegeben wird, wird dieser Befehl anstelle der login shell gestartet. -p <Port> gibt den Port an, auf dem der SSH-Server läuft, -l <login_name>, und [user@] den Benutzername, mit dem man sich auf dem System anmeldet, und hostname die IP-Adresse, oder den hostname des Systems.
Als Beispiel:

Code:workstation:/home/simon# ssh -l simon -p 443 localhost Password: Linux vsn-server 2.6.11 #3 SMP Thu Mar 3 22:27:04 CET 2005 i686 unknown Most of the programs included with the Debian GNU/Linux system are freely redistributable; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law.

Last login: Wed Aug 17 16:01:26 2005 from 192.168.0.2 simon@vsn-server:~$

Wie man ein Identity/Pubkey auswählt, wird hier im Teil 2 beschrieben.

Die Behandlung von Schlüsseln wird in den ersten Tutorial ausreichend beschrieben.

scp - remote file copy program Top

scp kopiert Dateien zwischen dem ssh server, und dem localhost verschlüsselt über ein Netzwerk.

Wichtige Parameter: scp [-l limit] [-r] [-P port] [-S program] [[user@]host1:]file1 [...] [[user@]host2:]file2 -l <limit> setzt die Bandbreite auf <limit> Kbit/s. -P <Port> gibt den Port des ssh-servers an. -r kopiert die Dateien rekursiv (d. h. mit allen Unterverzeichnissen).
Beispiel:

Code:workstation:/home/simon# scp datei.txt simon@vsn-server:/home/simon/files/

kopiert die Datei datei.txt aus dem aktuellen Ordner auf den ssh-server (vsn-server) in das Verzeichnis /home/simon/files.

Natürlich lassen sich so Dateien auch auf den Server kopieren, etwas was wir im zweiten Tutorial gemacht haben:

Code:workstation:/home/simon# scp -r simon@vsn-server:/home/simon/files/ /home/simon/incoming

kopiert die Dateien aus /home/simon/files vom ssh-server rekursiv in das lokale Verzeichnis /home/simon/incoming.

ssh - forwarding Top

Ein weiteres Feature von SSH ist Port Forwarding, damit kann man beispielsweise auf einen unverschlüsselten Dienst auf dem Server verschlüsselt zugreifen, oder eine verschlüsselte Verbindung zum Server aufbauen, und den Server dann als Proxy benutzen.

Es gibt 2 Arten von forwarding in SSH: * Local-Forward Nehmen wir an wir haben in Australien einen Mail-Server.
Wenn wir eine normale Verbindung über 110 mit ihm aufbauen, dann werden die Daten unverschlüsselt zum Server übertragen.
Deshalb bauen wir mit dem SSH-Server eine Verbindung auf, und öffnen eine Verbindung vom lokalen Port 123 über den SSH Tunnel zum Port 110 auf dem Mailserver. [workstation:123] -> verschlüsseln -> [ssh-server] -> unverschlüsselt [mailserver:110] Der Mailserver kann natürlich (im besten Fall) auch der SSH-Server sein Dafür machen wir folgendes:
Code:workstation:/home/simon# ssh -l simon -L 123:mailserver:110 ssh-server simon@ssh-server's password: ssh-server:/home/simon#
Solange diese Verbindung offen ist, hält SSH den lokalen Port 123 offen, deshalb lassen wir das Fenster jetzt offen, und öffnen ein neues:
Code:workstation:/home/simon# telnet 127.0.0.1 123 +OK Hello there.
USER blablab@babala.com +OK Password required.
PASS hallo +OK logged in.
Jetzt wird unsere Verbindung bis zum ssh-server, der bestenfalls unser mailserver ist, verschlüsselt.
Mit -g, oder GatewayPorts yes in der Datei ~/.ssh/config oder /etc/ssh/ssh_config wird der Port 123 übrigens nicht nur lokal, sondern global an localhost gebunden.

Remote-Forward Remote-Forwarding ist genau der umgekehrte Weg.
Nehmen wir an, wir haben bei der Arbeit eine Windows Kiste, und wir wollen zuhause weiter Arbeiten.
Leider lässt die Firewall Verbindungen nach innen nicht zu.
Jetzt kommt SSH ins Spiel: Wir bauen eine Verbindung nach Hause (Linux Box) auf, und leiten den Port 445 vom Büro nach Hause auf 123 um: Zuerst müssen wir in der .ssh/config Datei auf der Arbeit den Port-Forward freigeben:
~/.ssh/config:Host samba-tunnel-home Hostname ip-at-home RemoteForward 123:localhost:445 User simon
Jetzt können wir uns von der Arbeit zuhause einloggen, und alle paar Sekunden etwas nach Hause schicken, damit die Verbindung nicht von einer Firewall oder etwas ähnlichem unterbrochen wird:
Code:work:/home/simon# ssh samba-tunnel-home simon@ip-at-home's password: simon@vsn-server:/home/simon# ping -i 8 127.0.0.1 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.3 ms
Jetzt lassen wir das Fenster offen, und später können wir uns daheim an den Linux Computer setzen:
Code:workstation:/home/simon# last -1 simon pts/18 work.nat.ip Tue Aug 18 19:24 still logged in
Passt, die Verbindung steht noch, also weiter:
Code:workstation:/home/simon# mkdir work/ workstation:/home/simon# smbmount \\127.0.0.1\blubbfishordner work/ port=123
Tada, im Ordner /home/simon/work ist jetzt der Ordner blubbfishordner von der Arbeit gemounted.
Hier können wir den Port ebenfalls global machen, indem wir GatewayPorts yes in der Datei /etc/sshd_config eintragen.

ssh - sshfs Top

FUSE Hier wird FUSE, und sshfs benötigt.
Eine Anleitung wie man die Pakete installiert.
Mit dem Befehl:
Code:sshfs -p <port> <user>@<host>:<directory> <mountpoint>
wird das Verzeichnis eingebunden, wobei -p (Standard: 22), und <directory> (standard: Homeverzeichnis) optional sind.
Damit wird das Verzeichnis wieder ausgebunden:
Code:fusermount -u <mountpoint>
Wenn dieser Fehler auftaucht:
Code:fusermount: unknown option -- Try `fusermount -h' for more information
dann haben Sie noch eine andere Version in einem anderen Verzeichnis installiert.
whereis fusermount zeigt ihnen wo sich das Programm befindet, löschen Sie das ältere.

Lufs Für sshfs brauchen sie Lufs.
Laden sie es herunter und installieren Sie es. (/usr/local/lib in /etc/ld.so.conf eintragen, und ldconfig benutzen nicht vergessen) Ausserdem brauchen Sie ein Kernel modul: File systems -> Filesystem in Userspace support das ab dem Kernel 2.6.14 implementiert ist.
Mit dem Befehl:
Code:mount -t lufs none mountingpoing -o nosuid,fs=sshfs,host=<host>,username=<username>,port=22,fmode=444,dmode=555
wird das Verzeichnis eingebunden.
Mit umount <mountingpoint> können Sie es wieder ausbinden.

ssh - X11 forwarding Top

Mit SSH, ist eine einfache, und verschlüsselte Bildschirmübertragung möglich, das funktioniert ganz einfach: wir verbinden uns über den SSH-Client und dem Parameter -X, der SSH-Server startet einen virtuellen X-Server, und setzt DISPLAY entsprechend:

Code:simon@workstation:/home/simon# xhost access control enabled, only authorized clients can connect work@workstation:/home/simon# ssh -X -l simon ssh-server Password: simon@vsn-server:/home/simon# nedit simon@vsn-server:/home/simon# echo $DISPLAY localhost:10.0 simon@vsn-server:/home/simon# xauth Using authority file /home/simon/.Xauthority xauth> exit

Ich hoffe dieser Part hat einen guten Überblick über die Funktionen und features von SSH geschaffen Der nächste Part wird wahrscheinlich die Themen "ssh-agent", und "ssh-server security allgemein" behandeln.

Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?Editieren Versionen Linkpartnerschaft Top PrintversionHaben Sie einen Fehler gefunden? Dann klicken Sie doch auf Editieren, und beheben den Fehler, keine Angst, Sie können nichts zerstören, das Tutorial kann wiederhergestellt werden

Sprachenübersicht/Betriebssysteme/Linux/Security/Secure SSH Tutorial Part 3: Usage

Secure SSH Tutorial Part 4: Security & ssh-agent

Sprachenübersicht/Betriebssysteme/Linux/SecuritySecure SSH Tutorial Part 4: Security & ssh-agentDiese Seite wurde 34216 mal aufgerufen.Dieser Artikel wurde in einem Wikiweb System geschrieben, das heißt, Sie können die Artikel jederzeit editieren, wenn Sie einen Fehler gefunden haben, oder etwas hinzufügen wollen.Editieren Versionen Linkpartnerschaft Bottom Printversion

Keywords: Security, SSH, Tutorial, ssh-agent, agent, iptables

Vorwort Top

Im ersten Teil dieser Tutorialserie ging es um die sichere Verwaltung des Host-Schlüssels, der zweite Teil beschäftigt sich mit Identity/Pubkey Authentifizierung unter SSH.

Der dritte Teil hat sich mit dem Ungang mit den SSH-Tools beschäftigt.
In diesem Teil werden wir uns mit einigen Sicherheitszusätzen beschäftigen, und den ssh-agent kennen lernen.

Kapitel 1: Der ssh-agent Top

Im zweiten Teil haben wir die gewöhnliche plaintext-Passwort-Authentifizierung gegen eine Identity/Pubkey Authentifizierung ausgetauscht.

Dort habe ich versprochen einen Artikel zu bringen, in dem erklärt wird, wie wir einrichten, dass wir keine passphrase mehr eingeben müssen.
Das machen wir jetzt mithilfe von ssh-agent.

ssh-agent Enviroment-Variablen setzen Top

Als erstes starten wir den ssh-agent ohne Parameter:

Code:workstation:/home# ssh-agent SSH_AUTH_SOCK=/tmp/ssh-OqdW7921/agent.7921; export SSH_AUTH_SOCK; SSH_AGENT_PID=7922; export SSH_AGENT_PID; echo Agent pid 7922;

Der ssh-agent gibt Informationen aus, die wir nutzen können um die enviroment-variables der shell zu setzen.

Sollten Sie in einer anderen shell, beispielsweise einer C-shell, ala /bin/csh oder /bin/tcsh arbeiten, können diese Variablen anders sein, in diesem Fall sollten Sie die Parameter -c oder -s benutzen, um den C-Shell, bzw.
Bourne shell Syntax ausgeben zu lassen.
Wir müssen die SSH Enviroment-Variable SSH_AUTH_SOCK setzen, damit ssh weiß, wie mit dem ssh-agent kommunizieren kann, jedesmal wenn der ssh-agent gestartet wird, sollten wir diese Variable setzen.

Code:#Wir testen ob Variablen gesetzt sind workstation:/home# set | grep SSH_ #Variablen mit eval setzen workstation:/home# eval `ssh-agent` Agent pid 7943 #Jetzt sind wir bereit, nur noch testen: workstation:/home# set | grep SSH_ SSH_AUTH_SOCK=/tmp/ssh-xoGi7942/agent.7942 SSH_AGENT_PID=7943

Jetzt haben wir die SSH_AGENT_PID Variable gesetzt.

Wenn wir den ssh-agent nicht mehr als Daemon laufen lassen wollen können wir ihn mit ssh-agent -k killen.

ssh-agent Schlüssel hinzufügen Top

Als nächstes müssen wir Schlüssel mit dem Programm ssh-add hinzufügen.

Wenn wir ssh-add ohne Parameter starten wird es automatisch die Schlüssel von $HOME/.ssh/identity, $HOME/.ssh/id_rsa, und $HOME/.ssh/id_dsa zum laufenden ssh-agent hinzufügen.
Da unsere Schlüssel immer(!) mit passphrases geschützt sind, wird uns das Programm automatisch nach der passphrase fragen.

Code:#Wir testen ob der ssh-agent läuft workstation:/home# ps -fp $SSH_AGENT_PID UID PID PPID C STIME TTY TIME CMD lainee 7943 1 0 15:52 ? 00:00:00 ssh-agent #Welche keys sind bereits im ssh-agent -l = list workstation:/home# ssh-add -l The agent has no identities. #Keys importieren workstation:/home# ssh-add Enter passphrase for /home/simon/.ssh/id_rsa: Identity added: /home/simon/.ssh/id_rsa (/home/simon/.ssh/id_rsa) Identity added: /home/simon/.ssh/identity (simon@workstation) #Keys aus einer anderen Datei imporiteren workstation:/home# ssh-add ssh-keys/id* Enter passphrase for id_rsa.simon: Identity added: id_dsa.simon (id_dsa.simon)

Das Beispiel sollte selbst-erklärend sein.

ssh-agent Schlüssel löschen Top

Wenn wir zu viele Schlüssel im ssh-agent haben, einen Schlüssel nicht länger, oder nur für eine kurze Zeit brauchen, dann wollen wir den Schlüssel aus dem Schlüsselbund entfernen, mit ssh-add -d kann ein Schlüssel von ssh-agent entfernt werden:

Code:workstation:/home# ssh-add -d ~/.ssh/id_dsa Identity removed: id_dsa (id_dsa.pub) workstation:/home# ssh-add -l The agent has no identities.

ssh-add -D löscht alle Schlüssel.

ssh-agent Zu viele Schlüssel Top

Der SSH-Server erlaubt uns nur eine bestimmte Anzahl von Versuchen für eine bestimmte Zeit, jeder falsche Login-Versuch zieht uns erlaubte Versuche ab.

Wenn wir viele Schlüssel in ssh-agent haben, kickt uns der Server vielleicht bevor wir uns einloggen können.
Wenn dieser Fall eintrifft gibt es ein paar Möglichkeiten die wir nutzen können: * Wenn wir einen Schlüssel haben den wir nicht mehr brauchen, beispielsweise einen alten RSA1 Schlüssel, können wir ihn mit ssh-agent -d Dateiname löschen, siehe letztes Kapitel

Wir könnten auf Passwort-Authentifizierung umsteigen, dazu können wir temporär SSH_AUTH_SOCK abschalten:
Code:workstation:/home# SSH_AUTH_SOCK= ssh simon@vsn-server
Oder wir machen es per Konfigurations-Datei, ~/ssh/options für einen bestimmen host:
Code:workstation:/home# nano ~/.ssh/config Host vsn-server #Authentifizierung abschalten RSAAuthentication no PubkeyAuthentication no
Die dritte Möglichkeit wäre:
Code:ssh -o 'PubkeyAuthentication=no' -o'RSAAuthentication=no' simon@vsn-server

ssh-agent Unix Domain Socket Top

Wenn der ssh-agent gestartet wird, erstellt er einen unix domain socket, der auf Verbindungen von /usr/bin/ssh wartet, er erstellt ein neues Verzeichnis in /tmp/, mit 0700, und einen socket mit 0600, dadurch werden die Schlüssel für die root Benutzer lesbar.

Mit ls -la /tmp/ssh-*/* lassen sich die sockets auslesen, und mit SSH_AUTH_SOCK=/tmp/ssh-x && export SSH_AUTH_SOCK setzen.

Das Problem lässt sich zwar mit der -c Option beim importieren lösen, danach wird bei der Benutzung eine Bestätigung verlangt, indem ssh-agent das Programm ssh-askpass startet.

Dieses Programm läuft aber auf dem X11 server, der wiederum vom root komplett kontrolliert werden kann.

ssh-agent Lebensdauer der Schlüssel Top

Mit ssh-add -t seconds filename, oder ssh-agent -t seconds können wir die Lebensdauer eines bestimmen Schlüssels, oder von allen Schlüsseln im ssh-agent bestimmen.

ssh-agent Sperren Top

Mit der Option -x kann man den ssh-agent bis zur nächsten Eingabe von ssh-add -x sperren.

Wärend dieser Zeit ist ssh-agent unbenutzbar, eine gute Möglichkeit wenn man für eine bestimmte Zeit weg ist.

ssh-agent agent forwarding Top

Ein weiteres feature ist agent forwarding, dabei "folgt" uns SSH von Rechner zu Rechner, bei jeder weiteren Verbindung erstellt der Server einen ssh-tunnel zurück mit einer Verbindung zum agent.

Wichtig dabei ist das ssh-agent natürlich von jedem root auf dem Rechner ausgelesen werden kann, wenn agent forwarding aktiviert ist.
Wir benutzen agent forwarding so:

Code:workstation:/home# ssh -A user@ssh-server [code] In der globalen ssh_config Datei, die sich normalerweise in /etc/ oder /etc/ssh/ befindet können wir agent forwarding global ausstellen: [code] Host * ForwardAgent no

Wenn wir agent forwarding für einen bestimmten Server einschalten wollen, können wir das mit ForwardAgent yes machen:

Code:Host ssh-server-ip ForwardAgent yes

Kapitel 2: Sicherheitstipps Top

In diesem Kapitel werden noch zusätzlich zu den vorherigen Tutorials Sicherheitstipps besprochen, wobei es sinnlos sein kann, wenn man einige kombiniert, es wird für dasselbe mehrere Möglichkeiten angeboten.

Die Möglichkeit mit den begrenzten logins ist mit einem Pubkey oder mit einer Identity übrigens sinnlos.

Root login abschalten Top

Wenn es zum Konzept passt, kann man in der Datei ssh_config, die sich normalerweise in /etc/ oder /etc/ssh befindet, den login vom Benutzer root abschalten:

Code:PermitRootLogin no

Falls nötig kann man immer noch mit su oder sudo arbeiten.

Nur bestimmte User zulassen Top

Mit der Option AllowUser in der Datei ssh_config kann man nur bestimme User einloggen lassen:

Code:AllowUsers simon blubbfish

Nur ein bestimmtes Land zulassen Top

(Das setzt voraus, dass ssh mit "--with-tcp-wrappers" konfiguriert wurde und die entsprechende Bibliothek vorhanden ist.) Wenn man für das einloggen nur ein bestimmtes Land zulassen will, kann man das in der Datei /etc/hosts.allow machen:

Code:sshd : .at : allow sshd : ALL : deny

Maximale Login Versuche setzen Top

Wenn man nur ein paar login Versuche von einem Host zulassen will, kann man das mit MaxAuthTries in sshd_config machen:

Code:MaxAuthTries 1

Bruteforce Attacks mit iptables stoppen Top

Ich bin hier auf eine Lösung gestossen SSH mit iptables gegen Bruteforce zu schützen:

#!/bin/sh IPTABLES="/sbin/iptables" TRUSTED_HOST="192.168.0.2" $IPTABLES -F $IPTABLES -X $IPTABLES -N SSH_WHITELIST $IPTABLES -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force $IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP

Wenn man innerhalb einer Minute mehr als 3 neue eingehende Verbindungen hat, werden die Verbindungen gedroppt.

Benötigte Module: ipt_ULOG, ipt_state, ip_conntrack, ipt_REJECT, ipt_LOG, ipt_recent, iptable_filter, ip_tables

Alternativ dazu ist das tool fail2ban zu nennen.

Links

https://www.online-tutorials.net/security/secure-ssh-tutorial-part-4-security-ssh-agent/tutorials-t-69-206.html