Vraag Hoe maak ik een beperkte SSH-gebruiker aan voor port forwarding?


ændrük stelde een omgekeerde verbinding voor voor het verkrijgen van een eenvoudige SSH-verbinding met iemand anders (voor hulp op afstand). Om dat te laten werken, is een extra gebruiker nodig om de verbinding te accepteren. Deze gebruiker moet zijn poort kunnen doorsturen via de server (de server fungeert als proxy).

Hoe maak ik een beperkte gebruiker die niets meer kan doen dan de hierboven beschreven?

De nieuwe gebruiker moet niet in staat zijn om:

  • voer shell-commando's uit
  • toegang krijgen tot bestanden of bestanden uploaden naar de server
  • gebruik de server als proxy (bijvoorbeeld webproxy)
  • toegang tot lokale diensten die anders niet publiekelijk toegankelijk waren vanwege een firewall
  • dood de server

Samengevat, hoe maak ik een beperkte SSH-gebruiker die alleen zonder rechten verbinding kan maken met de SSH-server, zodat ik via die verbinding verbinding kan maken met zijn computer?


90
2018-06-10 20:04


oorsprong




antwoorden:


TL; DR - ga naar de onderkant van het antwoord, "De beperkingen toepassen"

Het toevoegen van een beperkte gebruiker bestaat uit twee delen: 1. De gebruiker maken 2. Configuratie van de SSH-daemon (sshd)

Sshd configureren

De beste plaats om bekend te raken met de mogelijkheden van SSH is door de bijbehorende handleidingen te lezen:

Waar kan de SSH-client acties uitvoeren?

Voordat u iets kunt beperken, moet u de functies van SSH kennen. Spuwen door de manual pagina's levert op:

  • Shell voert uitvoering uit
  • Bestand uploaden via sftp
  • Port forwarding
    • De client stuurt een (on) gebruikte poort door naar de server
    • De server stuurt zijn poort door naar de klant
    • De server stuurt een poort van een andere host naar de client (proxy-achtig)
  • X11 doorsturen (display forwarding)
  • Doorsturen van authenticatiemiddel
  • Forwarding van een tunnelapparaat

Van de authenticatie sectie van de manpage van sshd (8):

Als de client zichzelf met succes authenticeert, een dialoogvenster voor de voorbereiding   de sessie is ingevoerd. Op dit moment kan de klant dingen als vragen    toewijzen van een pseudo-tty, doorsturen van X11-verbindingen, doorsturen van TCP   verbindingen, of doorsturen van de verificatie agent verbinding over de   beveiligd kanaal.

Hierna, de klant ook vraagt ​​een shell of uitvoering van een commando.   De zijkanten gaan dan naar de sessiemodus. In deze modus kan elke kant verzenden   gegevens op elk gewenst moment, en dergelijke gegevens worden doorgestuurd naar / van de shell of het commando   aan de serverzijde en de gebruikersterminal aan de clientzijde.

Opties voor het beperken van SSH-functies

