Beantwoord

key based ssh authentication en/of vpn nodig ?

  • 21 december 2017
  • 14 reacties
  • 453 keer bekeken

Reputatie 2
Dag allemaal,

Bijna kerst dus ik dacht laat ik jullie nog even lastig vallen voordat jullie je straks aan het volproppen zijn met voedsel :)

Zoals jullie misschien weten ben ik momenteel bezig met het opstellen van een veilige raspberry pi waarover ik een server kan draaien.

na het lezen van de onderstaande post heb ik besloten mijn veiligheid nog een tandje te verhogen. ik wilde namelijk niet mijn gebruikersnaam als pi hebben bijvoorbeeld.
https://www.raspberrypi.org/documentation/configuration/security.md

ik ben echter in de war geraakt bij het stuk over de key based ssh authentication. dit gebruikte ik in mijn huidige systeem niet, maar ik gebruikte wel een vpn om met de ssh en vnc in verbinding te komen.

nu vraag ik mij af, is het nu nodig om beide methoden (key based en vpn) toe te passen of is het voldoende om slechts een vpn te gebruiken? daarnaast, als ik key based authentication gebruik, dan is mijn ssh verkeer beveiligd, maar klopt het dan dat als ik een vnc server start ik daardoor weer een veiligheids lek krijg omdat vnc niet over de ssh poort verloopt ?

al met al, klopt het nu dat ik compleet veilig ben als ik een vpn opzet en met pivpn of is het aan te raden ook nog key based authentication te gebruiken ?

en mocht een vpn genoeg zijn (waarbij je dus ook gebruik maakt van een key) enig idee waarom de raspberry pi foundation dat dan niet zegt dat je dat beter kan gebruiken? en hoe kan ik 100% zeker weten dat je alleen via deze vpn verbinding kan maken?

alvast hartelijk dank!

mvg,

Johan
icon

Beste antwoord door RobinFlikkema 21 december 2017, 16:00

Bijna kerst dus ik dacht laat ik jullie nog even lastig vallen voordat jullie je straks aan het volproppen zijn met voedsel ?
Dat doe ik altijd al :D

nu vraag ik mij af, is het nu nodig om beide methoden (key based en vpn) toe te passen of is het voldoende om slechts een vpn te gebruiken? daarnaast, als ik key based authentication gebruik, dan is mijn ssh verkeer beveiligd, maar klopt het dan dat als ik een vnc server start ik daardoor weer een veiligheids lek krijg omdat vnc niet over de ssh poort verloopt ?
Je kan zelf kiezen of je beide doet, maar het is altijd een afweging tussen veiligheid en gebruiksgemak.

Denk er wel aan dat SSH via je eigen netwerk wel met username + password bereikbaar is.
Je kan dus kiezen voor key-based auth om er voor te zorgen dat mensen op andere manieren niet bij je rpi kunnen.

Als jij VNC over de VPN start is dat ook "veilig". Het wordt namelijk geencrypt over de VPN tunnel en is alleen bereikbaar vanuit je eigen netwerk of via de VPN.
en mocht een vpn genoeg zijn (waarbij je dus ook gebruik maakt van een key) enig idee waarom de raspberry pi foundation dat dan niet zegt dat je dat beter kan gebruiken?
Omdat die VPN voornamelijk voor externe toegang is. Voor interne toegang (je eigen netwerk en gebruikers van de VPN) is het nog wel mogelijk om met username + password in te loggen
En hoe kan ik 100% zeker weten dat je alleen via deze vpn verbinding kan maken?
Dit is een vraag die je op meerdere manieren kan zien, ik ga er vanuit dat je dit bedoelt:
Zolang jij geen poorten opent op de Experiabox zal je alleen via je eigen netwerk en de VPN bij je raspberrypi kunnen (uitzonderingen zijn Cloud-services, zoals PleX Remote etc)

Robin
Bekijk origineel

14 reacties

Reputatie 7
Badge +30
Bijna kerst dus ik dacht laat ik jullie nog even lastig vallen voordat jullie je straks aan het volproppen zijn met voedsel ?
Dat doe ik altijd al :D

