Posts Tagged ‘SSH’

Mittwoch, 31. August 2016

Server mit vergessenen SSH-Schlüsseln ausfindig machen

Vor einigen Tagen habe ich das Schlüsselmanagement für meine SSH-Zugänge völlig umgekrempelt.

Da ich auf Nummer sicher gehen wollte, dass ich den alten Private Key nicht auf bei mir in Vergessenheit geratenen Systemen übersehen hatte, analysierte ich in den Folgetagen die Log-Datei /var/log/auth.log auf meinem zentralen Linux-Server.

Sucht man mittels cat | grep nach „Failed“, erhält man Einträge in der folgenden Form:

...
Aug 25 22:37:09 ALPHA sshd[8539]: Failed publickey for %user% from 85.X.X.X
...

Dies ist aber nur der Beginn der Nachforschung — als nächstes muss man stark hirnen, auf welchem Server das betreffende Script laufen könnte — schliesslich gibt ssh nur eine öffentliche IP-Adresse aus (der verursachende Server steht hinter einem NAT-Router und besitzt eine private IP).

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 23. Mai 2016

Passwort eines Asus RT-AC66U per SSH zurücksetzen

Die Idee war rückblickend doch nicht so genial, das Benutzerpasswort meines Asus RT-AC66U mit Merlin-Firmware ein Sonderzeichen enthalten zu lassen.

Glücklicherweise hatte ich meinen öffentlichen SSH-Schlüssel auf dem Router hinterlegt und konnte mich so zumindest per SSH einloggen. Einmal auf der Kommandozeile, führte ich folgende Befehle aus:

# nvram show | grep http_passwd
http_passwd=?einganzlangespasswort
# nvram set http_passwd="12345678"
# nvram commit

Quelle: DD-WRT :: NVRAM

Anschliessend funktionierte der Login über die Web-Oberfläche wieder.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. April 2016

Den eigenen SSH Public Key auf einem UniFi Access Point hinterlegen

Um sich ohne Passwort auf einen UniFi Access Point einzuloggen, ist der SSH Public Key auf dem Access Point in folgender Datei zu hinterlegen:

Persistent

Folgende Anpassungen überlebt Reboots des Access Points und ist dementsprechend die einzig zuverlässige Variante ohne böse Überraschungen.

Auf dem Server, der als UniFi-Controller dient, legt man eine Datei namens config.properties an, die folgende Zeilen enthält:

config.system_cfg.1=sshd.auth.key.1.status=enabled
config.system_cfg.2=sshd.auth.key.1.value=AAA...== Beschreibung des Public Keys 1
config.system_cfg.3=sshd.auth.key.1.type=ssh-rsa

config.system_cfg.4=sshd.auth.key.2.status=enabled
config.system_cfg.5=sshd.auth.key.2.value=AAA...== Beschreibung des Public Keys 2
config.system_cfg.6=sshd.auth.key.2.type=ssh-rsa

config.system_cfg.7=sshd.auth.key.3.status=enabled
config.system_cfg.8=sshd.auth.key.3.value=AAA...== Beschreibung des Public Keys 3
config.system_cfg.9=sshd.auth.key.3.type=ssh-rsa

config.system_cfg.10=sshd.auth.key.4.status=enabled
config.system_cfg.11=sshd.auth.key.4.value=AAA...== Beschreibung des Public Keys 4
config.system_cfg.12=sshd.auth.key.4.type=ssh-rsa

Im obigen Beispiel konfiguriere ich insgesamt vier Public Keys (sshd.auth.key.1 bis sshd.auth.key.4). Wer nur einen Schlüssel hinterlegen muss, pflegt dementsprechend nur die ersten drei Zeilen in die Datei ein.

Dem Wert sshd.auth.key.1.value weist man den ganzen Public Key zu, ohne aber den Typ (bei mir ssh-rsa) zu erwähnen. Auch Anführungszeichen sind nicht nötig, wenn dem Public Key noch eine Beschreibung mit Leerschlägen folgt (ist bei mir der Fall).

Der Pfad zu dieser Datei hängt vom Betriebssystem und den im Controller definierten Site-Namen ab. Bei mir (Debian GNU/Linux, Site-Name „default“) lautet der Pfad /var/lib/unifi/sites/default/config.properties.

Die Inspiration für dieses Prozedere habe ich dem Artikel UniFi – Add Custom SSH Keys to Your UniFi Devices entnommen.

