SSH nur für einen Tunnel zu einer bestimmten IP erlauben

[Laizzzy]

Hallo,

ich möchte jemanden einenTunnel zu einem Rechner bereitstellen.

Also einen Tunnel nur zu einer bestimmten IP im Netzwerk.

Es gibt zwar viel Vertrauen zu der Person, doch zur Sicherheit würde ich trotzdem den Nutzeraccount so limitieren, dass nur der Tunnel nur zu der einen IP und nicht zu anderen IPs gestattet wird.

(wenn die Geräte auch nicht ohne gültiges Passwort zugänglilch wären)

Lässt sich das durch "einfache" Konfiguration bewerkstelligen?

Oder führt da kein Weg an internen Firewall-Regeln, welche alle Verbindungen bis die auf diese besagte interne IP blocken, vorbei?

Beste Grüsse

[mat6937]

... nur der Tunnel nur zu der einen IP und nicht zu anderen IPs gestattet wird.

Das kannst Du in der sshd_config mit z. B.:

Code: Alles auswählen

AllowUsers <user>@<IP-Adresse>

konfigurieren.
Aber damit hast Du noch nicht sicher gestellt, wem bzw. wie die Gegenseite Zugang zum vorhandenen Tunnel gestattet.

[MSfree]

Oder führt da kein Weg an internen Firewall-Regeln, welche alle Verbindungen bis die auf diese besagte interne IP blocken, vorbei?

Clientseitig kann man SSH selbst nicht einschränken.

Wenn der Client also nur eine einzige IP erreichen können soll, führt kein Weg an iptables/nftables-Rgeln vorbei. Aber auch das ist nur ein unvollständiger "Schutz". Wenn jemand auf einem Server im Internet SSH auf Port 443 erreichbar macht, würde er deine Sperre auf Port 22 aushebeln.

[mat6937]

Wenn der Client also nur eine einzige IP erreichen können soll, führt kein Weg ...

Auf dem Client kann man in dessen config, die IP-Adresse des Servers festlegen, mit z. B.:

Code: Alles auswählen

CheckHostIP yes

[MSfree]

Auf dem Client kann man in dessen config, die IP-Adresse des Servers festlegen, mit z. B.:

Code: Alles auswählen

CheckHostIP yes

Der Parameter darf "Yes" oder "No" sein und führt lediglich dazu, daß zusätzlich zum Hostname (wer verwendet denn bitte IP-Adressen zu Eingabe?) noch die IP-Adresse mit dem DNS abgeglichen wird und mit der Datei ~/.ssh/known_hosts verglichen wird. Das ist nur als zusätzlicher Spoofing-Schutz gedacht.

Dieser Parameter verhindert nicht, daß man sich mit mehr als nur einen einzigen, erlaubten Host verbinden kann.

[mat6937]

... (wer verwendet denn bitte IP-Adressen zu Eingabe?) ...

Z. B. die die eine feste/statische IP-Adresse haben oder die, die ssh via VPN (oder gleichwertig) benutzen.

Aber Du hast in deinem Beitrag doch auch von nur einer einzigen IP-Adresse geschrieben, die der Client erreichen können soll:

Wenn der Client also nur eine einzige IP erreichen können soll, führt kein Weg an iptables/nftables-Rgeln vorbei.

BTW: Zur Eingabe muss man die IP-Adresse nicht benutzen, denn man kann diese in der config des Clienten (als HostName) eintragen und nur <Host> für den Verbindungsaufbau nutzen.

[MSfree]

Z. B. die die eine feste/statische IP-Adresse haben oder die, die ssh via VPN (oder gleichwertig) benutzen.

Verstehe ich nicht. Bei mir löst der DNS dynamische und statische IPs auf. Man braucht sich also nie irgendwelche IPs merken und benutzen.

BTW: Zur Eingabe muss man die IP-Adresse nicht benutzen, denn man kann diese in der config des Clienten (als HostName) eintragen und nur <Host> für den Verbindungsaufbau nutzen.

Wie gesagt, es ist egal, was du Clientseitig versuchst zu konfigurieren, du kannst nicht verhindern, daß der Benutzer sich mit ungewollten Hosts verbindet.

[mat6937]

Wie gesagt, es ist egal, was du Clientseitig versuchst zu konfigurieren, du kannst nicht verhindern, daß der Benutzer sich mit ungewollten Hosts verbindet.

Clientseitig benutze ich z. B. diese Konfiguration:

Code: Alles auswählen

Host *
	CheckHostIP yes
	 IdentitiesOnly yes
Host <Host>
	HostName <IP-Adresse-sshd-Server>
	BindAddress <IP-Adresse-ssh-Client>
	Port <Port-sshd-Server>
	User <user-auf-dem-sshd-server>
	....
	....

und damit kann ich das schon verhindern.

[MSfree]

Clientseitig benutze ich z. B. diese Konfiguration:...und damit kann ich das schon verhindern.

Nein, kannst du nicht.

Mit

Code: Alles auswählen

