http://rootiewiki.de/index.php?pagename=TipsUndTricksSSH

Gerade im Bereich der RootServer? ist der Zugang über SSH in vielen Fällen die einzige Möglichkeit, das System zu verwalten. Wird dieser Dienst einmal beendet (durch Speichermangel, Fehler des Admins, etc.), ist man ohne SerielleKonsole? vom System ausgesperrt, und ohne weitere Maßnahmen hilft nur ein Reboot aus dieser Misere. Um solchen Fällen vorzubeugen kann es sehr nützlich sein, den sshd direkt kontrolliert vom init-Prozess starten zu lassen.

Hierzu bedient man sich der OpenSSH-Option "-D" (don't detach), um init die Kontrolle über den Daemon zu ermöglichen. Der dann nötige Eintrag in die /etc/inittab (günstigstenfalls am Ende der Datei) sieht dann wie folgt aus:

ss:12345:respawn:/usr/sbin/sshd -D

Um die Änderungen aktiv werden zu lassen, lässt man init seine Konfiguration über init q neu einlesen, und kann daraufhin den bisher über die InitScript?e gestarteten sshd stoppen.

Eine weitere Variante dieses Tips bestünde darin, diesen sshd über eine eigene Konfigurationsdatei (Option "-f") auf einen eigenen Port lauschen zu lassen, um sich so einen (möglichst gut abgesicherten) zusätzlichen Zugang offen zu halten. Der Phantasie sind hierbei keine Grenzen gesetzt, z.B. wäre es möglich, diesen zusätzlichen Dienst nur auf localhost laufen zu lassen, und im Falle eines Falles über PortKnocking? von außen zugänglich zu machen. Vielleicht kommen hier ja noch weitere Ideen dazu zustande?!? SSH über PublicKeyAuthentifizierung? sicherer machen

Statt "unsicherer" (weil streng genommen zu kurzer) Passworte für den Zugang zu verwenden, kann der SSH-Zugang auch über PublicKeyAuthentifizierung? hergestellt werden. Da dieses Verfahren das "Erraten" eines Passworts allein durch die Länge erheblich unwahrscheinlicher macht, bietet es zudem noch den Vorteil, dass man nicht zwangsläufig für jeden Login sein Passwort eingeben muss.

Zu diesem Zweck ist zunächst ein Schlüsselpaar zu erzeugen:

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

Dieses Kommando generiert einen 2048 Bit langen RSA-Schlüssel (die sonst verwendete Länge von 1024 Bit gilt schon länger nicht mehr als sicher). Während dieses Prozesses wird man nach einer Passphrase gefragt, mit der man diesen Schlüssel noch zusätzlich absichern kann. Der bequemste (aber auch unsicherste) Weg besteht darin, diese Abfrage zwei Mal durch drücken der "Return"-Taste zu bestätigen, wodurch später keine Passphrase benötigt wird.

Achtung: Es ist nicht ungefährlich, einen Key ohne Passphrase zu verwenden, denn dann kann jeder, der sich irgendwie den Schlüssel verschafft, auf dem Server mit den Rechten des Besitzers arbeiten. Solange der Rechner, auf dem der Schlüssel liegt persönliches Eigentum ist, und man sich sicher ist, dass sonst Zugriff darauf hat, mag das noch passabel sein. Sofern es sich dabei aber um einen Fremden Rechner (z.B. in einer Uni oder einem Internetcafe) handelt, ist das Risiko groß. Selbst im Falle eines privaten Rechners kann man nie 100%ig sicher sein, dass man der einzige User ist (Stichwort RootKit?). Sofern der Schlüssel nicht durch eine Passphrase geschützt ist, kann ein potenzieller Angreifer 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.

Der öffentliche Teil dieses Schlüssels muss daraufhin nur noch auf den Zielrechner kopiert werden, wozu man sich wiederum der Hilfe von SSH bedienen kann:

user@localhost:~ > ssh user@remotehost.domain.example \ "umask 077; mkdir -p .ssh; cat >> .ssh/authorized_keys" <.ssh/id_dsa.pub

Die Angabe der umask ist wichtig, da der sshd die Datei mit anderen Berechtigungen als 0600 nicht akzeptieren wird. Ein SSH-Login auf dem anderen System sollte jetzt ohne die Eingabe eines Passworts möglich sein. Schlägt sie fehl, sollten folgende Punkte überprüft werden:

• Ist PubkeyAuthentication in der sshd_config auf "yes" gesetzt?

• Stimmt der Wert der Option AuthorizedKeysFile mit dem oben genannten überein?

Getrennte Einstellungen für spezielle Rechner

Hat man es mit mehreren SSH-Zugängen zu tun, die jeweils eigene Einstellungen benötigen, kann es sehr nützlich sein, diese in seiner eigenen ssh-Konfigurationsdatei einzutragen, um sie nicht jedes Mal händisch eingeben zu müssen. Dies kann beispielweise schon der Fall sein, wenn der Benutzername auf dem fremden System ein anderer ist als der, den man lokal nutzt. Diese Konfigurationsdatei (.ssh/config) ist in den meisten Fällen allerdings zuerst anzulegen, und könnte z.B. wie folgt aussehen:

Host remote

• Hostname remotehost.domain.example User remoteuser

# ForwardX11 yes # falls man auf dem fremden System X11-Programme starten will. # Port 23 # nur für spezielle Fälle

Mit IP-Adressen funtz das natürlich auch!

http://www.theparallax.org/security/linux/ssh/ssh_keygen.html

find /lib/modules/$(uname -a | cut -f3 -d" ") | grep ip      

Zumüllen der known_hosts verhindern

Wenn man sich regelmässig per ssh auf einen Rechner mit dynamischer IP-Adresse verbindet, müllt man sich auf Dauer die .ssh/known_hosts voll. Folgender Eintrag in die .ssh/config verhindert dies:

Host foo.bar.baz CheckHostIP no

http://www.koneczny.info/node/98

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 4 --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 4 --rttl \
--name SSH -j DROP
----
----
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl  --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60  --hitcount 4 --rttl --name SSH -j DROP

http://www.sshkeychain.org/mirrors/SSH-with-Keys-HOWTO/SSH-with-Keys-HOWTO-4.html

$SSH without password:micro HOWTO - by Arunchandar Vasan

ssh is a secure clone of rsh with RSA encryption based authentication. This micro HOWTO tells you how to use ssh without having to type in your password everytime you use ssh. I had to RTFM, and I hope this will be googled for others to use.

0. The basis of using ssh without typing your password is public key based authentication. You need to generate a pair of public/private keys for this. We shall stick to version 2 of ssh.

1. Firstly, generate your public/private keys using ssh-keygen

% ssh-keygen -t rsa

You must use the -t option to specify that you are producing keys for SSHv2 using RSA. This will generate your id_rsa and id_rsa.pub in the .ssh directory in your home directory. I strongly suggest using a passphrase.

2. Now copy the id_rsa.pub to the .ssh directory of the remote host you want to logon to as authorized_keys2 .

[Note: If you have more than one host from which you want to connect to the remote host, you need to add the local host's id_rsa.pub as one line in the authorized_keys2 file of the remote host, i.e., you can have more than one entry. Thanks to Jinn Koriech for pointing this out. Also, you need to 'chmod 644 authorized_keys2' to make it unwritable to everybody apart from the user. Thanks to Matthew Lohbihler for this info.]

You are basically telling the sshd daemon on the remote machine to encrypt the connection with this public key and that this key is authorized for version 2 of the ssh protocol. Try using something secure like scp for this copying.

% scp ~foo/.ssh/id_rsa.pub foo@bar.cs.umd.edu:~foo/.ssh/authorized_keys2

3. Your public key based authentication has been setup. You won't be asked your password on the remote machine. However, you need a program that manages your keys for you called an agent. You need to start the agent, tell it your passphrase, and hook up to the agent whenever you need to connect to the remote machine.

4. We shall assume the following situation: You logon to a console and then startx as in say, an out-of-the-box Linux installation. You should figure out what exactly has to be done for your specific machine's X initialization. All the following steps are to be done on your local machine, in this case- localmachine.cs.umd.edu.

5. Fire your favourite editor, and pull up your .profile file. Add the following line to the file:

alias startx='ssh-agent startx'

This means that every child of startx (i.e. anything under X) would be able to hookup to the agent.

6. Edit your .xinitrc file by adding the following lines:

DISPLAY="localmachine.cs.umd.edu:0"
SSH_ASKPASS="/usr/libexec/openssh/x11-ssh-askpass"
ssh-add < /dev/null

# Change this to whatever window manager you use under X
# or leave whatever was there unchanged.
startkde

.xinitrc is the init file for X. Unfortunately, as ssh-add doesn't have a controlling terminal, it needs to be told to read input from an external source. When you specify, /dev/null, the program pops up a d-box program specified by $SSH_ASKPASS and ask you for your passphrase. The d-box can be as simple as an xterm, but you could use the x11-ssh-askpass that comes with your openssh installation. The DISPLAY is usually automatically set, but just in case.

Nota Bene: If you had to create .xinitrc, then you must add something after the ssh-add statement to start the window-manager/desktop/whatever. Otherwise, X will simply terminate after asking for the password. If you don't know how to set this up, you might want to dig in your /etc/X11/init.d files for the appropriate init sequences.

7. Now when you startx, a dialog box should pop up and ask you for your passphrase. You are all set. Open up an xterm, and say

% ssh bar.cs.umd.edu

Voila ! You'll be logged in without typing in your password. You'll have to re-enter your passphrase, everytime you start X. The passphrase can be side-stepped by giving the empty string, but I'd rather you don't.

8. As a fringe benefit, you can execute any GUI based programs on the remote machine for free, no setting up $DISPLAY , no need to xhost+ etc. Cool, eh ?

NB: No promises if this will work for you. I am not responsible if you screw up your workspace environment and/or your machine. I'd appreciate it if you let me know if you found this useful.

 Tags: linux | security | putty | windows | unix | howto | network | software | rsync | debian

Linux/Sicherheit/ssh (last edited 2009-06-26 07:57:03 by DetlevLengsfeld)