Den Site-Namen findet man mit folgender Anleitung heraus: UniFi – config.properties File Explanation. Weitere Optionen (bspw. Public Keys, die nur auf einzelne Access Points ausgerollt werden) findet man im Artikel UniFi – How to make persistent changes to UAP(s) system.cfg.

Nicht persistent

Folgende, je nach Firmware unterschiedliche Methoden, erlauben ebenfalls den passwortlosen Login. Nach dem nächsten Neustart des Access Points müssen die Schritte aber zwingend wiederholt werden — die Anpassungen sind nicht persistent.

Firmware 3.4.19

/etc/persistent/.ssh/authorized_keys

Via: ssh key based auth

Wie ich im Januar 2017 bemerken musste, konnte ich mich so nicht mehr mit meinen SSH-Schlüsseln auf die UniFi Access Points einloggen. Nach einer Stunde debuggen dann endlich die Erkenntnis:

Firmware 3.7.28.5442

/etc/dropbear/authorized_keys

Evtl. ist auch noch folgender Befehl nötig (das merke ich spätestens beim nächsten Reboot):

# cfgmtd -w -p /etc

Quelle: Unifi AP: Maintaining SSH access whilst disabling password logins (authorized_keys only) sowie Hacking the KanKun Smartplug – HowTo: Login to SSH on BusyBox (DropBear) Without a Password

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 5. Februar 2016

Einen UniFi Controller von einem Server auf einen anderen migrieren

Mit Blick auf den Mitte Januar 2016 bestellten Glasfaser-Anschluss von Fiber7 habe ich mich entschieden, das heimische WLAN aufzurüsten (nicht zuletzt, weil ich den Router wegen des Glasfaseranschlusses in der Stube nicht am selben Ort betreiben möchte wie den Wireless Access Point). Hierzu habe ich die WLAN-Funktionalität meines Asus RT-AC66U deaktiviert und mir danach einen Ubiquiti UniFi AP-Pro n450 angeschafft, mitsamt eines PoE-Switches von TP-Link.

Eine Besonderheit des UniFi-Access Points ist es, dass er selber keine Web-Oberfläche zur Konfiguration anbietet, wie es Consumer-Geräte sonst tun (auch eine Router-Funktionalität sucht man vergebens). Stattdessen benötigt man den sog. UniFi Controller, eine auf Java und MongoDB basierende Software, die auf einem Rechner im heimischen LAN installiert werden muss. Die Software muss übrigens nicht ständig laufen — wenn man die Konfiguration des APs abgeschlossen hat, benötigt der AP keine ständige Verbindung mehr zum Controller. Ich entschied mich gegen diese Lösung, da ich den Controller jederzeit zugriffsbereit und funktionstüchtig haben möchte — man weiss ja nie. Ausserdem zeichnet die Software in dem Modus Vitalparameter des APs und der WLAN-Netzwerke auf.

Zuerst hatte ich den UniFi Controller auf meiner „Workstation“, einem Mac mini, installiert, welcher ständig läuft. Da mir dabei nie wirklich wohl war, entschied ich mich, den alten Raspberry Pi 1 auszugraben und den Controller darauf zu installieren. Das ist insofern etwas weniger trivial als bei einem x86-Server, weil die ARM-CPU andere Softwarepakete benötigt (insbesondere MongoDB). Ich habe es dank Anleitungen im Internet trotzdem hingekriegt (das Material wird dereinst zu einem eigenständigen Blog-Artikel verwurstet). Da ich anschliessend auch Smokeping auf dem Raspberry Pi installierte und mir die Performance zur Generierung der RRDtool-Graphen überhaupt nicht mehr reichte, entschied ich mich diese Woche, auf einen (gebrauchten) Intel Next Unit of Computing NUC DC3217IYE zu migrieren. Mitkommen sollte auch der UniFi Controller.

Da ich das Spielchen bereits einmal gemacht hatte, hier die im Grunde recht triviale Anleitung (Kurzfassung):

  1. In den alten UniFi-Controller einloggen und unter Settings > Maintenance > Backup > Download Backup ein aktuelles Backup herunterladen
  2. Den neuen UniFi-Controller auf dem neuen Server installieren (Anleitungen für Raspberry Pi und Debian folgen dereinst)
  3. Mit dem Browser auf den neuen UniFi-Controller verbinden
  4. Auf dem Homescreen des neuen UniFi-Controllers im Abschnitt „Alternatively you can restore from a previous backup“ die soeben generierte Backup-Datei auf „Choose File“ ablegen und warten (auf dem Raspberry Pi dauerte das Einlesen des Backups mehrere Minuten, unter dem NUC wenige Sekunden)
  5. Login auf den neuen UniFi-Controller — WLAN sollte Rot leuchten
  6. Login auf den Server des alten UniFi-Controllers und diesen Controller stoppen (service stop unifi)