touch MyConfig
ssh -F MyConfig user@EvilHost

kann ich das jederzeit umgehen.

[mat6937]

Nein, kannst du nicht.

Mit

Code: Alles auswählen

touch MyConfig
ssh -F MyConfig user@EvilHost

kann ich das jederzeit umgehen.

Dann reden wir aneinander vorbei. Denn Du gehst jetzt davon aus, dass auf dem ssh-Client-PC mehrere user (accounts) tätig sind, und der eine ssh-user den anderen ssh-user, mit Hilfe der ssh-Client-Konfiguration nicht einschränken kann.

[MSfree]

Dann reden wir aneinander vorbei. Denn Du gehst jetzt davon aus, dass auf dem ssh-Client-PC mehrere user (accounts) tätig sind, und der eine ssh-user den anderen ssh-user, mit Hilfe der ssh-Client-Konfiguration nicht einschränken kann.

Das hat doch m it der Anzahl User gar nichts zu tun.

Wenn der Admin des Clientrechners meint, er könne dem User Hugo verbieten, sich mit EvilHost zu verbinden, in dem eine Client-Config vorgesetzt wird, dann ist der Admin schlecht informiert. Hugo kann sich jederzeit seine eigene Config irgendwo anlegen, wo er Schreibberechtigung hat. Im einfachsten Fall legt er eine leere Config an, in der er eine neue Datei toucht. Hugo kann dann SSH mit seiner Config starten, dabei werden jegliche Configs, von /etc/ssh/ssh_config bis hin zu ~/.ssh/config schlicht und ergreifend ignoriert. Wie willst du dann verhindern, daß sich Hugo mit EvilHost verbindet?

[mat6937]

Wie willst du dann verhindern, daß sich Hugo mit EvilHost verbindet?

Naja, genau das was ich vermutet habe.

Clientseitig kann man SSH selbst nicht einschränken.

Auf einem privaten Clientrechner ist Hugo i. d. R. auch der admin. Auf meinem Firmenlaptop sagt der admin, was zulässig ist und was nicht zulässig ist.

[MSfree]

Auf einem privaten Clientrechner ist Hugo i. d. R. auch der admin.

Genau, und als Admin ist der auch in der Lage, Sperren auszuhebeln. Aber selbst als Nicht-Admin kann man "Sperren", die nur über die Config kommen, sehr einfach aushebeln, ohne root-Rechte zu benötigen.

Auf meinem Firmenlaptop sagt der admin, was zulässig ist und was nicht zulässig ist.

Auch da kann der Admin nicht alles durch Sperren einschränken. Dazu gibt es dann zusätzlich schriftliche Policies, die einem die ein oder andere Manipulation verbieten.

Man kann es z.B. nicht technisch verhindern, daß der SSH-Schlüssel auf eine andere Maschine kopiert wird. Man kann es aber dem Mitarbeiter schriftlich verbieten, tut er es dennoch, gibt es arbeitsrechtliche Konsequenzen.

[mat6937]

Genau, und als Admin ist der auch in der Lage, Sperren auszuhebeln. Aber selbst als Nicht-Admin kann man "Sperren", die nur über die Config kommen, sehr einfach aushebeln, ohne root-Rechte zu benötigen.

Wenn er der einzige user (egal ob admin oder Hugo) auf dem PC ist, wird er doch nicht seine eigene Konfiguration (... mit der er SSH aus gutem Grund clientseitig eingeschränkt hat) aushebeln wollen. Es geht ja lediglich darum, wie und ob man nur mit Hilfe der Konfiguration, SSH clientseitig einschränken kann oder nicht kann. Die Frage ob man das so konfigurierte dann auch aushebeln kann, stellt sich nicht, wenn man der einzige user auf diesem Client-PC ist.

Auch da kann der Admin nicht alles durch Sperren einschränken.

Naja, ich meinte ja nur, dass auf meinem Firmen-Laptop ich nicht alleiniger user bin (im Vergleich zum privaten PC). Da stellt sich ja auch nicht die Frage ob ich dort etwas aushebeln kann oder nicht kann, weil das Bedürfnis so etwas zu tun, nicht vorhanden ist.

[tubbi]

Hallo Laizzzy, falls dein Problem noch besteht, gestatte mir eine Gegenfrage: Sind die beiden Maschinen, welche durch den Tunnel verbunden werden sollen, linuxoider Art?

[uname]

@Laizzzy

Ich habe nicht alles gelesen. Abr es gibt in "authorized_keys" unter anderen die Optionen "from=" und "command".
Dann nur Keys erlauben und natürlich verbieten, dass der Anwender diese Datei ändert
Falls keine Shell benötigt wird setze entweder als Shell /bin/false (Benutzer muss dann -N verwenden) oder definiere den Zielbefehl auch in authorized_keys. Ich hatte das mal programmiert, dass man darüber nur in eine Restriced-Shell inkl. Screen/Tmux für Ferwartung kam.

https://debian-administration.org/artic ... _addresses