Bestanden en hun opties die gedrag veranderen zijn:

  • ~/.ssh/authorized_keys - bevat sleutels die mogen verbinden, die opties kunnen worden gegeven:
    • command="command" - Het door de gebruiker opgegeven commando (indien aanwezig) wordt genegeerd. Merk op dat de client TCP en / of X11-forwarding kan specificeren, tenzij deze expliciet zijn verboden. Merk op dat deze optie van toepassing is op shell-, commando- of subsysteemuitvoering.
    • no-agent-forwarding - Verbiedt authenticatie agent doorsturen wanneer deze sleutel wordt gebruikt voor authenticatie.
    • no-port-forwarding - Verbiedt TCP-forwarding wanneer deze sleutel wordt gebruikt voor authenticatie
    • no-X11-forwarding - "Verbiedt het doorsturen van X11 wanneer deze sleutel wordt gebruikt voor authenticatie."
    • permitopen="host:port" - Beperk lokale 'ssh -L' port forwarding zodanig dat deze alleen verbinding kan maken met de opgegeven host en poort.
  • ~/.ssh/environment - Dit bestand wordt ingelezen in de omgeving bij inloggen (indien aanwezig). Omgevingverwerking is standaard uitgeschakeld en wordt bestuurd via de optie PermitUserEnvironment
  • ~/.ssh/rc - Bevat initialisatieroutines die moeten worden uitgevoerd voordat de hoofddirectory van de gebruiker toegankelijk wordt.
  • /etc/ssh/sshd_config - het systeemomvattende configuratiebestand
    • AllowAgentForwarding - Geeft aan of ssh-agent (1) doorsturen is toegestaan.
    • AllowTcpForwarding
    • ForceCommand - "Forceert de uitvoering van het commando gespecificeerd door ForceCommand, negeert elke door de client geleverde opdracht en ~ / .ssh / rc indien aanwezig. De opdracht wordt aangeroepen door de inlogshell van de gebruiker met de -c optie te gebruiken."
    • GatewayPorts - "Geeft aan of externe hosts verbinding mogen maken met poorten die zijn doorgestuurd voor de client.Styd (8) bindt standaard externe poortdoorstuuracties aan het loopback-adres.Dit voorkomt dat andere hosts op afstand verbinding maken met doorgestuurde poorten.gatewayPoorten kunnen worden gebruikt om op te geven dat sshd externe doorstuurpoorten moet toestaan ​​om te binden aan niet-loopback-adressen, waardoor andere hosts verbinding kunnen maken. "
    • PermitOpen:

Hiermee geeft u de bestemmingen op waarnaar de TCP-poort wordt doorgestuurd   toegestaan. De doorstuurspecificatie moet een van de zijn   volgende vormen:

PermitOpen host:port
PermitOpen IPv4_addr:port
PermitOpen [IPv6_addr]:port

Meerdere forwards kunnen worden gespecificeerd door ze te scheiden met   witte ruimte. Een argument van 'any' kan worden gebruikt om alles te verwijderen   beperkingen en toestemming geven voor eventuele doorstuurverzoeken. Standaard alles   poortdoorzendingsverzoeken zijn toegestaan.


142
2018-06-22 09:11



Om dit te laten werken, is het account toegevoegd door useradd moet ontgrendeld zijn. Dat kan gedaan worden door het wachtwoord te vervangen in /etc/shadow door een asteric (*) of door een wachtwoord in te stellen met sudo passwd limited-user. - Lekensteyn
SFTP werkt omdat de SSH-server de sftp-server opdracht. Met ForceCommand, dit commando zal niet meer worden uitgevoerd. - Lekensteyn
Ook nuttig is de from= optie in authorized_keys. Hiermee kunt u het gebruik van de sleutel beperken tot bronnen met een bepaald IP-adres of een bepaalde hostnaam. Voorbeeld, from="1.1.1.1" of from="10.0.0.?,*.example.com". Zie de sectie "AUTHORIZED_KEYS FILE FORMAT" op de man-pagina (linux.die.net/man/8/sshd) voor alle opties met authorized_keys. - Donn Lee
"AllowTcpForwarding local" verbiedt remote forwarding. (Ik weet niet of het bestond toen dit antwoord werd geschreven.) - Simon Sapin
Merk op dat dit wordt onderbroken door aanhoudende ssh-verbindingen, dus je zou niet zoiets moeten hebben Host * ControlMaster auto in uw ~/.ssh/config bestand bij het verbinden met ssh -N. Gebruik als u het nodig hebt ssh -N -o ControlMaster=no - nh2


Ik weet zeker dat er veel oplossingen voor zijn, en veel robuuster dan degene die ik voorstel. Dit kan echter voldoende zijn voor uw behoeften. Om dit te doen, neem ik aan dat de gebruiker in staat is om op ssh key gebaseerde authenticatie te doen (putty of elke unix ssh zou dit moeten ondersteunen).

  • Voeg een gebruiker toe zoals u normaal zou doen ('adduser' of een andere tool)

  • Maak de gebruikers .ssh dir en .ssh / authorized_keys