UniFi Controller Import Backup
image-6517

Soweit so gut. Als nächstes muss man sich per SSH auf den Access Point verbinden — bei mir völlig ohne Interaktion, da ich den Access Point mit meinem SSH Public Key ausgestattet habe:

$ ssh unifi

Anschliessend startet man das CLI des lokalen Management Utility:

# mca-cli

Dort gibt man folgenden Befehl ein:

$ set-inform http://10.0.1.12:8080/inform

Wechselt man nun in den Browser zur Web-Oberfläche des neuen UniFi-Controllers, leuchtet WLAN grün — der Access Point wurde in der Zwischenzeit erkannt.

Voila, that’s it!

PS Eins: In Anleitungen im Netz liest man gelegentlich, dass man den AP im Web-GUI noch „adoptieren“ und danach noch einmal den set-inform-Befehl ausführen müsse — bei mir klappte dies auch ohne.

PS Zwei: Der alte UniFi-Controller lief unter 4.7.6, der neue läuft unter 4.8.12. Beim Import der Backup-Konfiguration gab es keine Probleme.

Tags: , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Montag, 22. Juni 2015

Raspberry Pi 2 einrichten (2/n): WLAN USB-Stick konfigurieren

Für meinen zweiten Raspberry habe ich in meinem Elektronik-Lager einen unbenutzten WLAN USB-Stick Linksys WUSB54GC v3 gefunden. Mit der Standard-Stromversorgung (1.2A) funktioniert dieser Stick problemlos (keine andere Peripherie an den USB-Anschlüssen) und Raspbian erkennt den WLAN-Stick automatisch.

Als erstes gilt es, den Raspberry Pi 2 zu booten. Angeschlossen an einen HDMI-Monitor und mit einem USB-Keyboard geht man danach an die Konfiguration des WLAN-Adapters, damit man die restliche Konfiguration per SSH vornehmen kann.

Nachdem man nach dem ersten booten in raspi-config landet, vergrössert man zuerst die Partition und startet den Taschencomputer neu. Beim nächsten Neustart loggt man sich mit dem Standardbenutzer pi und dem Passwort raspberry in die Shell ein. Dort startet man raspi-config erneut, und wechselt das Keyboard-Layout im Menupunkt „INTERNATIONALISATION OPTIONS“ auf „Deutsch (Schweiz)“. Anschliessend wechselt man das Passwort des Standardbenutzers. Sicher ist sicher.

Da in der Standardinstallation vim noch nicht vorhanden ist, nehmen wir nano und bearbeiten folgende Datei:

/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
   wpa-ssid EMEIDI-LEGACY
   wpa-psk ********

iface default inet dhcp

Um die Verbindung herzustellen, habe ich den WLAN-Stick kurzerhand aus- und wieder eingestöpselt. Nach gefühlten 10 Sekunden führte der Befehl ifconfig für das Interface wlan0 dann eine gültige IP-Adresse auf (sofern der in dieser Konfiguration zwingend benötigte DHCP-Server im Netzwerk sauber funktioniert).

Nachdem man sich die IP unter dem Interface wlan0 notiert hat, geht es an den Mac mini, von welchem aus man mittels SSH die restliche Konfiguration des Systems vornimmt.

WLAN nach Komplikationen automatisch neu starten

Falls man mit gelegentlichen Verbindungsproblemen kämpft, welche einen automatischen Neustart des WLAN-Interfaces nötig machen, sollte man einen entsprechenden Cron-Job einrichten:

/etc/crontab

...
* * * * *	root	/usr/local/bin/check-wifi.sh > /dev/null 2>&1
...

Das Script liest sich folgendermassen:

#!/bin/bash
##################################################################
# A Project of TNET Services, Inc
#
# Title:     WiFi_Check
# Author:    Kevin Reed (Dweeber)
#            dweeber.dweebs@gmail.com
# Project:   Raspberry Pi Stuff
#
# Copyright: Copyright (c) 2012 Kevin Reed 
#            https://github.com/dweeber/WiFi_Check
#
# Purpose:
#
# Script checks to see if WiFi has a network IP and if not
# restart WiFi
#
# Uses a lock file which prevents the script from running more
# than one at a time.  If lockfile is old, it removes it
#
# Instructions:
#
# o Install where you want to run it from like /usr/local/bin
# o chmod 0755 /usr/local/bin/WiFi_Check
# o Add to crontab
#
# Run Every 5 mins - Seems like ever min is over kill unless
# this is a very common problem.  If once a min change */5 to *
# once every 2 mins */5 to */2 ... 
#
# */5 * * * * /usr/local/bin/WiFi_Check 
#
##################################################################
# Settings
# Where and what you want to call the Lockfile
lockfile='/var/run/WiFi_Check.pid'
# Which Interface do you want to check/fix
wlan='wlan0'
##################################################################
echo
echo "Starting WiFi check for $wlan"
date
echo 

# Check to see if there is a lock file
if [ -e $lockfile ]; then
    # A lockfile exists... Lets check to see if it is still valid
    pid=`cat $lockfile`
    if kill -0 &>1 > /dev/null $pid; then
        # Still Valid... lets let it be...
        #echo "Process still running, Lockfile valid"
        exit 1
    else
        # Old Lockfile, Remove it
        #echo "Old lockfile, Removing Lockfile"
        rm $lockfile
    fi
fi
# If we get here, set a lock file using our current PID#
#echo "Setting Lockfile"
echo $$ > $lockfile

# We can perform check
echo "Performing Network check for $wlan"
if ifconfig $wlan | grep -q "inet addr:" ; then
    echo "Network is Okay"
else
    echo "Network connection down! Attempting reconnection."
    ifdown $wlan
    sleep 5
    ifup --force $wlan
    ifconfig $wlan | grep "inet addr"
fi

echo 
echo "Current Setting:"
ifconfig $wlan | grep "inet addr:"
echo
 
# Check is complete, Remove Lock file and exit
#echo "process is complete, removing lockfile"
rm $lockfile
exit 0

##################################################################
# End of Script
##################################################################

Quelle: dweeber/WiFi_Check

Tags: , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 3. Juni 2015

Welche Schlüsselstärke hat ein SSH Public-Key?

$ ssh-keygen -lf "1f:c7:da:ef:ff:ff:ff:ff:c8:77:c6:f8:1f:dd:f3:1a"
1024 1f:c7:da:ef:ff:ff:ff:ff:c8:77:c6:f8:1f:dd:f3:1a /tmp/key (RSA)

Quelle: Given keys in ~/.ssh/authorized_keys format, can you determine key strength easily?

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 20. November 2014

Schutz vor SSH-Bruteforce-Attacken mit Fail2ban

Seit mehreren Jahren setze ich auf meinem aus dem Internet erreichbaren Linux-Server das Paket Fail2ban ein, um Brute-Force-Attacken auf den SSH-Daemon und passwortgeschützte Apache-Verzeichnisse zu verhindern.

Erst kürzlich habe ich dabei die Option aktiviert, dass mir jeder „banned host“ per E-Mail gemeldet wird:

/etc/fail2ban/jail.conf

...
destemail = name@domain.tld
sendername = Fail2Ban
sender = fail2ban@domain.tld
...
action = %(action_mwl)s
...

Indem man die Action von action_ auf action_mwl ändert, wird das E-Mail bei jeder verhinderten Attacke ausgelöst.

Auswertung

Eine äusserst rasche Auswertung der attackierenden Quell-IPs zeigt, dass China offenbar gross im Geschäft mit automatisierten Attacken gegen SSH ist. Die meisten geblockten Hosts stammen aus folgenden vier Subnetzen:

inetnum:        61.174.48.0 - 61.174.55.255
netname:        CHINANET-ZJ-HU
country:        CN
descr:          CHINANET-ZJ Huzhou node network
descr:          Zhejiang Telecom
admin-c:        CZ4-AP
tech-c:         CH119-AP
mnt-irt:        IRT-CHINANET-ZJ
status:         ALLOCATED NON-PORTABLE
changed:        15325819758@189.cn 20111231
mnt-by:         MAINT-CHINANET-ZJ
mnt-lower:      MAINT-CN-CHINANET-ZJ-HU
source:         APNIC
...
inetnum:        122.225.109.0 - 122.225.109.127
netname:        DINGQI-NETWORK-TECHNOLOGY
country:        CN
descr:          Shaoxing Dingqi Network Technology Co., Ltd.
descr:
admin-c:        JS2095-AP
tech-c:         CH119-AP
mnt-irt:        IRT-CHINANET-ZJ
status:         ASSIGNED NON-PORTABLE
changed:        auto-dbm@dcb.hz.zj.cn 20110707
mnt-by:         MAINT-CN-CHINANET-ZJ-HU
source:         APNIC
...
inetnum:        218.2.0.0 - 218.4.255.255
netname:        CHINANET-JS
descr:          CHINANET jiangsu province network
descr:          China Telecom
descr:          A12,Xin-Jie-Kou-Wai Street
descr:          Beijing 100088
country:        CN
admin-c:        CH93-AP
tech-c:         CJ186-AP
mnt-by:         MAINT-CHINANET
mnt-lower:      MAINT-CHINANET-JS
mnt-routes:     maint-chinanet-js
changed:        hostmaster@ns.chinanet.cn.net 20020209
changed:        hostmaster@ns.chinanet.cn.net 20030306
status:         ALLOCATED non-PORTABLE
source:         APNIC
...
inetnum:        222.184.0.0 - 222.191.255.255
netname:        CHINANET-JS
descr:          CHINANET jiangsu province network
descr:          China Telecom
descr:          A12,Xin-Jie-Kou-Wai Street
descr:          Beijing 100088
country:        CN
admin-c:        CH93-AP
tech-c:         CJ186-AP
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CHINANET-JS
mnt-routes:     MAINT-CHINANET-JS
remarks:        This object can only modify by APNIC hostmaster
remarks:        If you wish to modify this object details please
remarks:        send email to hostmaster@apnic.net with your
remarks:        organisation account name in the subject line.
changed:        hm-changed@apnic.net 20040223
status:         ALLOCATED PORTABLE
source:         APNIC
...

Kann denen mal jemand die Stecker ziehen?

Tags: ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 2. November 2014

SNMP-Proxy einrichten

Seit Jahren zeichne ich minütlich Vitalwerte meiner IT-Infrastruktur auf. Dafür verwende ich das quelloffene cacti, dessen Entwicklung zwar seit mehr als einem Jahr stillsteht, meine Bedürfnisse aber immer noch abdeckt. An der Code-Qualität hege ich meine Zweifel, habe mich bisher aber damit arrangiert, insbesondere weil aus meiner Sicht derzeit keine Alternative zur Verfügung steht. Item!

Seit einigen Monaten habe ich das Netzwerk hier in unserer gemeinsamen Wohnung in Bern mittels OpenVPN mit dem Netzwerk im Elternhaus verbunden. Zum Einsatz kommen zwei Router, welche mit DD-WRT geflasht sind (die Konfiguration von OpenVPN auf diesen Kisten ist eine weitere Pendenz in der Liste der geplanten Blog-Artikel).

Der Linux-Server, auf welchem cacti installiert ist und der Poller läuft, befindet sich im Elternhaus. Meine OpenVPN-Konfiguration hat es nun an sich, dass ich den Router in meiner Wohnung nicht per SNMP abfragen kann, weil dessen interne IP aus dem entfernten Netzwerk nicht ansprechbar ist.

Vor einer Woche hatte ich deshalb die zündende Idee, mich auf die Suche nach einem SNMP-Proxy zu machen, welchen ich auf einem Client im LAN unserer Wohnung aufsetze und mittels cacti via SNMP darüber die SNMP-Werte des Routers abfragen kann. Die Wahl fiel auf meinen Mac mini, auf dem SNMP bereits aktiviert ist und bereits von cacti abgefragt wird.

Nach einigen Recherchen mit Google war rasch klar, dass net-snmp die Funktionalität mit sich bringt, einzelne OIDs oder einen ganzen OID-Baum von einem SNMP-fähigen Drittsystem einzubinden und so als Proxy zu wirken.

Die Anleitungen, die man im Netz findet, sind leider etwas holprig, weshalb ich hier für die Nachwelt festhalten möchte, wie ich das Setup schlussendlich zum Laufen gekriegt habe — im Grunde ist es äusserst simpel:

/etc/snmp/snmpd.conf

(Auf dem Rechner, welcher im selben Subnetz wie der abzufragende Router steht)

...
# Proxy to let remote cacti retrieve local router SNMP information

# Define a simple view 'systemview', which includes everthing under .1.3.6.1
view    systemview     included      .1.3

# Map 'public' community to the 'notConfigUser'
com2sec notConfigUser  default       public

# Map 'notConfigUser' to 'notConfigGroup'
group   notConfigGroup v1            notConfigUser
group   notConfigGroup v2c           notConfigUser

# Give 'notConfigGroup' read access to objects in the view 'systemview'
access  notConfigGroup ""            any       noauth    exact  systemview none none