nu vraag ik mij af, is het nu nodig om beide methoden (key based en vpn) toe te passen of is het voldoende om slechts een vpn te gebruiken? daarnaast, als ik key based authentication gebruik, dan is mijn ssh verkeer beveiligd, maar klopt het dan dat als ik een vnc server start ik daardoor weer een veiligheids lek krijg omdat vnc niet over de ssh poort verloopt ?
Je kan zelf kiezen of je beide doet, maar het is altijd een afweging tussen veiligheid en gebruiksgemak.

Denk er wel aan dat SSH via je eigen netwerk wel met username + password bereikbaar is.
Je kan dus kiezen voor key-based auth om er voor te zorgen dat mensen op andere manieren niet bij je rpi kunnen.

Als jij VNC over de VPN start is dat ook "veilig". Het wordt namelijk geencrypt over de VPN tunnel en is alleen bereikbaar vanuit je eigen netwerk of via de VPN.
en mocht een vpn genoeg zijn (waarbij je dus ook gebruik maakt van een key) enig idee waarom de raspberry pi foundation dat dan niet zegt dat je dat beter kan gebruiken?
Omdat die VPN voornamelijk voor externe toegang is. Voor interne toegang (je eigen netwerk en gebruikers van de VPN) is het nog wel mogelijk om met username + password in te loggen
En hoe kan ik 100% zeker weten dat je alleen via deze vpn verbinding kan maken?
Dit is een vraag die je op meerdere manieren kan zien, ik ga er vanuit dat je dit bedoelt:
Zolang jij geen poorten opent op de Experiabox zal je alleen via je eigen netwerk en de VPN bij je raspberrypi kunnen (uitzonderingen zijn Cloud-services, zoals PleX Remote etc)

Robin
Reputatie 2
Beste Robin,

Dank voor je antwoord. Zoals ik het nu begrijp is het dus prima om geen key based authentication te gebruiken.

Momenteel foreward ik dus alleen poorten voor pivpn en plex, ik zou mij dus geen zorgen hoeven te maken. Ik zal wel mijn fail2ban goed configureren om goed in de gaten te kunnen houden of er veel failed login attempts zijn.

Zijn er cijfers over hoe lang het minimaal zou moeten duren voordat een rpi (zonder pi account) een wachtwoord met speciale tekens ge brute forced kan worden ? Daar zijn ze denk ik toch zowiezo wel een paar dagen mee bezig ?

Dankje!
Reputatie 7
Badge +30
Hoi,

Klopt, persoonlijk heb ik alleen op extern bereikbare machines key-based auth.

Als je Fail2Ban gebruikt mag je sowieso maar een paar keer inloggen. Daarnaast zijn cijfers wat lastig omdat het voornamelijk afhankelijk is van hoe snel de Pi een login afkeurt. Mijn laptop of server kan namelijk redelijk snel die inloggegevens genereren en proberen, maar moet aldoor wachten tot ze afgekeurd of goedgekeurt worden.
Maar als de gebruikersnaam niet je voornaam/achternaam is en het wachtwoord relatief lastig dan zal het zeker wel meerdere dagen duren.

Robin
Reputatie 2
Goeiedag beste @RobinFlikkema,

Zoals je weet is het een tijd geleden gelukt om openvpn connectie met key based authentication te starten. Echter heb ik er sinds gister problemen mee.

Ik kan op mijn werk nogsteeds via SSH openvpn in contact komen met mijn pi en inloggen met key based authentication. Als ik nu echter verbinding probeer te maken met specifieke programmas dan wordt de verbinding geblokkeerd (403), de services denken namelijk dat ik niet op het lokale netwerk zit. De toegang tot mijn transmission webpage (192.168.2.100:9091) wordt geblokkeerd, en ook als ik verbinding maak met domoticz dan moet ik een wachtwoord invoeren, wat alleen nodig is als ik verbinding maak met een IP die niet begint met 192.168.*.*

