Hallo,
es sei ein gateway zwischen LAN und Internet. Problem: bestimmte Nutzer sollen sich per ssh zwar aus dem LAN, nicht aber aus dem Internet anmelden. Any ideas? (Zwei daemons laufen lassen fuer internes und externes interface ist bislang mein (unschoener) Ansatz.)
Danke im Voraus,
Gruss vom Frank.
Moin,
es sei ein gateway zwischen LAN und Internet. Problem:
bestimmte Nutzer sollen sich per ssh zwar aus dem LAN, nicht
aber aus dem Internet anmelden. Any ideas? (Zwei daemons
laufen lassen fuer internes und externes interface ist bislang
mein (unschoener) Ansatz.)
Hast Du 'n Gateway mit Firewall? Dann könntest Du doch Port 22 sperren für incoming traffic und niemand von außen kann ssh auf Deine Rechner.
Gruß,
Ingo
Moin,
Mahlzeit,
es sei ein gateway zwischen LAN und Internet. Problem:
bestimmte Nutzer sollen sich per ssh zwar aus dem LAN, nicht
aber aus dem Internet anmelden. Any ideas? (Zwei daemons
laufen lassen fuer internes und externes interface ist bislang
mein (unschoener) Ansatz.)Hast Du 'n Gateway mit Firewall? Dann könntest Du doch Port 22
sperren für incoming traffic und niemand von außen kann ssh
auf Deine Rechner.
Die Differenzmenge zwischen allen Nutzern und oben erwaehnten bestimmten Nutzern ist leider nicht leer: es gibt nach wie vor ein paar Nutzer, die sich auch von aussen anmelden duerfen. Es gibt Alice und Bob (und root) auf dem Rechner. Von innen duerfen beide, von aussen nur Bob.
Danke,
Gruss vom Frank.
Hallo,
es sei ein gateway zwischen LAN und Internet. Problem:
bestimmte Nutzer sollen sich per ssh zwar aus dem LAN, nicht
aber aus dem Internet anmelden. Any ideas?
man sshd:
AUTHORIZED\_KEYS FILE FORMAT
$HOME/.ssh/authorized\_keys is the default file that lists the public keys
that are permitted for RSA authentication in protocol version 1 and for
public key authentication (PubkeyAuthentication) in protocol version 2.
AuthorizedKeysFile may be used to specify an alternative file.
Each line of the file contains one key (empty lines and lines starting
with a `#' are ignored as comments). Each RSA public key consists of the
following fields, separated by spaces: options, bits, exponent, modulus,
comment. Each protocol version 2 public key consists of: options, key
type, base64 encoded key, comment. The options fields are optional; its
presence is determined by whether the line starts with a number or not
(the option field never starts with a number). The bits, exponent, modu
lus and comment fields give the RSA key for protocol version 1; the com
ment field is not used for anything (but may be convenient for the user
to identify the key). For protocol version 2 the keytype is ``ssh-dss''
or ``ssh-rsa''.
Note that lines in this file are usually several hundred bytes long
(because of the size of the RSA key modulus). You don't want to type
them in; instead, copy the identity.pub, id\_dsa.pub or the id\_rsa.pub
file and edit it.
sshd enforces a minimum RSA key modulus size for protocol 1 and protocol
2 keys of 768 bits.
The options (if present) consist of comma-separated option specifica
tions. No spaces are permitted, except within double quotes. The fol
lowing option specifications are supported (note that option keywords are
case-insensitive):
**from="pattern-list"**
**Specifies that in addition to RSA authentication, the canonical
name of the remote host must be present in the comma-separated
list of patterns (`*' and `'? serve as wildcards).** The list may
also contain patterns negated by prefixing them with `'!; if the
canonical host name matches a negated pattern, the key is not
accepted. The purpose of this option is to optionally increase
security: RSA authentication by itself does not trust the network
or name servers or anything (but the key); however, if somebody
somehow steals the key, the key permits an intruder to log in
from anywhere in the world. This additional option makes using a
stolen key more difficult (name servers and/or routers would have
to be compromised in addition to just the key).
Hallo,
Hi,
> AUTHORIZED\_KEYS FILE FORMAT
> $HOME/.ssh/authorized\_keys [snip]
> **from="pattern-list"**
> **Specifies that in addition to RSA authentication, the canonical
> name of the remote host must be present in the comma-separated
> list of patterns (`*' and `'? serve as wildcards).** [snip]
> The purpose of this option is to optionally increase
> security: RSA authentication by itself does not trust the network
> or name servers or anything (but the key); however, if somebody
> somehow steals the key, the key permits an intruder to log in
> from anywhere in the world.
Hm, und wenn ich gerade nicht mit public key komme? Den secret dazu will man ja auch nicht auf jedem Rechner der Welt liegen haben. Ausserdem ist der untrusted part in diesem Fall eher der user, der sich einloggen soll (oder eben nicht). Mitarbeiter sollen nicht von Zuhause in der Firma arbeiten. Wenn er nur in seinem ~/.ssh rumspielen muss waere das ja arg leicht zu umgehen. Oder missverstehen wir uns?
Trotzdem ein Anfang, danke,
Gruss vom Frank.
Hallo,
Hm, und wenn ich gerade nicht mit public key komme?
Passwort ist hier[tm] nicht. Den Schlüssel kann man ja auch auf Diskette/USB-Stick mitnehmen …
Den
secret dazu will man ja auch nicht auf jedem Rechner der Welt
liegen haben.
ein USB-Schlüssel tut auch. Von einer kompromittierten Kiste will man sich ohnehin nicht loggen, auch nicht per Passwort.
Ausserdem ist der untrusted part in diesem Fall
eher der user, der sich einloggen soll (oder eben nicht).
Mitarbeiter sollen nicht von Zuhause in der Firma arbeiten.
Wenn er nur in seinem ~/.ssh rumspielen muss waere das ja arg
leicht zu umgehen.
Ich habe nicht geguckt, wie leicht SSH zu patchen wäre, daß es in einem anderen Pfad sucht. Oder daß es eine Datei unter /etc/wrzlbrrz inkludiert.
Oder missverstehen wir uns?
Nein.
Gruß,
Sebastian
Hm, und wenn ich gerade nicht mit public key komme?
Passwort ist hier[tm] nicht.
Hier auch nicht, aber dort.
Den Schlüssel kann man ja auch auf Diskette/USB-Stick mitnehmen …
Mist, immer mit der Diskette erst zum webserver latschen, um mit der shell von zu Hause nach irgendwohin ssh zu machen.
Ich habe nicht geguckt, wie leicht SSH zu patchen wäre, daß es
in einem anderen Pfad sucht.
Ich hatte ja eher die Hoffnung, dass der sshd dem PAM sagt, von welchem interface oder auch von welcher IP# das login kam. Hm, tut er wohl nicht.
Gruss vom Frank.
Hallo,
Den Schlüssel kann man ja auch auf Diskette/USB-Stick mitnehmen …
Mist, immer mit der Diskette erst zum webserver latschen, um
mit der shell von zu Hause nach irgendwohin ssh zu machen.
Huch? Nein, andersrum. Du hast Zu Hause den Schlüssel auf USBette und loggst Dich mit dem auf dem Webserver ein.
Gruß,
Sebastian
Hallo,
es sei ein gateway zwischen LAN und Internet. Problem:
bestimmte Nutzer sollen sich per ssh zwar aus dem LAN, nicht
aber aus dem Internet anmelden. Any ideas? (Zwei daemons
laufen lassen fuer internes und externes interface ist bislang
mein (unschoener) Ansatz.)
Wenn es nicht allzu viele Nutzer sind, AllowUsers bzw. DenyUsers in der sshd_config. Da geht auch user@host, Wildcards sind erlaubt.
Alexander
Hallo,
Hi,
Den Schlüssel kann man ja auch auf Diskette/USB-Stick mitnehmen …
Mist, immer mit der Diskette erst zum webserver latschen, um
mit der shell von zu Hause nach irgendwohin ssh zu machen.Huch? Nein, andersrum. Du hast Zu Hause den Schlüssel auf
USBette und loggst Dich mit dem auf dem Webserver ein.
Ja und dann? Man will ja vom webserver auch schon mal noch auf andere Rechner. Auf dem webserver ist man aber vielleicht nicht unbedingt root und hat daher etwas gegen secret keys darauf. Wir schweifen ab.
Gruss vom Frank.
Hi,
aus man sshd_config:
AllowUsers
This keyword can be followed by a list of user name patterns,
separated by spaces. If specified, login is allowed only for us-
er names that match one of the patterns. `*' and `?' can be used
as wildcards in the patterns. Only user names are valid; a nu-
merical user ID is not recognized. By default, login is allowed
for all users. **If the pattern takes the form USER@HOST then USER
and HOST are separately checked, restricting logins to particular
users from particular hosts.**
Ist das nicht genau das, was Du möchtest? Bei den „restricted users“ nimmste dann halt das interne Netz (192.168.* o.ä.) als Host.
Hab ich jetzt nicht getestet, hört sich aber passend an, oder?
Gruß,
Malte.
Huhu,
Wenn es nicht allzu viele Nutzer sind, AllowUsers bzw.
DenyUsers in der sshd_config. Da geht auch user@host,
Wildcards sind erlaubt.
*AAGRG*
Warum komme ich da nicht drauf, wo ich gerade an sowas fast verzeifelt bin (und lange nach dem „Fehler“ gesucht gabe).?
Ich werde alt.
Gruß,
Sebastian
> AllowUsers
> [snip]
Ist das nicht genau das, was Du möchtest?
Hm… ja. (Ein Glueck kriege ich nicht wie andere eine midlife crisis, nur weil ich nicht lesen kann.)
Bei den „restricted users“ nimmste dann halt das interne
Netz (192.168.* o.ä.) als Host.
Naja, so aehnlich: IP#s mag er nicht (koennt ja jeder kommen) und das pattern fuer den host muss auf den FQDN matchen, da abkuerzend foo fuer foo.bar.org hinzuschreiben reicht nicht, auch wenn der resolver weiss, dass er in bar.org suchen soll. Naja, man vertraut halt dem DNS. Interne und externe IP#s fummle ich jetzt im DNS in unterschiedliche domains.
Danke,
Gruss vom Frank.