From mail at peter-thomassen.de Fri May 1 00:25:45 2009 From: mail at peter-thomassen.de (Peter Thomassen) Date: Thu, 30 Apr 2009 16:25:45 +0200 Subject: ChrootDirectory %h Message-ID: Hi, many people are having problems using SFTP with ChrootDirectory when the jail directory (or the path above) is not owned by root. The question is if chroot'ing to usual home directories can be allowed, even though they are owned by regular users. I know that this topic has been discussed on the list several times now, so I searched the list archives for posts that invalidate the following arguments, but I couldn't find any. 1.) SSH aims to provide an environment that makes the user feel like sitting in front of the physical machine, having logged in locally. Chroot'ing gives the additional feature of restricting filesystem access to a specified part of the tree, nothing more. Especially, it should not distort the kind of actions the user could take if he logged in locally and did `chroot ~`. In it was stated that the main reason for not relaxing this restriction is that setuid binaries could be executed. This argument isn't substantive (see arguments 2 to 5): 2.) In most cases, the user can execute the setuid binary using another execution chain, for example if - he's got a web hosting account and can execute it using a CGI script, or if - he logged into the machine locally. Why should the level of security depend on whether the session is a remote or a local one, and why should different restructions be imposed? 3.) Assuming the chroot directory (and the path above) is owned by root, people will create directories therein that the SSH user can write to. How is ensured that there isn't any setuid binary placed in this leaf directory that can be executed by the user? How is security increased by the adding a directory level? 4.) A common application is to grant users SFTP access using the internal-sftp feature, and to force them into their home directories. Those users can't execute any binaries because command execution is handled by internal-sftp. In this case, there is absolutely not risk coming from setuid binaries. Suggestion: If ChrootDirectory is applied together with ForceCommand internal-sftp in the same context (configuration wide, or in a Match block), do not check for root ownership. 5.) In case that the setuid argument still holds, one can check if the filesystem containing the chroot directory in question is mounted with the nosuid option, e.g. by looking at /etc/mtab. If so, there is absolutely not risk coming from setuid binaries. 6.) In it was stated that "allowing a user write access to a chroot target is dangerously similar to equivalence with allowing write access to the root of a filesystem". The difference is that the root of a filesystem is accessed by (and must be operational for) many people, while a home directory only is used by one user. According to common philosophy, every user has the right to destroy his account using setuid binaries. He also could do `rm -rf ~/*`. Suggestion: Drop the ownership check in case of ChrootDirectory %h. In this case one can be sure that the security of other users is not affected. 7.) Not only the user has the right to destroy his data. The system administrator (who always must be assumed to have a certain sensibility for security topics, especially when dealing with remote access) also has the right to lower security barriers. He also can decide not to use a firewall, or to do `rm -rf /`. Please allow him to decide the question of setuid binary execution inside a chroot target. Additionally, it is often suggested to set up a user-specific container directory (e.g. /home/user1container/) that is owned be root and chroot'ed to, and to create a user-writable directory therein (/home/user1container/user1/). The latter one, seen relative from the container directory (/user1/), than can be defined as the user's home directory in /etc/passwd so that OpenSSH automatically chdir's there after login. Often, this is not very pratical, since there are other services running outside the chroot jail that also need access to the user's home directory, such as MTAs or the Apache web server with the UserDir module (? la http://www.example.org/~user1/). Those services can't find the user's home directory if configured as described above. Please consider my remarks and tell me if I got anything technically wrong. Thanks, Peter From chris at qwirx.com Fri May 1 05:53:14 2009 From: chris at qwirx.com (Chris Wilson) Date: Thu, 30 Apr 2009 20:53:14 +0100 (BST) Subject: ChrootDirectory %h In-Reply-To: References: Message-ID: Hi Peter, On Thu, 30 Apr 2009, Peter Thomassen wrote: > I know that this topic has been discussed on the list several times now, > so I searched the list archives for posts that invalidate the following > arguments, but I couldn't find any. > > 1.) SSH aims to provide an environment that makes the user feel like > sitting in front of the physical machine, having logged in locally. > Chroot'ing gives the additional feature of restricting filesystem > access to a specified part of the tree, nothing more. Especially, it > should not distort the kind of actions the user could take if he > logged in locally and did `chroot ~`. As far as I know, only root can chroot. Does that invalidate your argument? > In it was stated that > the main reason for not relaxing this restriction is that setuid binaries > could be executed. This argument isn't substantive (see arguments 2 to 5): I think the argument is that setuid binaries can be *fooled* into doing something dangerous when the user can chroot, e.g. they can be made to run /bin/ls as root where /bin/ls is actually whatever the attacker wants to run as root. > 5.) In case that the setuid argument still holds, one can check if the > filesystem containing the chroot directory in question is mounted > with the nosuid option, e.g. by looking at /etc/mtab. If so, there > is absolutely not risk coming from setuid binaries. Is that portable? I'd guess not. If SFTP does not allow executing binaries at all then I guess it's moot. > 7.) Not only the user has the right to destroy his data. The system > administrator (who always must be assumed to have a certain > sensibility for security topics, especially when dealing with remote > access) also has the right to lower security barriers. He also can > decide not to use a firewall, or to do `rm -rf /`. Please allow him > to decide the question of setuid binary execution inside a chroot > target. Fair enough, but it should not be enabled by default. It should be a EnableChrootToUserDontBlameSsh = yes option. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From Jefferson.Ogata at noaa.gov Fri May 1 10:41:19 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Fri, 01 May 2009 00:41:19 +0000 Subject: ChrootDirectory %h In-Reply-To: References: Message-ID: <49FA452F.3030408@noaa.gov> On 2009-04-30 14:25, Peter Thomassen wrote: > 2.) In most cases, the user can execute the setuid binary using another > execution chain, for example if > - he's got a web hosting account and can execute it using a CGI script, > or if > - he logged into the machine locally. Why should the level of security > depend on whether the session is a remote or a local one, and why should > different restructions be imposed? You need to understand the sort of scenario that exists when you allow users to control a directory that someone chroots to. Let's suppose user home directories are on the same filesystem as /bin. This is becoming an increasingly common scenario as fewer sysadmins learn how to partition filesystems. In this case, a user can construct his own little root filesystem somewhere under his home directory by copying necessary binaries and libraries, and populate it with his own /etc/passwd and /etc/shadow. He can also hard link /bin/su under this mini root filesystem, and this file will still be owned by root with the setuid bit set. If you ever let the user chroot to this directory and execute his hard-linked /bin/su, he can become root within that directory and then escape the chroot. Even if you could prevent him from escaping chroot, he can create device nodes and operate directly on filesystems, mount /proc and operate on external processes, etc. It should be clear that this is Very Bad (tm). This is a principle reason why chroot() is limited to the superuser. Actually preventing this scenario, while still letting users operate in a chrooted environment at all, is relatively tricky, especially in a portable program, so careful developers like to stay far, far away from any possibility of it, lest the odd coding error yield a root shell, and blame for compromises fall on the developer. > 3.) Assuming the chroot directory (and the path above) is owned by root, > people will create directories therein that the SSH user can write to. > How is ensured that there isn't any setuid binary placed in this leaf > directory that can be executed by the user? How is security increased by > the adding a directory level? It isn't necessary to ensure that. But it is necessary to ensure that the user can't also construct a false authentication environment which the setuid binary would unwittingly rely on in a chroot scenario, e.g. by building his own /etc/passwd. That is what the ownership test is designed to achieve. > 7.) Not only the user has the right to destroy his data. The system > administrator (who always must be assumed to have a certain sensibility > for security topics, especially when dealing with remote access) also > has the right to lower security barriers. He also can decide not to use > a firewall, or to do `rm -rf /`. Please allow him to decide the question > of setuid binary execution inside a chroot target. The system administrator also has the ability to tweak the code to his heart's content. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From smkumaran87 at gmail.com Sat May 2 17:19:48 2009 From: smkumaran87 at gmail.com (S.M. Kumaran) Date: Sat, 2 May 2009 12:49:48 +0530 Subject: Ssh Doubt: Message-ID: <605b1ef70905020019w33ac1d53y72051a65a3e60d9f@mail.gmail.com> Hello sir very Greeting to u......... Right now i have using puppy linux (ver 3) how to install ssh packages & configured ( i have already got openssh 5.1 but i got some errors means root can't access via putty so what can i do...) Kindly tel step by step as soon as... im waiting for ur Reply Thanking you......... -- ????????z & ??g?r??...??? ?????????????????.G +91 9944065065, From peter at stuge.se Sat May 2 23:20:31 2009 From: peter at stuge.se (Peter Stuge) Date: Sat, 2 May 2009 15:20:31 +0200 Subject: Ssh Doubt: In-Reply-To: <605b1ef70905020019w33ac1d53y72051a65a3e60d9f@mail.gmail.com> References: <605b1ef70905020019w33ac1d53y72051a65a3e60d9f@mail.gmail.com> Message-ID: <20090502132031.2985.qmail@stuge.se> Hello S.M. Kumaran, S.M. Kumaran wrote: > Right now i have using puppy linux (ver 3) how to install ssh > packages & configured > > ( i have already got openssh 5.1 but i got some errors means root > can't access via putty so what can i do...) > > Kindly tel step by step as soon as... im waiting for ur Reply You sent this message to the OpenSSH developer mailing list, but you are asking a question about something very specifically for one particular Linux distribution. I am afraid you are asking people who can not help you. Instead, I suggest that you look for a support forum for Puppy Linux. It could be a web based forum or a mailing list or an IRC channel. Start searching their web page. You also mention that you get an error with OpenSSH 5.1 and can not log in as root. We may be able to help you with that issue, because it could be related to OpenSSH, but we need much more information than you have provided so far. At a minimum you have to provide the exact error message that you see and the sshd_config file that you are using on the server when you get the error. Lastly, please do not expect any open source project to spoon feed you detailed instructions on request. I do not know many situations where complete strangers are so helpful as in open source, but please understand that everyone who is contributing is doing so completely voluntarily, and that in using Puppy Linux you already benefit from the work of many thousand developers. This is fantastic - and fun also for developers, because they see that their work is being used by many. Language is always a barrier - it certainly is for me - but how questions are phrased when asking for help is very important. We need to be certain that you have really spent some time trying to diagnose and fix the problem yourself, that you have already consumed and interpreted the documentation that is available, and that you are asking developers for help only because you have looked hard for sources of information and have now exhausted all those you could find. Your request will be taken much more seriously if you explain how you have already tried to solve the problem yourself. //Peter From mail at peter-thomassen.de Sun May 3 03:17:26 2009 From: mail at peter-thomassen.de (Peter Thomassen) Date: Sat, 02 May 2009 19:17:26 +0200 Subject: ChrootDirectory %h In-Reply-To: <49FA452F.3030408@noaa.gov> References: <49FA452F.3030408@noaa.gov> Message-ID: Hi, Jefferson Ogata schrieb: > You need to understand the sort of scenario that exists when you allow > users to control a directory that someone chroots to. I now understood the security implications; thank you for your explanation. But what about this (--> )? > 4.) A common application is to grant users SFTP access using the internal-sftp feature, and to force them into their home directories. Those users can't execute any binaries because command execution is handled by internal-sftp. In this case, there is absolutely not risk coming from setuid binaries. > Suggestion: If ChrootDirectory is applied together with ForceCommand internal-sftp in the same context (configuration wide, or in a Match block), do not check for root ownership. Do you think it is practical and justifiable in terms of security to relax this constraint in the limited scope of SFTP? Because the problem raises mainly in the context of SFTP, this would help a lot of people. Have a nice weekend, Peter From Jefferson.Ogata at noaa.gov Sun May 3 07:00:04 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sat, 02 May 2009 21:00:04 +0000 Subject: ChrootDirectory %h In-Reply-To: References: <49FA452F.3030408@noaa.gov> Message-ID: <49FCB454.8070104@noaa.gov> On 2009-05-02 17:17, Peter Thomassen wrote: > But what about this (--> )? >> 4.) A common application is to grant users SFTP access using the >> internal-sftp feature, and to force them into their home directories. >> Those users can't execute any binaries because command execution is >> handled by internal-sftp. In this case, there is absolutely not risk >> coming from setuid binaries. >> Suggestion: If ChrootDirectory is applied together with ForceCommand >> internal-sftp in the same context (configuration wide, or in a Match >> block), do not check for root ownership. > > Do you think it is practical and justifiable in terms of security to > relax this constraint in the limited scope of SFTP? This is a good example of the problem. If there is a bug in the SFTP code that allows arbitrary code execution (a buffer overflow, for example), the risk when chroot to a user-controlled directory is allowed is dramatically higher. I can understand the developers not wanting to take that risk. If we could be certain that the sftp-server could never have such a bug, then perhaps it would more palatable. But I think the design philosophy with sftp is to assume that someone who has sftp access also has shell access with the same constraints. The expectation is that filesystem permissions should be able to achieve the limitations that you desire; in general users' home directories should not be readable by all. In the particular case where users are uploading content to be published by a web server, there may be alternate ways to accomplish this using bind mounts or some similar strategy. For example, you can put all your web user home directories under a common path /home/webusers, chroot all those sftp users to /home/webusers, make all those home directories mode 700, give each user a subdirectory for web content (e.g. public_html) that is mode 755, and bind mount each user's web content directory under an alternate path (e.g. mount -o bind /home/webusers/user1/public_html /public_html/user1), and configure your httpd to use /public_html/* for user content. On a large system this can end up with an unwieldy collection of bind mounts, but it's a workable strategy. Or, as I suggested, you can write your own patch to relax the ChrootDirectory restriction and make it part of an automated openssh build, e.g. using rpm. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From miguel.sanders at arcelormittal.com Mon May 4 02:20:11 2009 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Sun, 3 May 2009 18:20:11 +0200 Subject: Server option PrintLastLog does not work on AIX Message-ID: <7DF29B50FFF41848BB2281EC2E71A206B6EDB6@GEN-MXB-V04.msad.arcelor.net> Hi Apparently, the server option "PrintLastLog" does not work on AIX. The last login time is always displayed, disregarding the option. When browsing the code, I found out there are several functions in loginrec.c which solely handle the processing of the last login info (login_get_lastlog, getlast_entry). Since AIX does not provide such a function natively, the configure script sets the DISABLE_LASTLOG define. A small code snippet from getlast_entry in loginrec.c shows this #if defined(DISABLE_LASTLOG) /* On some systems we shouldn't even try to obtain last login * time, e.g. AIX */ return (0); On the other hand, when issuing the AIX loginsuccess() call (which writes a new login record), the last login record can be retrieved by that very same call. If we look at port-aix.c, we can see the following: if (loginsuccess((char *)user, (char *)host, (char *)ttynm, &msg) == 0) { success = 1; if (msg != NULL && loginmsg != NULL && !msg_done) { debug("AIX/loginsuccess: msg %s", msg); buffer_append(loginmsg, msg, strlen(msg)); xfree(msg); msg_done = 1; } } The pointer "msg" points to the new last login info for the user and it always appended to the loginmsg buffer. The buffer_append call should only be called if options.print_lastlog is set. Bugzilla item # 1595 was created to address this issue. Met vriendelijke groet Best regards Bien ? vous Miguel SANDERS ArcelorMittal Gent UNIX Systems & Storage IT Supply Western Europe | John Kennedylaan 51 B-9042 Gent T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023 E miguel.sanders at arcelormittal.com www.arcelormittal.com/gent **** This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement. **** From petesea at bigfoot.com Tue May 5 09:48:40 2009 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Mon, 04 May 2009 16:48:40 -0700 (PDT) Subject: Test port not available Message-ID: While building OpenSSH 5.2p1, "make tests" was failing on my system with the error "no sshd running on port 4242". After much head scratching, cursing and rooting around in the test scripts I finally figured out the real cause... something is already running on port 4242 (in my case, the Juniper Network Connect client). This got me thinking, it might be nice if the code used to set the port was a bit more resilient and/or the error message a bit more informative. On the first point, maybe this code in test-exec.sh: if [ ! -z "$TEST_SSH_PORT" ]; then PORT="$TEST_SSH_PORT" else PORT=4242 fi could be something similar to: if [ ! -z "$TEST_SSH_PORT" ]; then PORT="$TEST_SSH_PORT" else first_port=4200 last_port=4300 test_port=$first_port while [ "$test_port" -le "$last_port" ]; do netstat -na | grep "[:.]$test_port " >/dev/null 2>&1 || { PORT=$test_port; break; } test_port=`expr $test_port + 1` done if [ -z "$PORT" ]; then echo "Unable to find usable test port between $first_port and $last_port. Define \$TEST_SSH_PORT." exit 2 fi fi I realize the 'netstat | grep' command above may not be the best, most portable way to look for an available port, but the idea is the same... ie. run something that checks to see if the requested port is available or not. FYI, I did run the above code on several boxes (solaris, hpux, macosx, fedora, redhat, centos, cygwin) and it seemed to work fine. Another possible way to check would be to run sshd -D and look at the output. In my case it says: Bind to port 4242 on 127.0.0.1 failed: Address already in use. Cannot bind any address. Which (again in my particular case), would have been a much more helpful error message then "no sshd running on port 4242". Of course if it works, then a separate ssh command would need to run to close it... or I suppose just kill it. Or... maybe the sshd -t option could be enhanced (or a new option created) that actually checks to see if the port is available, but doesn't actually start a server. I suspect this really means it would try to bind to that port and then just close if it works, otherwise report the error. Problem is, on some system I believe it can take a while before a port can be reused... so a passive check would be better. If the idea of checking for multiple ports isn't acceptable, then what about at least enhancing the error message a bit: no sshd running on port 4242, try setting $TEST_SSH_PORT to a different port PS. As a side note... while reading the code I noticed I could set TEST_SSH_LOGFILE to a filename for any output from various commands instead of sending all the output to /dev/null. Is there a particular reason a logfile isn't created by default? I mean, in the grand scheme of things, is the output produced in this file really that large or for some other reason unwanted? When I first came across the initial error I looked for a test log file... something that might contain a bit more info on why the failure occurred. It wasn't until I couldn't find anything and had to resort to reading the test scripts that I discovered a log file is created if TEST_SSH_LOGFILE is defined. From petesea at bigfoot.com Tue May 5 08:51:40 2009 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Mon, 04 May 2009 15:51:40 -0700 (PDT) Subject: Multiplex tests fail on 5.2p1 Message-ID: I noticed "make tests" for openssh-5.2p1 fails the multiplex.sh tests. Turns out this is because I happen to have some non-standard configuration options in $HOME/.ssh/config and most of the multiplex.sh tests do not use a "-F $OBJ/ssh_config" option, which means they end up reading the users $HOME/.ssh/config. Is this on purpose or a bug? From dtucker at zip.com.au Tue May 5 13:47:09 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 5 May 2009 13:47:09 +1000 Subject: Multiplex tests fail on 5.2p1 In-Reply-To: References: Message-ID: <20090505034709.GA27413@gate.dtucker.net> On Mon, May 04, 2009 at 03:51:40PM -0700, petesea at bigfoot.com wrote: > ClamAV 0.94.2 > > I noticed "make tests" for openssh-5.2p1 fails the multiplex.sh tests. > > Turns out this is because I happen to have some non-standard > configuration options in $HOME/.ssh/config and most of the multiplex.sh > tests do not use a "-F $OBJ/ssh_config" option, which means they end up > reading the users $HOME/.ssh/config. > > Is this on purpose or a bug? I think it's a bug. Certainly I can't think of a good reason for it. The obvious change seems to work for me, does it work for you? Index: regress/multiplex.sh =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/regress/multiplex.sh,v retrieving revision 1.17 diff -u -p -r1.17 multiplex.sh --- regress/multiplex.sh 31 Jan 2006 10:57:27 -0000 1.17 +++ regress/multiplex.sh 5 May 2009 03:45:53 -0000 @@ -26,7 +26,7 @@ sleep 5 verbose "test $tid: envpass" trace "env passing over multiplexed connection" -_XXX_TEST=blah ${SSH} -oSendEnv="_XXX_TEST" -S$CTL otherhost sh << 'EOF' +_XXX_TEST=blah ${SSH} -F $OBJ/ssh_config -oSendEnv="_XXX_TEST" -S$CTL otherhost sh << 'EOF' test X"$_XXX_TEST" = X"blah" EOF if [ $? -ne 0 ]; then @@ -36,26 +36,26 @@ fi verbose "test $tid: transfer" rm -f ${COPY} trace "ssh transfer over multiplexed connection and check result" -${SSH} -S$CTL otherhost cat ${DATA} > ${COPY} +${SSH} -F $OBJ/ssh_config -S$CTL otherhost cat ${DATA} > ${COPY} test -f ${COPY} || fail "ssh -Sctl: failed copy ${DATA}" cmp ${DATA} ${COPY} || fail "ssh -Sctl: corrupted copy of ${DATA}" rm -f ${COPY} trace "ssh transfer over multiplexed connection and check result" -${SSH} -S $CTL otherhost cat ${DATA} > ${COPY} +${SSH} -F $OBJ/ssh_config -S $CTL otherhost cat ${DATA} > ${COPY} test -f ${COPY} || fail "ssh -S ctl: failed copy ${DATA}" cmp ${DATA} ${COPY} || fail "ssh -S ctl: corrupted copy of ${DATA}" rm -f ${COPY} trace "sftp transfer over multiplexed connection and check result" echo "get ${DATA} ${COPY}" | \ - ${SFTP} -S ${SSH} -oControlPath=$CTL otherhost >$LOG 2>&1 + ${SFTP} -S ${SSH} -F $OBJ/ssh_config -oControlPath=$CTL otherhost >$LOG 2>&1 test -f ${COPY} || fail "sftp: failed copy ${DATA}" cmp ${DATA} ${COPY} || fail "sftp: corrupted copy of ${DATA}" rm -f ${COPY} trace "scp transfer over multiplexed connection and check result" -${SCP} -S ${SSH} -oControlPath=$CTL otherhost:${DATA} ${COPY} >$LOG 2>&1 +${SCP} -S ${SSH} -F $OBJ/ssh_config -oControlPath=$CTL otherhost:${DATA} ${COPY} >$LOG 2>&1 test -f ${COPY} || fail "scp: failed copy ${DATA}" cmp ${DATA} ${COPY} || fail "scp: corrupted copy of ${DATA}" @@ -64,7 +64,7 @@ rm -f ${COPY} for s in 0 1 4 5 44; do trace "exit status $s over multiplexed connection" verbose "test $tid: status $s" - ${SSH} -S $CTL otherhost exit $s + ${SSH} -F $OBJ/ssh_config -S $CTL otherhost exit $s r=$? if [ $r -ne $s ]; then fail "exit code mismatch for protocol $p: $r != $s" @@ -72,7 +72,7 @@ for s in 0 1 4 5 44; do # same with early close of stdout/err trace "exit status $s with early close over multiplexed connection" - ${SSH} -S $CTL -n otherhost \ + ${SSH} -F $OBJ/ssh_config -S $CTL -n otherhost \ exec sh -c \'"sleep 2; exec > /dev/null 2>&1; sleep 3; exit $s"\' r=$? if [ $r -ne $s ]; then @@ -81,10 +81,10 @@ for s in 0 1 4 5 44; do done trace "test check command" -${SSH} -S $CTL -Ocheck otherhost || fail "check command failed" +${SSH} -F $OBJ/ssh_config -S $CTL -Ocheck otherhost || fail "check command failed" trace "test exit command" -${SSH} -S $CTL -Oexit otherhost || fail "send exit command failed" +${SSH} -F $OBJ/ssh_config -S $CTL -Oexit otherhost || fail "send exit command failed" # Wait for master to exit sleep 2 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue May 5 17:53:32 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 5 May 2009 17:53:32 +1000 Subject: [OPENSSH-DEV] Multiplex tests fail on 5.2p1 In-Reply-To: References: <20090505034709.GA27413@gate.dtucker.net> Message-ID: <20090505075332.GA17612@gate.dtucker.net> On Mon, May 04, 2009 at 09:22:42PM -0700, Dan Peterson wrote: > Yes... sorry, should have included that in original message. I basically > had already done the same thing you did and added "-F $OBJ/ssh_config" to > each of the ${SSH} commands and after that the tests worked just fine. Thanks, I've committed the patch to OpenBSD, it'll turn up in -portable next time we sync. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From molnarb81 at hotmail.com Tue May 5 18:59:32 2009 From: molnarb81 at hotmail.com (=?iso-8859-2?Q?Bal=E1zs_Moln=E1r?=) Date: Tue, 5 May 2009 10:59:32 +0200 Subject: ssh logging Message-ID: Dear All, I am a newbie in the unix world. I have a problem. I try to log all my typed, edited (via vi/vim) and of course the output/result of a command into a file (specific file e.g.: hostname_date_time.log into my home directory). I would like to reach the same logging what the putty does. But I do not want to use putty under linux. This is why I ask you is it possible to logging the ssh as the putty? I read the related man pages and look after my problems in the net as well (forums, etc). Unfortunately I have found nothing for my problem. :( Secondly the Logging levels info, debug, verbose ... there is no description in the man. Which level logs what. If it is possible can you please send me a detailed description about it? If it is not possible to log. Does it have chance that the ssh will contain this option as well? I would like to thank you in advance for your kind help and time as well. Regards,Bal?zs Moln?re-Mail:molnarb81 at hotmail.com _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx From dtucker at zip.com.au Tue May 5 21:56:02 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 5 May 2009 21:56:02 +1000 Subject: ssh logging In-Reply-To: References: Message-ID: <20090505115602.GA31180@gate.dtucker.net> On Tue, May 05, 2009 at 10:59:32AM +0200, Bal?zs Moln?r wrote: > Dear All, > > I am a newbie in the unix world. Welcome aboard. > I have a problem. I try to log all my typed, edited (via vi/vim) and > of course the output/result of a command into a file (specific file e.g.: > hostname_date_time.log into my home directory). Typically, Unix tools are cooperative rather than comprehensive. In this particular case, OpenSSH does not provide keystroke logging. Instead, the typical way to do this is to have a separate program do the logging. One such program is script(1). You invoke it before running the program that you want to record the output of. Depending on your platform, script may have an option to invoke the command directly, in which case you could do what you describe with something like #!/bin/sh host=$1 datetime=`date '+%y-%m-%d_%H-%M'` script -c "ssh $host" ${host}_${datetime}.log [...] > Secondly the Logging levels info, debug, verbose ... there is no > description in the man. Which level logs what. The logs that you describe are for diagnostic purposes, which is to say that they do not record keystrokes. The possible values are listed in sshd_config(5) in order from least verbose to most verbose but the only way to know what the possible outputs are is to check the source code. [...] -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From sofian.brabez at wallix.com Mon May 11 23:00:25 2009 From: sofian.brabez at wallix.com (Sofian Brabez) Date: Mon, 11 May 2009 15:00:25 +0200 Subject: ssh logging In-Reply-To: References: Message-ID: <20090511130024.GA9571@newaza.ifr.lan> On Tue, May 05, 2009 at 10:59:32AM +0200, Bal?zs Moln?r wrote: > > Dear All, > > I am a newbie in the unix world. Welcome in the Unix wonderful world :) > > I have a problem. I try to log all my typed, edited (via vi/vim) and of course the output/result of a command into a file (specific file e.g.: hostname_date_time.log into my home directory). > You can use tee(1) piped in you ssh command like this to log commands results: ssh user at host | tee "`hostname`_`date '+%Y%m%d_%H:%M:%S'`.log Have a look to [1] about ssh session recording > I would like to reach the same logging what the putty does. But I do not want to use putty under linux. > This is why I ask you is it possible to logging the ssh as the putty? > > I read the related man pages and look after my problems in the net as well (forums, etc). > Unfortunately I have found nothing for my problem. :( > > Secondly the Logging levels info, debug, verbose ... there is no description in the man. Which level logs what. > Look to sshd_config(5) man page, you can change Logging level in your ssh server config file (/etc/sshd/sshd_config) and with flag -v on client side. Regards [1] http://www.jms1.net/ssh-record.shtml -- Sofian Brabez - sbz at wallix.com P?le Produits / Security Research and Development http://www.wallix.com WALLIX, 118 Rue de Tocqueville 75017 Paris From mad at free-styler.net Tue May 12 23:40:07 2009 From: mad at free-styler.net (pascal peltriaux) Date: Tue, 12 May 2009 15:40:07 +0200 Subject: Patch Openssh-5.2p1 for opensc PIN Message-ID: Hi, I just released a very simple patch to openssh 5.2p1 in order to correct the pin code problem when using smartcards. This patch file include the patch for: scard.c scard.h scard-opensc.c ssh.c Cheers, Pascal From carlosvsilva.ssh at gmail.com Wed May 13 01:14:43 2009 From: carlosvsilva.ssh at gmail.com (Carlos Silva) Date: Tue, 12 May 2009 16:14:43 +0100 Subject: Blog with status updates for Google SoC project: renovate sftp(1) Message-ID: <8a4d31920905120814s6155678fod1aaadf5fa5f6404@mail.gmail.com> Hi! I created a blog which will be kept up to date with my progress on the Summer Of Code project "renovate sftp(1)". I'm really pleased to work on OpenSSH, and everyone is invited to check out the blog, comment on it, and hopefully i'll reply to all comments :) Thanks! Cheers Carlos Silva From imorgan at nas.nasa.gov Wed May 13 02:25:29 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 12 May 2009 09:25:29 -0700 Subject: Blog with status updates for Google SoC project: renovate sftp(1) In-Reply-To: <8a4d31920905120814s6155678fod1aaadf5fa5f6404@mail.gmail.com> References: <8a4d31920905120814s6155678fod1aaadf5fa5f6404@mail.gmail.com> Message-ID: <20090512162529.GA3710@linux55.nas.nasa.gov> Uh, so what's the URL? On Tue, May 12, 2009 at 10:14:43 -0500, Carlos Silva wrote: > Hi! I created a blog which will be kept up to date with my progress on the > Summer Of Code project "renovate sftp(1)". I'm really pleased to work on > OpenSSH, and everyone is invited to check out the blog, comment on it, and > hopefully i'll reply to all comments :) Thanks! > > Cheers > > Carlos Silva > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From carlosvsilva.ssh at gmail.com Thu May 14 06:38:08 2009 From: carlosvsilva.ssh at gmail.com (Carlos Silva) Date: Wed, 13 May 2009 21:38:08 +0100 Subject: Blog with status updates for Google SoC project: renovate sftp(1) In-Reply-To: <20090512162529.GA3710@linux55.nas.nasa.gov> References: <8a4d31920905120814s6155678fod1aaadf5fa5f6404@mail.gmail.com> <20090512162529.GA3710@linux55.nas.nasa.gov> Message-ID: <8a4d31920905131338p2059f8c1oc43d2d7de3f86eec@mail.gmail.com> It's at http://sftp-gsoc09.blogspot.com/ :) Cheers Carlos Silva 2009/5/12 Iain Morgan > Uh, so what's the URL? > > On Tue, May 12, 2009 at 10:14:43 -0500, Carlos Silva wrote: > > Hi! I created a blog which will be kept up to date with my progress on > the > > Summer Of Code project "renovate sftp(1)". I'm really pleased to work on > > OpenSSH, and everyone is invited to check out the blog, comment on it, > and > > hopefully i'll reply to all comments :) Thanks! > > > > Cheers > > > > Carlos Silva > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- > Iain Morgan > From mmitar at gmail.com Mon May 18 03:15:28 2009 From: mmitar at gmail.com (Mitar) Date: Sun, 17 May 2009 19:15:28 +0200 Subject: Running OpenSSH in a chroot without mounted proc on Linux Message-ID: Hi! I have tried to use PAM chroot module to chroot an user into his home directory after login. The problem is that it fails because "openpty returns device for which ttyname fails". The fix would be probably very similar to: https://bugzilla.mindrot.org/attachment.cgi?id=1415&action=diff So why OpenSSH is using ttyname which does not work without a proc on a newer glibc (it tries to translate a proc entry)? Why not use openpty directly as there is an argument for that? And about that patch - is it really OK? How big name buffer does openpty require? Is 64 really enough? Should not it be of PATH_MAX (+1) size? I know that OpenSSH supports chrooting from 4.9 version on but I would like to setup this through PAM so also other programs chroot in the same manner. (I have been testing on Debian 5.0, stable, but as I see this code is the same in the official version.) Mitar From miguel.sanders at arcelormittal.com Sat May 23 20:46:56 2009 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Sat, 23 May 2009 12:46:56 +0200 Subject: Memory leak caused by forwarded GSSAPI credential store Message-ID: <7DF29B50FFF41848BB2281EC2E71A206BDC958@GEN-MXB-V04.msad.arcelor.net> Hi guys While debugging a GSSAPI memory allocation problem not related to OpenSSH, I found a memory leak in OpenSSH when storing forwarded GSSAPI credentials resulting in a growing process segment for each connection that uses GSSAPI credentials forwarding. What happens is the following: In the privileged parent, we are calling ssh_gssapi_storecreds() which itself calls ssh_gssapi_krb5_storecreds(). ssh_gssapi_krb5_storecreds() makes some memory allocations in order to save the credentials store for the gssapi client. +167 client->store.filename = xstrdup(krb5_cc_get_name(krb_context, ccache)); +168 client->store.envvar = "KRB5CCNAME"; +169 len = strlen(client->store.filename) + 6; +170 client->store.envval = xmalloc(len); +171 snprintf(client->store.envval, len, "FILE:%s", client->store.filename); Those memory allocations are never freed. Moreover, since those memory allocations are done in the privileged parent (which is a finite-state machine and never returns) before forking the unprivileged child, the memory leak gets doubled for each connection that uses GSSAPI credential forwarding. A solution would be the following: 1) Migrate the ssh_gssapi_storecreds() call to the unprivileged child 2) Create a ssh_gssapi_free_store() call in gss-serv.c which frees the memory allocations. At first I was thinking of integrating this in the ssh_gssapi_cleanup_creds() call but freeing the memory is mandatory while the cleanup of credentials is the user's choice. 3) Integrate ssh_gssapi_free_store() call in the do_cleanup() call, which is located in session.c. Bugzilla item #1601 was created to address this issue. I also added a patch which solves this issue. Met vriendelijke groet Best regards Bien ? vous Miguel SANDERS ArcelorMittal Gent UNIX Systems & Storage IT Supply Western Europe | John Kennedylaan 51 B-9042 Gent T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023 E miguel.sanders at arcelormittal.com www.arcelormittal.com/gent **** This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights. If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited. Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient. This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement. **** From sxw at inf.ed.ac.uk Sat May 23 21:38:58 2009 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Sat, 23 May 2009 12:38:58 +0100 Subject: Memory leak caused by forwarded GSSAPI credential store In-Reply-To: <7DF29B50FFF41848BB2281EC2E71A206BDC958@GEN-MXB-V04.msad.arcelor.net> References: <7DF29B50FFF41848BB2281EC2E71A206BDC958@GEN-MXB-V04.msad.arcelor.net> Message-ID: <7550CFDA-0604-449C-87ED-68A936078D0F@inf.ed.ac.uk> On 23 May 2009, at 11:46, miguel.sanders at arcelormittal.com wrote: > 1) Migrate the ssh_gssapi_storecreds() call to the unprivileged child Unfortunately, you can't do this, as GSSAPI credentials need to be stored before the PAM stack is invoked (this also means that the credentials need to be stored in the process which invokes pam_setcred, and not in the unprivileged child). Also, credentials need to be stored whether the user is running privsep or not - this change moves credential storage to a privsep only code path. An alternative fix, that doesn't move the location of the storecreds() call, is going to be required. One option would be to dispose of these structures in the parent as soon as the child is forked (if we're running privsep), so removing the leak in the parent, and tidying up the leak in the child in the manner you suggest. Cheers, Simon. From alexander.panasyuk at gmail.com Mon May 25 03:57:31 2009 From: alexander.panasyuk at gmail.com (Alexander Panasyuk) Date: Sun, 24 May 2009 13:57:31 -0400 Subject: OpenSSH_5.2p1. non-vpn login to root account requests TUN interface and cannot exit Message-ID: <5082c8590905241057yd6ef0d7h79d2c0c329ad4728@mail.gmail.com> Hello! I've configured SSH-VPN between two subnets and it works fine. Option Tunnel=yes in config file is set. The problem I run into is that normal SSH login to root account does not terminate on "exit" command. > ssh root at pig pig> exit ;; screen is cleared but does not return to prompt Killed by signal 2. ctrl-D does not work. Running ssh with -vvv has shown that as soon as authentication succeeds ssh requests tun device: debug1: Authentication succeeded (publickey). debug1: Requesting tun unit 2147483647 in mode 1 debug1: sys_tun_open: tunnel mode 1 fd 4 debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new [tun] debug1: channel 1: new [client-session] debug3: ssh_session2_open: channel_new: 1 debug2: channel 1: send open and after I exit from shell can not close it: debug2: channel 1: rcvd eof debug2: channel 1: output open -> drain debug2: channel 1: obuf empty debug2: channel 1: close_write debug2: channel 1: output drain -> closed debug1: client_input_channel_req: channel 1 rtype exit-status reply 0 debug2: channel 1: rcvd close debug2: channel 1: close_read debug2: channel 1: input open -> closed debug3: channel 1: will not send data after close debug2: channel 1: almost dead debug2: channel 1: gc: notify user debug2: channel 1: gc: user detached debug2: channel 1: send close debug2: channel 1: is dead debug2: channel 1: garbage collecting debug1: channel 1: free: client-session, nchannels 2 debug3: channel 1: status: The following connections are open: #0 tun (t4 r0 i0/0 o0/0 fd 4/4 cfd -1) #1 client-session (t4 r1 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 1: close_fds r -1 w -1 e 7 c -1 Running ssh -oTunnel=no root at pig does not help either. Commenting out Tunnel=yes in configuration file does work. I wonder why TUN device is requested when I am not asking for SSH-VPN tunneling, why it can not be closed on exit (nothing is using it) and why -oTunnel=no option does not work. Thanks, Alex. From djm at mindrot.org Mon May 25 16:22:36 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 25 May 2009 16:22:36 +1000 (EST) Subject: Memory leak caused by forwarded GSSAPI credential store In-Reply-To: <7DF29B50FFF41848BB2281EC2E71A206BDC958@GEN-MXB-V04.msad.arcelor.net> References: <7DF29B50FFF41848BB2281EC2E71A206BDC958@GEN-MXB-V04.msad.arcelor.net> Message-ID: On Sat, 23 May 2009, miguel.sanders at arcelormittal.com wrote: > Those memory allocations are never freed. Moreover, since those memory > allocations are done in the privileged parent (which is a finite-state > machine and never returns) before forking the unprivileged child, > the memory leak gets doubled for each connection that uses GSSAPI > credential forwarding. I don't think so - the parent in this case is the per-connection privsep monitor, so any leaks here will not affect the master listening process. -d From kevmack at accesscomm.ca Wed May 27 13:30:03 2009 From: kevmack at accesscomm.ca (Kevin) Date: Tue, 26 May 2009 21:30:03 -0600 Subject: idle timeouts In-Reply-To: <20090527031903.GA4305@aspire.accesscomm.ca> References: <20090527031903.GA4305@aspire.accesscomm.ca> Message-ID: <20090527033003.GA4492@aspire.accesscomm.ca> I need to implement idle timeouts, based on user input. Our users connect through a gateway host to access other machines. Using the "autolog" package on the gateway seems to work fine for shell sessions. Keyboard input from users updates the utmp file on the gateway. However, we have users who use port forwarding to run GUI apps such as VNC. User input from these apps don't appear to cause utmp updates. Any suggestions? There's a watchdog patch out there, but I'd rather not resort to using patches. From sourcetrunk at gmail.com Wed May 27 21:24:17 2009 From: sourcetrunk at gmail.com (source trunk) Date: Wed, 27 May 2009 13:24:17 +0200 Subject: Sourcetrunk : OpenSSH episode Message-ID: <6129592a0905270424g25c9acbagc1c70566546387ba@mail.gmail.com> Hi, I've briefly reviewed your excellent software (OpenSSH) and thought I'd let you know. The podcast aired on 27/06/2009 . You can find it on www.sourcetrunk.com . If you are under the impression that your software was not reviewed like it should and/or did not get the review that it deserved, please let me know and I'll make adjustments and addenda in the next episode. Since the reviews are rather short and it is not possible to cover every feature of the software (and due to the nature of OpenSSH this task is really difficult), there is a fair chance that I've missed features that should have been mentioned. If so, just point them out to me in a reply and I'll be more then happy to mention them in the next episode. Thanks again for the great software. kind regards, Dimitri Larmuseau. host/producer Sourcetrunk. From hkunnana at gmail.com Fri May 29 19:13:36 2009 From: hkunnana at gmail.com (Hazem KUNNANA) Date: Fri, 29 May 2009 12:13:36 +0300 Subject: Tunnelling problem in windows 7 Message-ID: <255b46f30905290213j583adafev3b36befabc4f41ee@mail.gmail.com> Hi, I have recently installed Windows 7 RC [Version 6.1.7100], and instaled the OpenSSH [setupssh381-20040709] I wanted to tunnel through my ssh server, I usually use this command on my Windows XP machine, and it works. ssh -L 9983:10.0.0.37:3389 infram at 192.168.1.13 ?N When issuing that command on Windows 7, after asked for the password, it gives me this error: \226N: Command not found. and exits. It might be some setup different from XP on windows 7. anyway, trying just to use ssh (without tunnelling) on the same machine succeedes (ssh infram at 192.168.1.13) I haven't tried it on Windows Vista ( I never used it) I hope I don't get this answer :(Windows 7 is not supported yet) Is there a solution to this? Regards all. From dtucker at zip.com.au Sun May 31 15:01:08 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 31 May 2009 15:01:08 +1000 Subject: Tunnelling problem in windows 7 In-Reply-To: <255b46f30905290213j583adafev3b36befabc4f41ee@mail.gmail.com> References: <255b46f30905290213j583adafev3b36befabc4f41ee@mail.gmail.com> Message-ID: <4A220F14.9020400@zip.com.au> Hazem KUNNANA wrote: > Hi, I have recently installed Windows 7 RC [Version 6.1.7100], and instaled > the OpenSSH [setupssh381-20040709] That's a stripped-down Cygwin plus OpenSSH binary package, both of which are five years old and apparently unmaintained. If you're having problems with it you'll have to ask the people who supply it. I suggest you remove it and install a current Cygwin (http://www.cygwin.com, which has an OpenSSH package) or if you're looking for a prepackaged one, CopSSH (http://www.itefix.no/i2/copssh). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.