Nu is dit natuurlijk logisch, ik zit niet op het locale netwerk, maar als ik het goed begrijp zorgt de VPN service er voor dat de rpi wel denkt dat ik op een locaal netwerk zit. Daarnaast kon ik enkele dagen geleden zonder enige problemen met deze services (zoals transmission) verbinding maken vanaf een niet thuis locatie.

Nu heb ik in de afgelopen dagen wat met openVPN zitten rommelen en denk dat er dus onbewust een setting is veranderd. Ik heb alleen geen idee welke.

Wat mij vervolgens nog opvalt is dat als ik ifconfig op mijn rpi draai ik zie dat mijn ipaddress 192.168.10.100 is terwijl ik in dhcpcd.conf heb aangegeven dat het 192.168.2.100 moet zijn. Misschien is het mij nog nooit opgevallen, maar ik vind het wel raar.

Zou je mij misschien kunnen helpen?

Dank!

PS: Ik heb het onderwerp ook hier toegelicht, maar nog geen respons gekregen, waarschijnlijk omdat mijn opschrijving te complex is.
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=205512&p=1273839#p1273839
Reputatie 2
Zojuist thuis aangekomen, en kwam erachter dat ook mijn laptop het IP address heeft met 192.168.10.X Blijkbaar is dit de ip van een draadloze hotspot. Het vreemde is, alleen, hoe kan de rpi een IP van de hotspot krijgen als deze er niet mee is verbonden?
Mijn bekabelde configuratie is als volgt:
internet --> router ---> switch --> wireless hotspot
--> raspberry
Daarnaast heb ik de draadloze chip van de rpi uitgezet dus hij kan ook draadloos geen verbinding maken met de rpi.

Ik heb nu de draadlose hotspot uitgezet en mijn wifi van de pi opnieuw opgestart en nu heeft het weer een IP address in de vorm 192.168.2.X. Ik blijk het alleen vreemd vinden, hoe kan de draadloze hotspot ervoor zorgen dat de rpi hiervan een static ip (192.168.10.X) krijgt terwijl ik in dhcpcd aangeef dat deze een ip van de router moet gebruiken (192.168.2.X)?

Daarnaast heb ik geprobeerd om nu mijn pi weer het 192.168.2.X adres heeft te verbinden met transmission maar ik krijg nogsteeds de 403 error.

Ik hoop toch niet dat de hotspot voor een man in the middle hack heeft gezorgd?

wat trouwens wel vreemd is. op mijn werk kan ik dus wel gewoon via SSH en VNC taken uitvoeren, maar via transmission en domoticz wordt deze geblokkeerd.

Ik hoop dat jullie wat hebben aan deze extra info. bedankt!
Reputatie 2
Goed ik heb gister het probleem opgelost-ish. Ik heb de whitelost van de torrent daemon uitgezet en nu kan ik wel verbinding maken. Ik blijf het alleen heel raar vinden waarom dit eerst geen probleem was en nu ineens een probleem.

Enig idee hoe ik kan checken hoe ik de ip van mijn host computer kan zien zoals die door het doel netwerk wordt geidentificeerd als ik via een vpn verbinding maak? Ik weet wel hoe ik mijn ip kan vinden van mijn huidge lokale verbinding (ifconfig). En als ik in mijn router kijk zie ik niet alle verbonden apparaten staan. Is het zowiezo misschien mogelijk dat ik wat meer geavanceerde toegang kan krijgen tot mijn router?
Reputatie 7
Badge +30
Hoi,

Allereerst snap ik je probleem niet helemaal maar ik probeer zo veel mogelijk vragen te beantwoorden.

De router ziet dat IP niet.
Je kan het IP van de machine via de VPN zien door de logs van Transmission te checken of tcpdump te gebruiken op de machine die Transmission draait.

Domoticz draait opdezelfde machine als Transmission? Draai je die direct? Via docker? Met een proxy zoals nginx/HAProxy?

Kan je tochten wat de "wireless hotspot" is?

Robin
Reputatie 2
Beste robin,

Sorry voor mijn lastige taalgebruik. Ik weet zelf ook niet helemaal wat het probleem is dus ik vind het lastig op te schrijven.

