---

Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må kunne
logge ind over SSH og telnet? Der må vel være en fil hvor jeg kan nægte
brugere at kunne logge ind gennem de forskellige services så som telnet,
SSH med flere.


Hilsen Mikkel

---

Hej Mikkel,

Mikkel Bundgaard wrote:

> Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må kunne
> logge ind over SSH og telnet? Der må vel være en fil hvor jeg kan nægte
> brugere at kunne logge ind gennem de forskellige services så som telnet,
> SSH med flere.


Sæt deres shell til noget som ikke kan bruges. Når en bruger logger ind
via ssh, så eksekveres hans shell (normalt /bin/bash). Hvis hans shell
står til noget som maskinen ikke umiddelbart kan holde fast i, så bliver
han smidt ud igen.

In short; sæt hans shell til /bin/true eller /bin/false.

- Morten.

---

Morten Brix Pedersen <morten@wtf.dk> wrote:

>> Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må kunne
>> logge ind over SSH og telnet? Der må vel være en fil hvor jeg kan nægte
>> brugere at kunne logge ind gennem de forskellige services så som telnet,
>> SSH med flere.

> Sæt deres shell til noget som ikke kan bruges. Når en bruger logger ind
> via ssh, så eksekveres hans shell (normalt /bin/bash). Hvis hans shell
> står til noget som maskinen ikke umiddelbart kan holde fast i, så bliver
> han smidt ud igen.

Hvis han ønsker at brugeren stadig skal kunne logge ind fra terminal kan
man rette i de enkelte config-filer. For ssh klares det i
/etc/ssh/sshd_config hvor der tilføjes en linie á la:

DenyUsers mbp

Dette gør det umuligt for brugere "mbp" at logge ind med ssh (læs evt.
manualsiden for 'sshd').

Jeg har aldrig selv brugt telnetd og mener ikke at man bør bruge den nogen
steder hvor man bare ønsker den mindste sikkerhed,

--
Christian Jørgensen / He who can does. He who can't teaches. He who
http://www.razor.dk / can't teach builds learning systems.

---

Morten Brix Pedersen <morten@wtf.dk> wrote in <3C27CE1D.6030909@wtf.dk>:

>Hej Mikkel,
>
>Mikkel Bundgaard wrote:
>
>> Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må kunne
>> logge ind over SSH og telnet? Der må vel være en fil hvor jeg kan
>> nægte brugere at kunne logge ind gennem de forskellige services så som
>> telnet, SSH med flere.
>
>
>Sæt deres shell til noget som ikke kan bruges. Når en bruger logger ind
>via ssh, så eksekveres hans shell (normalt /bin/bash). Hvis hans shell
>står til noget som maskinen ikke umiddelbart kan holde fast i, så bliver
>han smidt ud igen.
>
>In short; sæt hans shell til /bin/true eller /bin/false.

Denne metode kan bruges, hvis bruger aldrig skal logge ind - f.eks. hvis
han er rent mail/ftp bruger.

For at pinde Mortens forslag lidt mere ud:

I filen /etc/shells tilføjes linien:
/bin/false
Derved snyder vi Linux til at tro at /bin/false er en valid shell - det er
den bare ikke.

Nu skal brugerens login shell ændres til at være /bin/false :

Ved eksisterende brugere ændres i filen /etc/passwd - find brugeren og ret
slutningen fra at være:
/bin/bash
til at være
/bin/false
Så kan brugeren ikke mere logge ind for programmet /bin/false kan ikke
eksekveres.

For nye brugere skal man angive
-s /bin/false
ved oprettelsen af brugeren (vha. adduser)

Mvh. NKJensen

---

Den 25 Dec 2001 12:11:20 GMT skrev Niels Kristian Jensen:
>Morten Brix Pedersen <morten@wtf.dk> wrote in <3C27CE1D.6030909@wtf.dk>:
>
>>Hej Mikkel,
>>
>>Mikkel Bundgaard wrote:
>>
>>> Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må kunne
>>> logge ind over SSH og telnet? Der må vel være en fil hvor jeg kan
>>> nægte brugere at kunne logge ind gennem de forskellige services så som
>>> telnet, SSH med flere.
>>
>>
>>Sæt deres shell til noget som ikke kan bruges. Når en bruger logger ind
>>via ssh, så eksekveres hans shell (normalt /bin/bash). Hvis hans shell
>>står til noget som maskinen ikke umiddelbart kan holde fast i, så bliver
>>han smidt ud igen.
>>
>>In short; sæt hans shell til /bin/true eller /bin/false.
>
>Denne metode kan bruges, hvis bruger aldrig skal logge ind - f.eks. hvis
>han er rent mail/ftp bruger.
>
>For at pinde Mortens forslag lidt mere ud:
>
>I filen /etc/shells tilføjes linien:
>/bin/false
>Derved snyder vi Linux til at tro at /bin/false er en valid shell - det er
>den bare ikke.

