Switch HP OfficeConnect 1920S: Telnet/SSH aktivieren

Problem:
Der Switch HP OfficeConnect 1920S ist ein sehr günstiger Full-Gigabit PoE Switch. Man muss ein paar Abstriche am Gerät machen, aber an sich ein sehr guter Switch. Für mich sind folgende Punkt etwas störend, aber für den Zweck der Switche akzeptabel:
- kein Consolen-Port (serieller Anschluss)
- Stromkabel kein Kaltgerätestecker - ist nur für den direkten Anschluss an der USV geeignet.
- Only Web-Managed

Mein Problem war, dass der Switch nur Web-Managed ist und keinen Zugriff per Telnet oder SSH bietet. Da ich kein Freund von GUIs bei Switchen bin wollte ich Telnet und/oder SSH-Zugriff haben um auf die CLI zugreifen zu können.
Per Default leider nicht möglich, aber man kann es über einen kleinen Umweg aktivieren!

Lösung:
1.) Firmware-Update auf die aktuelle Version über die GUI (bei mir PD.02.06)
2.) Eine aktuelle Start-Config exportieren über Maintenance -> Backup and Update Manage
3.) Die exportierte Config editieren und folgende Zeile VOR der Zeile "configure" setzen
ip telnet server enable
Beispiel Startup-Config von mir:
!Current Configuration:
!
!System Description "HPE OfficeConnect Switch 1920S 48G 4SFP PPoE+ (370W) JL386A, PD.02.06, Linux 3.6.5-a07f8920, U-Boot 2012.10-00118-g3773021 (Oct 11 2016 - 15:39:54)"
!System Software Version "PD.02.06"
!System Up Time "0 days 0 hrs 6 mins 39 secs"
!Additional Packages HPE QOS,HPE IPv6 Management,HPE Routing
!Current SNTP Synchronized Time: SNTP Client Mode Is Disabled
!
vlan database
exit
ip telnet server enable
configure
time-range Schedule-1
exit
time-range Schedule-2
exit
no username guest
line console
exit
line telnet
exit
line ssh
exit
!
exit

4.) Neue Startup-Config speichern und über die GUI als Startup-Config importieren (Maintenance -> Backup and Update Manage)
5.) Switch rebooten
6.) Telnet auf die Switch-IP ausführen (Default: Telnet 192.168.1.1)
7.) Mit folgenden Zeilen SSH aktivieren:
enable
configure
crypto key generate rsa
crypto key generate dsa
exit
ip ssh server enable
ip ssh protocol 2
write memory confirm
quit

8.) Wer möchte kann Telnet auch wieder deaktivieren mit dem Befehl:
ip telnet server disable


Kleiner Tipp am Rande: Wenn man die Startup-Config hochlädt, dann werden Kennwörter und sonstige Konfigurationen wieder verworfen! Also bitte erste Telnet/SSH aktivieren und dann Switch konfigurieren!

Quelle für die Hilfe:
Switches 'HPE OfficeConnect 1920S' - Enable SSH / TFTP Services

SSH : Tunneln zu Maschine hinter Jumphost

Da ich mir das nie merken kann schreib ich das hier mal auf ;-)
Ich möchte die Status Seite eines haproxys in einem Netz anzeigen das nur über einen Jumphost erreichbar ist. Dafür braucht man 2 Tunnel einen auf den Jumphost und dann von Jumphost auf das Zielsystem. Der Jumphost und das Zielsystem müssen mit Key verbunden sein das ein Tunnel möglich ist. ( SSH Login mit authorized_keys )
ssh -L 9090:localhost:9090 USERNAME@JUMPHOST -i SSHKEY ssh -L 9090:localhost:9090 -N USERNAME@TARGETSYSTEM

Git : User / Passwortabfrage bei git push

Bei dem Versuch ein git push zu machen erfolgt eine Abfrage nach Passwort & User. Der Hash des SSH Keys war aber sauber im Server registriert. Mit dem Befehl git remote -v habe ich mir erstmal die Quellen angesehen. Der initiale pull wurde scheinbar mit https ausgeführt, somit wird der ssh key gar nicht angefragt.
git remote -v
origin https://[URL]/[GRUPPE]/[PROJEKT].git (fetch)
origin https://[URL]/[GRUPPE]/[PROJEKT].git (push)
Nachdem ich die Quelle auf ssh konfiguriert habe lief auch alles so wie erwartet.
git remote set-url origin git@[FQDN]:[GRUPPE]/[PROJEKT].git
Ein erneutes Abfragen der Konfiguration
git remote -v
origin	git@[FQDN]:[GRUPPE]/[PROJEKT].git (fetch)
origin	git@[FQDN]:[GRUPPE]/[PROJEKT].git (push)

