From owner-freebsd-security Wed Feb 28 9:36:31 2001 Delivered-To: freebsd-security@freebsd.org Received: from link.mirror.org (link.mirror.org [216.38.7.35]) by hub.freebsd.org (Postfix) with ESMTP id 9A24137B718 for ; Wed, 28 Feb 2001 09:36:27 -0800 (PST) (envelope-from sgt@netcom.no) Received: from hal (32-d09-1.svg1.netcom.no [212.45.182.161]) by link.mirror.org (8.7.5/8.7.3) with ESMTP id MAA02122; Wed, 28 Feb 2001 12:34:40 -0500 Date: Wed, 28 Feb 2001 18:36:08 +0100 (CET) From: Torbjorn Kristoffersen X-Sender: To: Paul Herman Cc: Subject: Re: ssh tricks (was Re: ssh -t /bin/sh trick (was Re: ftp access)) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 28 Feb 2001, Paul Herman wrote: > On Tue, 27 Feb 2001, Steve Reid wrote: > > > On Tue, Feb 27, 2001 at 02:55:12PM -0800, Brooks Davis wrote: > > > If you do this be sure to keep users from being able to access the system > > > via ssh. Otherwise they can just use ssh to spawn a shell for themselves: > > > ssh -t /bin/sh > > > > Are you certain about this? > > > > I tried this on a 4.1.1-R box I operate and it didn't let me in. The > > box is set up with the ftp login shell set to "/nonexistent/ftponly", > > which is listed in /etc/shells but does not exist. > > This behaviour has changed over the years, which is why there are two > conflicting reports. > > I remember the days (FreeBSD 2.2.6, or so, using ssh from ssh.com) of > having to write a small script in /etc/sshrc which checks for invalid > shells to prevent what Brooks was describing. Back then, it *did* > work. > > Now (at least with OpenSSH_2_3_0), that trick doesn't work anymore. > Don't know when/where/in which version this changed, but my inkling is > that PAM is the culprit. > > -Paul. > Since the topic is 'ssh tricks', here's one that works with all versions of SSH I've used (openssh 2.3.0 as well): home$ ssh -l username site /bin/sh -i sh: can't access tty; job control turned off $ 6:14PM up 3 days, 7:22, 3 users, load averages: 0.19, 0.12, 0.11 USER TTY FROM LOGIN@ IDLE WHAT otheruser p0 microsoft.com Tue01PM 1:16 vi main.c $ tty not a tty $ Forcing the shell to behave interactively, makes the user hidden on 'who' (he's not allocated a tty), but you can still kill sshd or the sh process. But people adminstering big systems with hundreds of PIDs running might not check their process status tables for suspicious stuff as often as they should. Many just type w/who instead to see who's logged on. This feature of sh used together with ssh is probably well known, but I decided to mention it anyway. Cheers, Torbjorn Kristoffersen sgt@netcom.no sgt@digiweb.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message