[RH] ssh root probleem

[Verwijderd]

Er is mijn vertelt dat het onveilig is om als root in te loggen over ssh(2) maar als ik als een gewone user inlog en dan su doe dan kan ik niet bij een hoop root command zoals adduser etc.

Hoe komt dit want in principe moet daar toch geen verschil mee zijn

[Nick_S]

Probeer eens in root te veranderen met "su -" zonder de ". Ben ook nog een newbie, maar hiermee leest hij geloof ik ook de juiste zoekpaden in, waardoor alle root programma's uit /sbin weer gevonden kunnen worden.

[Paul]

Ik denk dat er in je .bash_profile en je .bash_rc (oid) verschillende dingen staan, en dan met name het path

De ene is als je inlogt, de andere is als je een shell start onder die user. En su is niet inloggen

[Verwijderd]

De ene is als je inlogt, de andere is als je een shell start onder die user. En su is niet inloggen

Ja daar heb je gelijk in denk je maar hoe log ik dan in als root via ssh zonder dat direct te doen?

[Paul]

Niet root-logins via SSH toestaan (allen niet zelf zo inloggen is niet voldoende, je moet echt uitzetten dat het mag wil de maatregel zin hebben) zorgt ervoor dat een hacker alleen het rootwachtwoord nodig heeft ipv een username, diens wachtwoord en het root-wachtwoord. Ipv 1 supergeheime string moet hij er nu 2 en een iets minder geheime (maar van buitenaf lastig achter te komen) hebben

Je moet gewoon zorgen dat in ~root/.bash_profile en ~root/.bashrc de path-variabele goed gevuld wordt (dus dat /sbin /usr/sbin en /usr/local/sbin er ook in staan )
(ervanuitgaande dat dat ook het probleem is )

[Wilke]

Je logt gewoon niet in als root - uberhaupt niet - , dat is meer het punt

Als je de root-login via SSH disabled, moeten eventuele krakers tenminste 3 dingen weten: een geldige username die een shell mag openen, het wachtwoord daarvan, en het root-password.

Dat is een stuk meer dan alleen het root-password.

Dus misschien is 'onveilig' een groot woord, maar het wordt als een goed idee gezien om uberhaupt geen remote root logins toe te laten (via welk protocol dan ook, en natuurlijk al wel zeker niet via onversleutelde protocollen zoals telnet, pop3, ftp, etc.)

[Verwijderd]

hmm ok maar ja het root password is dat niet makkelijk te achter halen als je eenmaal toch ingelogt bent? want in windows is dat niet echt heel moeilijk geloof ik.

En ik dacht dat ssh met encryptie werkt dus dat je uberhaupt die packets er wel kan af sniffer maar er dan weinig aan hebt

Je moet gewoon zorgen dat in ~root/.bash_profile en ~root/.bashrc de path-variabele goed gevuld wordt (dus dat /sbin /usr/sbin en /usr/local/sbin er ook in staan )
(ervanuitgaande dat dat ook het probleem is )

Dan ga ik daar maar eens mee aan de gang dan

[Verwijderd]

Het verstandigst is gewoon inloggen als user via ssh.
Daarna met
su -
switchen naar root.

even een quote van de su manual op hpux (gelijk aan andere waarschijnlijk)

If the - option is specified, the new shell starts up as if the new
user had initiated a new login session. Exceptions are as follows:

+ The HOME variable is reset to the new user's home directory.

+ If the new user name is root, the path and prompt variables are
reset:

PATH=/usr/bin:/usr/sbin:/sbin
PS1=#

For other user names:

PATH=/usr/bin
PS1=$

+ The TERM variable is retained.

+ The rest of the environment is deleted and reset to the login
state. However, the login files are normally executed anyway,
usually restoring the expected value of PATH and other variables.

[ Voor 3% gewijzigd door Verwijderd op 21-09-2004 10:53 ]

[Verwijderd]

hmm als ik su - dan heb ik wel de commands van root maar als ik su of su root dan doet ie het niet, maar ja het probeem is wel opgelost.


Ik dank u zeer vriendelijk

[Dennis]

Sommige unix-varianten, waaronder FreeBSD, staan niet eens toe dat je via SSH inlogt als root. Dan móet je wel eerst als gewone gebruiker inloggen.

[mvdejong]

Met "su - <gebruiker>" worden de login-scripts van de betreffende gebruiker ook ingelezen, en is de omgeving niet of nauwelijks te onderscheiden van een directe login.

Met "su <gebruiker>" worden wel de effecteive user-id en group-id veranderd, maar worden verder geen veranderingen aan de environment uitgevoerd.

[Wilke]

Verwijderd schreef op 21 september 2004 @ 10:50:
hmm ok maar ja het root password is dat niet makkelijk te achter halen als je eenmaal toch ingelogt bent?

Nee.

want in windows is dat niet echt heel moeilijk geloof ik.

Inderdaad niet als je windows 2000 zonder service packs hebt - anders vergelijkbaar moeilijk als in Linux.

[Verwijderd]

Wat je met su root en su doet is je huidige environment gebruiken, maar dan als user root. Je PATH variable en andere settings zijn dat gelijk aan die van user.

Volgens de manual op hpux zou de PATH variable naar /usr/bin:/usr/sbin:/sbin
gezet worden. Dat gebeurd ook.

Even getest op AIX. Daar veranderd dus niks....
Alle variablen zijn gelijk aan de user account.
Alleen als je dan een bestand wegschrijft, is de eigenaar van dat bestand root.

Er zit dus wel wat verschil tussen de *nix systemen.

Gebruik su - om echt in te loggen..

[Kees]

of zet 'source /etc/profile' in je .bashrc
werkt ook prima.

Eventueel kun je in /etc/profile (of in .bashrc van je user) een alias aanmaken: 'alias su="su -"' dan kun je gewoon 'su' blijven gebruiken.

[Verwijderd]

Dennis schreef op 21 september 2004 @ 11:10:
Sommige unix-varianten, waaronder FreeBSD, staan niet eens toe dat je via SSH inlogt als root. Dan móet je wel eerst als gewone gebruiker inloggen.

offtopic:
Standaard is het niet mogelijk, maar dit wil niet zeggen dat het helemaal niet mogelijk is...

Je kunt sshd_config gewoon aanpassen zodat het wel kan.

[smokalot]

Kees schreef op 21 september 2004 @ 16:54:
of zet 'source /etc/profile' in je .bashrc
werkt ook prima.

Eventueel kun je in /etc/profile (of in .bashrc van je user) een alias aanmaken: 'alias su="su -"' dan kun je gewoon 'su' blijven gebruiken.

/etc/profile wordt blijkbaar niet gebruikt juist, want daarin staat dat als je root bent je /sbin en /usr/sbin in je $PATH hebt staan.

Ik zou in .bashrc een regeltje toevoegen met "source /etc/profile". zou moeten werken.

[Verwijderd]

Inderdaad niet als je windows 2000 zonder service packs hebt - anders vergelijkbaar moeilijk als in Linux.

Maar elke windows nt + kan dan met service packs of niet. ik mag denk ik niet in detail treden maar ik heb ergens een trucje gelezen dat het heel makkelijk is om admin passes te kraken als je eenmaal ingelogt bent.

Dus ik dacht er zal dan mischen ook wel zo'n trucje zijn voor *nix

[Verwijderd]

Verwijderd schreef op 27 september 2004 @ 12:35:
[...]


Maar elke windows nt + kan dan met service packs of niet. ik mag denk ik niet in detail treden maar ik heb ergens een trucje gelezen dat het heel makkelijk is om admin passes te kraken als je eenmaal ingelogt bent.

Dus ik dacht er zal dan mischen ook wel zo'n trucje zijn voor *nix

Dat was voorheen wel zo, toen kon je uit /etc/passwd het encrypted wachtwoord halen en dat bruteforcen. /etc/passwd was voor iedereen leesbaar o.a. omdat kleine klusjes als 'ps' aan de hand van het user ID van een proces de bijbehorende username uit /etc/passwd visten.

Tegenwoordig staat er een 'x' in het paswoordveld in /etc/passwd: dit wil zeggen dat de paswoorden shadowed zijn. Dan staan de encrypted wachtwoorden in /etc/shadow, die niet world-readable is.

offtopic:
Spider.007:
"Dus ik dacht er zal dan mischen ook wel zo'n trucje zijn voor *nix"

[ Voor 8% gewijzigd door Verwijderd op 27-09-2004 13:17 ]

[Spider.007]

Verwijderd schreef op 27 september 2004 @ 12:46:

[...]

Dammas heeft het over Windows, niet over *nix Je uitleg klopt uiteraard wel

Wilke schreef op 21 september 2004 @ 11:17:
[...]

Inderdaad niet als je windows 2000 zonder service packs hebt - anders vergelijkbaar moeilijk als in Linux.

Er zijn in Windows redelijk veel eenvoudige exploits doordat Windows het wachtwoord zelf onthoud en soms ook automatisch invult in textboxen die je eenvoudig weer uit kunt lezen. *nux slaat de wachtwoorden zo op dat het alleen mogelijk is om de hash van het ingevoerde password te vergelijken met de opgeslagen hash. Hierdoor is decrypten van het password onmogelijk; en werkt alleen bruteforcen

[ Voor 14% gewijzigd door Spider.007 op 27-09-2004 13:01 ]