your_user $ sudo -Hu ssh_forwarder /bin/bash

ssh_forwarder $ cd ~
ssh_forwarder $ mkdir .ssh
ssh_forwarder $ ( umask 066 && cat > .ssh/authorized_keys ) <<EOF
no-agent-forwarding,no-X11-forwarding,command="read a; exit" ssh-rsa AAAB3NzaC1y....2cD/VN3NtHw== smoser@brickies
EOF
  • Schakel wachtwoordtoegang voor dit account uit.
your_user $ sudo usermod --lock ssh_forwarder

Nu, de enige manier waarop de gebruiker toegang kan krijgen tot je systeem is via toegang tot de juiste ssh-sleutel, en ssh zal "/ bin / bash -c 'een" "voor ze laten uitvoeren, ongeacht wat ze proberen uit te voeren. 'lees a' zal gewoon lezen tot een nieuwe regel, en dan zal de shell afsluiten, zodat de gebruiker gewoon op 'enter' hoeft te drukken om de verbinding te doden.

Er zijn veel andere dingen die je zou kunnen doen in 'command ='. Zien man authorized_keys en zoek naar 'commando' voor meer informatie.

Als u het niet leuk vindt dat het raken van enter de verbinding doodt, kunt u zoiets als het volgende gebruiken voor het item 'command =':

command="f=./.fifo.$$ && mkfifo $f && trap \"rm -f $f\" EXIT && read a <$f && echo $a; exit;"

Dit maakt gewoon een tijdelijke fifo in de homedirectory van de gebruiker en probeert er vervolgens uit te lezen. Er zal niets naar dat bestand worden geschreven, dus dit blijft voor onbepaalde tijd hangen. Als u bovendien die verbinding met geweld wilt beëindigen, kunt u iets doen als:

 your_user$ echo GOODBYE | sudo tee ~ssh_forwarder/.fifo.*

Dit zou heel weinig middelen moeten gebruiken, en niets zou fout kunnen gaan in dat script dat niet eindigt bij het beëindigen van de shell.

sleep 1h; echo You have been here too long. Good bye.

Ik zag niet uit de hand hoe je de gebruiker kon toestaan ​​om op afstand vooruit te gaan (ssh -R) maar limiet (ssh -L). Misschien zou 'permitopen' kunnen worden gebruikt. googlen was niet erg behulpzaam. Het lijkt erop dat zoiets als 'no-port-forwarding, permitremoteopen = 10001' nuttig zou zijn om toe te staan ssh -R 6901:localhost:6901.

Dit is een oplossing. Het kan zeker worden verbeterd en elke opening van afgelegen havens moet worden onderzocht. Als het mijn doel was mijn grootmoeder toestemming te geven om verbinding te maken met mijn LAN, zodat ik vnc kon gebruiken om haar scherm te bekijken, en de toegang tot die sleutels was beperkt tot haar, dan zou ik persoonlijk redelijk veilig zijn. Als dit voor een onderneming was, zou nader onderzoek nodig zijn. Een ding om op te letten is ssh -N vraagt ​​helemaal geen shell, dus de 'command =' code wordt niet uitgevoerd.

Andere, mogelijk veiliger mechanismen zijn bijvoorbeeld het maken van een aangepaste shell voor de gebruiker en zelfs vergrendelen met apparmour.


2
2018-06-21 13:09



Dit ziet er erg hackish uit, het is zelfs niet nodig om een ​​shell te hebben omdat er geen commando moet worden uitgevoerd. Zien de handleiding van ssh voor de -N keuze. Er moet een schonere manier zijn om dit te bereiken. - Lekensteyn
Dat is waar. Ik hoop ook een schonere oplossing te zien. Ik denk wel dat authorized_keys in combinatie met no-port-forwarding een redelijk goede oplossing zou zijn als er een 'permitremoteopen' optie was. - smoser
Ik heb wat onderzoek gedaan (zie hierboven). Sinds ssh -N voert helemaal geen commando uit, dat is geen probleem command="something" sluit de sessie. - Lekensteyn