From pepper at cbio.mskcc.org Tue Nov 3 09:14:08 2009 From: pepper at cbio.mskcc.org (Chris Pepper) Date: Mon, 02 Nov 2009 17:14:08 -0500 Subject: Match vs. ChallengeResponseAuthentication? In-Reply-To: References: <4AE9BC77.6090309@cbio.mskcc.org> <4AEA3995.3030708@zip.com.au> Message-ID: <4AEF59B0.5000101@cbio.mskcc.org> Damien Miller wrote: > On Fri, 30 Oct 2009, Darren Tucker wrote: > >> ChallengeResponseAuthentication no >> KbdInteractiveAuthentication no >> Match Address 10.0.0.0/8 >> KbdInteractiveAuthentication yes >> >> >> Originally ChallengeResponseAuthentication was omitted because it has slightly >> odd semantics. In sshd.c: >> >> /* Fill in default values for those options not explicitly set. */ >> fill_default_server_options(&options); >> >> /* challenge-response is implemented via keyboard interactive */ >> if (options.challenge_response_authentication) >> options.kbd_interactive_authentication = 1; >> >> If we're going to enable it we need to think through the use cases and make >> sure it adheres the principle of least surprise :-) > > Good point. I just noticed that we don't document > KbdInteractiveAuthentication in sshd_config(5). Maybe we should deprecate > it by making it a pointer to ChallengeResponseAutentication like > SkeyAuthentication already is? We don't allow v1, but I got it working on CentOS through iptables, so didn't have to build a custom sshd v5. Now I get to fight with SuSE's insane iptables implementation. Please tell me if I said anything bogus (especially as I didn't actually test the Match configuration)! http://www.extrapepperoni.com/post/2009/11/Conditional-%60ssh%60-Configuration%3A-%60iptables%60-%60sshd%60 Thanks much, Chris Pepper -- Chris Pepper: From zaq21wsx at rediffmail.com Tue Nov 3 22:25:13 2009 From: zaq21wsx at rediffmail.com (Neelabh) Date: 3 Nov 2009 11:25:13 -0000 Subject: =?utf-8?B?UmU6IFJlOiBzc2hfZnhwX25hbWU=?= Message-ID: <1256861309.S.4759.2135.f6mail-145-155.rediffmail.com.old.1257247513.9414@webmail.rediffmail.com> ok basically my FXP_READDIR loop consumed the entire channel window and the partial sftp packet was probably the last channel data server could send. Fixed that by introducing WINDOW_ADJUST message logic. Thanks for your inputs on this. On Fri, 30 Oct 2009 05:38:29 +0530 wrote >On Fri, 29 Oct 2009, qqq wrote: > Hello, > > I have a very basic sftp client which is able to successfully > intialize the transport layer, password authenticate, and start the > sftp subsystem. Now, I am stuck with an issue when I try to retrieve > the directory listing. Sometimes I get a transport packet in which the > sftp packet length field registers a length greater than the enclosing > transport packet. In othet words sometimes I get a transport packet > whose lenght is less than what the sftp packet length field registers. > This happens only sometimes. That is, if I give SSH_FXP_READDIR > commands say 30 times on the same directory, then I get this packet > after around 25-30 iterations. I tried to check the readability of the > socket when this happens but the server does not send anything after > this and select just hangs. I am not able to think of why this is > happening and would apprecaite pointers in the right direction. thanks sftp operates at a protocol layer above the SSH transport, so the size of sftp's packets may exceed the maximum allowed by the ssh connection. In these cases, a sftp packet may span multiple transport packets. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From aron at stria.com Wed Nov 4 06:04:37 2009 From: aron at stria.com (Aron Vietti) Date: Tue, 3 Nov 2009 13:04:37 -0600 Subject: Chroot a cifs home directory for sftp Message-ID: <8F0F5F4EE255CD4C9A40FA2DECA0C4510151D618@be15.exg4.exghost.com> Using OpenSSH 5.1 on Ubuntu Linux If you setup a home directory as a cifs share you cannot chroot and connect through sftp. If you turn off the cifs share then the connection works as expected with the same config file and permissions. From winstonwaite at gmail.com Fri Nov 6 06:38:05 2009 From: winstonwaite at gmail.com (Robert Waite) Date: Thu, 5 Nov 2009 14:38:05 -0500 Subject: sshd_config ChrootDirectory ambiguity... Message-ID: Under "ChrootDirectory" there is a line that says, "This path, and all its components, must be root-owned directories that are not writable by any other user or group." When I first read this "all its components" seemed to mean that all directories and files within this directory must be root owned and root only writable. This seemed odd as I would not be able to allow uploads if this was true. In this ChrootDirectory I have three folders. I set them all to be owned by a non root user and writable by a group. When I log in, it works just as I hoped and I am able to upload now. I would have figured at the very least that "all its components" would mean that direct children of the ChrootDirectory would have to have the above mentioned restrictions. However, it did work. So my question is... what is meant by "all its components"? From winstonwaite at gmail.com Fri Nov 6 06:39:33 2009 From: winstonwaite at gmail.com (Robert Waite) Date: Thu, 5 Nov 2009 14:39:33 -0500 Subject: Limiting simultaneous sftp downloads.. Message-ID: When I use Filezilla... the default setup will download two files in the queue at the same time. What I would notice is sometimes I could really hear my harddrive thrashing as it scanned over the disk trying to get data from both files. Now... it is quite possible that filezilla performs two logins... but it seems like it is performing the operations over the same connection. There is a sshd_config setting called "MaxSessions". I set this to one but filezilla still downloaded files in pairs simultaneously. Does anyone know if there is a facility to pull two files over one login? Is there a way to stop this? I realize that if multiple users login... then there is no way to really stop this.. but it is sad when I hear my harddrive cranking away when only one apparent user is signed in with filezilla. Seems like having server control over this would be nice. Thanks. From scott_n at xypro.com Fri Nov 6 06:48:17 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 5 Nov 2009 11:48:17 -0800 Subject: sshd_config ChrootDirectory ambiguity... In-Reply-To: References: Message-ID: <78DD71C304F38B41885A242996B96F730204F22C@xyservd.XYPRO-23.LOCAL> Quoth Robert Waite: > > Under "ChrootDirectory" there is a line that says, > > "This path, and all its components, must be root-owned directories > that are not writable by any other user or group." > > When I first read this "all its components" seemed to mean that > all directories and files within this directory must be root owned > and root only writable. This seemed odd as I would not be able > to allow uploads if this was true. > > In this ChrootDirectory I have three folders. I set them all to be > owned by a non root user and writable by a group. When I log in, it > works just as I hoped and I am able to upload now. > I would have figured at the very least that "all its components" would > mean that direct children of the ChrootDirectory would have to have the > above mentioned restrictions. However, it did work. > > So my question is... what is meant by "all its components"? [[SAN]] If the chrooted path is /a/b/c/d/e, the all of /a, /a/b, /a/b/c, /a/b/c/d, and /a/b/c/d/e must be owned by root, and only root writable. Otherwise, it's possible to spoof, by $EVILUSER renaming /a/b/c to /a/b/c.real and putting their own evil /a/b/c in place. I did this once (with management permission), when we needed root access to a system, the admin wasn't available, and he'd foolishly left / as world writeable. I renamed /etc, created a new /etc with a dummy /etc/passwd, and logged in as root. Ugly, and should never have been possible, but it worked. From markus.r.friedl at arcor.de Fri Nov 6 06:53:36 2009 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Thu, 5 Nov 2009 20:53:36 +0100 Subject: sshd_config ChrootDirectory ambiguity... In-Reply-To: References: Message-ID: <20091105195336.GA22084@folly> all components of the pathname On Thu, Nov 05, 2009 at 02:38:05PM -0500, Robert Waite wrote: > Under "ChrootDirectory" there is a line that says, > > "This path, and all its components, must be root-owned directories > that are not writable by any other user or group." > > When I first read this "all its components" seemed to mean that > all directories and files within this directory must be root owned > and root only writable. This seemed odd as I would not be able > to allow uploads if this was true. > > In this ChrootDirectory I have three folders. I set them all to be > owned by a non root user and writable by a group. When I log in, it > works just as I hoped and I am able to upload now. > I would have figured at the very least that "all its components" would > mean that direct children of the ChrootDirectory would have to have the > above mentioned restrictions. However, it did work. > > So my question is... what is meant by "all its components"? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From winstonwaite at gmail.com Fri Nov 6 07:22:18 2009 From: winstonwaite at gmail.com (Robert Waite) Date: Thu, 5 Nov 2009 15:22:18 -0500 Subject: sshd_config ChrootDirectory ambiguity... In-Reply-To: <20091105195336.GA22084@folly> References: <20091105195336.GA22084@folly> Message-ID: Ah ha! I got ya. Makes perfect sense now. I had showed it to an admin and also an old school linux kernel hacker and both were confused as well. Thanks for the quick response (to Scott as well)! On Thu, Nov 5, 2009 at 2:53 PM, Markus Friedl wrote: > all components of the pathname > > On Thu, Nov 05, 2009 at 02:38:05PM -0500, Robert Waite wrote: > > Under "ChrootDirectory" there is a line that says, > > > > "This path, and all its components, must be root-owned directories > > that are not writable by any other user or group." > > > > When I first read this "all its components" seemed to mean that > > all directories and files within this directory must be root owned > > and root only writable. This seemed odd as I would not be able > > to allow uploads if this was true. > > > > In this ChrootDirectory I have three folders. I set them all to be > > owned by a non root user and writable by a group. When I log in, it > > works just as I hoped and I am able to upload now. > > I would have figured at the very least that "all its components" would > > mean that direct children of the ChrootDirectory would have to have the > > above mentioned restrictions. However, it did work. > > > > So my question is... what is meant by "all its components"? > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Fri Nov 6 12:09:00 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 6 Nov 2009 12:09:00 +1100 (EST) Subject: SSL vulnerability and SSH Message-ID: Hi, This is just a quick note to state that the recently reported SSL/TLS MITM attack[1] *does not* affect SSH. Like SSL/TLS, SSH supports key and parameter renegotiation, but it is not vulnerable because a session identifier is carried over from the first key exchange into all subsequent key exchanges. Technical details: In SSL, key exchanges and subsequent renegotiations are completely independent. This allows an attack as follows: a MITM intercepts a connection from a real client. It then connects to the target server itself and negotiates a SSL/TLS connection. The MITM may then inject some data of its choice (say, the start of a HTTP request) before it initiates a regenotiation with the server and proxies the real client's negotiation to the server. The real client thinks it is negotiating for the first time, but the real server thinks the client is renegotiating. Once the negotiation is complete, thereal client and server continue the connection (proxied via the MITM) oblivious to the fact that the MITM has injected data. In SSH, the first key exchange generates a "session identifier" in addition to a key. This session identifier is used in the derivation of all future cipher and MAC keys (RFC4253 section 7.2). If an attacker tried the proxy and renegotiate SSL attack on SSH, the real client's session ID would not match that generated by the server, causing the derived keys to be different. The connection would terminate with a MAC error as soon as the first data was exchanged. (http://djm.net.au/2009/11/6/ssh-is-not-vulnerable-to-the-ssl-tls-mitm-attack) -d [1] http://extendedsubset.com/?p=8 From petesea at bigfoot.com Tue Nov 10 19:09:02 2009 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Tue, 10 Nov 2009 00:09:02 -0800 (PST) Subject: Cygwin OpenSSH 5.1 login session per user Message-ID: I'm using Cygwin OpenSSH 5.1 on a Windows XP SP3 system. Is sshd supposed to create a new "login session" for each user that logs in? Or, is there a way to force it to create a new "login session" for each user that logs in? Once logged in, I'm trying to use the Kerberos for Windows command line utilities (klist/kinit), but I'm told by one of the KfW developers, each user must be in it's own login session. From the way klist/kinit are behaving, it appears sshd is NOT creating a new login session for each user. From vinschen at redhat.com Tue Nov 10 20:52:07 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 10 Nov 2009 10:52:07 +0100 Subject: Cygwin OpenSSH 5.1 login session per user In-Reply-To: References: Message-ID: <20091110095207.GX26344@calimero.vinschen.de> On Nov 10 00:09, petesea at bigfoot.com wrote: > I'm using Cygwin OpenSSH 5.1 on a Windows XP SP3 system. > > Is sshd supposed to create a new "login session" for each user that > logs in? Or, is there a way to force it to create a new "login > session" for each user that logs in? > > Once logged in, I'm trying to use the Kerberos for Windows command > line utilities (klist/kinit), but I'm told by one of the KfW > developers, each user must be in it's own login session. From the > way klist/kinit are behaving, it appears sshd is NOT creating a new > login session for each user. That's a Windows/Cygwin thingy. Cygwin's sshd creates a new logon session only if you use password authentication. If you use pubkey auth, you're still running in the logon session of the user running sshd (typically "SYSTEM" or "LocalSystem" on XP). However, this behaviour of sshd with pubkey auth is *not* under control of sshd, it's entirely under control of Cygwin. Workarounds which allow to use pubkey auth and to get a logon session are available in the new Cygwin 1.7, which is in it's late beta test phase. See http://cygwin.com/#beta-test http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html http://cygwin.com/1.7/cygwin-ug-net/ntsec.html#ntsec-setuid-overview Please send followup question concerning Cygwin to the Cygwin mailing list, see http://cygwin.com/lists.html Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rdkehn at yahoo.com Sun Nov 15 02:00:46 2009 From: rdkehn at yahoo.com (Doug Kehn) Date: Sat, 14 Nov 2009 07:00:46 -0800 (PST) Subject: Alternate Install Location Patch Proposal Message-ID: <240668.54292.qm@web52003.mail.re2.yahoo.com> Hi All, Below (and attached) is a patch that will allow openssh to be installed in an alternate location. This is essential when cross-compiling. The cross-compile use case is: configure [bunch-of-options] make DESTDIR= make install-nokeys I believe the patch may also be useful for non-cross-compiling cases. Regards, ...doug ---8<----- diff -uraN openssh-5.3p1.orig/Makefile.in openssh-5.3p1/Makefile.in --- openssh-5.3p1.orig/Makefile.in 2009-08-27 19:47:38.000000000 -0500 +++ openssh-5.3p1/Makefile.in 2009-11-14 08:02:29.000000000 -0600 @@ -19,7 +19,7 @@ srcdir=@srcdir@ top_srcdir=@top_srcdir@ -DESTDIR= +DESTDIR?= VPATH=@srcdir@ SSH_PROGRAM=@bindir@/ssh ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-5.3p1-alt-install-loc.patch Type: text/x-diff Size: 373 bytes Desc: not available URL: From dtucker at zip.com.au Sun Nov 15 09:12:31 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 15 Nov 2009 09:12:31 +1100 Subject: Alternate Install Location Patch Proposal In-Reply-To: <240668.54292.qm@web52003.mail.re2.yahoo.com> References: <240668.54292.qm@web52003.mail.re2.yahoo.com> Message-ID: <4AFF2B4F.6090405@zip.com.au> Doug Kehn wrote: > Hi All, > > Below (and attached) is a patch that will allow openssh to be > installed in an alternate location. This is essential when > cross-compiling. The cross-compile use case is: > configure [bunch-of-options] > make > DESTDIR= make install-nokeys You can already do that with "make install-nokeys DESTDIR=". -- 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 lattera at gmail.com Wed Nov 18 13:30:13 2009 From: lattera at gmail.com (lattera) Date: Tue, 17 Nov 2009 19:30:13 -0700 Subject: SFTP Chroot Message-ID: <3a85d9b00911171830h603e1e0fy5a69287e65c33f57@mail.gmail.com> Hi all, Today, I was tasked at work with setting up a chroot SFTP server on a 64bit Arch Linux server. I naturally turned to Arch Linux's wiki article on the subject (http://wiki.archlinux.org/index.php/SFTP-chroot) and the directions were very clear. However, the directions did not work. I kept getting a "Write failed: Broken pipe" error after attempting to connect. Upon digging through the code for OpenSSH 5.3p1 , I found this snippet of code, starting at line 1399 of session.c and ending at line 1452: /* > * Chroot into a directory after checking it for safety: all path > components > * must be root-owned directories with strict permissions. > */ > static void > safely_chroot(const char *path, uid_t uid) > { > const char *cp; > char component[MAXPATHLEN]; > struct stat st; > > if (*path != '/') > fatal("chroot path does not begin at root"); > if (strlen(path) >= sizeof(component)) > fatal("chroot path too long"); > > /* > * Descend the path, checking that each component is a > * root-owned directory with strict permissions. > */ > for (cp = path; cp != NULL;) { > if ((cp = strchr(cp, '/')) == NULL) > strlcpy(component, path, sizeof(component)); > else { > cp++; > memcpy(component, path, cp - path); > component[cp - path] = '\0'; > } > > debug3("%s: checking '%s'", __func__, component); > > if (stat(component, &st) != 0) > fatal("%s: stat(\"%s\"): %s", __func__, > component, strerror(errno)); > if (st.st_uid != 0 || (st.st_mode & 022) != 0) > fatal("bad ownership or modes for chroot " > "directory %s\"%s\"", > cp == NULL ? "" : "component ", component); > if (!S_ISDIR(st.st_mode)) > fatal("chroot path %s\"%s\" is not a directory", > cp == NULL ? "" : "component ", component); > > } > > if (chdir(path) == -1) > fatal("Unable to chdir to chroot path \"%s\": " > "%s", path, strerror(errno)); > if (chroot(path) == -1) > fatal("chroot(\"%s\"): %s", path, strerror(errno)); > if (chdir("/") == -1) > fatal("%s: chdir(/) after chroot: %s", > __func__, strerror(errno)); > verbose("Changed root directory to \"%s\"", path); > } > Why should all the directory tree be root-owned and have that set of permissions? This is preventing me from setting the chroot to /home/ and be done with it, like that wiki article suggests. If there is no security concern, I would like to remove the offending code (the for loop). I will probably do this anyways for the project I'm working on, but I am unsure if the public as a whole could benefit from such a change. Thanks for taking the time to respond, Shawn From Jefferson.Ogata at noaa.gov Wed Nov 18 13:42:33 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 18 Nov 2009 02:42:33 +0000 Subject: SFTP Chroot In-Reply-To: <3a85d9b00911171830h603e1e0fy5a69287e65c33f57@mail.gmail.com> References: <3a85d9b00911171830h603e1e0fy5a69287e65c33f57@mail.gmail.com> Message-ID: <4B035F19.5020906@noaa.gov> On 2009-11-18 02:30, lattera wrote: > Why should all the directory tree be root-owned and have that set of > permissions? This is preventing me from setting the chroot to /home/ > and be done with it, like that wiki article suggests. If there is no > security concern, I would like to remove the offending code (the for loop). > I will probably do this anyways for the project I'm working on, but I am > unsure if the public as a whole could benefit from such a change. http://lists.mindrot.org/pipermail/openssh-unix-dev/2009-May/027651.html https://bugzilla.redhat.com/show_bug.cgi?id=522141 -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From surgpm at gmail.com Wed Nov 18 23:29:33 2009 From: surgpm at gmail.com (Paul Surgeon) Date: Wed, 18 Nov 2009 14:29:33 +0200 Subject: internal-sftp atomic file operations? Message-ID: <6d98c5450911180429u6fed581fh40953e34dc69bb18@mail.gmail.com> Hi I've been testing internal-sftp with chroot on OpenSSH_5.3p1 and it seems that internal-sftp does not support POSIX atomic rename() operations. Can someone confirm that this feature is only available in the sftp-server and not internal-sftp? Are there plans to include atomic file operations in internal-sftp? Thanks From Robert.Story at cobham.com Thu Nov 19 01:03:34 2009 From: Robert.Story at cobham.com (Robert Story) Date: Wed, 18 Nov 2009 09:03:34 -0500 Subject: local DNSSEC validation for 5.3p1 Message-ID: <20091118090334.66a4b80c@sparta.com> Attached is a patch that adds local DNSSEC validation to OpenSSH. See the readme for more detail. Please direct any questions or comments to users at dnssec-tools.org. Thanks.. -- Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From Robert.Story at cobham.com Thu Nov 19 01:10:33 2009 From: Robert.Story at cobham.com (Robert Story) Date: Wed, 18 Nov 2009 09:10:33 -0500 Subject: local DNSSEC validation for 5.3p1 In-Reply-To: <20091118090334.66a4b80c@sparta.com> References: <20091118090334.66a4b80c@sparta.com> Message-ID: <20091118091033.2d2bede5@sparta.com> On Wed, 18 Nov 2009 09:03:34 -0500 Robert wrote: RS> Attached is a patch that adds local DNSSEC validation to OpenSSH. See RS> the readme for more detail. Please direct any questions or comments to RS> users at dnssec-tools.org. Thanks.. Seems the patch was stripped... is there somewhere else to submit it, or should I just put it inline? -- Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tim at multitalents.net Thu Nov 19 02:49:20 2009 From: tim at multitalents.net (Tim Rice) Date: Wed, 18 Nov 2009 07:49:20 -0800 (PST) Subject: local DNSSEC validation for 5.3p1 In-Reply-To: <20091118091033.2d2bede5@sparta.com> References: <20091118090334.66a4b80c@sparta.com> <20091118091033.2d2bede5@sparta.com> Message-ID: On Wed, 18 Nov 2009, Robert Story wrote: > On Wed, 18 Nov 2009 09:03:34 -0500 Robert wrote: > RS> Attached is a patch that adds local DNSSEC validation to OpenSSH. See > RS> the readme for more detail. Please direct any questions or comments to > RS> users at dnssec-tools.org. Thanks.. > > Seems the patch was stripped... is there somewhere else to submit it, > or should I just put it inline? It must not have been text/plain. It is best to open a ticket on bugzilla. http://bugzilla.mindrot.org -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Thu Nov 19 21:59:37 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 19 Nov 2009 21:59:37 +1100 Subject: internal-sftp atomic file operations? In-Reply-To: <6d98c5450911180429u6fed581fh40953e34dc69bb18@mail.gmail.com> References: <6d98c5450911180429u6fed581fh40953e34dc69bb18@mail.gmail.com> Message-ID: <4B052519.3070704@zip.com.au> Paul Surgeon wrote: > I've been testing internal-sftp with chroot on OpenSSH_5.3p1 and it > seems that internal-sftp does not support POSIX atomic rename() > operations. > Can someone confirm that this feature is only available in the > sftp-server and not internal-sftp? It's the same sftp server code either way. A quick test with internal-sftp and chrootdirectory shows it's there: $ sftp -vv localhost [...] debug2: Remote version: 3 debug2: Server supports extension "posix-rename at openssh.com" revision 1 debug2: Server supports extension "statvfs at openssh.com" revision 2 debug2: Server supports extension "fstatvfs at openssh.com" revision 2 sftp> Under what conditions does it not work? The only scenario I can think of is of you had sshd and sftp-server from different OpenSSH releases. -- 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 austin_connolly87 at yahoo.ca Sun Nov 22 14:17:00 2009 From: austin_connolly87 at yahoo.ca (Austin Connolly) Date: Sat, 21 Nov 2009 19:17:00 -0800 (PST) Subject: I need help Message-ID: <35575.48321.qm@web43510.mail.sp1.yahoo.com> Sent from my iPod __________________________________________________________________ The new Internet Explorer? 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ From dan at doxpara.com Sun Nov 22 14:43:59 2009 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 21 Nov 2009 22:43:59 -0500 Subject: I need help In-Reply-To: <35575.48321.qm@web43510.mail.sp1.yahoo.com> References: <35575.48321.qm@web43510.mail.sp1.yahoo.com> Message-ID: <7A52FB2D-365D-4D19-97BA-44926AF47313@doxpara.com> The entire bar is offering replies: 'yes you do.' 'yes we can.' 'that IS what your mom said.' :) Seriously, what's up? On Nov 21, 2009, at 10:17 PM, Austin Connolly wrote: > > > Sent from my iPod > > > > __________________________________________________________________ > The new Internet Explorer? 8 - Faster, safer, easier. Optimized for > Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dwmw2 at infradead.org Mon Nov 23 20:58:32 2009 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 23 Nov 2009 09:58:32 +0000 Subject: [PATCH] Bluetooth support. Message-ID: <1258970312.29729.205.camel@macbook.infradead.org> This is just the first part -- it adds support for correctly reporting incoming connections when there's an external d?mon accepting the connections and invoking 'sshd -i' with them, like inetd does. In later patches I'll extend sshd to listen on a Bluetooth socket (and advertise the service in SDP) for itself, and extend the ssh client to make the connection directly. For now, I'm testing with http://david.woodhou.se/btserv.c and ssh -o 'ProxyCommand socat stdio SOCKET-CONNECT:31:3:x1ec1e4e21f000100' root at bluetooth Index: canohost.c =================================================================== RCS file: /cvs/openssh/canohost.c,v retrieving revision 1.75 diff -u -p -r1.75 canohost.c --- canohost.c 21 Jun 2009 08:13:58 -0000 1.75 +++ canohost.c 23 Nov 2009 09:50:32 -0000 @@ -20,6 +20,11 @@ #include #include +#ifdef HAVE_BLUETOOTH +#include +#include +#endif + #include #include #include @@ -60,6 +65,16 @@ get_remote_hostname(int sock, int use_dn cleanup_exit(255); } +#ifdef HAVE_BLUETOOTH + if (from.ss_family == AF_BLUETOOTH) { + struct sockaddr_rc *from_rc = (void *)&from; + char ba[28]; + + sprintf(ba, "Bluetooth:"); + ba2str(&from_rc->rc_bdaddr, ba + 10); + return xstrdup(ba); + } +#endif if (from.ss_family == AF_INET) check_ip_options(sock, ntop); @@ -264,6 +279,16 @@ get_socket_address(int sock, int remote, return NULL; } +#ifdef HAVE_BLUETOOTH + if (addr.ss_family == AF_BLUETOOTH) { + struct sockaddr_rc *from_rc = (void *)&addr; + char ba[28]; + + sprintf(ba, "Bluetooth:"); + ba2str(&from_rc->rc_bdaddr, ba + 10); + return xstrdup(ba); + } +#endif /* Work around Linux IPv6 weirdness */ if (addr.ss_family == AF_INET6) addrlen = sizeof(struct sockaddr_in6); @@ -375,6 +400,13 @@ get_sock_port(int sock, int local) } } +#ifdef HAVE_BLUETOOTH + if (from.ss_family == AF_BLUETOOTH) { + struct sockaddr_rc *from_rc = (void *)&from; + + return from_rc->rc_channel; + } +#endif /* Work around Linux IPv6 weirdness */ if (from.ss_family == AF_INET6) fromlen = sizeof(struct sockaddr_in6); Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.430 diff -u -p -r1.430 configure.ac --- configure.ac 11 Oct 2009 10:50:20 -0000 1.430 +++ configure.ac 23 Nov 2009 09:50:35 -0000 @@ -3636,6 +3636,27 @@ else fi AC_SUBST(mansubdir) +# Check whether to support Bluetooth +BLUETOOTH_MSG="no" +AC_ARG_ENABLE(bluetooth, + [ --disable-bluetooth disable Bluetooth support if detected [no]], + [ + if test "x$enableval" = "xno" ; then + disable_bluetooth=yes + fi + ] +) +if test -z "$disable_bluetooth" ; then + AC_CHECK_HEADERS(bluetooth/bluetooth.h, + [ AC_CHECK_LIB(bluetooth, ba2str, + [ LIBS="$LIBS -lbluetooth" + AC_DEFINE(HAVE_BLUETOOTH) + BLUETOOTH_MSG="yes" + ]) + ] + ) +fi + # Check whether to enable MD5 passwords MD5_MSG="no" AC_ARG_WITH(md5-passwords, @@ -4231,6 +4252,7 @@ echo " S/KEY support echo " TCP Wrappers support: $TCPW_MSG" echo " MD5 password support: $MD5_MSG" echo " libedit support: $LIBEDIT_MSG" +echo " Bluetooth support: $BLUETOOTH_MSG" echo " Solaris process contract support: $SPC_MSG" echo " IP address in \$DISPLAY hack: $DISPLAY_HACK_MSG" echo " Translate v4 in v6 hack: $IPV4_IN6_HACK_MSG" Index: packet.c =================================================================== RCS file: /cvs/openssh/packet.c,v retrieving revision 1.169 diff -u -p -r1.169 packet.c --- packet.c 2 Oct 2009 01:49:04 -0000 1.169 +++ packet.c 23 Nov 2009 09:50:36 -0000 @@ -308,6 +308,10 @@ packet_connection_is_on_socket(void) return 0; if (fromlen != tolen || memcmp(&from, &to, fromlen) != 0) return 0; +#ifdef HAVE_BLUETOOTH + if (from.ss_family == AF_BLUETOOTH) + return 1; +#endif if (from.ss_family != AF_INET && from.ss_family != AF_INET6) return 0; return 1; -- dwmw2 From luizcasey at yahoo.com Tue Nov 24 01:40:08 2009 From: luizcasey at yahoo.com (Luiz Casey) Date: Mon, 23 Nov 2009 06:40:08 -0800 (PST) Subject: Connection type variable Message-ID: <58805.76351.qm@web51606.mail.re2.yahoo.com> Hello, I would like to know how would I go about in using a connection type variable with the sshd_config. What would be the consequences,security,problem with doing such a thing. What I would like to accomplish is something like: Match Group Users ChrootDirectory "sftp/ssh" /home/%u ForceCommand "sftp/ssh" internal-sftp AllowTcpForwarding "sftp/ssh" no Where "sftp/ssh" would be used if the connection is regular ssh connection or sftp. So ChrootDirectory/ForceCommand would only be used if the connection matches that variable. Use case, a restricted or limited shell is being used which prevents users from running specific commands and locks them with a specific directory. All gets thrown out if sftp is used. Therefor if chrootdirectory/forcecommand can be used for sftp connection only it would lock the user within that directory. Currently is it not possible to use the above combination for both ssh/sftp user. Any ideas, suggestions, criticism would be helpful. -Luiz From dtucker at zip.com.au Tue Nov 24 10:30:56 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 24 Nov 2009 10:30:56 +1100 Subject: Connection type variable In-Reply-To: <58805.76351.qm@web51606.mail.re2.yahoo.com> References: <58805.76351.qm@web51606.mail.re2.yahoo.com> Message-ID: <4B0B1B30.3040806@zip.com.au> Luiz Casey wrote: > Hello, I would like to know how would I go about in using a > connection type variable with the sshd_config. [...] > Where "sftp/ssh" would be used if the connection is regular ssh > connection or sftp. So ChrootDirectory/ForceCommand would only be used > if the connection matches that variable. I don't understand what you mean by "connection type" or "variable" here. Could you please give an example of a connection that would match and one that would not match? -- 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.