Dette kan ikke anbefales.

Filen /etc/shells bruges til at fortælle hvilke shells der er reelle
shells, som brugerne selv kan skifte til via. chsh, uden at lave
ulykker.

Mvh
Kent
--
Nu har jeg arbejdet i 40 år på at opnå den sublime "mærklighed" og så
har jeg da ikke tænkt mig at lave om på det.
- Asbjørn Christensen i dk.snak 3/1-2002.

---

kfr@fleggaard.dk (Kent Friis) skrev i <a129r3$pml$1@sunsite.dk>:

>>>> Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må
>>>> kunne logge ind over SSH og telnet? Der må vel være en fil hvor jeg
>>>> kan nægte brugere at kunne logge ind gennem de forskellige services
>>>> så som telnet, SSH med flere.
>>>
>>>
>>>Sæt deres shell til noget som ikke kan bruges. Når en bruger logger
>>>ind via ssh, så eksekveres hans shell (normalt /bin/bash). Hvis hans
>>>shell står til noget som maskinen ikke umiddelbart kan holde fast i,
>>>så bliver han smidt ud igen.
>>>
>>>In short; sæt hans shell til /bin/true eller /bin/false.
>>
>>Denne metode kan bruges, hvis bruger aldrig skal logge ind - f.eks.
>>hvis han er rent mail/ftp bruger.
>>
>>For at pinde Mortens forslag lidt mere ud:
>>
>>I filen /etc/shells tilføjes linien:
>>/bin/false
>>Derved snyder vi Linux til at tro at /bin/false er en valid shell - det
>>er den bare ikke.
>
>Dette kan ikke anbefales.
>
>Filen /etc/shells bruges til at fortælle hvilke shells der er reelle
>shells, som brugerne selv kan skifte til via. chsh, uden at lave
>ulykker.

Hej Kent (eller andre),

1) Er der en anden bedre metode til at lave non-login brugere?

2) Hvilke "ulykker" kan der ske, hvis en bruger skifter shell til
/bin/false - altså et ikke-eksisterende program - man returneres mig
bekendt straks til den oprindelige shell? Er der en situation som jeg har
overset?

Mvh. NKJensen

--
Best regards, (remove the underscore to reply by mail)
Niels Kristian Jensen
MAN B&W Diesel A/S, Denmark
This a personal message, not an official MAN B&W statement.

---

Niels Kristian Jensen wrote:
> 2) Hvilke "ulykker" kan der ske, hvis en bruger skifter shell til
> /bin/false - altså et ikke-eksisterende program - man returneres mig
> bekendt straks til den oprindelige shell? Er der en situation som jeg har
> overset?

/bin/false eksisterer "normalt". Programmet gør intet, og returnerer med
en exit status (1) der indikerer fejl.
Sætter du shell til /bin/false afsluttes login forsøge vel i det
øjeblik, /bin/false eksekveres.

Lars

---

lars@_nospam_lh-online.dk (Lars Henriksen) skrev i
<3C622AC9.50402@_nospam_lh-online.dk>:

>Niels Kristian Jensen wrote:
>> 2) Hvilke "ulykker" kan der ske, hvis en bruger skifter shell til
>> /bin/false - altså et ikke-eksisterende program - man returneres mig
>> bekendt straks til den oprindelige shell? Er der en situation som jeg
>> har overset?
>
>/bin/false eksisterer "normalt". Programmet gør intet, og returnerer med
>en exit status (1) der indikerer fejl.
>Sætter du shell til /bin/false afsluttes login forsøge vel i det
>øjeblik, /bin/false eksekveres.

Takker for svaret - men så støtter du altså den viste metode til at lave
non-login brugere? (Som har virket fint i et års tid nu) Jeg er
forvirret...

Mvh. NKJensen

