# pam und ssh

## Mageta

Hallo Leute,

ich hab da ein kleines Problem.

Ich versuch gerade meinen ssh wenigstens ein wenig vor attacken von außen zu schützen, vor allem vor brute force und co.

Dazu hab ich versucht ssh mit  pam zu "verbinden"

Aber irgendwie gelingt es mir nicht so recht.

Hier sind mal die 3 wesentlichen Dateien:

/etc/ssh/sshd_config http://phpfi.com/291946

/etc/pam.d/sshd http://phpfi.com/291947

/etc/pam.d/system-auth http://phpfi.com/291948

Es soll halt so sein. Der User darf 4mal versuchen sich anzumelden und wenn er es beim 4. mal (egal ob er zwischendrin Cc drückt oder so) nicht schafft wird der Account für eine Stunde gesperrt (ich weiß in der sshd steht noch 1 Minute, is nur zu testzwecken).

Allerdings passiert folgendes wenn ich mich anmelde. Ich kann max. 3mal ein password eingeben und dann schmeißt er mich erstmal raus. Wenn ich dann nochmal anwähle kann ich wieder 3mal ein password eingeben usw. Obwohl der tally-count laut log schon bei über 4 steht. Wo er also schon lange den acc sperren sollte.

Ich hab schon viel Probiert aber ich schaff es irgendwie nicht. Vlei hat ja jemand von euch noch ne gute Idee.

grüße,

Mageta

P.S: ich weiß man kann das ganze auch viel einfacher UND sicherer machen, mit nem asymetrischen schluesselverfahren aber ich will es erstmal so versuchen. Weil mit den Schluesseln wird dass dann wieder son Ding, wenn ich mal irgendwo rein muss, dann hab ich den schluessel garantiert nicht zur verfügung..

----------

## ChrisJumper

Hi Mageta,

ich bin grade zwar noch zu müde um deinen Fehler mit oder in der pam Konfiguration zu finden. Aber hast du schon mal an Port-Knocking gedacht? Natürlich könnt man jetzt sagen das kann man erkennen und mitschneiden oder so. Aber vielleicht ist es einfacher für dich eine knock-Skript mit einer Spezifischen Kombination zu schreiben die sich z.B. nach drei Parametern wie "Vergangene Zeit ab einem bestimmten Datum", "Anzahl der versuchten Anklöpfe pro Tag" einzurichten, als dich mit pam anzufreunden. Schließlich kann man diese Begrenzung ja auch in das Knock-Skript integrieren.

Howto-Port-Knocking.

Voraussetzung ist das du iptables installiert hast und dich ein wenig damit auskennst.

Grüße

----------

## Mageta

Hmm werd ich mal versuche, danke erstmal.

Ja iptables is drauf, is ja nen kleiner Router und das geht nunmal mit den tables prima.

Falls totzdem noch jemand ne Idee haben sollte, immer her damit  :Wink: 

----------

## Korban1981

Also ich kann dir da Blockhosts empfehlen.

Anhand deiner Logfiles (du kannst ja deine SSH Zugriffsversuche loggen) sucht das Programm nach Zugriffsversuchen und je nach deinen Einstellungen sperrt er bei x Fehlversuchen die IP desjenigen, speichert diese in hosts.allow und löscht sie auch nach einer bestimmten Zeit die du selbst festlegen kannst.

Also z.B. 3 Fehlversuche, die das Programm an den typischen SSH Zugriffsabweisungen selbst findet, sperrt die IP für z.B. 5 Stunden oder 1 Monat, je nach deinen Einstellungen.

Simple Installation und Konfiguration, empfehlenswert ist eine seperate Logfile für deine SSH Zugriffe.

Link: http://www.aczoom.com/cms/blockhosts

----------

## TheSmallOne

 *Mageta wrote:*   

> Allerdings passiert folgendes wenn ich mich anmelde. Ich kann max. 3mal ein password eingeben und dann schmeißt er mich erstmal raus.

 

Ich persönlich halte ja nichts von PAM... wie auch immer: SSH ist eigentlich so schon ganz sicher und bietet auch so einige Möglichkeiten.