Ansible : Automatisches Registrieren der SSH Keys

Wir haben hier einige Adminstratoren die auf die erstellten Umgebungen Zugriff benötigen. Der Zugriff geschieht immer über einen SSH Key. Diese werden in unseren Ansible Script auf diese Weise registriert.

  - name: register default ssh admin keys
    authorized_key:
      user: admin
      state: present
      key: "{{ lookup('file', '{{ item }}') }}"
    with_fileglob:
      - "/ansible-deploy/global/ssh-keys/*.pub"

  - name: register admin-ssh-key for user app
    authorized_key:
      user: app
      state: present
      key: '{{ item }}'
    with_file:
      - "{{ admin_ssh_pub_file }}"

  - name: register default ssh app keys
    authorized_key:
      user: app
      state: present
      key: "{{ lookup('file', '{{ item }}') }}"
    with_fileglob:
      - '/ansible-deploy/global/ssh-keys/*.pub'

# allow developers to access servers 

  - name: register projekt-ssh keys for user app
    authorized_key:
      user: app
      state: present
      key: "{{ lookup('file', '{{ item }}') }}"
    with_fileglob:
      - '/ansible-deploy/customers/{{ customer }}/project_ssh_keys/*.pub'

# register key for user app to allow access between servers
# to generate a private key for this platform you can change into the project_ssh_keys directory and use
# ssh-keygen -t rsa -b 4096 -f ./id_rsa -P '' -C 'app-key' 

  - name: copy the app private key
    copy:
      owner: app
      group: app
      mode: 0600
      src: "/ansible-deploy/customers/{{ customer }}/project_ssh_keys/id_rsa"
      dest: "/home/app/.ssh/id_rsa"

Check_MK Agent über SSH Verbindung

Wenn man das Check_MK Monitoring nicht über den Standardport (xinet) laufen lassen möchte / kann besteht dich Möglichkeit dies über eine SSH Verbindung zu realisieren. Hierfür muss nur einiges an Vorarbeit erledigt werden.

Auf jedem Host der zu monitoren ist legt man einen User für den Check_Mk Agents an.
useradd -d /home/monitor -c 'CHECK_MK User' -g monitor -m -s /bin/bash monitor
Auf dem Monitoring-Server einen SSH Key für das monitoring erstellen. Dazu logt ihr euch über ssh auf dem Server ein und wechselt mit su - sitename auf die Check_MK Site (User). Dort legt ihr ein SSH-Keypair an.
ssh-keygen -t monitor
dann zeigt ihr euch den schlüssel über cat an und pflegt diesen auf den zu monitorenden Hostsystemen unter dem User monitor ein ( /home/monitor/.ssh/authorized_keys )
cat ~/.ssh/id_monitor.pub
Eintrag auf den Hostsystemen :
command="sudo /usr/bin/check_mk_agent" ssh-rsa [SSH KEY DES SERVERS]
Jetzt muss noch die sudoers Config angepasst werden.
vi /etc/sudoers
Dort fügt man die folgenden Zeilen ein, trägt man den User monitor ein
# Allow User monitor to run check_mk_agent
monitor ALL=NOPASSWD: /usr/bin/check_mk_agent
Jetzt kann man das bis jetzt mal testen.Wenn ihr euch über ssh auf dem Host als User monitor anmeldet, oder den check_mk_agent lokal auf dem Host als User monitor ausführt, muss der selbe output zu sehen sein.

Ist das der Fall muss jetzt noch in der WATO eine Regel erstellt werden.
Unter Host & Service ParametersDatasource ProgramsIndividual program call instead of agent access eine Regel für die Umgebung erstellen
	ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no monitor@$HOSTADDRESS$
dann sollten nach einem TabulaRasa alle Services zu sehen sein.
check_mk_agent über ssh
check_mk_agent über ssh


Mehr Info : Check_MK - Anleitung zu diesem Thema
“Sicher ist, dass nichts sicher ist. Selbst das nicht.”
Joachim Ringelnatz