--
Best regards, (remove the underscore to reply by mail)
Niels Kristian Jensen
MAN B&W Diesel A/S, Denmark
This a personal message, not an official MAN B&W statement.

---

Niels Kristian Jensen wrote:
> Takker for svaret - men så støtter du altså den viste metode til at lave
> non-login brugere? (Som har virket fint i et års tid nu) Jeg er
> forvirret...

hvis du mener, at du sætter brugerens shell (i password fil eller i
entry på NIS) til /bin/false, så er der efter min overbevisning ikke
noget problem.

alternativt kan du (som det vist også blev nævnt) i selve sshd angive
hvilke brugere der må og ikke må logge ind på shell niveau.

en 3. mulighed er, ikke at oprette brugerene som system brugere, men som
mailbrugere, hvor deres post ligger i en database sammen med bruger
informationer, og opretter brugere direkte som ftp brugere. Dette kunne
være at fortrække ved et stort antal brugere, der ikke behøver shell

hygge
Lars

---

>>>>> "Lars" == Lars Henriksen <lars@_nospam_lh-online.dk> writes:

> Niels Kristian Jensen wrote:
>> Takker for svaret - men så støtter du altså den viste metode til at
>> lave non-login brugere? (Som har virket fint i et års tid nu) Jeg er
>> forvirret...

> hvis du mener, at du sætter brugerens shell (i password fil eller i
> entry på NIS) til /bin/false, så er der efter min overbevisning ikke
> noget problem.

http://marc.theaimsgroup.com/?l=qmail&m=99694282315912&w=4
http://www.geocrawler.com/archives/3/91/1996/7/0/186175/
http://www.geocrawler.com/mail/msg.php3?msg_id=186230&list=91

Om disse tilfælde stadig er gældende skal jeg ikke udtale mig om.


/Claus A

---

Claus Alboege wrote:
> http://www.geocrawler.com/archives/3/91/1996/7/0/186175/
>
> Om disse tilfælde stadig er gældende skal jeg ikke udtale mig om.

De omtalte problemer her er, afaik, relateret til 'sh' implementationen
af false og true.
Uden at vide hvordan det er med RH, så vil jeg gå udfra at /bin/false i
deres distro stammer fra GNU sh-utils pakken, hvor /bin/false er
implementeret i C... Fra 'info false':