Ich würde z.B. generell keine Authetisierung über Passwort zulassen, sondern immer nur über Public-Keys... damit ist es relativ unmöglich, dass jemand unbefugtes sich einloggt.

Davon abgesehn ist es sowieso nicht so gut, den Account zu sperren, in den der Angreifer sich einloggen will; damit erlaubt man es ihm effektiv den wahren Nutzern den Dienst zu versperren.

----------

## root_tux_linux

Hab ich auch schon versucht mit max 3 Login versuchen und dann sperre.

Hab mir danach syslog-ng so angepasst das er alle fehlgeschlagenen Loginversuche in eine spezielle Log schreib, diese wird dann von meinem Python Script ausgelesen, wenn es mehr als 3 Versuche sind wird die IP mittels IP Tables gesperrt.  :Smile: 

Muss noch an dem Script feilen und paar Funktionen hinzufügen  :Smile: 

Sowas in der Art könnte man doch auch für die User machen?

Ist in der Log mehr oder gleich 4 Loginversuche für den Username "Foobar" schreibe Zeit in File/DB was auch immer und sperre den Account.

----------

## furanku

Hallo,

ich weiß, Du hast nach einer Umsetzung Deiner Idee gefragt, und Methoden den sshd zu schützen gibt es viele, und alle haben ihre Vor- und Nachteile. Ich will hier trotzdem noch mal eine andere vorstellen, die den Vorzug hat nur mit Bordmitteln auszukommen und den Job bei mir zumindest sehr zuverlässig macht.

In diesem HOWTO wird beschrieben, wie Du nur mit iptables realisierst, daß nur ein ssh Verbindungsversuch pro IP alle 30 Sekunden erlaubt wird.

Das hat IMHO einige Vorteile: Zunächst mal sind keine "weiteren" Skripte und Programme beteiligt, die gewartet und "extra" konfiguriert werden müssen und evtl. selber wieder Sicherheitslücken haben. Du brauchst Dir auch keinen anderen Port zu merken, oder ein Port-Knocking Sequenz. Port-Knocking hat auch den Nachteil, daß Du dafür entweder ein Tool brauchst, daß Du auf USB Stick oder ähnlichem mitnehmen mußt, oder gar auf einem anderen Rechner auf der Kommandozeile starten mußt (dann ist es in dessen Shell History, mindestens aber in dessen syslog). Den USB Stick bräuchtest Du auch, wenn Du die Authentifizierung via Passwort sperrst um Deinen Key mit herumzuschleppen. Mal davon abgesehen, daß das unpraktisch ist, würde ich einen Key nicht auf einen öffentliches Terminal, wie es z.B. bei Konferenzen oft zu finden ist, installieren (OK, da könnte auch ein Keyboard-Logger installiert sein, ganz sicher geht es eben nicht ...)

Auch werden keine Accounts gesperrt, was bei Brute Force Angriffen wohl keinen Sinn macht, und schlimmstenfallst dazu führt, daß man dich ärgern kann, indem man andauernd falsche Passwörter für Deinen Account eingibt, so daß Du diesen selber nicht mehr benutzen kann, sondern IPs. Auch findet das Filtern auf Paketebene statt, so daß ein Bruteforce Angreifer nach dem ersten erfolglosen Versuch noch nicht mal mehr sehen kann ob bei Dir überhaupt ein sshd läuft, alles was er bekommt ist ein Timeout, ansonsten ist der Port einfach tot. 30 Sekunden reichen damit die üblichen Skripte aufgeben. 

Einziger Nachteil ist, daß Du selber, nach einem Vertipper beim Passwort 30 Sekunden warten mußt bis Du den nächsten Versuch starten darfst. Aber damit kann ich leben --- und meine Log Files sind seit dem "sauber"   :Very Happy: Last edited by furanku on Sun Feb 24, 2008 10:12 am; edited 1 time in total

----------

## schachti

 *root_tux_linux wrote:*   

