---

Hej alle.

Som nævnt i subj, er jeg løbet lidt sur i det her.
Det er nok fordi, jeg har siddet de sidste dage og bøvlet med PXE boot, DHCP
server , TFTP server Randisk osv.

Scenarie:
Jeg har en 'master' server med ovenstående kørende.
Så har jeg en klient, der indeholder det mindste af det mindste linux, der
booter op fra master serveren.

Alt virker som det skal, og jeg kan telnette klienten.

Men jeg vil jo grumme gerne *kun* have sshd kørende.

Jeg har konfigureret sshd, og den kører fint - men den brokker sig over
invalid fingerprint osv. Den giver også fejl i loggen med PAM, men det
(PAM) vil jeg helst undgå.

Jeg har kopieret min offentlige nøgle over på klientens fil-system.

Til oplysning, kører jeg som sagt DHCP, uden navngivning af host. Jeg vil
helst undgå registrering af hver enkelt mac-adresse.

Dvs. at diverse rdns, arp osv formentlig vil fejle.

Altså, det jeg er ude efter, er en standardopsætning, der kan bruges på
flere klienter, /alene/ baseret på IP adressen.

Det er ikke fordi jeg ikke selv gider, men det er lige den sidste prik, jeg
mangler efter mange dages arbejde, og jeg synes hjernen er gået lidt død.

Hjælp/links modtages med kyshånd vedr:
- sshd_config
- generering og placering af keys
- known_hosts

På forhånd tak.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
>
> Hej alle.
>
> Som nævnt i subj, er jeg løbet lidt sur i det her.
> Det er nok fordi, jeg har siddet de sidste dage og bøvlet med PXE boot, DHCP
> server , TFTP server Randisk osv.
>
> Scenarie:
> Jeg har en 'master' server med ovenstående kørende.
> Så har jeg en klient, der indeholder det mindste af det mindste linux, der
> booter op fra master serveren.
>
> Alt virker som det skal, og jeg kan telnette klienten.
>
> Men jeg vil jo grumme gerne *kun* have sshd kørende.

Så snart du begynder at bruge netboot er du nødt til at
kunne stole på det pågældende netsegment. Og så er det
primære argument for brug af ssh ikke mere relevant.

Men nu er ssh jo så praktisk at arbejde med, når man
først har fået det sat rigtigt op, så jeg kan da godt
forstå hvis man gerne vil køre den selv over et trusted
netværk.

Jeg er lidt i tvivl om, hvorvidt du tænker på logins
fra server til klient eller omvendt. Logins fra klient
til server skulle ikke være noget problem, hvis blot
du har serverens offentlige nøgle i
/etc/ssh/ssh_knonwn_hosts2 på klienten.

--
Kasper Dupont

---

Kasper Dupont wrote:

> Stig Johansen wrote:
>>
>> Hej alle.
>>
>> Som nævnt i subj, er jeg løbet lidt sur i det her.
>> Det er nok fordi, jeg har siddet de sidste dage og bøvlet med PXE boot,
>> DHCP server , TFTP server Randisk osv.
>>
>> Scenarie:
>> Jeg har en 'master' server med ovenstående kørende.
>> Så har jeg en klient, der indeholder det mindste af det mindste linux,
>> der booter op fra master serveren.
>>
>> Alt virker som det skal, og jeg kan telnette klienten.
>>
>> Men jeg vil jo grumme gerne *kun* have sshd kørende.
>
> Så snart du begynder at bruge netboot er du nødt til at
> kunne stole på det pågældende netsegment. Og så er det
> primære argument for brug af ssh ikke mere relevant.
>
> Men nu er ssh jo så praktisk at arbejde med, når man
> først har fået det sat rigtigt op, så jeg kan da godt
> forstå hvis man gerne vil køre den selv over et trusted
> netværk.
>
> Jeg er lidt i tvivl om, hvorvidt du tænker på logins
> fra server til klient eller omvendt. Logins fra klient
> til server skulle ikke være noget problem, hvis blot
> du har serverens offentlige nøgle i
> /etc/ssh/ssh_knonwn_hosts2 på klienten.

Ja, hjernen er lidt overbelastet p.t.
Jeg har lige slappet lidt af, og fundet denne analogi(tror jeg nok):

Jeg vil sammenligne det lidt med PXE boot af linksys WRT-et eller andet, der
vistnok kører linux - eller embedded linux, der bootes fra master image.

I stedet for at boote fra eprom, bootes fra net. Boot serveren er placeret
på sit eget interne segment. Den bootede klient er nu ssh-serveren.

Nu er det ikke en FW, men hvis man forestiller sig, at der er flere, der
booter op med hver sin IP, kunne jeg godt tænke mig, at få fat i den
enkelte via ssh.

Det er som sagt kun prikken over i'et, da jeg ikke ser noget problem i at
ssh'e til 'master' server på bagsiden af LAN'et, og derfra telnette til de
'klienter', der er startede (styret via IP tables)

Men /hvis/ vi forestiller os, at det var en FW, så går det ud på, at det
kunne være rart at kunne 'tilgå' den et hvilketsomhelst sted i verden vha
medbragt key (og *ikke* via telnet).

Det er nok lidt uklart, men jeg er kun på brainstorming/POC stadiet, så det
er nok bedst, jeg lige tager en kort pause.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

[snip]

Hej igen.

Efter at have sovet lidt på det, gik jeg tingene igennem, lidt mere
struktureret, men fik det alligevel ikke til at virke.

Jeg har lagt det på køl indtil videre, da det ikke er et umidelbart behov.

Det skal forstås sådan, at jeg er i gang med lidt brainstorming/POC over
'det muliges kunst', og netop fordi det er brainstorming, er opsætningen
absolut *ikke* kvalitetssikret.

Med kvalitetssikret mener jeg, at jeg har plukket fra diverse linux
distributioner, og der er nok en til vished grænsende sandsynlighed for, at
mine udfordringer vedr. ssh bunder i inkompabilitet mellem diverse
kernel's, lib's, samt exec's, med vidt forskellige versioner.

Jeg vender måske tilbage når(hvis) jeg får håndbygget en kvalitetssikret
dist.

Jeg vil godt takke dem, der har brugt tid på det her, og status er lige nu,
at uanset hvordan jeg sætter det om, så får jeg bare:
16921: Permission denied (publickey,password,hostbased).
på klienten, og i /var/log/messages på serveren:
Mar 24 12:25:24 tiny auth.err sshd[212]: PAM no modules loaded for `sshd'
service
Mar 24 12:25:24 tiny auth.info sshd[212]: PAM rejected by account
configuration[6]: Permission denied
Mar 24 12:25:32 tiny auth.info sshd[212]: Connection closed by 192.168.0.121
(tiny = serveren, 192.168.0.121 = workstation)

Men jeg vil *ikke* have noget PAM installeret.

Som sagt, lægger jeg det på køl, men jeg vil stadig være glad for idéer.

(Og niveauet er ikke at generere keys, kopiere til authorized_keys etc.)

--
Med venlig hilsen
Stig Johansen