"
This version of `false' is implemented as a C program, and is thus
more secure and faster than a shell script implementation, and may
safely be used as a dummy shell for the purpose of disabling accounts.
"

false er vel bare implementeret som en main() { exit(1); }
Sikkerheden i det måde at håndtere logins på ligger vel da i den måde
sshd forker på?

just my $0.02

Hvis der er nogle af jer, der har modargumenter vil jeg meget gerne høre
om dem, så jeg kan tage min brugerhåndtering op til overvejelse.

cheers
Lars

---

Den 07 Feb 2002 09:34:40 +0100 skrev Claus Alboege:
>>>>>> "Lars" == Lars Henriksen <lars@_nospam_lh-online.dk> writes:
>
>> Niels Kristian Jensen wrote:
>>> Takker for svaret - men så støtter du altså den viste metode til at
>>> lave non-login brugere? (Som har virket fint i et års tid nu) Jeg er
>>> forvirret...
>
>> hvis du mener, at du sætter brugerens shell (i password fil eller i
>> entry på NIS) til /bin/false, så er der efter min overbevisning ikke
>> noget problem.
>
> http://marc.theaimsgroup.com/?l=qmail&m=99694282315912&w=4
> http://www.geocrawler.com/archives/3/91/1996/7/0/186175/
> http://www.geocrawler.com/mail/msg.php3?msg_id=186230&list=91
>
>Om disse tilfælde stadig er gældende skal jeg ikke udtale mig om.

Ved nærmere eftertanke har man faktisk før brugt /dev/null...

Mvh
Kent
--
IE is the only thing capable of making Netscape look good
- D. Spider in comp.os.linux.advocacy

---

lars@_nospam_lh-online.dk (Lars Henriksen) skrev i
<3C623687.60501@_nospam_lh-online.dk>:

>Niels Kristian Jensen wrote:
>> Takker for svaret - men så støtter du altså den viste metode til at
>> lave non-login brugere? (Som har virket fint i et års tid nu) Jeg er
>> forvirret...
>
>hvis du mener, at du sætter brugerens shell (i password fil eller i
>entry på NIS) til /bin/false, så er der efter min overbevisning ikke
>noget problem.

OK - jeg tror at Kent advarede mod at tilføje /bin/false til listen over
valide shells i /etc/shells - der kunne ske "ulykker".

Jeg fandt det nødvendigt at have /bin/false i /etc/shells for at

adduser -s /bin/false .... (og linuxconfig)

kan virke. Men hvis det har en "ulykke" sidevirkning må jeg jo ændre
metoden. BTW jeg anvender RedHat Linux 7.2

>alternativt kan du (som det vist også blev nævnt) i selve sshd angive
>hvilke brugere der må og ikke må logge ind på shell niveau.

OK - jeg anvender sshd og proftpd, jeg kigger på det.

>en 3. mulighed er, ikke at oprette brugerene som system brugere, men som
>mailbrugere, hvor deres post ligger i en database sammen med bruger
>informationer, og opretter brugere direkte som ftp brugere. Dette kunne
>være at fortrække ved et stort antal brugere, der ikke behøver shell

Jeg har flest FTP-brugere, der hverken behøver shell eller mail men som
skal kunne ændre hinandens filer efter et simpelt owner/group
rettighedsmønster. Filerne læses af en webserver (Lotus Domino R5). Det
virker fint, men den omtalte "ulykke" vil jeg godt have lidt mere styr på.

Mvh. NKJensen

--
Best regards, (remove the underscore to reply by mail)
Niels Kristian Jensen
MAN B&W Diesel A/S, Denmark
This a personal message, not an official MAN B&W statement.

---

Den 7 Feb 2002 09:42:53 +0100 skrev Niels Kristian Jensen:
>lars@_nospam_lh-online.dk (Lars Henriksen) skrev i
><3C623687.60501@_nospam_lh-online.dk>:
>
>>Niels Kristian Jensen wrote:
>>> Takker for svaret - men så støtter du altså den viste metode til at
>>> lave non-login brugere? (Som har virket fint i et års tid nu) Jeg er
>>> forvirret...
>>
>>hvis du mener, at du sætter brugerens shell (i password fil eller i
>>entry på NIS) til /bin/false, så er der efter min overbevisning ikke
>>noget problem.
>
>OK - jeg tror at Kent advarede mod at tilføje /bin/false til listen over
>valide shells i /etc/shells - der kunne ske "ulykker".
>
>Jeg fandt det nødvendigt at have /bin/false i /etc/shells for at
>
>adduser -s /bin/false .... (og linuxconfig)
>
>kan virke. Men hvis det har en "ulykke" sidevirkning må jeg jo ændre
>metoden. BTW jeg anvender RedHat Linux 7.2

Det vil jeg umiddelbart betragte som adduser... Når man kører adduser
er man logget ind som root, og ved *pr. definition* hvad man gør - og
derfor er der ingen grund til denne simple sikring mod komplet idioter.

(systemet brokker sig jo heller ikke over 'dd if=/dev/zero of=/dev/hda')

Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Railroad
Tycoon II and Unreal Tournament run side by side

---

Den Thu, 7 Feb 2002 16:23:02 +0000 (UTC) skrev Kent Friis:
>Den 7 Feb 2002 09:42:53 +0100 skrev Niels Kristian Jensen:
>>lars@_nospam_lh-online.dk (Lars Henriksen) skrev i
>><3C623687.60501@_nospam_lh-online.dk>:
>>
>>>Niels Kristian Jensen wrote:
>>>> Takker for svaret - men så støtter du altså den viste metode til at
>>>> lave non-login brugere? (Som har virket fint i et års tid nu) Jeg er
>>>> forvirret...
>>>
>>>hvis du mener, at du sætter brugerens shell (i password fil eller i
>>>entry på NIS) til /bin/false, så er der efter min overbevisning ikke
>>>noget problem.
>>
>>OK - jeg tror at Kent advarede mod at tilføje /bin/false til listen over
>>valide shells i /etc/shells - der kunne ske "ulykker".
>>
>>Jeg fandt det nødvendigt at have /bin/false i /etc/shells for at
>>
>>adduser -s /bin/false .... (og linuxconfig)
>>
>>kan virke. Men hvis det har en "ulykke" sidevirkning må jeg jo ændre
>>metoden. BTW jeg anvender RedHat Linux 7.2
>
>Det vil jeg umiddelbart betragte som adduser... Når man kører adduser
^^^
             en fejl i

>er man logget ind som root, og ved *pr. definition* hvad man gør - og
>derfor er der ingen grund til denne simple sikring mod komplet idioter.
>
>(systemet brokker sig jo heller ikke over 'dd if=/dev/zero of=/dev/hda')

Mvh
Kent
--
Indlæringskurven til Linux er stejl, til tider lodret... Men for katten
hvor er udsigten på toppen dog fantastisk
- Michael G. Vendelbo i dk.snak

---

kfr@fleggaard.dk (Kent Friis) skrev i <a3ublc$9ep$1@sunsite.dk>:

>>>OK - jeg tror at Kent advarede mod at tilføje /bin/false til listen
>>>over valide shells i /etc/shells - der kunne ske "ulykker".
>>>
>>>Jeg fandt det nødvendigt at have /bin/false i /etc/shells for at
>>>
>>>adduser -s /bin/false .... (og linuxconfig)
>>>
>>>kan virke. Men hvis det har en "ulykke" sidevirkning må jeg jo ændre
>>>metoden. BTW jeg anvender RedHat Linux 7.2
>>
>>Det vil jeg umiddelbart betragte som en fejl i adduser... Når man kører
>>adduser er man logget ind som root, og ved *pr. definition* hvad man gør
>>- og derfor er der ingen grund til denne simple sikring mod komplet
>>idioter.
>>
>>(systemet brokker sig jo heller ikke over 'dd if=/dev/zero
>>of=/dev/hda')

Ja og nej, selv en "rod" kan jo ramme lidt skævt på tazterne og så synes
jeg personligt godt om at adduser lige checker om de indtastede parametre
er lovlige - når det (som i dette tilfælde) er enkelt at lave testen.

Min konklusion er at jeg lader /bin/false stå, fordi der kun er ganske få
brugere med login-mulighed på det aktuelle system. Langt de fleste er ftp
(non-login) brugere og derfor kan de ikke køre chsh. Hvis en af kollegerne
kommer til at skifte sin shell til /bin/false, så kommer han til at give
kvaje-lakridser! Desuden er exploiten med /bin/false så vidt jeg kan
bedømme løst i RH 7.2 (og mange andre GNU/Linux'er)

Tak for de mange hjælpsomme svar

Mvh. NKJensen

--
Best regards, (remove the underscore to reply by mail)
Niels Kristian Jensen
MAN B&W Diesel A/S, Denmark
This a personal message, not an official MAN B&W statement.

---

Den 8 Feb 2002 08:01:36 +0100 skrev Niels Kristian Jensen:
>kfr@fleggaard.dk (Kent Friis) skrev i <a3ublc$9ep$1@sunsite.dk>:
>
>>>>OK - jeg tror at Kent advarede mod at tilføje /bin/false til listen
>>>>over valide shells i /etc/shells - der kunne ske "ulykker".
>>>>
>>>>Jeg fandt det nødvendigt at have /bin/false i /etc/shells for at
>>>>
>>>>adduser -s /bin/false .... (og linuxconfig)
>>>>
>>>>kan virke. Men hvis det har en "ulykke" sidevirkning må jeg jo ændre
>>>>metoden. BTW jeg anvender RedHat Linux 7.2
>>>
>>>Det vil jeg umiddelbart betragte som en fejl i adduser... Når man kører
>>>adduser er man logget ind som root, og ved *pr. definition* hvad man gør
>>>- og derfor er der ingen grund til denne simple sikring mod komplet
>>>idioter.
>>>
>>>(systemet brokker sig jo heller ikke over 'dd if=/dev/zero
>>>of=/dev/hda')
>
>Ja og nej, selv en "rod" kan jo ramme lidt skævt på tazterne og så synes
>jeg personligt godt om at adduser lige checker om de indtastede parametre
>er lovlige - når det (som i dette tilfælde) er enkelt at lave testen.

Problemet er jo at det er helt normalt at have brugere med /bin/false
eller /dev/null i shell, men ikke for brugere der kan logge ind.

/etc/shells skal beskytte mod at save den gren over man selv sidder på
- ikke mod at beskære træer i det hele taget. Adduser er IKKE at save
den gren over man selv sidder på.

Mvh
Kent
--
IE is the only thing capable of making Netscape look good
- D. Spider in comp.os.linux.advocacy

---

kfr@fleggaard.dk (Kent Friis) wrote in <a40tk4$1ct$3@sunsite.dk>:

>Den 8 Feb 2002 08:01:36 +0100 skrev Niels Kristian Jensen:
>>kfr@fleggaard.dk (Kent Friis) skrev i <a3ublc$9ep$1@sunsite.dk>:
>>
>>>>>OK - jeg tror at Kent advarede mod at tilføje /bin/false til listen
>>>>>over valide shells i /etc/shells - der kunne ske "ulykker".
>>>>>
>>>>>Jeg fandt det nødvendigt at have /bin/false i /etc/shells for at
>>>>>
>>>>>adduser -s /bin/false .... (og linuxconfig)
>>>>>
>>>>>kan virke. Men hvis det har en "ulykke" sidevirkning må jeg jo ændre
>>>>>metoden. BTW jeg anvender RedHat Linux 7.2
>>>>
>>>>Det vil jeg umiddelbart betragte som en fejl i adduser... Når man
>>>>kører adduser er man logget ind som root, og ved *pr. definition*
>>>>hvad man gør - og derfor er der ingen grund til denne simple sikring
>>>>mod komplet idioter.
>>>>
>>>>(systemet brokker sig jo heller ikke over 'dd if=/dev/zero
>>>>of=/dev/hda')
>>
>>Ja og nej, selv en "rod" kan jo ramme lidt skævt på tazterne og så
>>synes jeg personligt godt om at adduser lige checker om de indtastede
>>parametre er lovlige - når det (som i dette tilfælde) er enkelt at lave
>>testen.
>
>Problemet er jo at det er helt normalt at have brugere med /bin/false
>eller /dev/null i shell, men ikke for brugere der kan logge ind.
>
>/etc/shells skal beskytte mod at save den gren over man selv sidder på
>- ikke mod at beskære træer i det hele taget. Adduser er IKKE at save
>den gren over man selv sidder på.

Nej, det forhindrer blot et nyt account i at virke. I RH checker adduser om
root kommer til at taste en gal shell ind vha indholdet i /etc/shells (ser
det ud til for mig), det synes jeg er OK.

Ellers kan "rod" vel komme til at lave en slåfejl => bruger ringer og er
sur midt om natten eller hvornår han nu tester sit nye account...

Go' weekend,
NKJensen

---

Den 08 Feb 2002 17:43:40 GMT skrev Niels Kristian Jensen:
>kfr@fleggaard.dk (Kent Friis) wrote in <a40tk4$1ct$3@sunsite.dk>:
>
>>Den 8 Feb 2002 08:01:36 +0100 skrev Niels Kristian Jensen:
>>>kfr@fleggaard.dk (Kent Friis) skrev i <a3ublc$9ep$1@sunsite.dk>:
>>>
>>>>>>OK - jeg tror at Kent advarede mod at tilføje /bin/false til listen
>>>>>>over valide shells i /etc/shells - der kunne ske "ulykker".
>>>>>>
>>>>>>Jeg fandt det nødvendigt at have /bin/false i /etc/shells for at
>>>>>>
>>>>>>adduser -s /bin/false .... (og linuxconfig)
>>>>>>
>>>>>>kan virke. Men hvis det har en "ulykke" sidevirkning må jeg jo ændre
>>>>>>metoden. BTW jeg anvender RedHat Linux 7.2
>>>>>
>>>>>Det vil jeg umiddelbart betragte som en fejl i adduser... Når man
>>>>>kører adduser er man logget ind som root, og ved *pr. definition*
>>>>>hvad man gør - og derfor er der ingen grund til denne simple sikring
>>>>>mod komplet idioter.
>>>>>
>>>>>(systemet brokker sig jo heller ikke over 'dd if=/dev/zero
>>>>>of=/dev/hda')
>>>
>>>Ja og nej, selv en "rod" kan jo ramme lidt skævt på tazterne og så
>>>synes jeg personligt godt om at adduser lige checker om de indtastede
>>>parametre er lovlige - når det (som i dette tilfælde) er enkelt at lave
>>>testen.
>>
>>Problemet er jo at det er helt normalt at have brugere med /bin/false
>>eller /dev/null i shell, men ikke for brugere der kan logge ind.
>>
>>/etc/shells skal beskytte mod at save den gren over man selv sidder på
>>- ikke mod at beskære træer i det hele taget. Adduser er IKKE at save
>>den gren over man selv sidder på.
>
>Nej, det forhindrer blot et nyt account i at virke.

Det kommer an på hvordan den skal virke. Hvis man er ved at oprette
"httpd","mail","dns", etc... vel account'en da virke fint efter
formålet.

>I RH checker adduser om
>root kommer til at taste en gal shell ind vha indholdet i /etc/shells (ser
>det ud til for mig), det synes jeg er OK.
>
>Ellers kan "rod" vel komme til at lave en slåfejl => bruger ringer og er
>sur midt om natten eller hvornår han nu tester sit nye account...

Man plejer ikke at starte midt om natten, hverken på skoler eller
arbejde. Sidder man der midt om natten, er det typisk fordi man har et
projekt der skal være færdigt.

Mvh
Kent
--
A Elbereth Gilthoniel, silivren penna míriel
o menel aglar elenath! Na-chaered palan-díriel
o galadhremmin ennorath, Fanuilos, le linnathon nef aear, sí nef aearon!
- Tolkien, "The Lord of the Rings"

---

Den 7 Feb 2002 07:57:52 +0100 skrev Niels Kristian Jensen:
>kfr@fleggaard.dk (Kent Friis) skrev i <a129r3$pml$1@sunsite.dk>:
>
>>>>> Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må
>>>>> kunne logge ind over SSH og telnet? Der må vel være en fil hvor jeg
>>>>> kan nægte brugere at kunne logge ind gennem de forskellige services
>>>>> så som telnet, SSH med flere.
>>>>
>>>>
>>>>Sæt deres shell til noget som ikke kan bruges. Når en bruger logger
>>>>ind via ssh, så eksekveres hans shell (normalt /bin/bash). Hvis hans
>>>>shell står til noget som maskinen ikke umiddelbart kan holde fast i,
>>>>så bliver han smidt ud igen.
>>>>
>>>>In short; sæt hans shell til /bin/true eller /bin/false.
>>>
>>>Denne metode kan bruges, hvis bruger aldrig skal logge ind - f.eks.
>>>hvis han er rent mail/ftp bruger.
>>>
>>>For at pinde Mortens forslag lidt mere ud:
>>>
>>>I filen /etc/shells tilføjes linien:
>>>/bin/false
>>>Derved snyder vi Linux til at tro at /bin/false er en valid shell - det
>>>er den bare ikke.
>>
>>Dette kan ikke anbefales.
>>
>>Filen /etc/shells bruges til at fortælle hvilke shells der er reelle
>>shells, som brugerne selv kan skifte til via. chsh, uden at lave
>>ulykker.
>
>Hej Kent (eller andre),
>
>1) Er der en anden bedre metode til at lave non-login brugere?

Jeg protesterede ikke imod at sætte shell'en til /bin/false (sorry,
hvis det så sådan ud), kun imod at putte den i /etc/shells.

>2) Hvilke "ulykker" kan der ske, hvis en bruger skifter shell til
>/bin/false - altså et ikke-eksisterende program - man returneres mig
>bekendt straks til den oprindelige shell? Er der en situation som jeg har
>overset?

Når man bruger 'chsh', så ændrer man sin login-shell. Dvs. at man
pludselig ikke kan logge ind længere, hvis man ved et uheld vælger
/bin/false som login-shell. Og så er der kun en løsning - ring til
administratoren (og helst på det mest tåbelige tidspunkt)...

Derfor opfandt man /etc/shells til at beskytte dumme brugere mod at
få sat shell'en til noget så de ikke kunne logge ind.

(Jeg kan forøvrigt se at SuSE som default har både /bin/true og
/bin/false i /etc/shells).

Mvh
Kent
--
You haven't seen _multitasking_ until you've seen Doom and
Quake run side by side

---

Mikkel Bundgaard wrote:

> Er der et sted hvor jeg kan sætte hvilke brugere der må ikke må kunne
> logge ind over SSH og telnet? Der må vel være en fil hvor jeg kan nægte
> brugere at kunne logge ind gennem de forskellige services så som telnet,
> SSH med flere.

Hvis du vil styre servicene uafhængigt af hinanden kan du indstætte en
linie som:

auth required pam_listfile.so item=user sense=allow
file=/etc/allow/login onerr=fail

i PAM for alle servicene. Så skal en bruger stå i ex. /etc/allow/login for
at kunne logge ind lokalt.
--
Jesper

---

Tak for hjælpen til jer alle, det virker bare 100%

Hilsen Mikkel