> Hab mir danach syslog-ng so angepasst das er alle fehlgeschlagenen Loginversuche in eine spezielle Log schreib, diese wird dann von meinem Python Script ausgelesen, wenn es mehr als 3 Versuche sind wird die IP mittels IP Tables gesperrt. 

 

Sowas gibt's doch schon (auch in portage): Fail2ban.

----------

## root_tux_linux

 *schachti wrote:*   

>  *root_tux_linux wrote:*   Hab mir danach syslog-ng so angepasst das er alle fehlgeschlagenen Loginversuche in eine spezielle Log schreib, diese wird dann von meinem Python Script ausgelesen, wenn es mehr als 3 Versuche sind wird die IP mittels IP Tables gesperrt.  
> 
> Sowas gibt's doch schon (auch in portage): Fail2ban.

 

Na toll ^^

Immer wenn ich denke ich hab was gefunden was ich schreiben könnte, existiert es schon.

Für was hob ich mich durch "Einführung in Python" gequält  :Sad: 

----------

## furanku

 *root_tux_linux wrote:*   

> 
> 
> Für was hob ich mich durch "Einführung in Python" gequält 

 

Damit Du's jetzt kannst?! Ist ja nicht so, daß das die einzige mögliche  Anwendung von Python wäre ...   :Wink: 

----------

## schachti

Da das ganze in python geschrieben ist, kannst Du mit Deinen neu erworbenen Kenntnissen jetzt an der Weiterentwicklung mitarbeiten.   :Wink: 

----------

## root_tux_linux

 *furanku wrote:*   

>  *root_tux_linux wrote:*   
> 
> Für was hob ich mich durch "Einführung in Python" gequält  
> 
> Damit Du's jetzt kannst?! Ist ja nicht so, daß das die einzige mögliche  Anwendung von Python wäre ...  

 

 *schachti wrote:*   

> 
> 
> Da das ganze in python geschrieben ist, kannst Du mit Deinen neu erworbenen Kenntnissen jetzt an der Weiterentwicklung mitarbeiten. 

 

Na dann hoffen wir mal das die Jungs deutsch können lol

----------

## TheSmallOne

 *furanku wrote:*   

> Einziger Nachteil ist, daß Du selber, nach einem Vertipper beim Passwort 30 Sekunden warten mußt bis Du den nächsten Versuch starten darfst. Aber damit kann ich leben --- und meine Log Files sind seit dem "sauber"  

 

Hä? Seit wann baut SSH denn nach einem fehlerhaften Passwort direkt die Verbindung ab? Hat man nicht normalerweise drei Versuche (oder welche Anzahl auch immer in der Konfig-Datei eingestellt ist), bovor die Verbindung physisch getrennt wird?

----------

## furanku

 *TheSmallOne wrote:*   

> Hä? Seit wann baut SSH denn nach einem fehlerhaften Passwort direkt die Verbindung ab? Hat man nicht normalerweise drei Versuche (oder welche Anzahl auch immer in der Konfig-Datei eingestellt ist), bovor die Verbindung physisch getrennt wird?

 

Das hat in diesem Fall nichts mit dem ssh daemon zu tun, das machen die iptables Regeln. Die stellen fest, daß es auf Port 22 zu einem neuen Verbindungsversuch kam, und blockieren dann für 30 Sekunden jeden weiteren Versuch eine neue Verbindung (z.B. falls der Erste nicht geklappt hat, das Login also nicht erfolgreich war) von dieser IP zu Port 22 auf Deinem Rechner aufzubauen, indem sie die entsprechenden Pakete einfach verwerfen. Diese erreichen also Deinen sshd garnicht mehr und werden von den iptables Regeln gleich von der Netzwerkkarte nach /dev/null geschickt. Der Port ist also schon auf Netzwerk-Ebene nicht mehr erreichbar, nicht erst auf Protokoll-Ebene, wie es wäre wenn der sshd die Verbindung ablehnen würde.

