Bugtraq mailing list archives
Re: SSH LocalForward
From: amonk () LABYRINTH CFTNET COM (Kyle Amon)
Date: Tue, 5 Aug 1997 00:33:39 -0400
On Sun, 3 Aug 1997 long-morrow () CS YALE EDU wrote:
I recommend turning off the setuid bit ('chmod u-s /usr/local/bin/ssh'). until the posted code fix is installed and tested. In fact --unless you are willing to peruse source code for bugs and will always install patches asap when bug reports come in -- I'd recommend leaving the setuid bit off the ssh client executable for the long forseeable future just to be on the safe side.
Indeed. I always recommend removing the setuid bit from ssh. What is lost in flexibility is insignificant compared to what is gained in security. In high security environments, the 'features' provided by it are not usually even desirable.
It means that you will have to live (on Unix/Linux hosts) without passwordless connections (both the (1) ordinary 'rhosts' and the (2) 'RSA rhosts' authentication methods because (1) ssh won't be able to prove that it is running as a privileged process by opening up a connection from a port under 1024 on the local host via which to transmit the username of the current user, nor (2) will it be able to read the local host's private from the file /etc/ssh_host_key which is normally only readable by 'root').
In fact, I also recommed taking this step a little further. You can help to ensure that ssh is not used with 'rhosts' or 'RSA rhosts' authentication even if the setuid bit is set (or later reset), by configuring your router's ACLs to only accept ssh source ports of 1024 and above. Of course, this won't help connections that don't go through the routers, but it adds a little bit of extra protection and even flexibility. For example, in an environment with a medium internal trust level and low external trust level, it might be desirable to allow 'rhosts' and/or 'RSA rhosts' authentication internally and yet insure that this relaxed posture is not also a 'feature' to the outside world. You could leave the ssh setuid bit on and configure internal routers to accept ssh source ports of 1022 and above while configuring border routers to only accept ssh source ports of 1024 and above. You could then allow the more relaxed posture internally while not also relaxing your trust of the outside world OR prohibiting more secure 'RSA only' (augmented with S/Key, etc. if desired) ssh trafic from/to the outside world. This could be especially usefull in complex transitive trust environments. But, as I say, I wouldn't allow these 'features' as a general rule either and would even help to insure this by blasting their use at the routers as well. Best Regards, Kyle Kyle Amon email: amonk () labyrinth cftnet com Unix Systems Administrator url: http://labyrinth.cftnet.com/kyle Security Specialist phone: (203) 486-3290 IBM Global Services pager: 1-800-759-8888 PIN 1616512 KeyID 1024/173D96C9 Fingerprint = 90 4F 0B D4 2D 37 E7 61 1A 31 7B F2 72 04 66 1A
Current thread:
- Re: SSH LocalForward Sevo Stille (Aug 02)
- <Possible follow-ups>
- Re: SSH LocalForward Sevo Stille (Aug 03)
- Re: SSH LocalForward long-morrow () CS YALE EDU (Aug 03)
- Re: SSH LocalForward Kyle Amon (Aug 04)
- Netscape Referer header considered harmful? Ronald L. Parker (Aug 04)
- Re: Netscape Referer header considered harmful? Eric Murray (Aug 06)
- Re: SSH LocalForward Bryan Andregg (Aug 05)
- SGI Security Advisory 19970509-02-PX - IRIX ordist Buffer Overrun SGI Security Coordinator (Aug 05)
- IMAPd scans Steve Herman (Aug 06)
- XFREE86 can block reserved ports Willy TARREAU (Aug 06)
- Re: XFREE86 can block reserved ports Alex Belits (Aug 06)
- Re: SSH LocalForward Kyle Amon (Aug 04)