Mal wieder ein wenig (IT-) Fachlektüre 😉 Da ich im Berufsleben unter anderem auch für das Monitoring der Systeme bei uns im Unternehmen zuständig bin wird natürlich auch entsprechende Software benötigt. War dies früher - zumindest wenn man Open Source-Software einsetzt - meist Nagios wird seit einigen Jahren verstärkt Icinga eingesetzt. Ein bekanntes Unternehmen in Deutschland, das die Entwicklung, etc. fördert ist hierbei die Firma NETWAYS GmbH aus Nürnberg. So verwundert es wahrscheinlich wenig, dass die beiden Autoren Lennart Betz und Thomas Widhalm, die das Buch "Icinga 2 - Ein praktischer Einstieg ins Monitoring" herausgebracht haben auch dort arbeiten. Die hier kurz besprochene 2., aktualisierte und erweitert Auflage aus dem Jahr 2018 ist mehr als doppelt so umfangreich wie die 1. Auflage!
Deutlich über 600 Seiten haben die beiden zusammengeschrieben und bieten damit aus meiner Sicht im Endeffekt zwei Sachen an. Zum einen haben Menschen, die sich bisher noch nicht mit Icinga auseinandergesetzt haben die Möglichkeit sich quasi durch das Buch zu arbeiten und ein laufendes System aufzubauen, dass Standard-Überwachungen auf Linux- und Windows-Systemen locker abdeckt. Zum anderen haben Menschen, zu denen ich mich dann auch zähle, die die Software bereits einsetzen ein entsprechend gutes Nachschlagewerk falls es bei der Einrichtung eines Checks doch mal hakt oder irgendwo ein Problem auftritt.
Das Buch gliedert sich zuerst einmal in fünf größere Abschnitte: "Einführung", "Betriebssystemüberwachung", "Fortgeschrittene Überwachung", "Integration" und "Anhang". Diese Abschnitte sind dann noch wieder in einzelne Kapitel und Unterkapitel unterteilt. Während sich "Einführung" und "Betriebssystemüberwachung" im Endeffekt mit der Installation von Icinga selbst und beispielsweise Informationsabfragen mittels SNMP, dem Icinga-Agent, SSH oder NRPE befassen geht es ab dem Abschnitt "Fortgeschrittene Überwachung" schon eher ans Eingemachte: Vom Aufbau und Konfiguration von Satelliten, die die Abfragen übernehmen über Aufteilung der Konfiguration auf Zonen bis hin zu Überwachungen von Diensten wie Datenbanken, SAP, VMware vSphere oder Hardware. Auch spielt - fürs Monitoring nicht unwichtig - das Thema Hochverfügbarkeit eine entsprechende Rolle.
Der Abschnitt "Integration" beschäftigt sich dann mit solchen Themen wie der Erweiterung der Benutzeroberfläche Icinga Web 2, den Businessprozessen (auch eine sehr interessante Sache!), der recht umfangreichen REST-API oder der Erstellung von Graphen aus den gewonnenen Performancedaten beispielsweise mit Graphite oder Grafana. Der letzte Abschnitt "Anhang" kümmert sich dann noch um einige Themen wie Troubleshooting, Konfigurationsergänzungen oder auch einigen goldenen Regeln, die man beachten sollte. Insgesamt eine runde Sache, deren Anschaffung sich lohnt und rentiert.
Das Buch:
Icinga 2
Ein praktischer Einstieg ins Monitoring
2., aktualisierte und erweiterte Auflage
Lennart Betz, Thomas Widhalm
dpunkt.verlag GmbH, 2018, Heidelberg
ISBN 978-3-86490-556-8
Preis 44,90€
Kontakt feedback@icinga-book.net
Posts mit dem Label SSH werden angezeigt. Alle Posts anzeigen
Posts mit dem Label SSH werden angezeigt. Alle Posts anzeigen
Samstag, 20. Juli 2019
Buchrezension "Icinga 2"
Labels:
Agent,
API,
Buch,
Businessprozess,
Datenbank,
Deutschland,
Grafana,
Icinga,
IcingaWeb,
Lennart Betz,
Linux,
Monitoring,
Nagios,
NETWAYS GmbH,
NRPE,
REST-API,
SNMP,
SSH,
Thomas Widhalm,
Zone
Standort:
Nord, Hannover, Deutschland
Freitag, 18. Juni 2010
Bei Login Mail
In der aktuellen Ausgabe des Linux Magazins gibt es in der Rubrik "Aus dem Alltag eines Sysadmins" mal wieder einen sehr interessanten Artikel von Charly Kühnast.
Unter dem Titel "Türspion: Bei Login Mail" beschreibt er dort, wie man seine Systeme so "konfiguriert", dass bei einer sich öffnenden Shell sofort eine Mail an eine festgelegte Mailadresse geschickt wird. Aus der Mail geht dann hervor, wer sich von welchem System aus eingeloggt hat.
Da er so leider nicht dazugeschrieben hat, welche Distribution(en) er einsetzt und ich zeitgleich festgestellt habe, dass dies so unter Produkten von Novell, openSUSE oder auch Debian nicht direkt zu laufen scheint, hier die Kurzanleitung. Immer natürlich abhängig davon, welche Shells den Benutzer zugewiesen sind! Charly spricht im Artikel davon, dass er den im Artikel erwähnten Einzeiler
Um im SUSE Linux Enterprise Server einen wie im Artikel erwähnten Effekt für den Benutzer root zu erwirken muss die Datei
Die normalen Benutzer erhalten bei mir zum Beispiel die tcsh als Standard-Shell. Um auch diesen Fall mit abzudecken legen wir erst einmal die Datei
"Normale" Benutzer berücksichtige auch auch deshalb, weil es ja vielleicht durchaus Systeme gibt (geben könnte), auf denen zum Beispiel ein Login des Benutzers "root" komplett untersagt ist um vielleicht besser nachzuvollziehen, welcher Benutzer via "su" zum Administrator geworden ist.
Kommen wir nun zu den openSUSE-Produkten. Hier ist es eigentlich ähnlich, lediglich der awk-Befehl unterscheidet sich im zweiten Fall ein wenig. Für bash als die Standard-Shell muss die Datei
Was Debian als Distribution angeht: Für Benutzer mit der bash als Standard-Shell funktioniert es wie im Artikel selbst beschrieben. Für meine Benutzer, die die tcsh als Standard-Shell benutzen musste ich die Datei
Ein kleines "Problem" tritt aber dennoch auf. Nutzt man zum Beispiel Skripte oder ähnliches, die per SSH mit SSH-Keys Befehle auf Zielrechnern ausgeführen, ist die Zeitspanne wohl so gering, dass es nicht reicht um zu schauen, von welchem Rechner der Login kommt. Also ein einfaches "ssh who Rechnername" führt dazu, dass man zwar eine Meldung bekommt, dass dort was war, aber es geht aus der Mail nicht hervor, wer oder was es war. Hierfür habe ich auf die Schnelle so auch keine Lösung parat. Wird aber weiter untersucht.
Unter dem Titel "Türspion: Bei Login Mail" beschreibt er dort, wie man seine Systeme so "konfiguriert", dass bei einer sich öffnenden Shell sofort eine Mail an eine festgelegte Mailadresse geschickt wird. Aus der Mail geht dann hervor, wer sich von welchem System aus eingeloggt hat.
Da er so leider nicht dazugeschrieben hat, welche Distribution(en) er einsetzt und ich zeitgleich festgestellt habe, dass dies so unter Produkten von Novell, openSUSE oder auch Debian nicht direkt zu laufen scheint, hier die Kurzanleitung. Immer natürlich abhängig davon, welche Shells den Benutzer zugewiesen sind! Charly spricht im Artikel davon, dass er den im Artikel erwähnten Einzeiler
echo 'Login on' `hostname` `date` `who` | \in die systemweite "bashrc" einträgt. Unter dem SUSE Linux Enterprise Server, openSUSE und Debian funktioniert dies so allerdings nicht unbedingt. Entweder gibt es beim Einloggen bereits eine Fehlermeldung, die auch einen ungebetenen Gast hellhörig werden lassen würde oder aber die versendete Mail enthält nicht ganz die gewünschten Informationen in der Betreffzeile. Daher gehen wir das hier mal entsprechend für die einzelnen Distributionen durch :-)
mail -s "Login on `hostname` from `who | \
awk '{print $5}'`" user@example.com
Um im SUSE Linux Enterprise Server einen wie im Artikel erwähnten Effekt für den Benutzer root zu erwirken muss die Datei
/etc/bash.bashrc.localangelegt und mit folgendem Inhalt
WHO_AKTUELL=`who -m | /usr/bin/awk '{print $6}'`gefüllt werden. Wird die Variable "WHO_AKTUELL" vorher nicht gesetzt, sondern der entsprechende Befehl mit in die echo-Zeile gepostet, erscheint der Rechnername von dem aus der Login erfolgte nicht in der Betreffzeile der Mail. Dies würde jetzt für alle Logins funktionieren, bei denen der Benutzer die bash als Standard-Shell hat.
echo 'Login on' `hostname` `date` `who -m` | \
mail -s "Login on `hostname` from $WHO_AKTUELL" \ user@example.com
Die normalen Benutzer erhalten bei mir zum Beispiel die tcsh als Standard-Shell. Um auch diesen Fall mit abzudecken legen wir erst einmal die Datei
/etc/csh.login.localan und füllen Sie mit dem folgenden Inhalt
setenv HOSTNAME `hostname`Nachdem dies dann gespeichert ist, bekommen wir auch von diesen Benutzern beim Login eine entsprechende Mail-Benachrichtigung. "user@example.com" steht hier natürlich jeweils für die Mail-Adresse, an die die Information gesendet werden soll.
setenv DATE `date`
setenv WHO `who -m`
setenv WHO_AKTUELL `who -m | /usr/bin/awk '{print $6}'`
echo 'Login on' $HOSTNAME $DATE $WHO | \
mail -s "Login on $HOSTNAME from $WHO_AKTUELL" \ user@example.com
"Normale" Benutzer berücksichtige auch auch deshalb, weil es ja vielleicht durchaus Systeme gibt (geben könnte), auf denen zum Beispiel ein Login des Benutzers "root" komplett untersagt ist um vielleicht besser nachzuvollziehen, welcher Benutzer via "su" zum Administrator geworden ist.
Kommen wir nun zu den openSUSE-Produkten. Hier ist es eigentlich ähnlich, lediglich der awk-Befehl unterscheidet sich im zweiten Fall ein wenig. Für bash als die Standard-Shell muss die Datei
/etc/bash.bashrc.localangelegt und mit dem Inhalt
WHO_AKTUELL=`who -m | /usr/bin/awk '{print $6}'`gefüllt werden. Ist also nichts anderes als oben auch. Für die tcsh als Standard-Shell muss auch hier erst einmal die Datei
echo 'Login on' `hostname` `date` `who -m` | \
mail -s "Login on `hostname` from $WHO_AKTUELL" \ user@example.com
/etc/csh.login.localangelegt werden. Hier kommt als Füllung folgendes zum Einsatz
setenv HOSTNAME `hostname`Der/Die aufmerksame Leser/in wird hier das "/usr/bin/awk '{print $5}'" bemerkt haben. Dies sorgt bei openSUSE mit der tcsh als Shell für die Ausgabe des Rechnernamens, von dem aus der Login erfolgte. Würden wir hier $6 verwenden, wäre die Ausgabe leer.
setenv DATE `date`
setenv WHO `who -m`
setenv WHO_AKTUELL `who -m | /usr/bin/awk '{print $5}'`
echo 'Login on' $HOSTNAME $DATE $WHO | \
mail -s "Login on $HOSTNAME from $WHO_AKTUELL" \ user@example.com
Was Debian als Distribution angeht: Für Benutzer mit der bash als Standard-Shell funktioniert es wie im Artikel selbst beschrieben. Für meine Benutzer, die die tcsh als Standard-Shell benutzen musste ich die Datei
/etc/csh/login.d/csh.login.localanlegen und mit folgendem Inhalt füllen:
setenv HOSTNAME `hostname`Naja, und wenn ich schon einmal dabei bin, kann ich mich ja auch noch "kurz" Sun Solaris annehmen :-) Hier habe ich für die bash als Standard-Shell einfach mal kurz die Zeile
setenv DATE `date`
setenv WHO `who -m`
setenv WHO_AKTUELL `who -m | awk '{print $5}'`
echo 'Login on' $HOSTNAME $DATE $WHO | \
mail -s "Login on $HOSTNAME from $WHO_AKTUELL" \ user@example.com
echo 'Login on' `hostname` `date` `who` | \an die Datei
mailx -s "Login on `hostname` from `who | \
awk '{print $6}'`" user@example.com
/etc/profileangehängt. Wichtig ist hier anstatt dem Befehl "mail" den Befehl "mailx" zu verwenden, da die Betreffzeile ansonsten leer bleibt. Für Benutzer mit der tcsh als Standard-Shell wird eine Datei
/etc/.cshangelegt und mit dem Inhalt
setenv HOSTNAME `hostname`gefüllt. Et voilà: It works ;-) Auch hier natürlich wieder mit "mailx" anstelle von "mail".
setenv DATE `date`
setenv WHO `who -m`
setenv WHO_AKTUELL `who -m | awk '{print $6}'`
echo 'Login on' $HOSTNAME $DATE $WHO | \
mailx -s "Login on $HOSTNAME from $WHO_AKTUELL" \ user@example.com
Ein kleines "Problem" tritt aber dennoch auf. Nutzt man zum Beispiel Skripte oder ähnliches, die per SSH mit SSH-Keys Befehle auf Zielrechnern ausgeführen, ist die Zeitspanne wohl so gering, dass es nicht reicht um zu schauen, von welchem Rechner der Login kommt. Also ein einfaches "ssh
Sonntag, 13. Dezember 2009
Linux-Tool Sslh
Ein interessantes Tool hat Charly Kühnast einmal mehr im Linux Magazin (Ausgabe 01/10, Seite 67) vorgestellt: Sslh.
Bei Sslh handelt es sich um eine Mischung aus SSL und SSH. Gedacht ist es für den Einsatz auf einem Server, auf dem ein Webserver läuft. Das Tool selbst schaltet sich vor den Port 443 und versucht anhand der gesendeten Daten herauszufinden, ob eine SSL- oder aber eine SSH-Verbindung aufgebaut werden soll.
Interessant ist das Tool sicherlich für diejenigen, die häufiger mal unterwegs sind und schon des öfteren festgestellt haben, dass man sich zum Beispiel vom Hotel oder Flughafen aus zwar auf Port 80 (HTTP) bzw. 443 (HTTPS) verbinden kann, aber nicht auf Port 22 (SSH). Dieses Problem kann man durch Sslh umgehen. Es sollte im allgemeinen mit Apache und Lighttpd zusammenarbeiten.
Bei Sslh handelt es sich um eine Mischung aus SSL und SSH. Gedacht ist es für den Einsatz auf einem Server, auf dem ein Webserver läuft. Das Tool selbst schaltet sich vor den Port 443 und versucht anhand der gesendeten Daten herauszufinden, ob eine SSL- oder aber eine SSH-Verbindung aufgebaut werden soll.
Interessant ist das Tool sicherlich für diejenigen, die häufiger mal unterwegs sind und schon des öfteren festgestellt haben, dass man sich zum Beispiel vom Hotel oder Flughafen aus zwar auf Port 80 (HTTP) bzw. 443 (HTTPS) verbinden kann, aber nicht auf Port 22 (SSH). Dieses Problem kann man durch Sslh umgehen. Es sollte im allgemeinen mit Apache und Lighttpd zusammenarbeiten.
Freitag, 30. Oktober 2009
Bitvise SSH-Produkte
Wie vor einiger Zeit schon angekündigt, habe ich mir nun einmal die SSH-Software der Firma Bitvise Ltd. näher angesehen.
Das Unternehmen vertreibt die Software-Tools WinSSHD und Tunnelier bzw. stellt diese auf den eigenen Internetseiten zum Download zur Verfügung. Wichtig sind hierbei auch die jeweils zur Software gehörenden Lizenzbedingungen, die man sich vorab einmal durchlesen sollte. So ist bspw. für den Einsatz von WinSSHD eine Kauflizenz notwendig, sobald das Produkt im persönlichen UND nicht-kommerziellen Bereich eingesetzt wird. Also zum Beispiel auch, wenn ein Studierender es nicht nur zum persönlichen Gebrauch einsetzt sondern damit auch arbeitet (bspw. als Hilfskraft). Weiterhin ist die kostenlose Personal Edition noch darauf beschränkt, dass lediglich lokale Windows-Accounts genutzt werden können. Einschließlich nur einer Windows- bzw. eine virtuelle Gruppe und auch maximal zehn Windows- und virtuelle Accounts. Auch GSSAPI wird nicht unterstützt. Zudem ist WinSSHD eher ein Serverdienst und kommt auch daher vielleicht nicht unbedingt in Frage.
Bliebe Tunnelier. Diese Software ist dem SSH Secure Shell Client schon wesentlich ähnlicher. Sie bietet neben dem Terminal auch einen Datei-Explorer. Auch die Lizenzbedingungen sind für Privatanwender wesentlich angenehmer. So darf die Software von bis zu vier Personen auf bis zu vier Computern in Einzelumgebungen genutzt werden. Auch die Handhabung ist ähnlich wie beim SSH Secure Shell Client. Von daher kann man diese Software auch problemlos weiterempfehlen. Zumal sie im Entwicklungsstand wesentlich aktueller ist als der frei nicht mehr weiterentwickelte SSH Secure Shell Client. Für den kommerziellen Einsatz sollte man es sich allerdings überlegen. Eine Unlimited Project License schlägt immerhin mit 12.500 US-Dollar zu Buche, für den einzelnen User mit je 44,95 US-Dollar ...
Weitere Projekte, aus denen in der Zukunft vielleicht noch einmal etwas wird, seien auch noch kurz genannt. Aktuell sind diese Tools aber wohl nicht wirklich einsatzbereit.
Das Unternehmen vertreibt die Software-Tools WinSSHD und Tunnelier bzw. stellt diese auf den eigenen Internetseiten zum Download zur Verfügung. Wichtig sind hierbei auch die jeweils zur Software gehörenden Lizenzbedingungen, die man sich vorab einmal durchlesen sollte. So ist bspw. für den Einsatz von WinSSHD eine Kauflizenz notwendig, sobald das Produkt im persönlichen UND nicht-kommerziellen Bereich eingesetzt wird. Also zum Beispiel auch, wenn ein Studierender es nicht nur zum persönlichen Gebrauch einsetzt sondern damit auch arbeitet (bspw. als Hilfskraft). Weiterhin ist die kostenlose Personal Edition noch darauf beschränkt, dass lediglich lokale Windows-Accounts genutzt werden können. Einschließlich nur einer Windows- bzw. eine virtuelle Gruppe und auch maximal zehn Windows- und virtuelle Accounts. Auch GSSAPI wird nicht unterstützt. Zudem ist WinSSHD eher ein Serverdienst und kommt auch daher vielleicht nicht unbedingt in Frage.
Bliebe Tunnelier. Diese Software ist dem SSH Secure Shell Client schon wesentlich ähnlicher. Sie bietet neben dem Terminal auch einen Datei-Explorer. Auch die Lizenzbedingungen sind für Privatanwender wesentlich angenehmer. So darf die Software von bis zu vier Personen auf bis zu vier Computern in Einzelumgebungen genutzt werden. Auch die Handhabung ist ähnlich wie beim SSH Secure Shell Client. Von daher kann man diese Software auch problemlos weiterempfehlen. Zumal sie im Entwicklungsstand wesentlich aktueller ist als der frei nicht mehr weiterentwickelte SSH Secure Shell Client. Für den kommerziellen Einsatz sollte man es sich allerdings überlegen. Eine Unlimited Project License schlägt immerhin mit 12.500 US-Dollar zu Buche, für den einzelnen User mit je 44,95 US-Dollar ...
Weitere Projekte, aus denen in der Zukunft vielleicht noch einmal etwas wird, seien auch noch kurz genannt. Aktuell sind diese Tools aber wohl nicht wirklich einsatzbereit.
- QuarkSSH: http://quarkssh.sourceforge.net/
- SmartSSH: http://smartssh.sourceforge.net/
- SSHTools: http://sshtools.sourceforge.net/
Sonntag, 18. Oktober 2009
PuTTY, SSH und Windows
Da ich sowohl im beruflichen als auch im privaten Umfeld eigentlich fast ausschließlich mit Linux und (Open-) Solaris arbeite, kommt von (Informatik-) Studierenden hin und wieder mal die Frage, wie sie sich auch von Windows aus per SSH mit SSH-Keys einloggen können. Kennwortlogins lassen wir nämlich aus gutem Grund nicht zu :-)
Leider ist die von mir bevorzugt empfohlene SSH Secure Shell-Software so nicht mehr frei erhältlich. Eine ältere Version gibt es aber beispielsweise noch auf den Internetseiten der Universität Köln. Die Software hat die angenehme Eigenschaft, dass sie neben einem Terminalfenster auch einen Dateiexplorer mit anbietet.
So müsste man nun zwei Programme installieren, um die Funktionalität zu erhalten. Das eine ist PuTTY für das Terminal, dass andere WinSCP für den Dateiexplorer um auch Dateien ohne Probleme und einfach übertragen zu können. Die Installation ist eigentlich selbsterklärend.
Wenn ich mir nun unter Linux schon einen SSH-Key generiert habe, möchte ich diesen natürlich auch in PuTTY importieren. Hierzu starte ich puttygen.exe und importiere den privaten Schlüssel, den ich auf dem Linux-System generiert hatte. Anschließend ist auch alles bereit und kann genutzt werden. Eine ausführliche Anleitung dazu gibt es zum Beispiel hier. Wobei ich beim zusammenschreiben hier gerade noch auf die Software Bitvise WinSSHD und Bitvise Tunnelier gestoßen bin. Beide sind für den persönlichen und nicht-kommerziellen Einsatz anscheinend kostenlos. Das schaue ich mir bei Gelegenheit noch einmal an.
Wer jetzt zum Beispiel auch noch vor hat, auf einem entfernten Linuxsystem ein grafisches Programm auszuführen, wird erst einmal eine Fehlermeldung bekommen. Hintergrund ist hier, dass unter Windows standardmäßig kein X-System installiert ist. Eine Möglichkeit wäre hier zum Beispiel Xming. Ist diese Software installiert und PuTTY noch so konfiguriert, dass es X-Verbindungen durchtunnelt (Configuration -> Connection -> SSH -> X11 -> Enable X11 forwarding), lassen sich auch auf entfernten Linux-PCs grafische Anwendungen ausführen.
Und auch auf der guten Seite HowtoForge gibt es unter dem Titel "Key-basierte SSH Logins mit PuTTY" eine entsprechende Anleitung, wie man zum Beispiel auch direkt unter Windows sein Schlüsselpaar erstellt und den öffentlichen Schlüssel entsprechend auf den Server kopiert. Ist zwar aus dem Jahr 2006, aber nach wie vor aktuell.
Leider ist die von mir bevorzugt empfohlene SSH Secure Shell-Software so nicht mehr frei erhältlich. Eine ältere Version gibt es aber beispielsweise noch auf den Internetseiten der Universität Köln. Die Software hat die angenehme Eigenschaft, dass sie neben einem Terminalfenster auch einen Dateiexplorer mit anbietet.
So müsste man nun zwei Programme installieren, um die Funktionalität zu erhalten. Das eine ist PuTTY für das Terminal, dass andere WinSCP für den Dateiexplorer um auch Dateien ohne Probleme und einfach übertragen zu können. Die Installation ist eigentlich selbsterklärend.
Wenn ich mir nun unter Linux schon einen SSH-Key generiert habe, möchte ich diesen natürlich auch in PuTTY importieren. Hierzu starte ich puttygen.exe und importiere den privaten Schlüssel, den ich auf dem Linux-System generiert hatte. Anschließend ist auch alles bereit und kann genutzt werden. Eine ausführliche Anleitung dazu gibt es zum Beispiel hier. Wobei ich beim zusammenschreiben hier gerade noch auf die Software Bitvise WinSSHD und Bitvise Tunnelier gestoßen bin. Beide sind für den persönlichen und nicht-kommerziellen Einsatz anscheinend kostenlos. Das schaue ich mir bei Gelegenheit noch einmal an.
Wer jetzt zum Beispiel auch noch vor hat, auf einem entfernten Linuxsystem ein grafisches Programm auszuführen, wird erst einmal eine Fehlermeldung bekommen. Hintergrund ist hier, dass unter Windows standardmäßig kein X-System installiert ist. Eine Möglichkeit wäre hier zum Beispiel Xming. Ist diese Software installiert und PuTTY noch so konfiguriert, dass es X-Verbindungen durchtunnelt (Configuration -> Connection -> SSH -> X11 -> Enable X11 forwarding), lassen sich auch auf entfernten Linux-PCs grafische Anwendungen ausführen.
Und auch auf der guten Seite HowtoForge gibt es unter dem Titel "Key-basierte SSH Logins mit PuTTY" eine entsprechende Anleitung, wie man zum Beispiel auch direkt unter Windows sein Schlüsselpaar erstellt und den öffentlichen Schlüssel entsprechend auf den Server kopiert. Ist zwar aus dem Jahr 2006, aber nach wie vor aktuell.
Abonnieren
Posts (Atom)