Es ist ein bisschen so, als hättest Du für alle neu eingehenden ssh Verbindungen von dieser IP für 30 Sekunden das Netzwerkkabel herausgezogen. Naja, das ist jetzt ein bisschen arg übertrieben, da die Paketfilter auch "nur" Software sind, sind die natürlich nie so sicher wie eine physikalisch getrennte Verbindung, soll allerdings auch nur den prinzipiellen Unterschied der Layer zwischen sshd Konfiguration und Paketfilter verdeutlichen. Das echte physikalische Trennen der Verbindung ist wieder ein Layer tiefer, die iptables ziehen nur den "Stecker" zwischen dem Kernel und dem ssh Dienst.

(OSI Layer Modell Experten mögen die Ungenauigkeiten verzeihen ... mir ging es nur um's Prinzip der verschiedenen Layer)

----------

## mv

 *furanku wrote:*   

> In diesem HOWTO wird beschrieben, wie Du nur mit iptables realisierst, daß nur ein ssh Verbindungsversuch pro IP alle 30 Sekunden erlaubt wird.

 

Das hat erstens den Nachteil, dass $BOESER_BUBE_MIT_IP_FAKE Dich ohne großen Aufwand für alle Zeiten aussperren kann.

Zweitens - und vor allem - schützt es Dich natürlich nicht vor möglichen Bugs in sshd selbst.

 *Quote:*   

> Zunächst mal sind keine "weiteren" Skripte und Programme beteiligt, die gewartet und "extra" konfiguriert werden müssen und evtl. selber wieder Sicherheitslücken haben.

 

Mit exakt dem selben "recent"-Modul lässt sich auch Port-Knocking realisieren, siehe dieses Firewall Skript.

 *Quote:*   

> Port-Knocking hat auch den Nachteil, daß Du dafür entweder ein Tool brauchst, daß Du auf USB Stick oder ähnlichem mitnehmen mußt

 

Nö. Man kann ssh selbst zum knocken benutzen. Klar, dem Rechner, von dem aus man sich einloggt, muss man vertrauen - das muss man sowieso, da dieser auf jeden Fall die Möglichkeit hat, den Schlüssel und alle Tasten abzugreifen...

----------

## TheSmallOne

 *furanku wrote:*   

> Das hat in diesem Fall nichts mit dem ssh daemon zu tun, das machen die iptables Regeln. Die stellen fest, daß es auf Port 22 zu einem neuen Verbindungsversuch kam, und blockieren dann für 30 Sekunden jeden weiteren Versuch eine neue Verbindung (z.B. falls der Erste nicht geklappt hat, das Login also nicht erfolgreich war) von dieser IP zu Port 22 auf Deinem Rechner aufzubauen, indem sie die entsprechenden Pakete einfach verwerfen.

 

Ich weiß schon was IP-Tables macht.

Aber du beschreibst das so, als würde nach einem fehlerhaften Passwortversuch die Verbindung getrennt, denn nur wenn die Verbindung getrennt wird muß man eine neue Aufbauen.

Aber normalerweise ist es doch so, dass die (erste) Verbindung bestehen bleibt, auch wenn das Passwort falsch war und erst nach dem dritten Fehlversuch wird tatsächlich die Verbindung getrennt. Das ist wie mit einem Telefonanruf: Man hat drei Versuche, bevor die andere Seite auflegt, und wenn sie erstmal aufgelegt hat, dann nimmt sie für 30 Sekunden keinen Anruf mehr an.

----------

## furanku

 *mv wrote:*   

> Das hat erstens den Nachteil, dass $BOESER_BUBE_MIT_IP_FAKE Dich ohne großen Aufwand für alle Zeiten aussperren kann.
> 
> 

 

Dazu müßte er ja die IP des Rechners von dem ich mich gerade Einloggen will kennen. Das ist doch ein ganz anderer Angriff als die Brute Force Attacken um die es hier zunächst mal geht. Tut mir leid, aber wenn es hier um gezielte Angriffe geht haben alle hier vorgeschlagenen Möglichkeiten ihre Nachteile mit denen man ein DOS hinbekommt, da sehe ich keinen großen Nachteil dieser Methode, im Gegenteil, die meisten dieser Absicherungen basieren auf dem Blocken von IPs.

 *mv wrote:*   

> Zweitens - und vor allem - schützt es Dich natürlich nicht vor möglichen Bugs in sshd selbst.
> 
> 

 Hätte ich da prinzipielle Bedenken, würde ich ssh wohl besser nicht einsetzen, oder? Portknocking ist nun weiß Gott kein Allheilmittel für unsichere Dienste.

 *mv wrote:*   

> Nö. Man kann ssh selbst zum knocken benutzen. Klar, dem Rechner, von dem aus man sich einloggt, muss man vertrauen - das muss man sowieso, da dieser auf jeden Fall die Möglichkeit hat, den Schlüssel und alle Tasten abzugreifen...

 

Das eine setzt Böswilligkeit voraus, das andere nur einen neugierigen, verspielten Admin, der sich mal die syslogs anguckt. Portknocking ist ja schön und gut, aber ein "Allheilmittel" mit "überlegener Sicherheit" ist es nun wirklich nicht. Da hat man eben den Nachteil, daß man auf jedem Rechner von dem aus man sich einloggt und auf allen "Man in the Middle" zwangsläufig die Knocking Sequenz hinterläßt --- und damit die vermeintlich erhöhte Sicherheit dahin ist. Das Sperren der IP ist dagegen von diesen Rechnern aus nicht so einfach auszuhebeln.

Hat alles seine Vor- und Nachteile, oder?

----------

## furanku

 *TheSmallOne wrote:*   

> 
> 
> Aber du beschreibst das so, als würde nach einem fehlerhaften Passwortversuch die Verbindung getrennt, denn nur wenn die Verbindung getrennt wird muß man eine neue Aufbauen.
> 
> 

 

Ach so meinst Du das ... Ja da hast Du recht, und ich mich mißverständlich ausgedrückt. "Nach dem ersten endgültig fehlgeschlagenen Login Versuch ..." muß es natürlich heißen. Wieviele der sshd zuläßt ist natürlich Sache des sshd.

Danke für die Korrektur!

----------

## think4urs11

 *mv wrote:*   

> Das hat erstens den Nachteil, dass $BOESER_BUBE_MIT_IP_FAKE Dich ohne großen Aufwand für alle Zeiten aussperren kann.

 

Dazu müßte $badboy aber erstmal wissen von welchen IPs aus ich mich regelmäßig einlogge. 'mal eben' alle möglichen IPs faken würde dann doch ein bis zwei Momente dauern.

Alleine nur alle möglichen Dialin-IPs der DTAG zu faken braucht seine Zeit, von anderen Providern/Ausland ganz zu schweigen.

Zusätzlich kann man auf ESTABLISHED statt NEW ausweichen. Der Kreis derer die eine _etablierte_ TCP-Session zu einer beliebigen IP faken können ist recht übersichtlich. (Von den Jungs direkt beim eigenen ISP abgesehen)

 *mv wrote:*   

> Zweitens - und vor allem - schützt es Dich natürlich nicht vor möglichen Bugs in sshd selbst.

 

Das tun fail2ban/denyhosts und Co. auch nicht.

Sich nur auf eine Maßnahme verlassen ist gefährlich. Besser ist es eine Kombination zu nutzen.

- nur public key Auth zulassen

- root login sowieso nicht

- 'bedenkliche IP-Ranges' von vorneherein ausblenden (24.x/8, asiatische, russische IP-Ranges und alle anderen in denen man nicht selbst verkehrt)

- sshv2 only

- nur dedizierte User dürfen sich via SSH überhaupt anmelden (sshd_config: DenyUsers, AllowUsers, DenyGroups, AllowGroups)

- wer mag kann die exakte OpenSSH-Version unterdrücken (security by obscurity)

- 2sshds; den 'externen' ssh in einem chroot/jail betreiben, auf random highport, forwarding von außen 22->intern:highport und den ssh für intern weiterhin auf 22

- minimale Rechte für jeden Account der sich anmelden darf (keine wheel-Mitgliedschaft u.ä.)

- fail2ban/denyhosts/ip-tables-'Blocker'

- Port-Knocking (aber nur mit variabler Knocksequenz sonst ist das witzlos, z.B. abhängig von Uhrzeit, IP, Username, FQDN und anderer Parameter)

(natürlich nur so kompliziert das man sich die richtige Sequenz selbst merken kann und/oder mit einem kleinen Java-App auf dem Handy berechnen *g*)

- OTP-Auth

- (wer sowas hat) Token-Auth

- die üblichen Parameter in sshd_config explizit sinnvoll bestücken, never trust defaults (AcceptEnv, Ciphers, ClientAlive*, LoginGraceTime, MaxAuthTries, Permit*, X11Forwarding)

----------

## apraxas

Also ähm mit Verlaub: Wenn man den root Login verbietet und nur public key auth zulässt (und den gefälligst schützt) - dann sollten damit quasi jeder Brute-Force Versuch ausgehebelt sein und der ssh ausreichend sicher. Sicherlich kann man noch viel machen - aber es stellt sich ja doch die Frage, in wie fern das einen Sinn ergibt. 

Dazu kommt noch, das gerade fail2ban (und Konsorten) durchaus durch DoS Möglichkeiten im Script aufgefallen sind. Als letztes möchte ich noch bemerken, dass der sshd wohl ein eher unwahrscheinliches Einfallstor ist (mal von wirklich dämlichen Passwörtern abgesehen) - Gewisse Webapplikationen bieten da leichtere Möglichkeiten. Wenn man sein log sauber halten will, dann möge man den Port verändern - das ist leichter.

----------

## xraver

Also seid dem ich den default Port von SSH auf einen anderen gelegt habe ist denyhosts bei mir arbeitslos  :Wink: .

Es hält schon mal zumindest das Log sauber und hält die meisten ScriptKiddis ab. Nebenbei noch publicKey+password und nur ein erlaubter $user, kein root.

So sollte man doch wenigstens gegen die $default Cracker halbwegs sicher sein.

Um den Thread zu beantworten, denyhosts oder Verwandte scheinen mir da die richtigen zu sein.

 *Think4UrS11 wrote:*   

> - 'bedenkliche IP-Ranges' von vorneherein ausblenden (24.x/8, asiatische, russische IP-Ranges und alle anderen in denen man nicht selbst verkehrt)

 

Danke für den Tipp, den werde ich noch mit aufnehmen.

Aber wie gesagt, die meisten Nervsäcke, besonders die automatisierten konnte man mit einem anderen Port zum aufgeben zwingen  :Wink: .

----------

## schachti

 *apraxas wrote:*   

> Also ähm mit Verlaub: Wenn man den root Login verbietet und nur public key auth zulässt (und den gefälligst schützt) - dann sollten damit quasi jeder Brute-Force Versuch ausgehebelt sein und der ssh ausreichend sicher.

 

Das Problem ist, dass man das nicht mit jedem Rechner machen kann (weil man dann immer den Key auf CD oder USB-Stick mit sich herumschleppen muss).

----------

## xraver

 *schachti wrote:*   

> Das Problem ist, dass man das nicht mit jedem Rechner machen kann (weil man dann immer den Key auf CD oder USB-Stick mit sich herumschleppen muss).

 

Der Sicherheit zu liebe sollte das doch kein Problem sein. Kleinen netten USB-Stick als Schlüssel Anhänger der gleich putty+Tools enhält.

Auf fremden Rechnern würde ich es mir sowieso verkneifen mich von denen aus in "kritische" Systeme einzuloggen. Man weiss ja nie was an Software im Rechner oder Netzwerk hockt.

----------

## Max Steel

 *schachti wrote:*   

>  *apraxas wrote:*   Also ähm mit Verlaub: Wenn man den root Login verbietet und nur public key auth zulässt (und den gefälligst schützt) - dann sollten damit quasi jeder Brute-Force Versuch ausgehebelt sein und der ssh ausreichend sicher. 
> 
> Das Problem ist, dass man das nicht mit jedem Rechner machen kann (weil man dann immer den Key auf CD oder USB-Stick mit sich herumschleppen muss).

 

Das ist kein PRoblem, zumal es bereits USB-Sticks gibt die in einem Kugelschreiber untergebracht ist, einfach oben das Käppchen wegmachen und schon gehts los.

----------

## furanku

Diese Thema tendiert immer dazu zum Endlosthema zu werden, und ich glaube wir haben die gängigsten Methoden mit ihren Vor- und Nachteilen alle erwähnt. Jetzt noch spezifisch zu diskutieren ob ein mitgenommener USB Stick nun mehr Sicherheit oder Aufwand ist oder wann Portverlegen und Portknocking bzw. IP-Blocking angebracht, ausreichend oder Overkill ist, muß wohl jeder vernünftig denkende Mensch für sich selber entscheiden.

Alles in allem ist ssh tatsächlich ohnehin eines der sichereren Protokolle und was nutzt der verriegeltste und vernagelste ssh Port, wenn man eine ungepatche PHP Lücke auf dem Rechner oder schwache Passworte hat. In diesem Sinne ... Rechnersicherheit ist immer auch ein Gesamtkonzept, Brute Force Skripte etwas anderes als ein gezielter Angriff und man sollte in Sachen Rechnersicherheit schon wissen was man wogegen tut.

.... wir sind doch alle "große" Gentoo User  und administrieren nicht "Mein erstes SuSE"  :Laughing: 

----------

## think4urs11

 *furanku wrote:*   

> ...ob ein mitgenommener USB Stick nun mehr Sicherheit oder Aufwand ist oder wann Portverlegen und Portknocking bzw. IP-Blocking angebracht, ausreichend oder Overkill ist,.... wir sind doch alle "große" Gentoo User  und administrieren nicht "Mein erstes SuSE" 

 

Aber viele nach wie vor das erste Gentoo - wozu auch neu installieren  :Wink: 

Wenn man sich von fremden Rechnern aus auf ein System einloggt ist es immer kritisch, egal ob pubkey+password oder nur password.

Letztlich könnte auf dem System ein Keylogger mitlaufen und im Hintergrund ein Prozeß der sich die auf dem Stick liegende Datei mit dem private key zieht. Wirklich verhindern könnte man das nur durch Booten von einem sicheren Medium - und selbst dann ... tinfoil-hat such   :Wink: 

Für den Hausgebrauch ist ein Verlegen des ssh-Ports auf 50.000+ schonmal ein großes Plus - die wenigsten scannen wirklich alle 65k Ports. Wer es denn wirklich braucht benutzt one time passwords in Kombination mit einem Tokensystem.

----------

## xraver

 *furanku wrote:*   

> Diese Thema tendiert immer dazu zum Endlosthema zu werden, und ich glaube wir haben die gängigsten Methoden mit ihren Vor- und Nachteilen alle erwähnt. 

 

Und was spricht dagegen die aufgezählten Maßnahmen noch zu diskutieren? Schließlich lassen diese sich noch durch diskussionen Optimieren und helfen dem einen oder anderen bei Entscheidungen. Auch tut sich hier der eine oder andere Tipp auf. (hab ich tut gesagt?  :Wink: )

Also da hab ich echt schon "sinnlosere" Threads gesehen  :Wink: .

----------

## furanku

 *xraver wrote:*   

> Und was spricht dagegen die aufgezählten Maßnahmen noch zu diskutieren? 

 

Selbstverständlich nichts. Aber das hier ist das Internet, und wir alle wissen doch was Da oft mit Diskussionen passiert in denen es um Computer und speziell um Themen bei denen man unterschiedlicher Aufassung sein kann  :Wink: 

Auch wäre dann vielleicht ein Sammelthread oder ein "Tipps und Tricks" Thread besser, denn auch dieser Thread wird irgendwann in den Tiefen des Forums verschwinden, und bei der nächten Frage geht es dann wieder von vorne los. Auch haben wir uns mittlerweile doch recht weit von dem ursprünglichen Thema des OP, nämlich wieman PAM in ssh einbindet entfernt.

Ich wollte aber keinesfalls eine nette Diskussion abwürgen.

----------