Ik heb op mijn rpi de volgende software: Domoticz, plex, transmission, jdownloader en motioneye. Ik draai ze allemaal direct op de rpi, geen docker of iets degelijks.. Als ik mijn transmission gebruik zet ik vaak wel PIA aan, maar als ik klaar ben reboot ik zodat ik weer mijn oude IP krijg. Als ik namelijk PIA aan heb staan kan ik buiten mijn netwerk geen verbinding meer maken met mijn rpi.

Wat ik dus raar vindt is dat ik van het een op andere moment mijn verbinding tot transmission buiten de whitelist viel, zonder dat ij (denk ik) wat heb aangepast. En dat kan niets te maken hebben met PIA want die staat gewoon uit, als ik curl ifconfig.me doe krijg ik gewoon de werkelijke ip van mijn huis.

Betreffende de hotspot, dit is een access point die ik in china heb besteld. Deze is met een kabel verbonden aan de router (via een switch) en creeert vervolgens een hotspot. deze werkt met de IP 192.168.10.X en heeft ook een andere SSID dan mijn router. Dus daar zou denk ik geen probleem mee kunnen ontstaan. Toch had mijn RPI ineens een IP met 192.168.10.X wat ik erg raar vindt. Misschien komt het doordat een andere machine op de router het IP address van 192.168.2.100 in beslag nam en dat de rpi daardoor op zoek ging naar de IP op het netwerk die er het meest op leek?

mijn vragen zijn denk ik:
- Hoe kan het dat ik ineens problemen heb met de whitelist van transmission?
- Hoe kan de IP van de RPI 192.168.10.100 worden terwijl ik een statische IP van 192.168.2.100 heb ingesteld in dhcpcd.conf?

Ik zal die logbestanden van de rpi en transmission ook eens gaan onderzoeken bedankt!
Reputatie 7
Badge +30
Dat de VPN niet werkt wanneer je PIA gebruikt klopt. Dat heeft met de routering op de rapsberrypi te maken.

Ik weet niet hoe de whitelist precies werkte, maar als je deze als 192.168.2.0/24 hebt staan is het logisch dat het niet werkte omdat het IP anders was.

Maar, die hotspot, dat is geen hotspot. Dat is een router. En ik betwijfel of je dat zoekt.

Is de Pi bedraad of via WiFi aangesloten?
Reputatie 2
Goeiedag Robin,

sorry voor de late reactie, beetje druk op werk.

Goed ik ven weer met mijn raspberry aan het klooien. Nu probeer ik een raspberry-camera via een access point (geen router meer dus) te verbinden aan de rpi maar dat werkt niet. Ik heb de volgende setup.

Vanaf mijn router (192.168.2.254) loopt een ethernet kabel naar een switch. Aan deze switch zijn 2 apparaten aangesloten via ethernet. Het eerste apparaat is mijn raspberry pi basis station (192.168.2.100), deze kan ik prima bereiken. De tweede kabel is verbinden met een wireless access point. Deze zet de ethernet om in wifi en heeft een ip address van 192.168.10.1, hierin heb ik 2 porten geforeward: 192.168.10.101:22 en 192.168.101:80. Nu wil ik de raspberry-camera kunnen bereiken via de access point. Ik heb de raspberry-camera een statisch ip gegeven (in /etc/dhcpcd.conf) van 192.168.10.101 met een router addres van 192.168.10.1.

Nu beginnen d e problemen, als ik met mijn laptop verbinding maak met de draadloze AP dan kan ik de raspberry-camera via SSH (poort 22) bereiken. Maar zodra ik met mijn laptop verbinding maak met mijn router (192.168.2.254) dan kan ik via ssh de raspberry-camera niet meer bereiken via SSH.

Graag wil ik dat ik vanaf mijn normale netwerk dus verbindig kunnen maken met de camera, en met de camera ook verbinding kunnen maken met het internet. Maar dat gaat dus niet.

Heb jij enig idee hoe ik dit kan oplossen? Ik denk dat het iets te maken heeft met iptables maar ik miet zeggen dat ik hier te weinig verstand van heb.

Voor de duidelijkheid, het verkeer naar de camera loopt bij mij nu dus als volgt:
router (192.168.2.265) ---> switch --> AP (192.168.10.1) --> raspberry camera (192.168.10.101)