# v1/v2c community string for each proxied host
com2sec -Cn my_router_int notConfigUser  default       my_router

# Allow the 'notConfigUser' (a member of 'notConfigGroup') access for these contexts
access  notConfigGroup my_router_int        any     noauth  prefix  systemview none none

# Proxy configuration
proxy -Cn my_router_int -v 1 -c public 192.168.168.168 .1.3

Via: [HOWTO] Graph multiple servers using an SNMP proxy

Diese Konfiguration kann problemlos in die eigene Konfiguration eingepflegt werden, anzupassen sind einzig die IP des Routers (hier: 192.168.168.168), der über den Proxy abgefragt werden können soll, sowie dessen Community-Namen (hier fahrlässigerweise public).

Aus ästhetischen und verständlichen Gründen anzupassen sind zudem die Bezeichnungen my_router_int sowie my_router. my_router ist der Community-Name, mit welchem die SNMP-Daten des Drittsystems abgefragt werden können. my_router_int wiederum scheint eine Rolle bei der internen Zugriffsverwaltung zu spielen.

Unter Mac OS X verwende ich das von mir auf Github geteilten Restart-Script, um den SNMP-Server neu zu starten.

Test

Mittels des Tools snmpwalk prüfen wir in einer Shell direkt auf dem Proxy, ob net-snmp den OID-Baum tatsächlich einbindet:

$ snmpwalk -v 1 -c my_router localhost
SNMPv2-MIB::sysDescr.0 = STRING: Linux DD-WRT 3.X.X #110 Sun Mar 24 15:46:47 CET 2013 mips
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12623972) 1 day, 11:03:59.72
SNMPv2-MIB::sysContact.0 = STRING: user@domain.tld
...

Klappt!

cacti

Schlussendlich muss das neue Gerät noch in cacti erfasst werden. Das stellt den erfahrenen cacti-Benutzer vor keine Probleme, einzig muss darauf geachtet werden, dass man nicht die IP des Routers, sondern diejenige des Proxys und der in snmpd.conf definierte Community-String (im obigen Beispiel -c my_router, also my_router) angibt. Belässt man den Community-Wert auf public frägt man stattdessen die Werte des Proxys selber ab — und nicht diejenigen des zu überwachenden Routers.

Weiterführende Links

Ein ETH-Mitarbeiter hat aufgeschrieben, wie man so etwas via SSH-Tunnel hinkriegt, wenn man keinen VPN-Tunnel hat.

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 5. Juli 2014

E-Mail bei (erfolgreichem) SSH-Login

Dank Google und dem Internet war dieses unterfangen in einer Minute erledigt:

/etc/pam.d/sshd

Am Ende der Datei (die ich weder kannte und deren Inhalt ich nicht verstehe) fügte ich folgende Zeile ein:

...
session optional pam_exec.so seteuid /usr/local/bin/ssh-login-notify.sh

/usr/local/bin/ssh-login-notify.sh

Auch mailx kannte ich nicht, bisher habe ich immer mail verwendet (Erläuterungen zum Unterschied) — diese Ubuntu-Benutzer sind am „bleeding edge“ unterwegs!

#!/bin/sh
EMAILTO="logger@domain.tld"

if [ "$PAM_TYPE" != "close_session" ]; then
HOST="`hostname`"
SUBJECT="SSH Login: $PAM_USER from $PAM_RHOST on $HOST"
MESSAGE="`env`"

echo "$MESSAGE" | mailx -s "$SUBJECT" "$EMAILTO" &
fi

Quelle: How do I set up an email alert when a ssh login is successful?

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 6. März 2014

SSH zwingen, sich ausschliesslich mit einem spezifischen Private Key anzumelden

Wer bereits einmal SSH-Verbindungsaufnahmen debuggen musste und dazu den Kommandozeilenparameter -v, -vv oder -vvv verwendet hat, weiss, das der SSH-Agent standardmässig all im .ssh-Ordner vorhandenen private Keys durchprobiert, bis einer passt (oder eben nicht).

Ob dies eine Sicherheitslücke darstellt weiss ich nicht, aber ich finde es ineffizient. Diese Unschönheit lässt sich mit zwei zusätzlichen Parametern IdentityFile sowie IdentitiesOnly in den Host-Definitionen in .ssh/config beheben:

Host shortcut
	Hostname domain.tld
	IdentityFile /Users/mario/.ssh/id_rsa_special
	IdentitiesOnly

Quelle: GitHub / SSH with multiple identities; the slightly-more-definitive guide

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen