I have found that using the PermitRootLogin setting in YaST2 doesn't seem to work. I have emailed support about it and am awaiting a reply. It seems to be happy to add in the line when the setting is "yes", but simply deletes the line when you change it, perhaps relying on a default setting that has changed. Or maybe I am just going quietly mad. I ended up having to downgrade the security settings from paranoid to secure because it became pretty much impossible to get into the box and do anything. Great, except all my admin is going to have to be remote, and it appears that the only person who can use sudo under the paranoid setting was root... Getting into the box via sshd is no problem, and using "sudo command" rather than "su root" means you don't have to disclose the root password to administrators, plus what they do is usually caught by the logs. You should also be able to use "sudo rxvt" over ssh to get a secure root X session as well, after logging in as a user. TTFN, Marco van Beek -----Original Message----- From: Geordon VanTassle [SMTP:gvantass@thecoventree.com] Sent: Tuesday, April 24, 2001 7:25 PM To: Robert Sweet; suse-security@suse.com Subject: Re: [suse-security] sshd lets root login! Bug? It's just a configuration thing. grep RootLogin /etc/ssh/sshd_config On my firewall, I have PermitRootLogin set to no and I cannot ssh to it as root. However, I *can* ssh as $USER and then su to root. HTH ----- Original Message ----- From: "Robert Sweet" <rsweet@socal.rr.com> To: <suse-security@suse.com> Sent: Monday, April 23, 2001 10:18 PM Subject: [suse-security] sshd lets root login! Bug?
How can we ssh into a box when root login is disabled. We have Marc Heuses New Firewall script running on a 7.1 Suse box using 2.4 kernel. Here are the open ports:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ ) Interesting ports on YaddaYaddaYadda (XXXXXXXXXXX): (The 1516 ports scanned but not shown below are in state: filtered) Port State Service 21/tcp open ftp 22/tcp open ssh 25/tcp closed smtp 53/tcp open domain 80/tcp open http 113/tcp closed auth 123/tcp closed ntp
Here is root logged on my friend's box locally and me logged in as root using ssh. root tty1 Apr 21 11:34 root tty2 Apr 21 11:38 root pts/0 Apr 21 11:35 (My.Box.At.Home) root pts/1 Apr 21 11:54 (My.Box.At.Home)
Here is the output of /etc/securetty on the bad box:
tty1 tty2 tty3 tty4 tty5 tty6 # for devfs: vc/1 vc/2 vc/3 vc/4 vc/5 vc/6
Any help on this one would be appreciated. We have shutdown sshd for now. Thanks -- _ _ __ _____ _____ ___| |_ | '__| / __\ \ /\ / / _ \/ _ \ __| | | _ \__ \\ V V / __/ __/ |_ |_|(_) |___/ \_/\_/ \___|\___|\__| rsweet@socal.rr.com "unix soit qui mal y pense."
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
* Marco van Beek wrote on Tue, Apr 24, 2001 at 19:50 +0100:
I have found that using the PermitRootLogin setting in YaST2 doesn't seem to work. I have emailed support about it and am awaiting a reply. It seems to be happy to add in the line when the setting is "yes",
Maybe this line is twice in that /etc/rc.config file (you change the first but the seconds counts). That may happen since rc.config is just a Shell script and semantic checks like double options are not done. Otherwise try to edit it by hand ($EDITOR - not $HAND :)).
Or maybe I am just going quietly mad. I ended up having to downgrade the security settings from paranoid to secure because it became pretty much impossible to get into the box and do anything.
I though that's what "paraniod" mode is for? To made some things pretty much impossible...
Getting into the box via sshd is no problem, and using "sudo command" rather than "su root" means you don't have to disclose the root password to administrators, plus what they do is usually caught by the logs.
Are you just afraid of the password? Then use ssh-Key authorization. This is more nice (and more secure, since 2048 bits [please no entrophy flame here I know it's an RSA key :)] are harder to guess than 8 letters :) ) Useing SSH enables X11 forwarding, usage of the ssh-agent and other nice features.
You should also be able to use "sudo rxvt" over ssh to get a secure root X session as well, after logging in as a user.
It should be possible to alias su="ssh root@localhost" :) SSH is the better way I thing, since agents keep the key usable (remote, too) and so on. Just nice :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
rather than "su root" means you don't have to disclose the root password to administrators, plus what they do is usually caught by the logs. You should also be able to use "sudo rxvt" over ssh to get a secure root X session as well, after logging in as a user. but unless sudo is well configured someone can always do sudo bash and then all their subsequent commands will not be logged. Same thing with sudo su -
On Wed, 25 Apr 2001, semat wrote:
but unless sudo is well configured someone can always do sudo bash and then all their subsequent commands will not be logged. Same thing with sudo su -
well, that is not really true: unless sudo is *particularly badly* configured this is impossible! Remember that sudo wants you to list all alllowed commands in its config file, with path and all. So unless you do a 'ls /bin /sbin' and pipe the result into your sudo config, 'sudo bash' is going to shut the door at you and log the attempt in the logfile. Dirk
I have seen configs like user ALL=(ALL) ALL Then there have also been configs like user ALL= (ALL) ALL ! a few commands here Here the admin allowed all comands apart froma few. Of course in this case the silly admin had allowed an editor vi so the sudoer simply run sudo vi then in vi :SHELL and voila he had a root shell. On Wed, 25 Apr 2001, dirk janssen wrote:
On Wed, 25 Apr 2001, semat wrote:
but unless sudo is well configured someone can always do sudo bash and then all their subsequent commands will not be logged. Same thing with sudo su -
well, that is not really true: unless sudo is *particularly badly* configured this is impossible!
Remember that sudo wants you to list all alllowed commands in its config file, with path and all. So unless you do a 'ls /bin /sbin' and pipe the result into your sudo config, 'sudo bash' is going to shut the door at you and log the attempt in the logfile.
Dirk
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
semat wrote:
I have seen configs like user ALL=(ALL) ALL Then there have also been configs like user ALL= (ALL) ALL ! a few commands here Here the admin allowed all comands apart froma few. Of course in this case the silly admin had allowed an editor vi so the sudoer simply run sudo vi then in vi :SHELL and voila he had a root shell.
I saw things like: luser@someserver $ sudo su - root@someserver # no password .. nothing... -- Mit freundlichen Gruessen / best regards, Sven Michels Network Operating Center / Infrastructure */* Wichtig */* Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. */* Important */* This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ----------------------------------------- intraDAT AG Wilhelm Leuschner Strasse 7 u. 9-11 60329 Frankfurt / Germany Tel: +49 69 256 29 - 0 Fax: +49 69 256 29 - 256 http://www.intradat.com --------------------
I saw things like: luser@someserver $ sudo su - root@someserver # no password .. nothing... I would only expect this to happen if either the user has no passwd or he has used sudo during the last 5 minutes because then it does not ask for the password again until the 5 minute period elapses. regards, Noah.
semat wrote:
I saw things like: luser@someserver $ sudo su - root@someserver # no password .. nothing... I would only expect this to happen if either the user has no passwd or he has used sudo during the last 5 minutes because then it does not ask for the password again until the 5 minute period elapses.
no, just something like: user ALL = NOPASSWORD: /bin/su -- Mit freundlichen Gruessen / best regards, Sven Michels Network Operating Center / Infrastructure */* Wichtig */* Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. */* Important */* This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ----------------------------------------- intraDAT AG Wilhelm Leuschner Strasse 7 u. 9-11 60329 Frankfurt / Germany Tel: +49 69 256 29 - 0 Fax: +49 69 256 29 - 256 http://www.intradat.com --------------------
participants (5)
-
dirk janssen -
Marco van Beek -
semat -
Steffen Dettmer -
Sven Michels