alvast bedankt!

edit: owja misschien handig om te zeggen, als ik met mijn laptop verbinding maak met de AP kan ik wel gewoon op het internet, dus er is denk ik niets aan de hand met de verbinding tussen de AP en de router, maar wel tussen de AP en de raspberry-camera

en misschien wat handige info vanuit de ssh van de raspberry-camera:

ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163 mtu 1500
inet 192.168.10.101 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::4272:6b27:3d4c:245f prefixlen 64 scopeid 0x20
ether b8:27:eb:9d:af:37 txqueuelen 1000 (Ethernet)
RX packets 474 bytes 40618 (39.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 346 bytes 39719 (38.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163 mtu 1500
inet 192.168.10.101 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::4272:6b27:3d4c:245f prefixlen 64 scopeid 0x20
ether b8:27:eb:9d:af:37 txqueuelen 1000 (Ethernet)
RX packets 474 bytes 40618 (39.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 346 bytes 39719 (38.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163 mtu 1500
inet 192.168.10.101 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::4272:6b27:3d4c:245f prefixlen 64 scopeid 0x20
ether b8:27:eb:9d:af:37 txqueuelen 1000 (Ethernet)
RX packets 474 bytes 40618 (39.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 346 bytes 39719 (38.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.10.1 0.0.0.0 UG 302 0 0 wlan0
192.168.10.0 0.0.0.0 255.255.255.0 U 302 0 0 wlan0

ping 192.168.2.254
PING 192.168.2.254 (192.168.2.254) 56(84) bytes of data.
64 bytes from 192.168.2.254: icmp_seq=1 ttl=63 time=3.73 ms
64 bytes from 192.168.2.254: icmp_seq=2 ttl=63 time=5.73 ms
64 bytes from 192.168.2.254: icmp_seq=3 ttl=63 time=5.78 ms
64 bytes from 192.168.2.254: icmp_seq=4 ttl=63 time=5.71 ms
^C
--- 192.168.2.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 3.735/5.242/5.782/0.875 ms

cat /etc/dhcpcd.conf
interface wlan0
static ip_address=192.168.10.101
static routers=192.168.10.1
static domain_name_servers=8.8.8.8
Reputatie 7
Badge +30
Nou, jij zegt dat het een accesspoint is, maar eigenlijk geloof ik daar geen ene moer van. Het heeft namelijk een andere ip-range, functioneert als gateway en doet dhcp.

Ben in iedergeval erg benieuwd naar het merk + type van de AP/router

Robin
Reputatie 2
Dag robin,

Dit is hem, apparaatje uit china. en ik heb hem ingesteld op access point modus.

https://nl.aliexpress.com/item/Comfast-150M-750M-Dual-band-Wireless-home-wifi-repeater-bridge-signal-booster-Amplifier-10dBi-Antenna-wi/32809940412.html
Reputatie 7
Badge +30
Hoi,

Ik ken dat ding niet, maar hij staat niet echt in accesspoint modus. Misschien noemt de interface het wel zo, maar als het echt in accesspoint modus staat dan zal het ding een IP in de 192.168.2.x range hebben en de clients daarachter ook.

Heb je deze een bedrade verbinding gegeven? Dat kan nog wel eens verschil maken.

Wil je, in de huidige situatie, inkomende verbindingen toe staan op de rpi camera dan moet je een forwarding maken op die versterker en het 192.168.2.x IP van de versterker gebruiken om verbinding te maken (dubbel-nat)

Robin
Reputatie 2
Beste robin,

Hij staat met ethernet verbonden ja. in de afbeelding staan de keuzes die ik heb in de router. De reden dat ik voor de AP heb gekozen en niet voor de repeater is omdat ik dacht dat de repeater alleen van wifi naar wifi gaat en de AP van ethernet naar wifi kan. Maar het is inderdaad vreemd dat die die als die in AP staat een ander IP heeft. Ik zal eens een factory reset doen, wellicht zijn de instellingen van de router modus nog geldig terwijl die AP weergeeft.

Reageer