From bana at docisland.org Mon Mar 2 21:52:30 2009 From: bana at docisland.org (Xavier Lapie) Date: Mon, 2 Mar 2009 11:52:30 +0100 Subject: About setpcred() and chroot() Message-ID: <20090302105230.GF14491@saje3.Docisland.org> Hi, I need to use sftp-only accounts, chroot()ed in their home dirs, on AIX 5.3 with OpenSSH_5.2p1. But there is a problem with the chroot() call. In the do_setusercontext() function, chroot() is called after the setpcred() (only AIX is concerned by the setpcred() call), so privileges are already dropped when chroot() is called. When not calling setpcred(), the chroot() does not fail and the privileges are dropped anyway within the permanently_set_uid() call, just after the safely_chroot() call. Is the setpcred() really usefull ? If so, is it called at the right time ? Best Regards. -- Xavier From sfandino at yahoo.com Thu Mar 5 00:13:01 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Wed, 04 Mar 2009 14:13:01 +0100 Subject: [PATCH] accept SOCKS request over the mux socket Message-ID: Hi, The attached patch extends the mux listener to accept SOCKS requests in addition to the native mux commands. The rationale behind is that creating tunnels attached to TCP ports is a security hazard in multi-user machines where there is no way to control who connects through the tunnels. On the other hand, The mux UNIX domain socket binds to the file system and regular permissions can be used for access control. I have also created a small Perl script "snc", similar to netcat, that uses this new feature. In the end, if this patch gets accepted, my idea is to extend my Perl module Net::OpenSSH to use it. Under the hood, the code I have added just looks at the first byte coming from the mux connection. When it is a mux command, it corresponds to the first byte for the packet length encoded as a 32bits integer in network order and so, it is 0 (packet length is limited to 256KB). When it is a SOCKS connection the first byte is 4 or 5 so we can easyly distinguish both protocols. I know it is somewhat hacky, but the alternatives I see are: 1) to use a dedicated socket for the SOCKS proxy 2) to extend the mux "protocol" with new commands offering equivalent functionality. I don't like (1) because, IMO, it would unnecessarily complicate ssh usage. I don't like (2) because adapting a SOCKS client to use a UNIX socket instead of a TCP one, should be much easier than implementing a new protocol. Cheers, - Salva -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-muxsocks-1.patch Type: text/x-patch Size: 3669 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090304/11d9d6ba/attachment.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: snc Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090304/11d9d6ba/attachment.ksh From vinschen at redhat.com Thu Mar 5 00:32:35 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 4 Mar 2009 14:32:35 +0100 Subject: An old new idea, and a Cygwin patch (was Re: Call for testing: openssh-5.2) In-Reply-To: <20090225162218.GM18319@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> <20090225162218.GM18319@calimero.vinschen.de> Message-ID: <20090304133235.GD10046@calimero.vinschen.de> Ping? On Feb 25 17:22, Corinna Vinschen wrote: > On Feb 17 08:11, Damien Miller wrote: > > On Mon, 16 Feb 2009, Corinna Vinschen wrote: > > > On Feb 16 15:32, Damien Miller wrote: > > > > OpenSSH 5.2 is almost ready for release, [...] > > > > > > Builds and runs fine on Cygwin 1.7. Since I won't support any new > > > OpenSSH package for Cygwin 1.5, and since Cygwin 1.7 will stop > > > supporting Windows 9x, I'm wondering if it's ok to strip all Windows 9x > > > support, as well as the *really* old Cygwin version considerations from > > > OpenSSH at this point. It will strip some extra Cygwin-only code from > > > portable SSH. Or, maybe we should do that right after the 5.2p1 release? > > > > Yes, we can do this after the release of 5.2p1. > > Below is the patch to remove support for Windows 95/98/Me as well > as support for very old versions of Cygwin. Please apply. > > What's still missing in the upstream sources is code which abstracts the > idea of the root user to the idea of a user with certain privileges. > Cygwin/Windows is not the only platform which has the capability to give > finer grained user rights to a user, so that certain types of tasks are > not necessarily run by the root user. Given that, the hardcoded checks > for uid == 0 don't make sense in many environments. To reiterate an > idea I'm proposing for quite some time now: > > Instead of checks as > > if (getuid() == 0) > do_foo_bar (); > else > EEEEK! > > openssh should have checks along the lines of > > if (uid_has_capability (getuid (), CAP_foo_bar)) > do_foo_bar (); > else > EEEEK! > > The function uid_has_capability() would be quite simple on systems > which don't have fine-grained user rights: > > int > uid_has_capability (uid_t uid, int capability) > { > return uid == 0; > } > > but could be much more elaborate on other platforms like Linux, Solaris, > or Cygwin. And, again, I'm willing to help with this stuff in terms of > coding. > > > Corinna > > > Index: auth-passwd.c > =================================================================== > RCS file: /cvs/openssh/auth-passwd.c,v > retrieving revision 1.89 > diff -u -p -r1.89 auth-passwd.c > --- auth-passwd.c 26 Oct 2007 04:25:12 -0000 1.89 > +++ auth-passwd.c 25 Feb 2009 16:06:53 -0000 > @@ -102,7 +102,7 @@ auth_password(Authctxt *authctxt, const > } > #endif > #ifdef HAVE_CYGWIN > - if (is_winnt) { > + { > HANDLE hToken = cygwin_logon_user(pw, password); > > if (hToken == INVALID_HANDLE_VALUE) > Index: auth1.c > =================================================================== > RCS file: /cvs/openssh/auth1.c,v > retrieving revision 1.124 > diff -u -p -r1.124 auth1.c > --- auth1.c 9 Jul 2008 10:54:05 -0000 1.124 > +++ auth1.c 25 Feb 2009 16:06:53 -0000 > @@ -318,15 +318,7 @@ do_authloop(Authctxt *authctxt) > } > #endif /* _UNICOS */ > > -#ifdef HAVE_CYGWIN > - if (authenticated && > - !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD, > - authctxt->pw)) { > - packet_disconnect("Authentication rejected for uid %d.", > - authctxt->pw == NULL ? -1 : authctxt->pw->pw_uid); > - authenticated = 0; > - } > -#else > +#ifndef HAVE_CYGWIN > /* Special handling for root */ > if (authenticated && authctxt->pw->pw_uid == 0 && > !auth_root_allowed(meth->name)) { > Index: auth2-kbdint.c > =================================================================== > RCS file: /cvs/openssh/auth2-kbdint.c,v > retrieving revision 1.7 > diff -u -p -r1.7 auth2-kbdint.c > --- auth2-kbdint.c 1 Sep 2006 05:38:36 -0000 1.7 > +++ auth2-kbdint.c 25 Feb 2009 16:06:53 -0000 > @@ -58,10 +58,6 @@ userauth_kbdint(Authctxt *authctxt) > > xfree(devs); > xfree(lang); > -#ifdef HAVE_CYGWIN > - if (check_nt_auth(0, authctxt->pw) == 0) > - authenticated = 0; > -#endif > return authenticated; > } > > Index: auth2-none.c > =================================================================== > RCS file: /cvs/openssh/auth2-none.c,v > retrieving revision 1.19 > diff -u -p -r1.19 auth2-none.c > --- auth2-none.c 2 Jul 2008 12:56:09 -0000 1.19 > +++ auth2-none.c 25 Feb 2009 16:06:53 -0000 > @@ -61,10 +61,6 @@ userauth_none(Authctxt *authctxt) > { > none_enabled = 0; > packet_check_eom(); > -#ifdef HAVE_CYGWIN > - if (check_nt_auth(1, authctxt->pw) == 0) > - return (0); > -#endif > if (options.password_authentication) > return (PRIVSEP(auth_password(authctxt, ""))); > return (0); > Index: auth2-passwd.c > =================================================================== > RCS file: /cvs/openssh/auth2-passwd.c,v > retrieving revision 1.11 > diff -u -p -r1.11 auth2-passwd.c > --- auth2-passwd.c 5 Aug 2006 02:39:39 -0000 1.11 > +++ auth2-passwd.c 25 Feb 2009 16:06:53 -0000 > @@ -68,10 +68,6 @@ userauth_passwd(Authctxt *authctxt) > logit("password change not supported"); > else if (PRIVSEP(auth_password(authctxt, password)) == 1) > authenticated = 1; > -#ifdef HAVE_CYGWIN > - if (check_nt_auth(1, authctxt->pw) == 0) > - authenticated = 0; > -#endif > memset(password, 0, len); > xfree(password); > return authenticated; > Index: auth2-pubkey.c > =================================================================== > RCS file: /cvs/openssh/auth2-pubkey.c,v > retrieving revision 1.20 > diff -u -p -r1.20 auth2-pubkey.c > --- auth2-pubkey.c 4 Jul 2008 02:54:25 -0000 1.20 > +++ auth2-pubkey.c 25 Feb 2009 16:06:53 -0000 > @@ -170,10 +170,6 @@ done: > key_free(key); > xfree(pkalg); > xfree(pkblob); > -#ifdef HAVE_CYGWIN > - if (check_nt_auth(0, authctxt->pw) == 0) > - authenticated = 0; > -#endif > return authenticated; > } > > Index: session.c > =================================================================== > RCS file: /cvs/openssh/session.c,v > retrieving revision 1.380 > diff -u -p -r1.380 session.c > --- session.c 28 Jan 2009 05:29:49 -0000 1.380 > +++ session.c 25 Feb 2009 16:06:54 -0000 > @@ -571,8 +571,7 @@ do_exec_no_pty(Session *s, const char *c > signal(WJSIGNAL, cray_job_termination_handler); > #endif /* _UNICOS */ > #ifdef HAVE_CYGWIN > - if (is_winnt) > - cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); > + cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); > #endif > > s->pid = pid; > @@ -726,8 +725,7 @@ do_exec_pty(Session *s, const char *comm > signal(WJSIGNAL, cray_job_termination_handler); > #endif /* _UNICOS */ > #ifdef HAVE_CYGWIN > - if (is_winnt) > - cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); > + cygwin_set_impersonation_token(INVALID_HANDLE_VALUE); > #endif > > s->pid = pid; > @@ -1116,7 +1114,7 @@ do_setup_env(Session *s, const char *she > u_int i, envsize; > char **env, *laddr; > struct passwd *pw = s->pw; > -#ifndef HAVE_LOGIN_CAP > +#if !defined (HAVE_LOGIN_CAP) && !defined (HAVE_CYGWIN) > char *path = NULL; > #endif > > @@ -1551,9 +1549,6 @@ do_setusercontext(struct passwd *pw) > #endif > } > > -#ifdef HAVE_CYGWIN > - if (is_winnt) > -#endif > if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid) > fatal("Failed to set uids to %u.", (u_int) pw->pw_uid); > > Index: openbsd-compat/bsd-cygwin_util.c > =================================================================== > RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v > retrieving revision 1.20 > diff -u -p -r1.20 bsd-cygwin_util.c > --- openbsd-compat/bsd-cygwin_util.c 17 Jul 2008 09:03:49 -0000 1.20 > +++ openbsd-compat/bsd-cygwin_util.c 25 Feb 2009 16:06:54 -0000 > @@ -39,9 +39,6 @@ > #endif > > #include > -#include > -#include > -#include > > #include > #include > @@ -49,11 +46,6 @@ > #include > > #include "xmalloc.h" > -#define is_winnt (GetVersion() < 0x80000000) > - > -#define ntsec_on(c) ((c) && strstr((c),"ntsec") && !strstr((c),"nontsec")) > -#define ntsec_off(c) ((c) && strstr((c),"nontsec")) > -#define ntea_on(c) ((c) && strstr((c),"ntea") && !strstr((c),"nontea")) > > int > binary_open(const char *filename, int flags, ...) > @@ -79,126 +71,10 @@ binary_pipe(int fd[2]) > return (ret); > } > > -#define HAS_CREATE_TOKEN 1 > -#define HAS_NTSEC_BY_DEFAULT 2 > -#define HAS_CREATE_TOKEN_WO_NTSEC 3 > - > -static int > -has_capability(int what) > -{ > - static int inited; > - static int has_create_token; > - static int has_ntsec_by_default; > - static int has_create_token_wo_ntsec; > - > - /* > - * has_capability() basically calls uname() and checks if > - * specific capabilities of Cygwin can be evaluated from that. > - * This simplifies the calling functions which only have to ask > - * for a capability using has_capability() instead of having > - * to figure that out by themselves. > - */ > - if (!inited) { > - struct utsname uts; > - > - if (!uname(&uts)) { > - int major_high = 0, major_low = 0, minor = 0; > - int api_major_version = 0, api_minor_version = 0; > - char *c; > - > - sscanf(uts.release, "%d.%d.%d", &major_high, > - &major_low, &minor); > - if ((c = strchr(uts.release, '(')) != NULL) { > - sscanf(c + 1, "%d.%d", &api_major_version, > - &api_minor_version); > - } > - if (major_high > 1 || > - (major_high == 1 && (major_low > 3 || > - (major_low == 3 && minor >= 2)))) > - has_create_token = 1; > - if (api_major_version > 0 || api_minor_version >= 56) > - has_ntsec_by_default = 1; > - if (major_high > 1 || > - (major_high == 1 && major_low >= 5)) > - has_create_token_wo_ntsec = 1; > - inited = 1; > - } > - } > - switch (what) { > - case HAS_CREATE_TOKEN: > - return (has_create_token); > - case HAS_NTSEC_BY_DEFAULT: > - return (has_ntsec_by_default); > - case HAS_CREATE_TOKEN_WO_NTSEC: > - return (has_create_token_wo_ntsec); > - } > - return (0); > -} > - > -int > -check_nt_auth(int pwd_authenticated, struct passwd *pw) > -{ > - /* > - * The only authentication which is able to change the user > - * context on NT systems is the password authentication. So > - * we deny all requsts for changing the user context if another > - * authentication method is used. > - * > - * This doesn't apply to Cygwin versions >= 1.3.2 anymore which > - * uses the undocumented NtCreateToken() call to create a user > - * token if the process has the appropriate privileges and if > - * CYGWIN ntsec setting is on. > - */ > - static int has_create_token = -1; > - > - if (pw == NULL) > - return 0; > - if (is_winnt) { > - if (has_create_token < 0) { > - char *cygwin = getenv("CYGWIN"); > - > - has_create_token = 0; > - if (has_capability(HAS_CREATE_TOKEN) && > - (ntsec_on(cygwin) || > - (has_capability(HAS_NTSEC_BY_DEFAULT) && > - !ntsec_off(cygwin)) || > - has_capability(HAS_CREATE_TOKEN_WO_NTSEC))) > - has_create_token = 1; > - } > - if (has_create_token < 1 && > - !pwd_authenticated && geteuid() != pw->pw_uid) > - return (0); > - } > - return (1); > -} > - > int > check_ntsec(const char *filename) > { > return (pathconf(filename, _PC_POSIX_PERMISSIONS)); > -} > - > -void > -register_9x_service(void) > -{ > - HINSTANCE kerneldll; > - DWORD (*RegisterServiceProcess)(DWORD, DWORD); > - > - /* The service register mechanism in 9x/Me is pretty different from > - * NT/2K/XP. In NT/2K/XP we're using a special service starter > - * application to register and control sshd as service. This method > - * doesn't play nicely with 9x/Me. For that reason we register here > - * as service when running under 9x/Me. This function is only called > - * by the child sshd when it's going to daemonize. > - */ > - if (is_winnt) > - return; > - if (!(kerneldll = LoadLibrary("KERNEL32.DLL"))) > - return; > - if (!(RegisterServiceProcess = (DWORD (*)(DWORD, DWORD)) > - GetProcAddress(kerneldll, "RegisterServiceProcess"))) > - return; > - RegisterServiceProcess(0, 1); > } > > #define NL(x) x, (sizeof (x) - 1) > Index: openbsd-compat/daemon.c > =================================================================== > RCS file: /cvs/openssh/openbsd-compat/daemon.c,v > retrieving revision 1.9 > diff -u -p -r1.9 daemon.c > --- openbsd-compat/daemon.c 2 Aug 2006 13:33:55 -0000 1.9 > +++ openbsd-compat/daemon.c 25 Feb 2009 16:06:54 -0000 > @@ -57,18 +57,8 @@ daemon(int nochdir, int noclose) > case -1: > return (-1); > case 0: > -#ifdef HAVE_CYGWIN > - register_9x_service(); > -#endif > break; > default: > -#ifdef HAVE_CYGWIN > - /* > - * This sleep avoids a race condition which kills the > - * child process if parent is started by a NT/W2K service. > - */ > - sleep(1); > -#endif > _exit(0); > } > > > -- > Corinna Vinschen > Cygwin Project Co-Leader > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From Adam.Jaber.ctr at dla.mil Thu Mar 5 08:34:40 2009 From: Adam.Jaber.ctr at dla.mil (Jaber, Adam M CTR DLA J6UIA) Date: Wed, 4 Mar 2009 13:34:40 -0800 Subject: Zlib.h error Message-ID: <6BFE84EEF46EA1489AABF128D9C4FBCCCAC550@SCK0SGEM002.AD.DLA.MIL> Hello, I am having trouble configuring my openssh 5.2p1 install. I keep getting "configure: error: *** zlib.h missing - please install first or check config.log* ". I updated and installed the correct version of ZLIB needed from the prereq. Can you please help me? Thank you, Adam Jaber -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5011 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090304/a6b9312e/attachment-0001.bin From scott_n at xypro.com Thu Mar 5 10:43:43 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Wed, 4 Mar 2009 15:43:43 -0800 Subject: Yet another "none" request Message-ID: <78DD71C304F38B41885A242996B96F7301C21AFB@xyservd.XYPRO-23.LOCAL> Does anyone have a patch (doesn't have to be official) to enable the "none" cipher? I need to examine some wire protocol stuff ---- Scott Neugroschl XYPRO Technologies scott_n at xypro.com 805-583-2874 x133 From djm at mindrot.org Fri Mar 6 01:01:58 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 6 Mar 2009 01:01:58 +1100 (EST) Subject: Yet another "none" request In-Reply-To: <78DD71C304F38B41885A242996B96F7301C21AFB@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F7301C21AFB@xyservd.XYPRO-23.LOCAL> Message-ID: On Wed, 4 Mar 2009, Scott Neugroschl wrote: > Does anyone have a patch (doesn't have to be official) to enable the > "none" cipher? I need to examine some wire protocol stuff I'd suggest defining PACKET_DEBUG for this. Note that it deliberately prints to stderr, rather than via logit() and friends, to avoid sensitive things ending up in syslog. -d From djm at mindrot.org Fri Mar 6 01:05:01 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 6 Mar 2009 01:05:01 +1100 (EST) Subject: autoconf-2.62 Message-ID: Hi, I'm switching the snapshot builds to use autoconf-2.62 to generate configure (from autoconf-2.61). Please report any problems. -d From hjehren at linux-magazine.com Fri Mar 6 01:14:53 2009 From: hjehren at linux-magazine.com (=?UTF-8?B?SGFucy1Kw7ZyZyBFaHJlbiAvIExpbnV4IE1hZ2F6aW5l?=) Date: Thu, 05 Mar 2009 15:14:53 +0100 Subject: OpenSSH logo in hi-res, suitable for printing? Message-ID: <20090305141455.3D738303026D@mail.linux-new-media.de> Hi, My name is Hans, I'm the product manager for Linux Magazine, http://www.linux-magazine.com. We'd like to illustrate a news item on OpenSSH 5.2 with the official logo. Would it be possible for you to provide us with a hi-res version, suitable for printing? Could you send this to me ASAP? (Our print date is already Monday, Mar 9th) Thank you very much for your help! Kind regards, Hans -- Hans-J?rg Ehren Product Manager, Linux Magazine Linux New Media AG Phone: +49 89 9934 1161 Putzbrunner Str. 71 Fax: +49 89 9934 1199 81739 Munich, Germany http://www.linux-magazine.com Linux New Media Lawrence - M?laga - Manchester - The Pulse of Linux Munich - S?o Paulo - Warszawa --------------------------------------------------------------- Headquarters: Putzbrunner Str. 71, 81739 Munich, Germany Corporate ID: HRB 129161, Amtsgericht M?nchen Officers: Brian Osborn, Hermann Plank Chairman: Rudolf Strobl From tim at multitalents.net Fri Mar 6 02:54:00 2009 From: tim at multitalents.net (Tim Rice) Date: Thu, 5 Mar 2009 07:54:00 -0800 (PST) Subject: autoconf-2.62 In-Reply-To: References: Message-ID: On Fri, 6 Mar 2009, Damien Miller wrote: > Hi, > > I'm switching the snapshot builds to use autoconf-2.62 to generate > configure (from autoconf-2.61). Please report any problems. How about going to 2.63? autoconf-2.62 has some problems with here documents on UnixWare. > > -d -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From openssh at roumenpetrov.info Fri Mar 6 06:37:49 2009 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 05 Mar 2009 21:37:49 +0200 Subject: autoconf-2.62 In-Reply-To: References: Message-ID: <49B02A0D.8080206@roumenpetrov.info> Tim Rice wrote: > On Fri, 6 Mar 2009, Damien Miller wrote: > >> Hi, >> >> I'm switching the snapshot builds to use autoconf-2.62 to generate >> configure (from autoconf-2.61). Please report any problems. > > How about going to 2.63? > autoconf-2.62 has some problems with here documents on UnixWare. > >> -d Autoconf v2.63 announce list fixes for regression bugs introduced in 2.62. One vote more for 2.63. Roumen From djm at mindrot.org Fri Mar 6 12:09:11 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 6 Mar 2009 12:09:11 +1100 (EST) Subject: autoconf-2.62 In-Reply-To: <49B02A0D.8080206@roumenpetrov.info> References: <49B02A0D.8080206@roumenpetrov.info> Message-ID: On Thu, 5 Mar 2009, Roumen Petrov wrote: > Tim Rice wrote: > > On Fri, 6 Mar 2009, Damien Miller wrote: > > > >> Hi, > >> > >> I'm switching the snapshot builds to use autoconf-2.62 to generate > >> configure (from autoconf-2.61). Please report any problems. > > > > How about going to 2.63? > > autoconf-2.62 has some problems with here documents on UnixWare. > > Autoconf v2.63 announce list fixes for regression bugs introduced in 2.62. > One vote more for 2.63. Ok, I'll keep it at 2.61 until there is an openbsd package for 2.63 (I wasn't aware of its existence). -d From adrya1984 at gmail.com Fri Mar 6 20:36:39 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Fri, 6 Mar 2009 11:36:39 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates In-Reply-To: <4983710A.4020804@roumenpetrov.info> References: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> <4950B162.6000107@roumenpetrov.info> <496c8fcc0901280322g1db0aa29j55dc77b638b97fda@mail.gmail.com> <4980CA4C.5060900@roumenpetrov.info> <496c8fcc0901282358g57467b88mb2a578ba40c0fa32@mail.gmail.com> <498203DF.1080003@roumenpetrov.info> <496c8fcc0901300426uf87bbc4h97d482732e578c58@mail.gmail.com> <4983710A.4020804@roumenpetrov.info> Message-ID: <496c8fcc0903060136g344f2de3g84adbe3b5db7bd90@mail.gmail.com> Hi all, We patched it on cygwin and got executables to run, but when I try to connect to server I got the following from client: Debug3: ssh_x509cert_check: for ?c=ME,ST=ME,L=ME,O=Internet Widgits Pty Ltd? ssh_x509store_cb: subject=?c=ME,ST=ME,L=ME,O=Internet Widgits Pty Ltd?, error 20 at 0 depth lookup:unable to get local issuer certificate Ssh_verify_cert: verify error, code=20, msg=? unable to get local issuer certificate? I run executable under Windows with cygwin dlls in same folder. Thank you, Adriana. From openssh at roumenpetrov.info Sun Mar 8 07:49:31 2009 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 07 Mar 2009 22:49:31 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates In-Reply-To: <496c8fcc0903060136g344f2de3g84adbe3b5db7bd90@mail.gmail.com> References: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> <4950B162.6000107@roumenpetrov.info> <496c8fcc0901280322g1db0aa29j55dc77b638b97fda@mail.gmail.com> <4980CA4C.5060900@roumenpetrov.info> <496c8fcc0901282358g57467b88mb2a578ba40c0fa32@mail.gmail.com> <498203DF.1080003@roumenpetrov.info> <496c8fcc0901300426uf87bbc4h97d482732e578c58@mail.gmail.com> <4983710A.4020804@roumenpetrov.info> <496c8fcc0903060136g344f2de3g84adbe3b5db7bd90@mail.gmail.com> Message-ID: <49B2DDDB.3050109@roumenpetrov.info> Hi Adriana , Adriana Rodean wrote: > Hi all, > > We patched it on cygwin and got executables to run, but when I try to > connect to server I got the following from client: > > > > Debug3: ssh_x509cert_check: for ?c=ME,ST=ME,L=ME,O=Internet Widgits Pty Ltd? > > ssh_x509store_cb: subject=?c=ME,ST=ME,L=ME,O=Internet Widgits Pty Ltd?, error > > 20 at 0 depth lookup:unable to get local issuer certificate > > Ssh_verify_cert: verify error, code=20, msg=? unable to get local > issuer certificate? > > I run executable under Windows with cygwin dlls in same folder. > > Thank you, > Adriana. To verify server certificate you need "trust certificate chain". See ssh_config manual page for "x509_store" optionslike CACertificateFile and CACertificatePath and also UserCACertificateFile and UserCACertificatePath. You could check openssh x509 store with openssl command: $ openssl --verify [-CApath directory] [-CAfile file] certificate In you case openssl arguments -CApath -CAfile correspond to openssh config options {|User}CACertificatePath {|User}CACertificateFile and certificate is you server certificate. Roumen From yaniv at aknin.name Sun Mar 8 16:55:43 2009 From: yaniv at aknin.name (Yaniv Aknin) Date: Sun, 8 Mar 2009 07:55:43 +0200 Subject: OpenSSH with 'none' cipher (after reading bug #877) In-Reply-To: <200902261850.27409.luciano@debian.org> References: <200902261850.27409.luciano@debian.org> Message-ID: Sorry for the delayed reply. I gather the list's silence on this matter amounts to telling me to shut up and go implement it myself on my own branch of the source? (ah, the horror...). Luciano, as for your suggestion of private exponent on the sniffer: this is technically possible, but much more cumbersome, not supported by all sniffers, requires special code to parse / decrypt / store sniffed packets with the like of libpcap rather than just use a socket and get a plain TCP stream, etc. To add insult to injury, due to architectural reasons I use two and rarely three ssh sessions, tunneled one inside the other (I can explain why, though it isn't very interesting, honest) - if the previous description was cumbersome, think about it done two/three levels deep. - Yaniv On Thu, Feb 26, 2009 at 10:50 PM, Luciano Bello wrote: > El Jue 26 Feb 2009, Yaniv Aknin escribi?: > > However, It seems that a solution I'm implementing may require cleartext > > transport due to regulation / auditing compliance reasons. Turns out that > > the government suits of some countries mandated that some institutions > are > > required to keep a cleartext copy of all communications ever sent from > their > > premises for a while, and I can't use my SSH based solution for these > > customers (Please, I don't want to argue about whether it's a good or a > bad > > idea). > > What about put a copy of the sshd's private exponent in the sniffer/auditor > machine? Whit this, the auditor can recalculate the share secret and > decipher the communication. Of course, this broke PFS in DHE but looks like > a better solution than just use plain text. > > luciano > > PD: I'm in favor of implement 'none' cipher but with the 'performance' > reasons. > From tiagomnm at gmail.com Mon Mar 9 02:42:46 2009 From: tiagomnm at gmail.com (Tiago Marques) Date: Sun, 8 Mar 2009 15:42:46 +0000 Subject: Disabling specific port-forwarding Message-ID: On 25 Fev, 14:59, pe... at stuge.se (Peter Stuge) wrote: > Tiago Marques wrote: > > What can I do? I want to open all ports to some users but limit > > some for the rest(3-4 different user accounts). > > One way is to use permitopen= in authorized_keys. Then you even get a > setting per key. AFAIK, this is done in the user accounts authorized_keys file and, hence, not secure. >From what I've read on the web, I need to set the immutable flag on the file, so it is secure. Can't this be done in a better way? Best regards, Tiago Marques > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-... at mindrot.orghttps:// lists.mindrot.org/mailman/listinfo/openssh-unix-dev From john at foseda.com Mon Mar 9 05:57:13 2009 From: john at foseda.com (John Griessen) Date: Sun, 08 Mar 2009 13:57:13 -0500 Subject: question on using keys Message-ID: <49B41509.9020708@foseda.com> I've read man ssh and man ssh-keygen and some howtos and still am not getting what I expect. I can do ssh john at 192.168.15.3 and login with a password OK. I want to be able to do that with keys in preparation for running rsync with keys, so I created a key on router1, the machine I want to ssh from. routem at router1:~/.ssh$ lla total 20 drwx------ 2 routem routem 4096 2009-03-08 09:55 . drwxr-xr-x 5 routem routem 4096 2009-03-08 13:41 .. -rw------- 1 routem routem 1675 2009-03-07 12:02 id_rsync_rsa -rw-r--r-- 1 routem routem 397 2009-03-07 12:02 id_rsync_rsa.pub -rw-r--r-- 1 routem routem 650 2009-03-08 09:56 known_hosts I used scp to copy id_rsync_rsa.pub over to 192.168.15.3:/home/john/.ssh john at toolbench:~/.ssh$ lla total 60 drwx------ 2 john cibolo 4096 2009-03-08 09:54 . drwxrwxr-x 162 john cibolo 12288 2009-03-08 11:47 .. -rw-r--r-- 1 john john 4096 2005-11-26 09:26 .known_hosts.swo -rw------- 1 john john 963 2006-10-15 13:26 IDENTITY -rw-r--r-- 1 john john 963 2006-10-15 13:26 IDENTITY.cibolo -rw------- 1 john john 397 2009-03-07 15:04 authorized_keys2 Now I try the below command: ssh -2 -vvv -i "/home/routem/.ssh/id_rsync_rsa" john at 192.168.15.3 It comes to problems right away: OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug3: key names ok: [ssh-dss,ssh-rsa] debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.15.3 [192.168.15.3] port 22. debug1: Connection established. debug3: Not a RSA1 key file /home/routem/.ssh/id_rsync_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace My ssh-config on both machines is default plus these lines: Protocol 2,1 HostKeyAlgorithms ssh-dss,ssh-rsa after the above wrong looking log lines this also looks suspicious: debug2: key: /home/routem/.ssh/id_rsync_rsa (0x7007dae0) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/routem/.ssh/id_rsync_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password it drops to password and that will work if entered. Any hints appreciated. John Griessen From peter at stuge.se Mon Mar 9 07:06:57 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 8 Mar 2009 21:06:57 +0100 Subject: question on using keys In-Reply-To: <49B41509.9020708@foseda.com> References: <49B41509.9020708@foseda.com> Message-ID: <20090308200657.30028.qmail@stuge.se> John Griessen wrote: .. > -rw------- 1 john john 397 2009-03-07 15:04 authorized_keys2 Rename this to authorized_keys and it should work. authorized_keys2 is a very old filename that recent versions of OpenSSH do not use anymore. > debug3: Not a RSA1 key file /home/routem/.ssh/id_rsync_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace This is as expected. The file is an RSA key file for use with SSH protocol version 2. > after the above wrong looking log lines this also looks suspicious: > > debug2: key: /home/routem/.ssh/id_rsync_rsa (0x7007dae0) This is also as expected. ssh has now loaded your key. Keyfile handling was unified so that the user does not have to say which type of key each file contains. The flip side is that there will always be an error message. //Peter From john at foseda.com Mon Mar 9 07:37:34 2009 From: john at foseda.com (John Griessen) Date: Sun, 08 Mar 2009 15:37:34 -0500 Subject: question on using keys In-Reply-To: <20090308200657.30028.qmail@stuge.se> References: <49B41509.9020708@foseda.com> <20090308200657.30028.qmail@stuge.se> Message-ID: <49B42C8E.9030005@foseda.com> Peter Stuge wrote: >> debug2: key: /home/routem/.ssh/id_rsync_rsa (0x7007dae0) > > This is also as expected. ssh has now loaded your key. > > > Keyfile handling was unified so that the user does not have to say > which type of key each file contains. The flip side is that there > will always be an error message. Thanks, Still not working. I have a keyfile id_rsync_rsa.pub that starts with ssh-rsa and a keyfile id_rsync_rsa that starts with -----BEGIN RSA PRIVATE KEY---- on the first machine. in .ssh of 2nd machine I moved authorized_keys2 to authorized_keys john at toolbench:~/.ssh$ lla total 40 drwx------ 2 john cibolo 4096 2009-03-08 15:30 . drwxrwxr-x 162 john cibolo 12288 2009-03-08 15:25 .. -rw------- 1 john john 963 2006-10-15 13:26 IDENTITY -rw-r--r-- 1 john john 963 2006-10-15 13:26 IDENTITY.cibolo -rw------- 1 john john 397 2009-03-07 15:04 authorized_keys Here's the debug output now: debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/routem/.ssh/id_rsync_rsa (0x7007dae0) debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey jg] looks good.... debug1: Next authentication method: publickey debug1: Offering public key: /home/routem/.ssh/id_rsync_rsa jg] above is naem of priv key.... debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method jg] above doesn't jive with previous "we sent a publickey packet" why? debug3: authmethod_lookup password drops to password method.... John Griessen From djm at mindrot.org Mon Mar 9 07:42:52 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Mar 2009 07:42:52 +1100 (EST) Subject: Disabling specific port-forwarding In-Reply-To: References: Message-ID: On Sun, 8 Mar 2009, Tiago Marques wrote: > On 25 Fev, 14:59, pe... at stuge.se (Peter Stuge) wrote: > > Tiago Marques wrote: > > > What can I do? I want to open all ports to some users but limit > > > some for the rest(3-4 different user accounts). > > > > One way is to use permitopen= in authorized_keys. Then you even get > >a > > > setting per key. > > AFAIK, this is done in the user accounts authorized_keys file and, > hence, not secure. > > >From what I've read on the web, I need to set the immutable flag on > the file, so it is secure. Can't this be done in a better way? PermitOpen is supported in sshd_config for a few releases now. -d From peter at stuge.se Mon Mar 9 08:25:14 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 8 Mar 2009 22:25:14 +0100 Subject: question on using keys In-Reply-To: <49B42C8E.9030005@foseda.com> References: <49B41509.9020708@foseda.com> <20090308200657.30028.qmail@stuge.se> <49B42C8E.9030005@foseda.com> Message-ID: <20090308212514.20641.qmail@stuge.se> John Griessen wrote: > john at toolbench:~/.ssh$ lla > total 40 > drwx------ 2 john cibolo 4096 2009-03-08 15:30 . > drwxrwxr-x 162 john cibolo 12288 2009-03-08 15:25 .. I didn't notice this before. You'll need to chmod g-w ~john //Peter From djm at mindrot.org Mon Mar 9 09:11:32 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Mar 2009 09:11:32 +1100 (EST) Subject: question on using keys In-Reply-To: <20090308200657.30028.qmail@stuge.se> References: <49B41509.9020708@foseda.com> <20090308200657.30028.qmail@stuge.se> Message-ID: On Sun, 8 Mar 2009, Peter Stuge wrote: > John Griessen wrote: > .. > > -rw------- 1 john john 397 2009-03-07 15:04 authorized_keys2 > > Rename this to authorized_keys and it should work. authorized_keys2 > is a very old filename that recent versions of OpenSSH do not use > anymore. authorized_keys2 is still checked. -d From tiagomnm at gmail.com Mon Mar 9 09:35:46 2009 From: tiagomnm at gmail.com (Tiago Marques) Date: Sun, 8 Mar 2009 22:35:46 +0000 Subject: Disabling specific port-forwarding In-Reply-To: References: Message-ID: On a per user basis also? I need per-user permitopen. Best regards, Tiago Marques On Sun, Mar 8, 2009 at 8:42 PM, Damien Miller wrote: > On Sun, 8 Mar 2009, Tiago Marques wrote: > > > On 25 Fev, 14:59, pe... at stuge.se (Peter Stuge) wrote: > > > Tiago Marques wrote: > > > > What can I do? I want to open all ports to some users but limit > > > > some for the rest(3-4 different user accounts). > > > > > > One way is to use permitopen= in authorized_keys. Then you even get > > >a > > > > > setting per key. > > > > AFAIK, this is done in the user accounts authorized_keys file and, > > hence, not secure. > > > > >From what I've read on the web, I need to set the immutable flag on > > the file, so it is secure. Can't this be done in a better way? > > PermitOpen is supported in sshd_config for a few releases now. > > -d > From djm at mindrot.org Mon Mar 9 10:17:39 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Mar 2009 10:17:39 +1100 (EST) Subject: Disabling specific port-forwarding In-Reply-To: References: Message-ID: On Sun, 8 Mar 2009, Tiago Marques wrote: > On a per user basis also? I need per-user permitopen. You could always RTFM, in particular the Match keyword in sshd_config(5) -d From tiagomnm at gmail.com Mon Mar 9 10:23:43 2009 From: tiagomnm at gmail.com (Tiago Marques) Date: Sun, 8 Mar 2009 23:23:43 +0000 Subject: Disabling specific port-forwarding In-Reply-To: References: Message-ID: I RTFM and didn't found any useful information, as I didn't know where to look - messing with SSH is not something I do everyday. As I couldn't find anything useful, I posted here for help. Thanks for the input about the "Match" keyword. Best regards, Tiago Marques On Sun, Mar 8, 2009 at 11:17 PM, Damien Miller wrote: > On Sun, 8 Mar 2009, Tiago Marques wrote: > > > On a per user basis also? I need per-user permitopen. > > You could always RTFM, in particular the Match keyword in sshd_config(5) > > -d > From peter at stuge.se Mon Mar 9 10:27:13 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 9 Mar 2009 00:27:13 +0100 Subject: question on using keys In-Reply-To: References: <49B41509.9020708@foseda.com> <20090308200657.30028.qmail@stuge.se> Message-ID: <20090308232713.21282.qmail@stuge.se> Damien Miller wrote: > On Sun, 8 Mar 2009, Peter Stuge wrote: > > > -rw------- 1 john john 397 2009-03-07 15:04 authorized_keys2 > > > > Rename this to authorized_keys and it should work. authorized_keys2 > > is a very old filename that recent versions of OpenSSH do not use > > anymore. > > authorized_keys2 is still checked. Oh thanks! I was pretty sure it had gone away because I found one of these files on a system with an old OpenSSH and I renamed it as I upgraded. I was just playing it safe then. //Peter From william at 25thandClement.com Mon Mar 9 10:29:53 2009 From: william at 25thandClement.com (William Ahern) Date: Sun, 8 Mar 2009 16:29:53 -0700 Subject: Disabling specific port-forwarding In-Reply-To: References: Message-ID: <20090308232953.GA28620@wilbur.25thandClement.com> On Sun, Mar 08, 2009 at 11:23:43PM +0000, Tiago Marques wrote: > On Sun, Mar 8, 2009 at 11:17 PM, Damien Miller wrote: > > On Sun, 8 Mar 2009, Tiago Marques wrote: > > > > > On a per user basis also? I need per-user permitopen. > > > > You could always RTFM, in particular the Match keyword in sshd_config(5) > > > I RTFM and didn't found any useful information, as I didn't know where to > look - messing with SSH is not something I do everyday. > > As I couldn't find anything useful, I posted here for help. Thanks for the > input about the "Match" keyword. > http://lmgtfy.com/?q=openssh+per-user+permitopen From adrya1984 at gmail.com Tue Mar 10 16:52:30 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Tue, 10 Mar 2009 07:52:30 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates In-Reply-To: <49B2DDDB.3050109@roumenpetrov.info> References: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> <4950B162.6000107@roumenpetrov.info> <496c8fcc0901280322g1db0aa29j55dc77b638b97fda@mail.gmail.com> <4980CA4C.5060900@roumenpetrov.info> <496c8fcc0901282358g57467b88mb2a578ba40c0fa32@mail.gmail.com> <498203DF.1080003@roumenpetrov.info> <496c8fcc0901300426uf87bbc4h97d482732e578c58@mail.gmail.com> <4983710A.4020804@roumenpetrov.info> <496c8fcc0903060136g344f2de3g84adbe3b5db7bd90@mail.gmail.com> <49B2DDDB.3050109@roumenpetrov.info> Message-ID: <496c8fcc0903092252t2b33b7a3n6d8a4a36d2434424@mail.gmail.com> Hi Roumen, I fixed the certificate validation, so it return 1(trusted) now, but I still can?t go on. After everything seem to be OK, certificate validated, Client tries to authenticate with keyboard.interactive. This of course doesn?t work and connection is closed. Here is output from server (started with option -d): debug1: ssh_set_validator: ignore responder url debug1: sshd version OpenSSH_5.1p1 debug1: read PEM private key begin debug1: read X509 certificate done: type RSA+cert debug1: read PEM private key done: type RSA+cert debug1: private host key: #0 type 3 RSA+cert debug1: rexec_argv[0]='/usr/local/openssh/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on ::. Server listening on :: port 22. debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 10.3.3.10 port 1080 debug1: Client protocol version 2.0; client software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: permanently_set_uid: 1001/1001 debug1: list_hostkey_types: x509v3-sign-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user administrator service ssh-connection method none debug1: attempt 0 failures 0 debug1: userauth-request for user administrator service ssh-connection method keyboard-interactive debug1: attempt 1 failures 0 debug1: keyboard-interactive devs debug1: auth2_challenge: user=administrator devs= debug1: kbdint_alloc: devices '' Connection closed by 10.3.3.10 debug1: do_cleanup and ouput from client (started with option -v): OpenSSH_5.1p1, OpenSSL 0.9.8j 07 Jan 2009 debug1: Reading configuration data c:\\openssh\\bin\\ssh_config debug1: ssh_set_validator: ignore responder url debug1: Connecting to 10.3.3.12 [10.3.3.12] port 22. debug1: Connection established. debug1: identity file C:/OpenSSH/Certs/id_rsa type 3 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '10.3.3.12' is known and matches the RSA+cert host key. debug1: Found key in /home/Administrator.JOGE/.ssh/known_hosts:1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: keyboard-interactive debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: keyboard-interactive debug1: No more authentication methods to try. What did I miss? Thank you, Adriana. On Sat, Mar 7, 2009 at 22:49, Roumen Petrov wrote: > Hi Adriana , > Adriana Rodean wrote: >> >> Hi all, >> >> We patched it on cygwin and got executables to run, but when I try to >> connect to server I got the following from client: >> >> >> >> Debug3: ssh_x509cert_check: for ?c=ME,ST=ME,L=ME,O=Internet Widgits Pty >> Ltd? >> >> ssh_x509store_cb: subject=?c=ME,ST=ME,L=ME,O=Internet Widgits Pty Ltd?, >> error >> >> 20 at 0 depth lookup:unable to get local issuer certificate >> >> Ssh_verify_cert: verify error, code=20, msg=? unable to get local >> issuer certificate? >> >> I run executable under Windows with cygwin dlls in same folder. >> >> Thank you, >> Adriana. > > > To verify server certificate you need "trust certificate chain". > See ssh_config manual page for "x509_store" optionslike CACertificateFile > and CACertificatePath and also UserCACertificateFile and > UserCACertificatePath. > > You could check openssh x509 store with openssl command: > $ openssl --verify [-CApath directory] [-CAfile file] certificate > > In you case openssl arguments -CApath -CAfile correspond to openssh config > options {|User}CACertificatePath {|User}CACertificateFile and certificate is > you server certificate. > > Roumen > From sfandino at yahoo.com Wed Mar 11 02:47:10 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Tue, 10 Mar 2009 16:47:10 +0100 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: References: Message-ID: Hi Salvador Fandino wrote: > The attached patch extends the mux listener to accept SOCKS requests in > addition to the native mux commands. Attached to this mail you will find: - an updated version of the patch that applies against the CVS version of OpenSSH. - a patch for dsocks-1.6 (http://www.monkey.org/~dugsong/dsocks/) that adds support for connecting to the SOCKS server through an UNIX domain socket. For instance, with these patches applied, I can run: $ ssh -M -S /tmp/mux 172.20.3.12 -N -f $ LD_PRELOAD=/root/my-dsocks-1.6/libdsocks.so.1.0 \ DSOCKS_PROXY=/tmp/mux \ DSOCKS_NAMESERVER=172.20.4.17 \ lynx www.openbsd.org And browse the web without opening a local listening port on my computer. Cheers, - Salva -------------- next part -------------- A non-text attachment was scrubbed... Name: dsocks-unixsocket-0.patch Type: text/x-patch Size: 3843 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090310/5f827a85/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-muxsocks-3.patch Type: text/x-patch Size: 5692 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090310/5f827a85/attachment-0001.bin From djm at mindrot.org Wed Mar 11 11:24:33 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Mar 2009 11:24:33 +1100 (EST) Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: References: Message-ID: On Tue, 10 Mar 2009, Salvador Fandino wrote: > Hi > > Salvador Fandino wrote: > > The attached patch extends the mux listener to accept SOCKS requests in > > addition to the native mux commands. > > Attached to this mail you will find: > > - an updated version of the patch that applies against the CVS version of > OpenSSH. > > - a patch for dsocks-1.6 (http://www.monkey.org/~dugsong/dsocks/) that adds > support for connecting to the SOCKS server through an UNIX domain socket. Please create a bug on https://bugzilla.mindrot.org/ and attach your patches there so they can be tracked. Thanks, Damien From mouring at eviladmin.org Wed Mar 11 16:02:40 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 11 Mar 2009 00:02:40 -0500 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: References: Message-ID: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> On Mar 10, 2009, at 10:47 AM, Salvador Fandino wrote: > Hi > > Salvador Fandino wrote: >> The attached patch extends the mux listener to accept SOCKS >> requests in addition to the native mux commands. > > Attached to this mail you will find: > > - an updated version of the patch that applies against the CVS > version of OpenSSH. > > - a patch for dsocks-1.6 (http://www.monkey.org/~dugsong/dsocks/) > that adds support for connecting to the SOCKS server through an UNIX > domain socket. > > > For instance, with these patches applied, I can run: > > $ ssh -M -S /tmp/mux 172.20.3.12 -N -f > $ LD_PRELOAD=/root/my-dsocks-1.6/libdsocks.so.1.0 \ > DSOCKS_PROXY=/tmp/mux \ > DSOCKS_NAMESERVER=172.20.4.17 \ > lynx www.openbsd.org > > And browse the web without opening a local listening port on my > computer. > How does this differ from "ssh -D" ?? Which already makes SSH into a SOCK4/5 server? Seems like we're duplicating functionality unless there is something else I'm missing. - Ben From openssh at roumenpetrov.info Wed Mar 11 17:47:07 2009 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 11 Mar 2009 08:47:07 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates In-Reply-To: <496c8fcc0903092252t2b33b7a3n6d8a4a36d2434424@mail.gmail.com> References: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> <4950B162.6000107@roumenpetrov.info> <496c8fcc0901280322g1db0aa29j55dc77b638b97fda@mail.gmail.com> <4980CA4C.5060900@roumenpetrov.info> <496c8fcc0901282358g57467b88mb2a578ba40c0fa32@mail.gmail.com> <498203DF.1080003@roumenpetrov.info> <496c8fcc0901300426uf87bbc4h97d482732e578c58@mail.gmail.com> <4983710A.4020804@roumenpetrov.info> <496c8fcc0903060136g344f2de3g84adbe3b5db7bd90@mail.gmail.com> <49B2DDDB.3050109@roumenpetrov.info> <496c8fcc0903092252t2b33b7a3n6d8a4a36d2434424@mail.gmail.com> Message-ID: <49B75E6B.8060707@roumenpetrov.info> Adriana Rodean wrote: > Hi Roumen, > > I fixed the certificate validation, so it return 1(trusted) now, but I > still can?t go on. After everything seem to be OK, certificate > validated, > Client tries to authenticate with keyboard.interactive. This of course > doesn?t work and connection is closed. > > Here is output from server (started with option -d): > debug1: ssh_set_validator: ignore responder url > debug1: sshd version OpenSSH_5.1p1 > debug1: read PEM private key begin > debug1: read X509 certificate done: type RSA+cert > debug1: read PEM private key done: type RSA+cert > debug1: private host key: #0 type 3 RSA+cert [SNIP] > method keyboard-interactive [SNIP] > and ouput from client (started with option -v): > OpenSSH_5.1p1, OpenSSL 0.9.8j 07 Jan 2009 > debug1: Reading configuration data c:\\openssh\\bin\\ssh_config > debug1: ssh_set_validator: ignore responder url > debug1: Connecting to 10.3.3.12 [10.3.3.12] port 22. > debug1: Connection established. > debug1: identity file C:/OpenSSH/Certs/id_rsa type 3 > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1 > debug1: match: OpenSSH_5.1 pat OpenSSH* [SNIP] > debug1: Host '10.3.3.12' is known and matches the RSA+cert host key. > debug1: Found key in /home/Administrator.JOGE/.ssh/known_hosts:1 [SNIP] > debug1: Authentications that can continue: keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug1: Authentications that can continue: keyboard-interactive [SNIP] > What did I miss? Check the client option PreferredAuthentications. In you case may be is only keyboard-interactive. The default is "hostbased, publickey, keyboard-interactive, password". For certificates it has to contain publickey or hostbased. Lets start with publickey. Also check client options PubkeyAuthentication and PubkeyAlgorithms. On the server check server options PubkeyAuthentication and PubkeyAlgorithms. Initially you may left PubkeyAlgorithms as default. [SNIP] Roumen From vinschen at redhat.com Wed Mar 11 19:26:39 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 11 Mar 2009 09:26:39 +0100 Subject: Replace uid==0 tests with capability checks In-Reply-To: References: <20090216135649.GH5416@calimero.vinschen.de> Message-ID: <20090311082639.GH9322@calimero.vinschen.de> Hi, This time with it's own subject: What's still missing in OpenSSH is code which abstracts the idea of the root user to the idea of a user with certain privileges. At least Linux/Solaris/Cygwin/Windows allow to specify finer grained user rights, so that certain types of tasks are not necessarily run by the root user. In case of Cygwin/Windows there isn't even a root user, just users with certain privileges. Given that, the hardcoded checks for uid == 0 don't make sense or rather, are too bulky in a couple of environments. To reiterate an idea I'm proposing for quite some time now: Instead of checks as if (getuid() == 0) do_foo_bar (); else EEEEK! openssh should have checks along the lines of if (uid_has_capability (getuid (), CAP_foo_bar)) do_foo_bar (); else EEEEK! The function uid_has_capability() would be quite simple on systems which don't have fine-grained user rights: int uid_has_capability (uid_t uid, int capability) { return uid == 0; } but could be much more elaborate on other platforms like Linux, Solaris, or Cygwin. And, again, I'm willing to help with this stuff in terms of coding. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From sfandino at yahoo.com Wed Mar 11 19:48:37 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Wed, 11 Mar 2009 01:48:37 -0700 (PDT) Subject: [PATCH] accept SOCKS request over the mux socket References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> Message-ID: <18124.94238.qm@web52704.mail.re2.yahoo.com> hi > How does this differ from "ssh -D" ?? Which already makes SSH into a SOCK4/5 > server? > > Seems like we're duplicating functionality unless there is something else I'm > missing. Actually, I am reusing the SOCKS4/5 code. The difference is that now request are also accepted over the multiplexing UNIX socket created when ssh is run in master mode. The problem with INET sockets is that there is no way* to control who access then. Even if they are only bound to localhost, in multiuser machines, any local user can connect to them. On the other hand, access to an UNIX socket can be controlled using just file permissions, so that, for instance, only the user running ssh could connect to it. - Salva * well, unless you add authentication support to the SOCKS4/5 code, but IMO, that would be something really complex to manage and to use. From mouring at eviladmin.org Thu Mar 12 02:27:14 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 11 Mar 2009 10:27:14 -0500 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: <18124.94238.qm@web52704.mail.re2.yahoo.com> References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> Message-ID: On Mar 11, 2009, at 3:48 AM, Salvador Fandino wrote: > > hi > >> How does this differ from "ssh -D" ?? Which already makes SSH into >> a SOCK4/5 >> server? >> >> Seems like we're duplicating functionality unless there is >> something else I'm >> missing. > > Actually, I am reusing the SOCKS4/5 code. The difference is that now > request are also accepted over the multiplexing UNIX socket created > when ssh is run in master mode. > > The problem with INET sockets is that there is no way* to control > who access then. Even if they are only bound to localhost, in > multiuser machines, any local user can connect to them. > > On the other hand, access to an UNIX socket can be controlled using > just file permissions, so that, for instance, only the user running > ssh could connect to it. I'm concerned that people will become confused since -M -S combo has been resevered for multiple ssh terminal sessions over a single tunnel. I'd rather see it more clear like: ssh -D -M -S /tmp/mux 172.20.3.12 -N -f if you want multiple tunnels + SOCK support ssh -D -S /tmp/mux .. if you just want SOCKS support instead of a PORT Which means an error needs to be throw on ssh -Dxxx -S xxxx - Ben From richardtheis at yahoo.com Thu Mar 12 01:58:12 2009 From: richardtheis at yahoo.com (Richard Theis) Date: Wed, 11 Mar 2009 07:58:12 -0700 (PDT) Subject: ssh hang with ForceCommand=internal-sftp Message-ID: <794222.88104.qm@web35405.mail.mud.yahoo.com> > /usr/sbin/sshd -oForceCommand=internal-sftp > sftp user at host # This connects as expected. > ssh user at host # This hangs...at least from an end-user's perspective. It would be ideal if the connection terminated gracefully. Do others see this same behavior? If so, is there a fix or configuration change that can implemented to eliminate the hang? I'm using OpenSSH 5.0p1. Thanks, Richard From peter at stuge.se Thu Mar 12 03:34:15 2009 From: peter at stuge.se (Peter Stuge) Date: Wed, 11 Mar 2009 17:34:15 +0100 Subject: ssh hang with ForceCommand=internal-sftp In-Reply-To: <794222.88104.qm@web35405.mail.mud.yahoo.com> References: <794222.88104.qm@web35405.mail.mud.yahoo.com> Message-ID: <20090311163415.23227.qmail@stuge.se> Richard Theis wrote: > > /usr/sbin/sshd -oForceCommand=internal-sftp > > sftp user at host # This connects as expected. > > ssh user at host # This hangs...at least from an end-user's perspective. > > It would be ideal if the connection terminated gracefully. Do > others see this same behavior? If so, is there a fix or > configuration change that can implemented to eliminate the hang? > I'm using OpenSSH 5.0p1. If the server is configured to behave in an ill fashin, of course clients shall suffer. It's the job of the server admin to make sure that the server does what is intended. Now, what is actually going on here? Is the user talking to internal-sftp when invoking ssh - or does the login/shell channel request just fail? In case there is or should be a protocol failure in the ssh case - of course the client should error out. //Peter From sfandino at yahoo.com Thu Mar 12 04:41:11 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Wed, 11 Mar 2009 10:41:11 -0700 (PDT) Subject: [PATCH] accept SOCKS request over the mux socket References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> Message-ID: <864510.27419.qm@web52709.mail.re2.yahoo.com> Hi ----- Original Message ---- > From: Ben Lindstrom > To: Salvador Fandino > Cc: openssh-unix-dev at mindrot.org > Sent: Wednesday, March 11, 2009 4:27:14 PM > Subject: Re: [PATCH] accept SOCKS request over the mux socket > > I'm concerned that people will become confused since -M -S combo has been > resevered for multiple ssh terminal sessions over a single tunnel. I'd rather > see it more clear like: > > ssh -D -M -S /tmp/mux 172.20.3.12 -N -f if you want multiple tunnels + SOCK > support > ssh -D -S /tmp/mux .. if you just want SOCKS support instead of a PORT It makes sense to me, but I think that for the same reason, it would be better to use a different flag instead of -D, say -E Cheers, - Salva From mouring at eviladmin.org Thu Mar 12 05:58:28 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 11 Mar 2009 13:58:28 -0500 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: <20090311182154.GF13652@crawfish.ais.com> References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> <20090311182154.GF13652@crawfish.ais.com> Message-ID: <6DE21885-E969-4F03-960F-89FC3DA59832@eviladmin.org> On Mar 11, 2009, at 1:21 PM, Jim Knoble wrote: > Circa 2009-03-11 10:27 dixit Ben Lindstrom: > > : I'm concerned that people will become confused since -M -S combo has > : been resevered for multiple ssh terminal sessions over a single > : tunnel. I'd rather see it more clear like: > : > : ssh -D -M -S /tmp/mux 172.20.3.12 -N -f if you want multiple > tunnels > : + SOCK support > : ssh -D -S /tmp/mux .. if you just want SOCKS support instead of a > PORT > : > : Which means an error needs to be throw on > : > : ssh -Dxxx -S xxxx > > The above means that you can't separate permissions for the mux socket > and the SOCKS socket. > > Better to create a dedicated SOCKS socket, no? > > ssh -D /tmp/ssh-socks-socket ... > > That is, '-D' may accept either an IP address or a filesystem path. > Reserve '-S' for use with multiplexing sockets. This way, one can: > > ssh -D /tmp/ssh-socks-socket -M -S /tmp/ssh-mux-socket ... > > and allow more than one user to use the SOCKS connection while keeping > the mux socket more private. > > This also makes the '-D' syntax consistent and sensible. > That works for me. I just found the mutation and corruption of -M -S to be a bit dodgy when we already have a -D that is clearly tagged as being a socks4/5 server functionality flag. - Ben From jmknoble at pobox.com Thu Mar 12 05:21:54 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 11 Mar 2009 13:21:54 -0500 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> Message-ID: <20090311182154.GF13652@crawfish.ais.com> Circa 2009-03-11 10:27 dixit Ben Lindstrom: : I'm concerned that people will become confused since -M -S combo has : been resevered for multiple ssh terminal sessions over a single : tunnel. I'd rather see it more clear like: : : ssh -D -M -S /tmp/mux 172.20.3.12 -N -f if you want multiple tunnels : + SOCK support : ssh -D -S /tmp/mux .. if you just want SOCKS support instead of a PORT : : Which means an error needs to be throw on : : ssh -Dxxx -S xxxx The above means that you can't separate permissions for the mux socket and the SOCKS socket. Better to create a dedicated SOCKS socket, no? ssh -D /tmp/ssh-socks-socket ... That is, '-D' may accept either an IP address or a filesystem path. Reserve '-S' for use with multiplexing sockets. This way, one can: ssh -D /tmp/ssh-socks-socket -M -S /tmp/ssh-mux-socket ... and allow more than one user to use the SOCKS connection while keeping the mux socket more private. This also makes the '-D' syntax consistent and sensible. --jim -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) From imorgan at nas.nasa.gov Thu Mar 12 07:39:07 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 11 Mar 2009 13:39:07 -0700 Subject: Possible issue with forced commands Message-ID: <20090311203907.GA31081@linux55.nas.nasa.gov> Hi, I noticed some behaviour recently that seems a bit odd. I have a command-restricted public key that I use for checkouts from a local CVS server. If I have the command-restricted key loaded into ssh-agent and connect to the server, but authenticate via password rather than the key (to get a login session) the forced command is still applied. In other words, I get the ssh-askpass dialogue box asking if I want to use the key and select 'Cancel.' I then get a password prompt and successfully authenticate, but rather than getting a login shell I'm apparently running the cvs command. If I don't have the key loaded, I'm able to get a login session as expected. Admittedly, the server is running an older version of OpenSSH (4.3p1) and I have not verified that this behaviour exists with the current version of OpenSSH, but it seems to me that the restriction should only be applied if I actually used the key. Any thoughts? Thanks -- Iain Morgan P.S.: I'll try to test this against a more recent version shortly. From imorgan at nas.nasa.gov Thu Mar 12 09:01:15 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 11 Mar 2009 15:01:15 -0700 Subject: Possible issue with forced commands In-Reply-To: <20090311203907.GA31081@linux55.nas.nasa.gov> References: <20090311203907.GA31081@linux55.nas.nasa.gov> Message-ID: <20090311220115.GA32034@linux55.nas.nasa.gov> On Wed, Mar 11, 2009 at 15:39:07 -0500, Iain Morgan wrote: > Hi, > > I noticed some behaviour recently that seems a bit odd. I have a > command-restricted public key that I use for checkouts from a local CVS > server. If I have the command-restricted key loaded into ssh-agent and > connect to the server, but authenticate via password rather than the key > (to get a login session) the forced command is still applied. > > In other words, I get the ssh-askpass dialogue box asking if I want to > use the key and select 'Cancel.' I then get a password prompt and > successfully authenticate, but rather than getting a login shell I'm > apparently running the cvs command. If I don't have the key loaded, I'm > able to get a login session as expected. > > Admittedly, the server is running an older version of OpenSSH (4.3p1) > and I have not verified that this behaviour exists with the current > version of OpenSSH, but it seems to me that the restriction should only > be applied if I actually used the key. > > Any thoughts? > I suppose for clarity's sake I should have mentioned that the key is added with the -c option, so confirmation is required. Anyway, this looks like this was fixed with more recent versions of OpenSSH. I am not able to reproduce the problem with 5.1p1. Sorry for the false alarm. -- Iain Morgan From djm at mindrot.org Thu Mar 12 10:12:16 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 12 Mar 2009 10:12:16 +1100 (EST) Subject: Possible issue with forced commands In-Reply-To: <20090311220115.GA32034@linux55.nas.nasa.gov> References: <20090311203907.GA31081@linux55.nas.nasa.gov> <20090311220115.GA32034@linux55.nas.nasa.gov> Message-ID: On Wed, 11 Mar 2009, Iain Morgan wrote: > I suppose for clarity's sake I should have mentioned that the key is > added with the -c option, so confirmation is required. Anyway, this > looks like this was fixed with more recent versions of OpenSSH. I am not > able to reproduce the problem with 5.1p1. Sorry for the false alarm. Yes, this was http://bugzilla.mindrot.org/b/1472 - fixed in 5.1 -d From sfandino at yahoo.com Fri Mar 13 03:22:40 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Thu, 12 Mar 2009 09:22:40 -0700 (PDT) Subject: [PATCH] accept SOCKS request over the mux socket References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> <20090311182154.GF13652@crawfish.ais.com> Message-ID: <934399.22713.qm@web52709.mail.re2.yahoo.com> ----- Original Message ---- > From: Jim Knoble > To: Ben Lindstrom > Cc: Salvador Fandino ; openssh-unix-dev at mindrot.org > Sent: Wednesday, March 11, 2009 7:21:54 PM > Subject: Re: [PATCH] accept SOCKS request over the mux socket > > Circa 2009-03-11 10:27 dixit Ben Lindstrom: > > : I'm concerned that people will become confused since -M -S combo has > : been resevered for multiple ssh terminal sessions over a single > : tunnel. I'd rather see it more clear like: > : > : ssh -D -M -S /tmp/mux 172.20.3.12 -N -f if you want multiple tunnels > : + SOCK support > : ssh -D -S /tmp/mux .. if you just want SOCKS support instead of a PORT > : > : Which means an error needs to be throw on > : > : ssh -Dxxx -S xxxx > > The above means that you can't separate permissions for the mux socket > and the SOCKS socket. > > Better to create a dedicated SOCKS socket, no? > > ssh -D /tmp/ssh-socks-socket ... > > That is, '-D' may accept either an IP address or a filesystem path. > Reserve '-S' for use with multiplexing sockets. This way, one can: > > ssh -D /tmp/ssh-socks-socket -M -S /tmp/ssh-mux-socket ... > > and allow more than one user to use the SOCKS connection while keeping > the mux socket more private. > > This also makes the '-D' syntax consistent and sensible. I have attached a new patch to the request at... https://bugzilla.mindrot.org/show_bug.cgi?id=1572 doing just that. There is a problem with it and is that slashes already have an special meaning on tunnel specifications , they are used with IPv6 addresses. My proposal (not implemented on the patch yet) would be to use {} to demarcate unix paths as in $ ssh -D{/tmp/bar} ... and $ ssh -L{/tmp/foo}:host:22 ... It will fail for -L{/tmp/name,with,commas}, but hey, this is not very common! Cheers, - Salva > > --jim > > -- > jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ > (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) > (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) From scott_n at xypro.com Fri Mar 13 03:56:13 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 12 Mar 2009 09:56:13 -0700 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090311082639.GH9322@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> <20090311082639.GH9322@calimero.vinschen.de> Message-ID: <78DD71C304F38B41885A242996B96F7301C220ED@xyservd.XYPRO-23.LOCAL> > > What's still missing in OpenSSH is code which abstracts the idea of the > root user to the idea of a user with certain privileges. At least > Linux/Solaris/Cygwin/Windows allow to specify finer grained user > rights, > so that certain types of tasks are not necessarily run by the root > user. > In case of Cygwin/Windows there isn't even a root user, just users with > certain privileges. Given that, the hardcoded checks for uid == 0 > don't > make sense or rather, are too bulky in a couple of environments. To > reiterate an idea I'm proposing for quite some time now: > > Instead of checks as > > if (getuid() == 0) > do_foo_bar (); > else > EEEEK! > > openssh should have checks along the lines of > > if (uid_has_capability (getuid (), CAP_foo_bar)) > do_foo_bar (); > else > EEEEK! > > The function uid_has_capability() would be quite simple on systems > which don't have fine-grained user rights: > > int > uid_has_capability (uid_t uid, int capability) > { > return uid == 0; > } > > but could be much more elaborate on other platforms like Linux, > Solaris, > or Cygwin. And, again, I'm willing to help with this stuff in terms of > coding. > I'd love to see something like this. I'm on an oddball system (Tandem/HP NonStop), where root isn't UID 0, and other stuff has ACL/permissions. From rob at nofocus.org Fri Mar 13 06:06:48 2009 From: rob at nofocus.org (Robert Banz) Date: Thu, 12 Mar 2009 12:06:48 -0700 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: <934399.22713.qm@web52709.mail.re2.yahoo.com> References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> <20090311182154.GF13652@crawfish.ais.com> <934399.22713.qm@web52709.mail.re2.yahoo.com> Message-ID: <6B44119E-C75D-462B-9470-D6A04CAC01E6@nofocus.org> > > There is a problem with it and is that slashes already have an > special meaning on tunnel specifications , they are used with IPv6 > addresses. > > My proposal (not implemented on the patch yet) would be to use {} to > demarcate unix paths as in > > $ ssh -D{/tmp/bar} ... > > and > > $ ssh -L{/tmp/foo}:host:22 ... > > It will fail for -L{/tmp/name,with,commas}, but hey, this is not > very common! > > Cheers, Why not do something a little more flexible, and do something like ssh -Lsocket=/tmp/foo:host:22 It certainly would never be confused with a standard port, and you'd have a framework to expand to forwarding other sorts of things in the future. Not to mention { } causes magic to happen in certain shells, which may have unwanted side effects. -rob From william at 25thandClement.com Fri Mar 13 06:25:36 2009 From: william at 25thandClement.com (William Ahern) Date: Thu, 12 Mar 2009 12:25:36 -0700 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: <6B44119E-C75D-462B-9470-D6A04CAC01E6@nofocus.org> References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> <20090311182154.GF13652@crawfish.ais.com> <934399.22713.qm@web52709.mail.re2.yahoo.com> <6B44119E-C75D-462B-9470-D6A04CAC01E6@nofocus.org> Message-ID: <20090312192536.GA7376@wilbur.25thandClement.com> On Thu, Mar 12, 2009 at 12:06:48PM -0700, Robert Banz wrote: > > > > There is a problem with it and is that slashes already have an > > special meaning on tunnel specifications , they are used with IPv6 > > addresses. > > > > My proposal (not implemented on the patch yet) would be to use {} to > > demarcate unix paths as in > > > > $ ssh -D{/tmp/bar} ... > > > > and > > > > $ ssh -L{/tmp/foo}:host:22 ... > > Many moons ago I wrote a patch to do exactly this: http://www.25thandclement.com/~william/projects/streamlocal.html I think that was before mux sockets were even available. At the time, patching OpenSSH to grok domain sockets in all the right places was a gigantic PITA. Nobody showed interest in the patch, perhaps because it was quite large. The patch works, though; running 24/7 on tens of thousands of boxes as we speak. From jmknoble at pobox.com Fri Mar 13 09:31:35 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 12 Mar 2009 17:31:35 -0500 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: <934399.22713.qm@web52709.mail.re2.yahoo.com> References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> <20090311182154.GF13652@crawfish.ais.com> <934399.22713.qm@web52709.mail.re2.yahoo.com> Message-ID: <20090312223135.GE2667@crawfish.ais.com> Circa 2009-03-12 11:22 dixit Salvador Fandino: : > From: Jim Knoble : > Sent: Wednesday, March 11, 2009 7:21:54 PM : > : > ssh -D /tmp/ssh-socks-socket ... : : I have attached a new patch to the request at... : : https://bugzilla.mindrot.org/show_bug.cgi?id=1572 : : doing just that. : : There is a problem with it and is that slashes already have an special : meaning on tunnel specifications , they are used with IPv6 addresses. The syntax you're speaking of is (from ssh(1)): IPv6 addresses can be specified with an alternative syntax: [bind_address/]port/host/hostport or by enclosing the address in square brackets. There's a key difference between that syntax and the Unix-domain socket path: The leading slash of an absolute path. That is: # Listen on IPv6 address ::1 on port 2222, forward across the # ssh link to address ::1, port 22 ssh -L ::1/2222/::1/22 # Listen on a Unix domain socket at /tmp/my-ssh-forward-sock, and # forward across the ssh link to address 127.0.0.1, port 22 ssh -L /tmp/my-ssh-forward-sock:127.0.0.1:22 # Listen on a Unix domain socket at /tmp/my-ssh-forward-sock, and # forward across the ssh link to address ::1, port 22 # TODO: Does this work: -L [::1]:2222:[::1]:22 ssh -L /tmp/my-ssh-forward-sock:[::1]:22 # Syntax error (too many ':') ssh -L /::1/2222/::1/22 In words: If the first character of the argument to -L is '/', it's a filesystem path, and ':' is required to be the sub-argument separator. Remote IPv6 addresses must be enclosed in square brackets. Otherwise, the syntax is the same as before. Are there plans to implement domain sockets for '-R'? If so: # Listen on the remote address ::1 on port 2222, forward back across # the ssh link to address ::1, port 22 ssh -R ::1/2222/::1/22 # Listen on the remote address 127.0.0.1 on port 2222, forward back # across the ssh link to the socket at /tmp/my-service-sock on the # host ssh is running on ssh -R 127.0.0.1:2222:/tmp/my-service-sock # Listen on the remote address ::1 on port 2222, forward back across # the ssh link to the socket at /tmp/my-service-sock on the host ssh # is running on ssh -R [::1]:2222:/tmp/my-service-sock # Syntax error (probably produces either "tmp: host not found" or # "my-service-sock: unknown port") ssh -R ::1/2222/tmp/my-service-sock In words, if '/' is used as the subargument separator, then Unix domain sockets cannot be specified. If ':' is used, remote IPv6 addresses must be specified in square brackets, and if the first character of the "local" host specification is '/', then it's a Unix domain socket. If you want Unix domain sockets to be used with -L or -R on the remote end as well, that works the same as above, only with -L and -R reversed. To forward between Unix domain sockets on both ends, you get: ssh -L /tmp/ssh-forward-sock:/tmp/my-service-sock (I.e., only 2 subarguments, separated by ':'). Same for -R. Obviously, sshd would have to be patched to support that. Anything i missed, for -L or -R? -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) From william at 25thandClement.com Fri Mar 13 11:51:27 2009 From: william at 25thandClement.com (William Ahern) Date: Thu, 12 Mar 2009 17:51:27 -0700 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: <20090312223135.GE2667@crawfish.ais.com> References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> <20090311182154.GF13652@crawfish.ais.com> <934399.22713.qm@web52709.mail.re2.yahoo.com> <20090312223135.GE2667@crawfish.ais.com> Message-ID: <20090313005127.GA12637@wilbur.25thandClement.com> On Thu, Mar 12, 2009 at 05:31:35PM -0500, Jim Knoble wrote: > Are there plans to implement domain sockets for '-R'? If so: > > # Listen on the remote address ::1 on port 2222, forward back across > # the ssh link to address ::1, port 22 > > ssh -R ::1/2222/::1/22 > > # Listen on the remote address 127.0.0.1 on port 2222, forward back > # across the ssh link to the socket at /tmp/my-service-sock on the > # host ssh is running on > > ssh -R 127.0.0.1:2222:/tmp/my-service-sock First of all, you have to modify the wire protocol to request remote domain socket forwarding. When I did it, it was relatively simple. But... Second of all, there are security issues with domain sockets. One of the pains of domain sockets in general is you can't simply set SO_REUSEADDR. To make them practical, you have to (at least provide the option to) unlink() the path. Otherwise broken connections and other regular happenstances will make live miserable to make use of the capability. And for all but the most convoluted solutions, there are still races and other uncertainties. > In words, if '/' is used as the subargument separator, then Unix domain > sockets cannot be specified. If ':' is used, remote IPv6 addresses > must be specified in square brackets, and if the first character of the > "local" host specification is '/', then it's a Unix domain socket. > > If you want Unix domain sockets to be used with -L or -R on the remote > end as well, that works the same as above, only with -L and -R reversed. > To forward between Unix domain sockets on both ends, you get: > > ssh -L /tmp/ssh-forward-sock:/tmp/my-service-sock > > (I.e., only 2 subarguments, separated by ':'). Same for -R. Obviously, > sshd would have to be patched to support that. > The way I implemented it was I re-wrote the the -L and -R parser to be more generic, using a small state machine rather than ad-hoc string parsing. The most straight-forward syntax would be to require domain paths to be between braces; then there's no conflict (unless your path contains brances, but you can escape those), and you don't even necessarily need to require absolute paths, because the brace syntax can bootstrap you into a new syntax domain. For instance: -R[/tmp/remote-foo]:[/tmp/local-bar] Or perhaps: -R[unix://some/relative/path/remote-foo]:[unix:///tmp/local-bar] (I'm unfamiliar with the sftp spec, but I bet there's a useful syntax there, too.) From jmknoble at pobox.com Fri Mar 13 17:00:24 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 13 Mar 2009 01:00:24 -0500 Subject: [PATCH] accept SOCKS request over the mux socket In-Reply-To: <20090313005127.GA12637@wilbur.25thandClement.com> References: <952D1E7A-03C7-46D6-AFCB-7C9EBDAAA98A@eviladmin.org> <18124.94238.qm@web52704.mail.re2.yahoo.com> <20090311182154.GF13652@crawfish.ais.com> <934399.22713.qm@web52709.mail.re2.yahoo.com> <20090312223135.GE2667@crawfish.ais.com> <20090313005127.GA12637@wilbur.25thandClement.com> Message-ID: <20090313060024.GB6721@crawfish.ais.com> On 2009-03-12 19:51, William Ahern wrote: : The way I implemented it was I re-wrote the the -L and -R parser to be : more generic, using a small state machine rather than ad-hoc string : parsing. The most straight-forward syntax would be to require domain : paths to be between braces; then there's no conflict (unless your path : contains brances, but you can escape those), and you don't even : necessarily need to require absolute paths, because the brace syntax : can bootstrap you into a new syntax domain. For instance: : : -R[/tmp/remote-foo]:[/tmp/local-bar] This is interesting. Salvo had proposed using curly braces '{' and '}' for this, which may be necessary, as IPv6 addresses are curently allowed to be inside square brackets '[' and ']'. Haven't looked at the code, though. : Or perhaps: : : -R[unix://some/relative/path/remote-foo]:[unix:///tmp/local-bar] Aha. Thanks, William, for pointing out what I missed: the possibility of relative paths for the remote end. This is very interesting, and obviously URI-style specifiers are relatively commonplace these days. I would get rid of the '//' after the ':', as it is supposed to denote a host, but with Unix domain sockets, the host is implied to be one of the hosts at either end of the SSH connection. Thus: -R[unix:some/relative/path/remote-foo]:[unix:/tmp/local-bar] should be sufficient. I don't mind the extra typing associated with the square brackets and the URI-style specifier, as i suspect this usage wouldn't be terribly commonplace anyway. It also allows square brackets to be used without conflicting with the optional square brackets around IPv6 addresses. I'm in favor of this. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) From pocketnerd at gmail.com Fri Mar 13 19:04:37 2009 From: pocketnerd at gmail.com (Richard Stockley) Date: Fri, 13 Mar 2009 08:04:37 +0000 Subject: RM using a Windows Service Message-ID: <6bb76ff00903130104o27c7f805n3413d9ef5df22fae@mail.gmail.com> Hi, I am trying to run an "rm" using SSH, from a Windows Service using the following command line arguments - the aim is to clear the target folder before i SFTP new files to it so that the two folders are then identical. -o BatchMode=yes -o StrictHostkeyChecking=no -o -i C:\uat_key -l USERNAME MACHINE rm -f /targetfolder/* If I run this from a Windows EXE or Console application everything works fine and the folder is cleared and my SFTP copies the new files over. However, when I run it from the Windows Service the files are deleted but the SSH process doesn?t actually end and therefore my application hangs and the SFTP never happens. Can you tell me why this would be the case for the Windows Service version and ideally how i can get it to work? Alternatively, can you tell me how i can clear the target folder before i do my SFTP? Many thanks RS From gert at greenie.muc.de Fri Mar 13 21:24:25 2009 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 13 Mar 2009 11:24:25 +0100 Subject: ssh -t host sleep 100 + Ctrl-Z (SIGSTOP) does not suspend process? In-Reply-To: <158294901135158438021011027452339999560-Webmail@me.com> References: <158294901135158438021011027452339999560-Webmail@me.com> Message-ID: <20090313102425.GZ290@greenie.muc.de> Hi, On Thu, Feb 26, 2009 at 12:10:43PM +0200, prestoo at me.com wrote: > Currently executing "ssh -t host sleep 100" and then pressing Ctrl-Z (to send SIGSTOP) does not seem to suspend the SSH process. Would it make sense to have Ctrl-Z suspend the SSH process, or is there some rationale for not doing that? I'm not intimately familiar with how SSH interacts with terminals on pseudo-TTY allocation, which is why I'm asking. If you force PTY allocation ("-t"), all that stuff needs to go to the other end. How can ssh know that you want to suspend the local SSH process, instead of "whatever you are running in the PTY on the other end"? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From mrmaikel007 at googlemail.com Fri Mar 13 10:38:03 2009 From: mrmaikel007 at googlemail.com (Michael) Date: Fri, 13 Mar 2009 00:38:03 +0100 Subject: scp hangs Message-ID: <49B99CDB.7060305@gmail.com> Hello! scp hangs while copying file over a certain size. Here's the output of scp in verbose mode: scp -v test.pdf pc: Executing: program /usr/bin/ssh host pc, user (unspecified), command scp -v -t . OpenSSH_5.1p1, OpenSSL 0.9.8j 07 Jan 2009 debug1: Reading configuration data /home/user/.ssh/config debug1: Applying options for pc debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.0.21 [192.168.0.21] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/identity type -1 debug1: identity file /home/user/.ssh/id_rsa type -1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '192.168.0.21' is known and matches the RSA host key. debug1: Found key in /home/user/.ssh/known_hosts:10 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/user/.ssh/identity debug1: Trying private key: /home/user/.ssh/id_rsa debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Next authentication method: password [1]user at 192.168.0.2's password: debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Requesting [2]no-more-sessions at openssh.com debug1: Entering interactive session. debug1: Sending command: scp -v -t . Sending file modes: C0600 33843 test.pdf Sink: C0600 33843 test.pdf test.pdf 100% 33KB 33.1KB/s 00:00 ^Cdebug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Killed by signal 2. The Terminal writes he uploaded 100% but the file is emtpy (0 byte). The openssh version used in cygwin seems to have a similar problem with dual core machines. I'm using Archlinux on a dual core. Does anybody has the same problem? Regards, Michael References 1. mailto:user at 192.168.0.2 2. mailto:no-more-sessions at openssh.com From tgc at jupiterrise.com Tue Mar 17 07:17:17 2009 From: tgc at jupiterrise.com (Tom Christensen) Date: Mon, 16 Mar 2009 21:17:17 +0100 Subject: openssh 5.2p1 fails to build on IRIX 5.3 Message-ID: <49BEB3CD.5090700@jupiterrise.com> Hello, I ran into a few problems when trying to build openssh 5.2p1 on IRIX 5.3. First one is new to 5.2p1: cc -I. -I. -I/usr/tgcware/include/openssl -I/usr/tgcware/include -DSSHDIR=\"/usr/tgcware/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/tgcware/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/tgcware/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/tgcware/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/tgcware/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/tgcware/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c channels.c cfe: Warning 581: /usr/include/sys/param.h:223: Macro MAXPATHLEN redefined. cfe: Error: channels.c, line 2472: 'in_port_t' undefined; reoccurrences will not be reported. in_port_t *lport_p; ^ cfe: Error: channels.c, line 2546: 'lport_p' undefined; reoccurrences will not be reported. lport_p = &((struct sockaddr_in *)ai->ai_addr)-> ^ cfe: Error: channels.c, line 2562: 'lport_p' undefined; reoccurrences will not be reported. *lport_p = (*allocated_listen_port) ; -^ make: *** [channels.o] Error 1 IRIX 5.3 does not define in_port_t in instead it uses ushort for sockaddr_in.sin_port. In other parts of openssh users of sin_port either use ushort or u_int16_t instead of in_port_t. The second problem has been around since 4.7p1 and is only present when building with the old SGI compiler: cc -I. -I. -I/usr/tgcware/include/openssl -I/usr/tgcware/include -DSSHDIR=\"/usr/tgcware/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/tgcware/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/tgcware/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/tgcware/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/tgcware/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty/sshd\" -DSSH_RAND_HELPER=\"/usr/tgcware/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c atomicio.c cfe: Warning 581: /usr/include/sys/param.h:223: Macro MAXPATHLEN redefined. cfe: Error: atomicio.c, line 102: Unacceptable operand of == or != pfd.events = f == readv ? 0x0001 : 0x0004 ; ---------------^ make: *** [atomicio.o] Error 1 The code is gibberish to me but since GCC has no issues I assume it's the compiler being difficult and not a problem with the intent of the code. Is there perhaps another way to write this that the SGI compiler would be more likely to grok? -tgc From tim at multitalents.net Tue Mar 17 09:33:40 2009 From: tim at multitalents.net (Tim Rice) Date: Mon, 16 Mar 2009 15:33:40 -0700 (PDT) Subject: openssh 5.2p1 fails to build on IRIX 5.3 In-Reply-To: <49BEB3CD.5090700@jupiterrise.com> References: <49BEB3CD.5090700@jupiterrise.com> Message-ID: On Mon, 16 Mar 2009, Tom Christensen wrote: > Hello, > > I ran into a few problems when trying to build openssh 5.2p1 on IRIX 5.3. > > First one is new to 5.2p1: [snip] > cfe: Error: channels.c, line 2472: 'in_port_t' undefined; reoccurrences > will not be reported. > in_port_t *lport_p; > ^ [snip] Please try the attached in_port_t.patch and report back. You'll need to run autoreconf with version 2.61 or better. If you don't have an up to date autoconf, apply the attached optional-part2.patch. I haven't looked at the second probelm yet. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- openssh/configure.ac.old 2009-02-16 09:47:37.628109004 -0800 +++ openssh/configure.ac 2009-03-16 14:36:27.020757062 -0700 @@ -2694,7 +2694,7 @@ #endif ]) -AC_CHECK_TYPES(in_addr_t,,, +AC_CHECK_TYPES([in_addr_t, in_port_t],,, [#include #include ]) --- openssh/defines.h.old 2009-02-16 09:47:37.648109004 -0800 +++ openssh/defines.h 2009-03-16 13:40:27.660357005 -0700 @@ -301,6 +301,10 @@ typedef u_int32_t in_addr_t; #endif +#ifndef HAVE_IN_PORT_T +typedef unsigned short in_port_t; +#endif + #if defined(BROKEN_SYS_TERMIO_H) && !defined(_STRUCT_WINSIZE) #define _STRUCT_WINSIZE struct winsize { -------------- next part -------------- --- openssh/config.h.in.old 2009-02-16 09:47:49.000000000 -0800 +++ openssh/config.h.in 2009-03-16 14:36:41.000000000 -0700 @@ -518,6 +518,9 @@ /* Define to 1 if the system has the type `in_addr_t'. */ #undef HAVE_IN_ADDR_T +/* Define to 1 if the system has the type `in_port_t'. */ +#undef HAVE_IN_PORT_T + /* Define to 1 if you have the header file. */ #undef HAVE_LASTLOG_H --- openssh/configure.old 2009-02-22 19:57:05.000000000 -0800 +++ openssh/configure 2009-03-16 14:36:40.520757002 -0700 @@ -22186,6 +22186,69 @@ fi +{ echo "$as_me:$LINENO: checking for in_port_t" >&5 +echo $ECHO_N "checking for in_port_t... $ECHO_C" >&6; } +if test "${ac_cv_type_in_port_t+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ +#include +#include + +typedef in_port_t ac__type_new_; +int +main () +{ +if ((ac__type_new_ *) 0) + return 0; +if (sizeof (ac__type_new_)) + return 0; + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext +if { (ac_try="$ac_compile" +case "(($ac_try" in + *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; + *) ac_try_echo=$ac_try;; +esac +eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5 + (eval "$ac_compile") 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && { + test -z "$ac_c_werror_flag" || + test ! -s conftest.err + } && test -s conftest.$ac_objext; then + ac_cv_type_in_port_t=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + + ac_cv_type_in_port_t=no +fi + +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext +fi +{ echo "$as_me:$LINENO: result: $ac_cv_type_in_port_t" >&5 +echo "${ECHO_T}$ac_cv_type_in_port_t" >&6; } +if test $ac_cv_type_in_port_t = yes; then + +cat >>confdefs.h <<_ACEOF +#define HAVE_IN_PORT_T 1 +_ACEOF + + +fi { echo "$as_me:$LINENO: checking for size_t" >&5 From adrya1984 at gmail.com Tue Mar 17 16:54:33 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Tue, 17 Mar 2009 07:54:33 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates In-Reply-To: <49B75E6B.8060707@roumenpetrov.info> References: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> <4980CA4C.5060900@roumenpetrov.info> <496c8fcc0901282358g57467b88mb2a578ba40c0fa32@mail.gmail.com> <498203DF.1080003@roumenpetrov.info> <496c8fcc0901300426uf87bbc4h97d482732e578c58@mail.gmail.com> <4983710A.4020804@roumenpetrov.info> <496c8fcc0903060136g344f2de3g84adbe3b5db7bd90@mail.gmail.com> <49B2DDDB.3050109@roumenpetrov.info> <496c8fcc0903092252t2b33b7a3n6d8a4a36d2434424@mail.gmail.com> <49B75E6B.8060707@roumenpetrov.info> Message-ID: <496c8fcc0903162254u23ade8bhea224ecedee99b02@mail.gmail.com> Hi Roumen, I changed config files as you said and now it works, thanks for help! But I am in doubt if the way it works now is the right one. I had to copy clients public key to authorized_keys file on server machine, and servers public key to known_hosts file on client machine. It seems pretty much as usual PKI authentication now, except that client and server send certificates to each other. Is that possible by any way to avoid public key storage and just use certificates validation? Like if certificate is OK ? no need to have public key from this certificate in authorized_key or known_hosts. Thank you, Adriana. From tgc at jupiterrise.com Tue Mar 17 18:01:33 2009 From: tgc at jupiterrise.com (Tom Christensen) Date: Tue, 17 Mar 2009 08:01:33 +0100 Subject: openssh 5.2p1 fails to build on IRIX 5.3 In-Reply-To: References: <49BEB3CD.5090700@jupiterrise.com> Message-ID: <49BF4ACD.9030308@jupiterrise.com> Tim Rice wrote: > On Mon, 16 Mar 2009, Tom Christensen wrote: > >> Hello, >> >> I ran into a few problems when trying to build openssh 5.2p1 on IRIX 5.3. >> >> First one is new to 5.2p1: > [snip] >> cfe: Error: channels.c, line 2472: 'in_port_t' undefined; reoccurrences >> will not be reported. >> in_port_t *lport_p; >> ^ > [snip] > > Please try the attached in_port_t.patch and report back. > You'll need to run autoreconf with version 2.61 or better. > If you don't have an up to date autoconf, apply the > attached optional-part2.patch. > Applied and ran autoreconf. It detects that in_port_t is missing and channels.c compiles without problems now. -tgc From tim at multitalents.net Wed Mar 18 02:14:23 2009 From: tim at multitalents.net (Tim Rice) Date: Tue, 17 Mar 2009 08:14:23 -0700 (PDT) Subject: openssh 5.2p1 fails to build on IRIX 5.3 In-Reply-To: <49BF4ACD.9030308@jupiterrise.com> References: <49BEB3CD.5090700@jupiterrise.com> <49BF4ACD.9030308@jupiterrise.com> Message-ID: On Tue, 17 Mar 2009, Tom Christensen wrote: > Tim Rice wrote: > > On Mon, 16 Mar 2009, Tom Christensen wrote: > > [snip] > > > cfe: Error: channels.c, line 2472: 'in_port_t' undefined; reoccurrences > > > will not be reported. > > > in_port_t *lport_p; > > > ^ > > [snip] > > > > Please try the attached in_port_t.patch and report back. > > You'll need to run autoreconf with version 2.61 or better. > > If you don't have an up to date autoconf, apply the attached > > optional-part2.patch. > > > Applied and ran autoreconf. > > It detects that in_port_t is missing and channels.c compiles without problems > now. I should have sync'd my tree befor posting. It looks like Darren commited a nearly identical patch on the 7th. He used a slightly different typedef in defines.h. Does #ifndef HAVE_IN_PORT_T typedef u_int16_t in_port_t; #endif work for you in defines.h? > -tgc > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tgc at jupiterrise.com Wed Mar 18 03:34:01 2009 From: tgc at jupiterrise.com (Tom Christensen) Date: Tue, 17 Mar 2009 17:34:01 +0100 Subject: openssh 5.2p1 fails to build on IRIX 5.3 In-Reply-To: References: <49BEB3CD.5090700@jupiterrise.com> <49BF4ACD.9030308@jupiterrise.com> Message-ID: <49BFD0F9.9030700@jupiterrise.com> Tim Rice wrote: > On Tue, 17 Mar 2009, Tom Christensen wrote: > >> Tim Rice wrote: >>> On Mon, 16 Mar 2009, Tom Christensen wrote: >>> > [snip] >>>> cfe: Error: channels.c, line 2472: 'in_port_t' undefined; reoccurrences >>>> will not be reported. >>>> in_port_t *lport_p; >>>> ^ >>> [snip] >>> >>> Please try the attached in_port_t.patch and report back. >>> You'll need to run autoreconf with version 2.61 or better. >>> If you don't have an up to date autoconf, apply the attached >>> optional-part2.patch. >>> >> Applied and ran autoreconf. >> >> It detects that in_port_t is missing and channels.c compiles without problems >> now. > > I should have sync'd my tree befor posting. It looks like Darren > commited a nearly identical patch on the 7th. He used a slightly > different typedef in defines.h. > Does > #ifndef HAVE_IN_PORT_T > typedef u_int16_t in_port_t; > #endif > work for you in defines.h? > Yes. Before you posted your patch I had already built it with in_port_t replaced with u_uint16_t and it's working as expected. -tgc From tim at multitalents.net Wed Mar 18 05:49:27 2009 From: tim at multitalents.net (Tim Rice) Date: Tue, 17 Mar 2009 11:49:27 -0700 (PDT) Subject: openssh 5.2p1 fails to build on IRIX 5.3 In-Reply-To: <49BFD0F9.9030700@jupiterrise.com> References: <49BEB3CD.5090700@jupiterrise.com> <49BF4ACD.9030308@jupiterrise.com> <49BFD0F9.9030700@jupiterrise.com> Message-ID: On Tue, 17 Mar 2009, Tom Christensen wrote: > Tim Rice wrote: > > Does > > #ifndef HAVE_IN_PORT_T > > typedef u_int16_t in_port_t; > > #endif > > work for you in defines.h? > > > Yes. > Before you posted your patch I had already built it with in_port_t replaced > with u_uint16_t and it's working as expected. Good, that is what is in the current snapshots. Thanks. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From brolin at brolin.be Wed Mar 18 16:43:10 2009 From: brolin at brolin.be (Brolin Empey) Date: Tue, 17 Mar 2009 22:43:10 -0700 Subject: scp: rounding bug in displayed transfer rate? Message-ID: Hello, [brolin at optiplex960] [0] [5] ~/ $ echo hello >hello.txt ... [brolin at optiplex960] [1] [9] ~/ $ scp -pP 2222 hello.txt k7t266:~/ brolin at k7t266's password: hello.txt 100% 6 0.0KB/s 00:00 [brolin at optiplex960] [0] [10] ~/ $ Why is the transfer rate "0.0KB/s"? That means nothing was transferred. I think the transfer rate should be displayed in B/s instead of KB/s if it is less than 0.1 KB/s because copying 6 bytes but saying "0.0KB/s" is misleading and wrong to me. Thanks, Brolin -- Sometimes I forget how to do small talk: "What if there were no hypothetical questions?" ? George Carlin From peter at stuge.se Wed Mar 18 22:34:51 2009 From: peter at stuge.se (Peter Stuge) Date: Wed, 18 Mar 2009 12:34:51 +0100 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: Message-ID: <20090318113451.29420.qmail@stuge.se> Brolin Empey wrote: > 100% 6 0.0KB/s 00:00 > > Why is the transfer rate "0.0KB/s"? Maybe it took less than one second, so no /s average is available? //Peter From vinschen at redhat.com Thu Mar 19 02:07:36 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 18 Mar 2009 16:07:36 +0100 Subject: [PATCH] Remove setting IP_TOS_IS_BROKEN for Cygwin Message-ID: <20090318150736.GL9322@calimero.vinschen.de> Hi, The problem that setsockopt(IP_TOS) doesn't work on Cygwin is long fixed. Ages ago Microsoft changed the definition for IP_TOS when moving from winsock1 to winsock2 and IP_TOS in Cygwin didn't work all these years because nobody (that's especialy me) realized that we were still using the old winsock1 value. This has been fixed since 2005, though. Patch below. Corinna Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.418 diff -u -p -r1.418 configure.ac --- configure.ac 7 Mar 2009 11:22:35 -0000 1.418 +++ configure.ac 18 Mar 2009 15:03:02 -0000 @@ -434,8 +434,6 @@ int main(void) { exit(0); } AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) AC_DEFINE(DISABLE_SHADOW, 1, [Define if you want to disable shadow passwords]) - AC_DEFINE(IP_TOS_IS_BROKEN, 1, - [Define if your system choked on IP TOS setting]) AC_DEFINE(NO_X11_UNIX_SOCKETS, 1, [Define if X11 doesn't support AF_UNIX sockets on that system]) AC_DEFINE(NO_IPPORT_RESERVED_CONCEPT, 1, -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Thu Mar 19 02:08:08 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 18 Mar 2009 16:08:08 +0100 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090311082639.GH9322@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> <20090311082639.GH9322@calimero.vinschen.de> Message-ID: <20090318150808.GM9322@calimero.vinschen.de> Is there any chance this can be discussed at one point? On Mar 11 09:26, Corinna Vinschen wrote: > Hi, > > This time with it's own subject: > > What's still missing in OpenSSH is code which abstracts the idea of the > root user to the idea of a user with certain privileges. At least > Linux/Solaris/Cygwin/Windows allow to specify finer grained user rights, > so that certain types of tasks are not necessarily run by the root user. > In case of Cygwin/Windows there isn't even a root user, just users with > certain privileges. Given that, the hardcoded checks for uid == 0 don't > make sense or rather, are too bulky in a couple of environments. To > reiterate an idea I'm proposing for quite some time now: > > Instead of checks as > > if (getuid() == 0) > do_foo_bar (); > else > EEEEK! > > openssh should have checks along the lines of > > if (uid_has_capability (getuid (), CAP_foo_bar)) > do_foo_bar (); > else > EEEEK! > > The function uid_has_capability() would be quite simple on systems > which don't have fine-grained user rights: > > int > uid_has_capability (uid_t uid, int capability) > { > return uid == 0; > } > > but could be much more elaborate on other platforms like Linux, Solaris, > or Cygwin. And, again, I'm willing to help with this stuff in terms of > coding. > > > Corinna > > -- > Corinna Vinschen > Cygwin Project Co-Leader > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Thu Mar 19 04:07:26 2009 From: tim at multitalents.net (Tim Rice) Date: Wed, 18 Mar 2009 10:07:26 -0700 (PDT) Subject: openssh 5.2p1 fails to build on IRIX 5.3 In-Reply-To: <49BEB3CD.5090700@jupiterrise.com> References: <49BEB3CD.5090700@jupiterrise.com> Message-ID: On Mon, 16 Mar 2009, Tom Christensen wrote: > The second problem has been around since 4.7p1 and is only present when > building with the old SGI compiler: > cfe: Error: atomicio.c, line 102: Unacceptable operand of == or != > pfd.events = f == readv ? 0x0001 : 0x0004 ; > ---------------^ > make: *** [atomicio.o] Error 1 > > The code is gibberish to me but since GCC has no issues I assume it's > the compiler being difficult and not a problem with the intent of the > code. > Is there perhaps another way to write this that the SGI compiler would > be more likely to grok? Does your compiler like this any better? pfd.events = (f == readv) ? 0x0001 : 0x0004 ; -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Thu Mar 19 05:31:11 2009 From: tim at multitalents.net (Tim Rice) Date: Wed, 18 Mar 2009 11:31:11 -0700 (PDT) Subject: [PATCH] Remove setting IP_TOS_IS_BROKEN for Cygwin In-Reply-To: <20090318150736.GL9322@calimero.vinschen.de> References: <20090318150736.GL9322@calimero.vinschen.de> Message-ID: On Wed, 18 Mar 2009, Corinna Vinschen wrote: > Hi, > > The problem that setsockopt(IP_TOS) doesn't work on Cygwin is long > fixed. Ages ago Microsoft changed the definition for IP_TOS when moving > from winsock1 to winsock2 and IP_TOS in Cygwin didn't work all these > years because nobody (that's especialy me) realized that we were still > using the old winsock1 value. This has been fixed since 2005, though. > > Patch below. The first AC_DEFINE needs a description. Here is what I've commited ...... --- openssh/configure.ac.old 2009-03-17 07:51:51.111200008 -0700 +++ openssh/configure.ac 2009-03-18 11:25:02.000000000 -0700 @@ -434,8 +434,6 @@ AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) AC_DEFINE(DISABLE_SHADOW, 1, [Define if you want to disable shadow passwords]) - AC_DEFINE(IP_TOS_IS_BROKEN, 1, - [Define if your system choked on IP TOS setting]) AC_DEFINE(NO_X11_UNIX_SOCKETS, 1, [Define if X11 doesn't support AF_UNIX sockets on that system]) AC_DEFINE(NO_IPPORT_RESERVED_CONCEPT, 1, @@ -446,7 +444,8 @@ file descriptor passing]) ;; *-*-dgux*) - AC_DEFINE(IP_TOS_IS_BROKEN) + AC_DEFINE(IP_TOS_IS_BROKEN, 1, + [Define if your system choked on IP TOS setting]) AC_DEFINE(SETEUID_BREAKS_SETUID) AC_DEFINE(BROKEN_SETREUID) AC_DEFINE(BROKEN_SETREGID) ...... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tgc at jupiterrise.com Thu Mar 19 07:06:30 2009 From: tgc at jupiterrise.com (Tom Christensen) Date: Wed, 18 Mar 2009 21:06:30 +0100 Subject: openssh 5.2p1 fails to build on IRIX 5.3 In-Reply-To: References: <49BEB3CD.5090700@jupiterrise.com> Message-ID: <49C15446.3010701@jupiterrise.com> Tim Rice wrote: > On Mon, 16 Mar 2009, Tom Christensen wrote: > >> The second problem has been around since 4.7p1 and is only present when >> building with the old SGI compiler: >> cfe: Error: atomicio.c, line 102: Unacceptable operand of == or != >> pfd.events = f == readv ? 0x0001 : 0x0004 ; >> ---------------^ >> make: *** [atomicio.o] Error 1 >> >> The code is gibberish to me but since GCC has no issues I assume it's >> the compiler being difficult and not a problem with the intent of the >> code. >> Is there perhaps another way to write this that the SGI compiler would >> be more likely to grok? > > Does your compiler like this any better? > pfd.events = (f == readv) ? 0x0001 : 0x0004 ; > No it makes no difference. cfe: Error: atomicio.c, line 102: Unacceptable operand of == or != pfd.events = (f == readv) ? 0x0001 : 0x0004 ; ----------------^ I notice that this error seems very very similar to bz#1386. -tgc From jmknoble at pobox.com Thu Mar 19 10:27:58 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 18 Mar 2009 18:27:58 -0500 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090318150808.GM9322@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> <20090311082639.GH9322@calimero.vinschen.de> <20090318150808.GM9322@calimero.vinschen.de> Message-ID: <20090318232758.GN6721@crawfish.ais.com> On 2009-03-18 10:08, Corinna Vinschen wrote: : Is there any chance this [the below] can be discussed at one point? I'm all for it. : On Mar 11 09:26, Corinna Vinschen wrote: : > What's still missing in OpenSSH is code which abstracts the idea of the : > root user to the idea of a user with certain privileges. [...] : > the hardcoded checks for uid == 0 don't : > make sense or rather, are too bulky in a couple of environments. [...] : > openssh should have checks along the lines of : > : > if (uid_has_capability (getuid (), CAP_foo_bar)) : > do_foo_bar (); : > else : > EEEEK! -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) From scott_n at xypro.com Thu Mar 19 10:42:51 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Wed, 18 Mar 2009 16:42:51 -0700 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090318232758.GN6721@crawfish.ais.com> References: <20090216135649.GH5416@calimero.vinschen.de><20090311082639.GH9322@calimero.vinschen.de><20090318150808.GM9322@calimero.vinschen.de> <20090318232758.GN6721@crawfish.ais.com> Message-ID: <78DD71C304F38B41885A242996B96F7301C8573E@xyservd.XYPRO-23.LOCAL> > On 2009-03-18 10:08, Corinna Vinschen wrote: > : Is there any chance this [the below] can be discussed at one point? > > I'm all for it. At the risk of sounding AOL-ish, me too. I'm working on a non-standard unix-like system (HP/Tandem Nonstop) and things are sometimes a bit odd/weird there w.r.t. permissions and uids. > : On Mar 11 09:26, Corinna Vinschen wrote: > : > What's still missing in OpenSSH is code which abstracts the idea of > the > : > root user to the idea of a user with certain privileges. [...] > : > the hardcoded checks for uid == 0 don't > : > make sense or rather, are too bulky in a couple of environments. > > [...] > > : > openssh should have checks along the lines of > : > > : > if (uid_has_capability (getuid (), CAP_foo_bar)) > : > do_foo_bar (); > : > else > : > EEEEK! > From peter at stuge.se Thu Mar 19 12:08:50 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 19 Mar 2009 02:08:50 +0100 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090318150808.GM9322@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> <20090311082639.GH9322@calimero.vinschen.de> <20090318150808.GM9322@calimero.vinschen.de> Message-ID: <20090319010850.26100.qmail@stuge.se> Corinna Vinschen wrote: > Is there any chance this can be discussed at one point? I approve too, even though I am not really affected. Maybe it could take advantage of capabilities in Linux though. //Peter From brolin at brolin.be Thu Mar 19 17:48:34 2009 From: brolin at brolin.be (Brolin Empey) Date: Wed, 18 Mar 2009 23:48:34 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <20090318113451.29420.qmail@stuge.se> References: <20090318113451.29420.qmail@stuge.se> Message-ID: 2009/3/18 Peter Stuge > Brolin Empey wrote: > > 100% 6 0.0KB/s 00:00 > > > > Why is the transfer rate "0.0KB/s"? > > Maybe it took less than one second, so no /s average is available? > So what? After 1 second, it had still transferred 6 bytes. From vinschen at redhat.com Thu Mar 19 20:42:18 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 19 Mar 2009 10:42:18 +0100 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090319010850.26100.qmail@stuge.se> References: <20090216135649.GH5416@calimero.vinschen.de> <20090311082639.GH9322@calimero.vinschen.de> <20090318150808.GM9322@calimero.vinschen.de> <20090319010850.26100.qmail@stuge.se> Message-ID: <20090319094218.GY9322@calimero.vinschen.de> On Mar 19 02:08, Peter Stuge wrote: > Corinna Vinschen wrote: > > Is there any chance this can be discussed at one point? > > I approve too, even though I am not really affected. > > Maybe it could take advantage of capabilities in Linux though. That's the idea. I'm not asking for Cygwin's benefit alone. A couple of OSes have finer grained capabilities. And, as far as I'm concerned, code like this: if (uid_has_capability(getuid(), CAP_SWITCH_USER)) is much more instructive than if (getuid() == 0) Likewise, this: if (channel_input_port_forward_request( uid_has_capability(s->pw->pw_uid, CAP_RSVD_PORTS), options.gateway_ports) < 0) { is more instructive than this: if (channel_input_port_forward_request(s->pw->pw_uid == 0, options.gateway_ports) < 0) { So, in my eyes this change would make the code clearer even in the upstream OpenBSD-only code. Given that the uid_has_capability function would be a no-brainer on BSD and other systems having no capabilities model int uid_has_capability (uid_t uid, int capability __attribute ((unused))) { return uid == 0; } I only see advantages here. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From peter at stuge.se Thu Mar 19 22:25:33 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 19 Mar 2009 12:25:33 +0100 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> Message-ID: <20090319112533.11650.qmail@stuge.se> Brolin Empey wrote: > > > Why is the transfer rate "0.0KB/s"? > > > > Maybe it took less than one second, so no /s average is available? > > So what? After 1 second, it had still transferred 6 bytes. But the transfer didn't last one full second. Had it done so, the actual transfer rate would quite likely be higher than 6b/s. Are you suggesting that the program should wait idle until one full second has passed from start of transfer - or that it should fabricate a number which isn't accurate? Sorry, but neither seems like an improvement to me. It's simply impossible to calculate an average when there isn't an excess of data. Here, the transfer rate resolution is one second. Would you consider an "unmeasurable" style message to be an improvement for cases when no transfer rate can be calculated? //Peter From peter at stuge.se Thu Mar 19 22:32:29 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 19 Mar 2009 12:32:29 +0100 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090319094218.GY9322@calimero.vinschen.de> References: <20090216135649.GH5416@calimero.vinschen.de> <20090311082639.GH9322@calimero.vinschen.de> <20090318150808.GM9322@calimero.vinschen.de> <20090319010850.26100.qmail@stuge.se> <20090319094218.GY9322@calimero.vinschen.de> Message-ID: <20090319113229.13146.qmail@stuge.se> Corinna Vinschen wrote: > > > Is there any chance this can be discussed at one point? > > > > I approve too, even though I am not really affected. > > So, in my eyes this change would make the code clearer even in the > upstream OpenBSD-only code. .. > I only see advantages here. I agree. I guess produce the patch and push for inclusion.. No real protests yet and the idea has been around for long. //Peter From anandafit at gmail.com Fri Mar 20 16:45:23 2009 From: anandafit at gmail.com (Ananda Subasinghe) Date: Fri, 20 Mar 2009 11:15:23 +0530 Subject: Join with openssh org: GSOC 2009-Performance improvements Message-ID: Hi All, I am Ananda student of university of Moratuwa Sri lanka(www.mrt.ac.lk). I have worked with SAHNA open source community and have a experience with open source software as well. I am familiar with C language base soft ware development through the my university master degree and out source, so that I have decided to apply for GSOC in this year through your organisation. I am going to apply for GSOC under "Performance improvement" idea that you have mention in "http://www.openssh.com/gsoc.html#perf" page. I want to get experience with your org and good understand of my selected idea. I hope that you may help me to get a involvement to my selected idea. Best regards, Ananda. -- "?Respere | http://respere.com/ | "Dum spiro spero" From brolin at brolin.be Fri Mar 20 18:23:33 2009 From: brolin at brolin.be (Brolin Empey) Date: Fri, 20 Mar 2009 00:23:33 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <20090319112533.11650.qmail@stuge.se> References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> Message-ID: 2009/3/19 Peter Stuge > > Brolin Empey wrote: > > > > Why is the transfer rate "0.0KB/s"? > > > > > > Maybe it took less than one second, so no /s average is available? > > > > So what? ?After 1 second, it had still transferred 6 bytes. > > But the transfer didn't last one full second. Had it done so, the > actual transfer rate would quite likely be higher than 6b/s. You mean 6 B/s. 6 b/s is less than 1 B/s. :P Anyway, you are correct; I thought of that after I sent my message. > Are you suggesting that the program should wait idle until one full > second has passed from start of transfer - or that it should > fabricate a number which isn't accurate? As opposed to fabricating an accurate number? ;) Seriously: no, I am not suggesting either of those changes. > Sorry, but neither seems like an improvement to me. I agree. > It's simply impossible to calculate an average when there isn't an > excess of data. Here, the transfer rate resolution is one second. Then why does scp try to calculate an average when it has insufficient data? > Would you consider an "unmeasurable" style message to be an > improvement for cases when no transfer rate can be calculated? No, I do not think scp should say anything in these cases because such a message violates the Rule of Silence: Incidentally, I think this discussion list should allow rich (hyper)text mail so I can link parts of my prose instead of pasting URLs: in the case of the previous paragraph, the pasted URL is almost as long as the sentence on the previous line ? even when using a proportional font. Why am I limited to plain text when using a computer to write about computer software? Perhaps I am too contemporary for this discussion list: I am writing this message in a proportional font in Gmail's Web interface in Mozilla Firefox on Windows Vista with subpixel font antialiasing on a widescreen LCD monitor. ;) From vinschen at redhat.com Fri Mar 20 19:45:57 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 20 Mar 2009 09:45:57 +0100 Subject: Replace uid==0 tests with capability checks In-Reply-To: <20090319113229.13146.qmail@stuge.se> References: <20090216135649.GH5416@calimero.vinschen.de> <20090311082639.GH9322@calimero.vinschen.de> <20090318150808.GM9322@calimero.vinschen.de> <20090319010850.26100.qmail@stuge.se> <20090319094218.GY9322@calimero.vinschen.de> <20090319113229.13146.qmail@stuge.se> Message-ID: <20090320084557.GG9322@calimero.vinschen.de> On Mar 19 12:32, Peter Stuge wrote: > Corinna Vinschen wrote: > > > > Is there any chance this can be discussed at one point? > > > > > > I approve too, even though I am not really affected. > > > > So, in my eyes this change would make the code clearer even in the > > upstream OpenBSD-only code. > .. > > I only see advantages here. > > I agree. I guess produce the patch and push for inclusion.. > > No real protests yet and the idea has been around for long. Right. The problem is, I already created a patch a couple of years ago which has just gone stale. Nothing came out of it. If I *knew* it's not futile work, I'd create another patch happily. That's why I hope for some definitive answer from the core developers beforehand. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From gert at greenie.muc.de Fri Mar 20 19:55:09 2009 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 20 Mar 2009 09:55:09 +0100 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> Message-ID: <20090320085509.GO290@greenie.muc.de> Hi, On Fri, Mar 20, 2009 at 12:23:33AM -0700, Brolin Empey wrote: > Perhaps I am too contemporary for this discussion list: I am writing > this message in a proportional font in Gmail's Web interface in > Mozilla Firefox on Windows Vista with subpixel font antialiasing on a > widescreen LCD monitor. ;) You are. We are interested in content, not in presentation. I'm reading this in an 80x24 xterm using "mutt", because it's WAY faster to use the keyboard than having klick on things all the time. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From peter at stuge.se Fri Mar 20 22:05:24 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 20 Mar 2009 12:05:24 +0100 Subject: Join with openssh org: GSOC 2009-Performance improvements In-Reply-To: References: Message-ID: <20090320110524.3195.qmail@stuge.se> Hi Ananda, Ananda Subasinghe wrote: > I am Ananda student of university of Moratuwa Sri lanka(www.mrt.ac.lk). .. > I am going to apply for GSOC under "Performance improvement" idea > that you have mention in "http://www.openssh.com/gsoc.html#perf" > page. I want to get experience with your org and good understand of > my selected idea. Welcome to the project! > I hope that you may help me to get a involvement to my selected > idea. I don't think the participating projects can influence who is selected very much - aren't GSoC deciding that in some magic way? It's nice to hear from you! I hope you'll find OpenSSH a fun project to work on if you get the project. //Peter From sxw at inf.ed.ac.uk Fri Mar 20 22:12:11 2009 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Fri, 20 Mar 2009 11:12:11 +0000 Subject: Join with openssh org: GSOC 2009-Performance improvements In-Reply-To: <20090320110524.3195.qmail@stuge.se> References: <20090320110524.3195.qmail@stuge.se> Message-ID: <350DC704-58AF-4C7C-9368-8AEC90ED7FDB@inf.ed.ac.uk> On 20 Mar 2009, at 11:05, Peter Stuge wrote: > I don't think the participating projects can influence who is > selected very much - aren't GSoC deciding that in some magic way? No, Google decide on how many slots each project gets. The project selects which students they want to fill the slots Simon (who mentored for OpenAFS last year) From bob at proulx.com Sat Mar 21 03:55:34 2009 From: bob at proulx.com (Bob Proulx) Date: Fri, 20 Mar 2009 10:55:34 -0600 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> Message-ID: <20090320165534.GA25545@dementia.proulx.com> Brolin Empey wrote: > Incidentally, I think this discussion list should allow rich > (hyper)text mail so I can link parts of my prose instead of pasting > URLs: Please no. > in the case of the previous paragraph, the pasted URL is almost > as long as the sentence on the previous line ? even when using a > proportional font. Is that important? It doesn't seem to matter. > Why am I limited to plain text when using a computer to write about > computer software? More value is place on function over form. Plain text email is viewed using the recipient's preferred fonts and colors, which enhances accessibility. HTML email is viewed using the sender's preferred fonts and colors, which often make reading the message harder for the recipient. Senders cannot know what the best form is for the recipient. > Perhaps I am too contemporary for this discussion list: I am writing > this message in a proportional font in Gmail's Web interface in > Mozilla Firefox on Windows Vista with subpixel font antialiasing on a > widescreen LCD monitor. ;) I am happy that you have cool toys to play with but Email is written to be read by others. If others find it harder to read then it isn't accomplishing a good result. Bob From peter at stuge.se Sat Mar 21 04:24:49 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 20 Mar 2009 18:24:49 +0100 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> Message-ID: <20090320172450.16584.qmail@stuge.se> Brolin Empey wrote: > > But the transfer didn't last one full second. Had it done so, the > > actual transfer rate would quite likely be higher than 6b/s. > > You mean 6 B/s. 6 b/s is less than 1 B/s. :P Personally I make no difference between b and B. Conventions differ almost on a personal basis so I just keep it simple with lowercase all the time. For bits per second my preference is to use bps. I guess a habit from the modem days.. > > It's simply impossible to calculate an average when there isn't an > > excess of data. Here, the transfer rate resolution is one second. > > Then why does scp try to calculate an average when it has > insufficient data? I think there are two reasons for this; 1. It is a corner case where accuracy does not make a big difference. Being a corner case means that some amount of code needs to go into OpenSSH to cover it, but that code would not run very often. That's bad from a security/code quality perspective. The fact that the inaccuracy is near unmeasurable further motivates ignoring the problem. 2. Noone has felt strongly about making this more accurate. I do not know which is the stronger motivator, but I think both are important reasons. > > Would you consider an "unmeasurable" style message to be an > > improvement for cases when no transfer rate can be calculated? > > No, I do not think scp should say anything in these cases because > such a message violates the Rule of Silence: Hm. A little problematic because the other fields still have valid information. Omitting the throughput field would introduce a rather messy inconsistency in the program's output. If I were to interpret scp output programmatically I would be able to deal with 0 much more easily than especially since I may be using whitespace as field separator. > > > Incidentally, I think this discussion list should allow rich > (hyper)text mail so I can link parts of my prose instead of pasting > URLs: In this case I'd suggest to simply quote the rule (just the rule though) and save people who read your message a web dereference. It's quite interesting how two totally f*ed up technologies (web and email) can combine into something that people live their lives by. Webmail: Two wrongs don't make a right! //Peter From brolin at brolin.be Sat Mar 21 10:31:43 2009 From: brolin at brolin.be (Brolin Empey) Date: Fri, 20 Mar 2009 16:31:43 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <20090320085509.GO290@greenie.muc.de> References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320085509.GO290@greenie.muc.de> Message-ID: 2009/3/20 Gert Doering > > Hi, > > On Fri, Mar 20, 2009 at 12:23:33AM -0700, Brolin Empey wrote: > > Perhaps I am too contemporary for this discussion list: ?I am writing > > this message in a proportional font in Gmail's Web interface in > > Mozilla Firefox on Windows Vista with subpixel font antialiasing on a > > widescreen LCD monitor. ;) > > You are. ?We are interested in content, not in presentation. I was joking, hence the ";)". I am interested in content too, but I like to use links in e-mail without having to paste long URLs. I also like to be able to use rich text formatting such as bold, italic, and monospaced (as opposed to proportional) text for emphasis. I am used to using such formatting in e-mail and on Web forums. I wrote the paragraph you quoted because I thought limiting discussion list users to plain text seems to support the stereotype that discussion lists and Usenet are for people who are so passionate about criticising HTML e-mail that they include such things as "ASCII ribbon against HTML e-mail" in their signatures. I like to use Unicode characters, such as em dashes, arrows, copyright, registered, and trade mark symbols instead of ASCII approximations. That is why I joked that I was too contemporary for this discussion list. Artificial limitations seem silly because I am using a GUI on a microcomputer, not a text terminal connected to a mainframe or minicomputer. However, I have still respected the rules of this discussion list by using plain text. Of course, I know text terminals are not limited to use with mainframes and minicomputers. I frequently use terminal emulators, console windows (on Windows), and text-mode or (graphics-mode) frame buffer VTs on Linux. I have even written Linux man pages. I used to be convinced by plain text supporters that e-mail should be written in plain text, but I switched to HTML e-mail because I like the presentational control offered by rich text. I still believe in separation of structure from presentation, which is why I prefer using document markup languages, such as XHTML + CSS, in a text editor over graphical word processors. I have seen many users of graphical word processors hard-wire text formatting instead of using classes or styles. Granted, I suppose I may be hard-wiring formatting in HTML e-mail, but it does not bother me because no one has ever complained nor have I been unable to read HTML e-mail from others. I could probably use user stylesheets if I really wanted all of my received e-mail to be presented uniformly, but I am not sufficiently motivated to do so. > I'm reading this in an 80x24 xterm using "mutt", because it's WAY faster > to use the keyboard than having klick on things all the time. I am not clicking all the time while using a WIMP/GUI environment to read and write e-mail; I am not one of those users who uses the mouse to select the next field in a form instead of pressing Tab. :P I agree about the keyboard being faster than the mouse (or other pointing device) for certain tasks. For example, I use many readline shortcuts in bash. I also prefer to use the keyboard exclusively to edit text with Vim. From djm at mindrot.org Sat Mar 21 10:46:28 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 21 Mar 2009 10:46:28 +1100 (EST) Subject: Join with openssh org: GSOC 2009-Performance improvements In-Reply-To: <350DC704-58AF-4C7C-9368-8AEC90ED7FDB@inf.ed.ac.uk> References: <20090320110524.3195.qmail@stuge.se> <350DC704-58AF-4C7C-9368-8AEC90ED7FDB@inf.ed.ac.uk> Message-ID: On Fri, 20 Mar 2009, Simon Wilkinson wrote: > > On 20 Mar 2009, at 11:05, Peter Stuge wrote: > > > I don't think the participating projects can influence who is > > selected very much - aren't GSoC deciding that in some magic way? > > No, Google decide on how many slots each project gets. The project > selects which students they want to fill the slots Just to describe what is going on - OpenSSH has requested one student slot for this year's summer of code. This is our first time, so this is both an experiment and a learning exercise. I'm currently quite swamped with questions from prospective students, but I intend to answer them en-masse on Monday. Most of the discussion for the GSoC work will be happening on this mailing list, so please constructive in your comments and tolerant of someone who, in all likelihood, is less experiences with free software development and many people here. -d From peter at stuge.se Sat Mar 21 10:59:42 2009 From: peter at stuge.se (Peter Stuge) Date: Sat, 21 Mar 2009 00:59:42 +0100 Subject: Join with openssh org: GSOC 2009-Performance improvements In-Reply-To: References: <20090320110524.3195.qmail@stuge.se> <350DC704-58AF-4C7C-9368-8AEC90ED7FDB@inf.ed.ac.uk> Message-ID: <20090320235942.25906.qmail@stuge.se> Damien Miller wrote: > OpenSSH has requested one student slot for this year's summer of > code. This is our first time, so this is both an experiment and a > learning exercise. I'm looking forward to this! We've participated in GSoC in other projects where I am involved, and it is usually a good experience. Maybe there will also be some project suggestions from interested students - or is the performance thing the only project we'll consider? //Peter From Jefferson.Ogata at noaa.gov Sat Mar 21 12:21:34 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sat, 21 Mar 2009 01:21:34 +0000 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320085509.GO290@greenie.muc.de> Message-ID: <49C4411E.5010702@noaa.gov> On 2009-03-20 23:31, Brolin Empey wrote: > I was joking, hence the ";)". I am interested in content too, but I > like to use links in e-mail without having to paste long URLs. I also http://tinyurl.com/ > like to be able to use rich text formatting such as bold, italic, and > monospaced (as opposed to proportional) text for emphasis. I am used > to using such formatting in e-mail and on Web forums. I wrote the > paragraph you quoted because I thought limiting discussion list users > to plain text seems to support the stereotype that discussion lists > and Usenet are for people who are so passionate about criticising HTML > e-mail that they include such things as "ASCII ribbon against HTML > e-mail" in their signatures. I like to use Unicode characters, such > as em dashes, arrows, copyright, registered, and trade mark symbols > instead of ASCII approximations. That is why I joked that I was too I don't know about this list, but there's no reason that you can't use Unicode in plain text documents, with UTF-8 encoding. ??????? ???? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From djm at mindrot.org Sat Mar 21 12:33:45 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 21 Mar 2009 12:33:45 +1100 (EST) Subject: Join with openssh org: GSOC 2009-Performance improvements In-Reply-To: <20090320235942.25906.qmail@stuge.se> References: <20090320110524.3195.qmail@stuge.se> <350DC704-58AF-4C7C-9368-8AEC90ED7FDB@inf.ed.ac.uk> <20090320235942.25906.qmail@stuge.se> Message-ID: On Sat, 21 Mar 2009, Peter Stuge wrote: > Damien Miller wrote: > > OpenSSH has requested one student slot for this year's summer of > > code. This is our first time, so this is both an experiment and a > > learning exercise. > > I'm looking forward to this! > > We've participated in GSoC in other projects where I am involved, and > it is usually a good experience. > > Maybe there will also be some project suggestions from interested > students - or is the performance thing the only project we'll > consider? Yes, there is a list at http://www.openssh.com/gsoc.html -d From brolin at brolin.be Sat Mar 21 23:25:56 2009 From: brolin at brolin.be (Brolin Empey) Date: Sat, 21 Mar 2009 05:25:56 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <49C4411E.5010702@noaa.gov> References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320085509.GO290@greenie.muc.de> <49C4411E.5010702@noaa.gov> Message-ID: 2009/3/20 Jefferson Ogata : > On 2009-03-20 23:31, Brolin Empey wrote: >> I was joking, hence the ";)". I am interested in content too, but I >> like to use links in e-mail without having to paste long URLs. I also > > http://tinyurl.com/ You missed my point: I meant I like to be able to link parts of my prose instead of pasting URLs of /any/ length. Oh well, it is not a big deal. > >> like to be able to use rich text formatting such as bold, italic, and >> monospaced (as opposed to proportional) text for emphasis. I am used >> to using such formatting in e-mail and on Web forums. I wrote the >> paragraph you quoted because I thought limiting discussion list users >> to plain text seems to support the stereotype that discussion lists >> and Usenet are for people who are so passionate about criticising HTML >> e-mail that they include such things as "ASCII ribbon against HTML >> e-mail" in their signatures. I like to use Unicode characters, such >> as em dashes, arrows, copyright, registered, and trade mark symbols >> instead of ASCII approximations. That is why I joked that I was too > > I don't know about this list, but there's no reason that you can't use > Unicode in plain text documents, with UTF-8 encoding. Yes, I know. > $B#U#n#i#c#o#d#e(B $B#t#e#s#t(B Your test appears to have succeeded because I can read "Unicode test". From brolin at brolin.be Sat Mar 21 23:57:34 2009 From: brolin at brolin.be (Brolin Empey) Date: Sat, 21 Mar 2009 05:57:34 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <20090320165534.GA25545@dementia.proulx.com> References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320165534.GA25545@dementia.proulx.com> Message-ID: 2009/3/20 Bob Proulx : > Brolin Empey wrote: >> in the case of the previous paragraph, the pasted URL is almost >> as long as the sentence on the previous line ? even when using a >> proportional font. > > Is that important? ?It doesn't seem to matter. My point was that only one line instead of two is required if I can link part of my sentence instead of having to paste the URL. >> Why am I limited to plain text when using a computer to write about >> computer software? > > More value is place on function over form. > > Plain text email is viewed using the recipient's preferred fonts and > colors, which enhances accessibility. ?HTML email is viewed using the > sender's preferred fonts and colors, which often make reading the > message harder for the recipient. ?Senders cannot know what the best > form is for the recipient. This is probably true in some circumstances, but I do not think it affects any of the people with whom I correspond via e-mail. From bob at proulx.com Sun Mar 22 04:27:53 2009 From: bob at proulx.com (Bob Proulx) Date: Sat, 21 Mar 2009 11:27:53 -0600 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320165534.GA25545@dementia.proulx.com> Message-ID: <20090321172753.GB23121@discord.proulx.com> Brolin Empey wrote: > Bob Proulx wrote: > > Plain text email is viewed using the recipient's preferred fonts and > > colors, which enhances accessibility. HTML email is viewed using the > > sender's preferred fonts and colors, which often make reading the > > message harder for the recipient. Senders cannot know what the best > > form is for the recipient. > > This is probably true in some circumstances, but I do not think it > affects any of the people with whom I correspond via e-mail. You just now corresponded via e-mail with myself and with hundreds of other members of the mailing list. Bob From brolin at brolin.be Sun Mar 22 11:19:39 2009 From: brolin at brolin.be (Brolin Empey) Date: Sat, 21 Mar 2009 17:19:39 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <20090320172450.16584.qmail@stuge.se> References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320172450.16584.qmail@stuge.se> Message-ID: 2009/3/20 Peter Stuge : > Brolin Empey wrote: >> > But the transfer didn't last one full second. Had it done so, the >> > actual transfer rate would quite likely be higher than 6b/s. >> >> You mean 6 B/s. ?6 b/s is less than 1 B/s. :P > > Personally I make no difference between b and B. Conventions differ > almost on a personal basis so I just keep it simple with lowercase > all the time. For bits per second my preference is to use bps. I > guess a habit from the modem days.. The formal convention is to use 'B' for bytes and 'b' for bits. However, many people mistakenly use 'b' for bytes. I can usually still tell what they mean because a combination such as "mb" for megabytes really means millibits, which is impossible because a bit is a fundamental unit of information. I am a purist. Incorrect common usage bothers me even if I know what is meant. >> > Would you consider an "unmeasurable" style message to be an >> > improvement for cases when no transfer rate can be calculated? >> >> No, I do not think scp should say anything in these cases because >> such a message violates the Rule of Silence: > > Hm. A little problematic because the other fields still have valid > information. Omitting the throughput field would introduce a rather > messy inconsistency in the program's output. Yes, I realise this. The throughput field could be moved so it is the last field on the line, but that would break compatibility with scripts that expect the throughput field to be the second-last field. The throughput field could also be interpreted as a boolean expression in C: the field's value is false if it is zero. :) > If I were to interpret scp output programmatically I would be able to > deal with 0 much more easily than especially > since I may be using whitespace as field separator. I realise this too. How about printing "-.-KB/s" instead of "0.0KB/s"? The '-'s mean no value is specified, but the presence of the decimal point and rate indicate that a value would be specified under non-exceptional conditions. From brolin at brolin.be Sun Mar 22 08:17:04 2009 From: brolin at brolin.be (Brolin Empey) Date: Sat, 21 Mar 2009 14:17:04 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <20090321172753.GB23121@discord.proulx.com> References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320165534.GA25545@dementia.proulx.com> <20090321172753.GB23121@discord.proulx.com> Message-ID: 2009/3/21 Bob Proulx : > Brolin Empey wrote: >> Bob Proulx wrote: >> > Plain text email is viewed using the recipient's preferred fonts and >> > colors, which enhances accessibility. ?HTML email is viewed using the >> > sender's preferred fonts and colors, which often make reading the >> > message harder for the recipient. ?Senders cannot know what the best >> > form is for the recipient. >> >> This is probably true in some circumstances, but I do not think it >> affects any of the people with whom I correspond via e-mail. > > You just now corresponded via e-mail with myself and with hundreds of > other members of the mailing list. I was not sufficiently precise: I meant I do not think any of the people to whom I send HTML e-mail are affected by the accessibility issues of HTML e-mail. I have sent only plain-text e-mail to this list. Anyway, I apologise for sidetracking this discussion. I will now attempt to get back on track. From mouring at eviladmin.org Sun Mar 22 12:45:41 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sat, 21 Mar 2009 20:45:41 -0500 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320172450.16584.qmail@stuge.se> Message-ID: <0DB49A0A-9473-4B9F-AD4D-18D0815C523D@eviladmin.org> On Mar 21, 2009, at 7:19 PM, Brolin Empey wrote: [..] >> If I were to interpret scp output programmatically I would be able to >> deal with 0 much more easily than especially >> since I may be using whitespace as field separator. > > I realise this too. How about printing "-.-KB/s" instead of > "0.0KB/s"? The '-'s mean no value is specified, but the presence of > the decimal point and rate indicate that a value would be specified > under non-exceptional conditions. If you feel this should be done then please write a patch and submit it to the bugzilla tracking page. Most around here don't feel it is detrimental nor worth investing development cycles. - Ben From Jefferson.Ogata at noaa.gov Sun Mar 22 19:42:24 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 22 Mar 2009 08:42:24 +0000 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320172450.16584.qmail@stuge.se> Message-ID: <49C5F9F0.6090905@noaa.gov> On 2009-03-22 00:19, Brolin Empey wrote: > The formal convention is to use 'B' for bytes and 'b' for bits. > However, many people mistakenly use 'b' for bytes. I can usually > still tell what they mean because a combination such as "mb" for > megabytes really means millibits, which is impossible because a bit is > a fundamental unit of information. A millibit is a valid measure of entropy. Otherwise you are correct. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From brolin at brolin.be Sun Mar 22 20:49:39 2009 From: brolin at brolin.be (Brolin Empey) Date: Sun, 22 Mar 2009 02:49:39 -0700 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: <49C5F9F0.6090905@noaa.gov> References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320172450.16584.qmail@stuge.se> <49C5F9F0.6090905@noaa.gov> Message-ID: 2009/3/22 Jefferson Ogata : > A millibit is a valid measure of entropy. Otherwise you are correct. Which sense of entropy do you mean? I assume you mean: 2. (in data transmission and information theory) a measure of the loss of information in a transmitted signal or message. From Jefferson.Ogata at noaa.gov Mon Mar 23 02:23:38 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 22 Mar 2009 15:23:38 +0000 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320172450.16584.qmail@stuge.se> <49C5F9F0.6090905@noaa.gov> Message-ID: <49C657FA.2090409@noaa.gov> On 2009-03-22 09:49, Brolin Empey wrote: > 2009/3/22 Jefferson Ogata : >> A millibit is a valid measure of entropy. Otherwise you are correct. > I assume you mean: > > 2. (in data transmission and information theory) a measure of the > loss of information in a transmitted signal or message. Yes, Shannon's entropy. http://en.wikipedia.org/wiki/Entropy_(Information_theory) -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From p.wright at besc.ac.uk Tue Mar 24 00:43:34 2009 From: p.wright at besc.ac.uk (Peter Wright) Date: Mon, 23 Mar 2009 13:43:34 +0000 Subject: ForcePTTYAllocation config parameter? Message-ID: <49C79206.4030803@besc.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've been enjoying the -t argument to ssh lately to force ptty allocation and I noticed there's no option in the config file that controls it. The O'Reilly ssh book specifies a ForcePTTYAllocation parameter so I've created a patch to openssh-5.2p1 which adds this functionality. Is this of interest to anyone? - -- Peter Wright Software Engineer Belfast eScience Centre (BeSC) Queen's University, Belfast e-mail: p.wright at besc.ac.uk web: www.besc.ac.uk tel: +44 (0)28 9097 4768 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknHkgYACgkQNUqFgcnUSsK3ggCeMXR2gpuqO/On8dxkfVcaaf1q PHkAniWql6JxrXNzTFDBKKU3J2uwDlJh =SZLp -----END PGP SIGNATURE----- From jawaad.ahmad at gmail.com Tue Mar 24 03:00:28 2009 From: jawaad.ahmad at gmail.com (Jawaad Ahmad) Date: Mon, 23 Mar 2009 12:00:28 -0400 Subject: OpenSSH GSoC Project In-Reply-To: <1237491407.20077.55.camel@garfield.waady.gotdns.org> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> Message-ID: <1237824028.20077.104.camel@garfield.waady.gotdns.org> Hello, I apologize if this isn't the right place to post about the Google Summer of Code; if so, I would appreciate guidance toward the correct list. If this is the correct list, I would appreciate answers to the message below. Thanks. -----Original Message----- From: Jawaad Ahmad To: djm at openssh.com Subject: OpenSSH GSoC Project Date: Thu, 19 Mar 2009 15:36:51 -0400 Damien, I am a student at Webster university, and I am interested in participating the the Summer of Code this year. I noticed your project idea regarding renovating sftp to improve its command-line interface. Can you tell me more about this? For this project, I assume you have certain key features in mind besides recursive uploads/downloads via the command-line interface. In addition, by "command-line interface", I assume you mean the "sftp" command line and not the shell in which we enter when we run sftp, correct? Also, I'm curious about the rationale for this. Why beef up sftp to handle this if scp already takes care of it? Do you envision cases in which scp is available but sftp is not? Thanks, Jawaad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090323/3ddd0323/attachment.bin From Jan.Pechanec at Sun.COM Tue Mar 24 03:53:18 2009 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Mon, 23 Mar 2009 17:53:18 +0100 (CET) Subject: OpenSSH GSoC Project In-Reply-To: <1237824028.20077.104.camel@garfield.waady.gotdns.org> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: On Mon, 23 Mar 2009, Jawaad Ahmad wrote: >Also, I'm curious about the rationale for this. Why beef up sftp to >handle this if scp already takes care of it? Do you envision cases in >which scp is available but sftp is not? SFTP is a different protocol, a real one, and while still in a draft, will hopefully become an RFC some day. It's rather a file system protocol now. See this: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ in contrast to that, SCP is just an RCP over SSH link. Very simple, not extensible, meant to be a quick replacement for rcp(1). http://blogs.sun.com/janp/entry/how_the_scp_protocol_works if sftp(1) command can do all what scp(1) can do then users could stop using scp completely, and preferrably just link it to sftp. J. -- Jan Pechanec From peter at stuge.se Tue Mar 24 03:58:49 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 23 Mar 2009 17:58:49 +0100 Subject: OpenSSH GSoC Project In-Reply-To: <1237824028.20077.104.camel@garfield.waady.gotdns.org> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: <20090323165849.10363.qmail@stuge.se> Hi Jawaad, Jawaad Ahmad wrote: > I apologize if this isn't the right place to post about the Google > Summer of Code; if so, I would appreciate guidance toward the > correct list. > > If this is the correct list, I would appreciate answers to the > message below. This is the list, as is Damien's address, but I guess he has many emails to reply to. I'll try to answer, best as I can. > -----Original Message----- > I noticed your project idea regarding renovating sftp to improve > its command-line interface. Can you tell me more about this? For > this project, I assume you have certain key features in mind > besides recursive uploads/downloads via the command-line interface. I think this is about internal structure in the sftp client program. At present I view it more as proof of concept than an actual file transfer utility. That is what I would like the project to fix. > In addition, by "command-line interface", I assume you mean the > "sftp" command line and not the shell in which we enter when we > run sftp, correct? Naturally both those interfaces should be able to use any new features. > Also, I'm curious about the rationale for this. Why beef up sftp to > handle this if scp already takes care of it? Do you envision cases > in which scp is available but sftp is not? The sole reason for scp's existence is backwards compatibility with rcp. scp uses an application protocol similar (identical?) to rcp on top of Unix fd:s, and is really a sorry excuse for a file transfer program in 2009. scp does however work well enough for it to continue to be used by many, and in particular scp has some features which the OpenSSH sftp program lacks. SFTP on the other hand is a modern, standardized, file transfer protocol directly on top of SSH, and the sftp program is an elementary implementation of a client software. scp is bad, but can not be changed because it is compatibility only. scp is legacy. sftp (and to a degree SFTP, the protocol itself) can easily be changed and improved. Even the user interface can (and should) change, for the better. SFTP is the future. The OpenSSH sftp client is, as said, not so impressive, and it needs some love to really shine. The tool can be improved in many ways, internally and externally. Recursive transfers is just one thing. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090323/208111ad/attachment.bin From scott_n at xypro.com Tue Mar 24 04:52:58 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 23 Mar 2009 10:52:58 -0700 Subject: SFTP (was Re:GSoC) In-Reply-To: <20090323165849.10363.qmail@stuge.se> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org><1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> Message-ID: <78DD71C304F38B41885A242996B96F7301C85A9E@xyservd.XYPRO-23.LOCAL> Quoth Peter Stuge > sftp (and to a degree SFTP, the protocol itself) can easily be changed > and improved. Even the user interface can (and should) change, for the > better. SFTP is the future. > > The OpenSSH sftp client is, as said, not so impressive, and it needs > some love to really shine. The tool can be improved in many ways, > internally and externally. Recursive transfers is just one thing. > Since SFTP appears to be on the RFC track, how does one go about proposing protocol extensions? In particular, an "append" command, similar to that of FTP? From Jan.Pechanec at Sun.COM Tue Mar 24 05:28:47 2009 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Mon, 23 Mar 2009 19:28:47 +0100 (CET) Subject: SFTP (was Re:GSoC) In-Reply-To: <78DD71C304F38B41885A242996B96F7301C85A9E@xyservd.XYPRO-23.LOCAL> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <78DD71C304F38B41885A242996B96F7301C85A9E@xyservd.XYPRO-23.LOCAL> Message-ID: On Mon, 23 Mar 2009, Scott Neugroschl wrote: >> The OpenSSH sftp client is, as said, not so impressive, and it needs >> some love to really shine. The tool can be improved in many ways, >> internally and externally. Recursive transfers is just one thing. >> > >Since SFTP appears to be on the RFC track, how does one go about >proposing >protocol extensions? In particular, an "append" command, similar to >that >of FTP? I don't think you need it, see O_APPEND in the draft. J. -- Jan Pechanec From scott_n at xypro.com Tue Mar 24 07:12:01 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 23 Mar 2009 13:12:01 -0700 Subject: SFTP (was Re:GSoC) In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <78DD71C304F38B41885A242996B96F7301C85A9E@xyservd.XYPRO-23.LOCAL> Message-ID: <78DD71C304F38B41885A242996B96F7301C85AE5@xyservd.XYPRO-23.LOCAL> > -----Original Message----- > From: Jan.Pechanec at Sun.COM [mailto:Jan.Pechanec at Sun.COM] > >Since SFTP appears to be on the RFC track, how does one go about > >proposing > >protocol extensions? In particular, an "append" command, similar to > >that > >of FTP? > > I don't think you need it, see O_APPEND in the draft. J. > Hi Jan, I assume you mean SSH_FXF_APPEND? Is there any reason it hasn't been implemented in sftp-server yet (as of 5.2p1), or in the SFTP client? From imorgan at nas.nasa.gov Tue Mar 24 07:14:04 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 23 Mar 2009 13:14:04 -0700 Subject: OpenSSH GSoC Project In-Reply-To: <20090323165849.10363.qmail@stuge.se> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> Message-ID: <20090323201404.GA17426@linux55.nas.nasa.gov> On Mon, Mar 23, 2009 at 11:58:49 -0500, Peter Stuge wrote: > > sftp (and to a degree SFTP, the protocol itself) can easily be > changed and improved. Even the user interface can (and should) > change, for the better. SFTP is the future. > > The OpenSSH sftp client is, as said, not so impressive, and it needs > some love to really shine. The tool can be improved in many ways, > internally and externally. Recursive transfers is just one thing. > As long as improvements to sftp are being discussed, the addition of reget/reput support would be _very_ nice. I know the topic has come up on the mailing list a few times and there was at least one bug opened on this issue. But, unfortunately, it never seemed to get much traction. When dealing with large transfers (100GB+), the ability to resume an interupted transfer would be very handy. -- Iain Morgan From dkg at fifthhorseman.net Tue Mar 24 06:45:22 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 23 Mar 2009 15:45:22 -0400 Subject: scp: rounding bug in displayed transfer rate? In-Reply-To: References: <20090318113451.29420.qmail@stuge.se> <20090319112533.11650.qmail@stuge.se> <20090320165534.GA25545@dementia.proulx.com> <20090321172753.GB23121@discord.proulx.com> Message-ID: <49C7E6D2.8060302@fifthhorseman.net> On 03/21/2009 05:17 PM, Brolin Empey wrote: > Anyway, I apologise for sidetracking this discussion. I will now > attempt to get back on track. So, speaking of "scp: rounding bug in displayed transfer rate"... Other tools appear to deal with this same problem in a different way: http://blog.rupamsunyata.org/2009/03/23/artificial-intelligence.xhtml our machines are clearly capable of measuring timestamps with finer granularity than 1 second, even if they report human-comprehensible times to the (presumably human) user. I wouldn't see a reason reject a patch that allowed scp to produce output of "42B/s" if 1 byte gets transferred in 1/42 seconds. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090323/69debb05/attachment.bin From pavelo at centrum.sk Tue Mar 24 08:05:23 2009 From: pavelo at centrum.sk (Pavel Labath) Date: Mon, 23 Mar 2009 22:05:23 +0100 Subject: OpenSSH GSoC Project In-Reply-To: <20090323201404.GA17426@linux55.nas.nasa.gov> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> Message-ID: <49C7F993.8040501@centrum.sk> Hi all, I too would like to apply for GSoC scholarship and work on sftp. I'm not sure if i should contact djm directly (you say he's swamped with emails, so i guess people are talking to him privately), but I thought I'd write here. So, what are the features we want a polished sftp to have? The only thing mentioned so far is the recursive up/down load, which looks more like a thing for a two day hackfest than a all-summer-long $4.5k operation. Features i would consider useful are: - tab completion (both commands and filenames) - very useful, not difficult - transfer resume (thanks Iain Morgan, I almost forgot) - very useful, not difficult - background transfer (possibly threads, or just fancy select() calls) - useful, not very difficult - server to server transfer (the data will have to go through the local machine - unless we want to add an extension for a pure server2server xfer, but that is probably not a good idea, security-wise) - I'm not sure about the usefulness, it may be easier to just log onto one machine (assuming you can do that) and initiate the transfer from there. But, scp can do that so I guess it should be done. the client doesn't use global variables, so it shouldn't be that difficult to do. Also, I was wondering, did you plan to do any modifications to the server program? - the append thing was mentioned already, it could be useful (piping logs through sftp? maybe, i don't know) - I noticed the spec mentions ACL:s and mandatory/advisory locks. Do we want to support that? I'm not sure how portable those are, but it may be possible to do them. - If I understood the code correctly, server does buffer network messages. But it may be better, given today's fast networks, to also do parallel disk reads and writes, especially if they are on different disks. Am I on the right track here? What did you have in mind for this project? I'd appreciate any feedback. PS: @Peter Stuge What did you mean by the "internal structure in the sftp client program"? Could you elaborate on that? I found the code very easy to read and self-explanatory, even without comments. Sure, it doesn't have all the bells and whistles, but that's what we're here to change. ;) Thanks, -- Pavel Labath From jmknoble at pobox.com Tue Mar 24 10:30:35 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 23 Mar 2009 18:30:35 -0500 Subject: OpenSSH GSoC Project In-Reply-To: <49C7F993.8040501@centrum.sk> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> Message-ID: <20090323233035.GF29122@crawfish.ais.com> On 2009-03-23 16:05, Pavel Labath wrote: : So, what are the features we want a polished sftp to have? The best interactive terminal-based SFTP client i've used so far is LFTP , by opening an URL like 'sftp://remote-host'. : The only thing mentioned so far is the recursive up/down load, which : looks more like a thing for a two day hackfest than a all-summer-long : $4.5k operation. Perhaps i misunderstand, but i think the intent of the GSoC description is to make sftp(1) a potential replacement for scp(1), insofar as non-interactive invocation from the shell prompt is concerned. Example: scp -p -r ./some_dir remote-host: Currently, sftp(1) understands neither '-p' nor '-r'. Obviously, sftp(1) currently has some conflicting options, and it will be necessary to balance compatibility with scp(1) against compatibilty with prior versions of sftp(1). It may be that the best way to do some of this would be the same way F-Secure's SSH does it: use scp2(1), which would eventually completely replace scp(1). That said, i often use either rsync(1) or combinations of ssh(1) and tar(1) to do transfers from a shell command-line. : Features i would consider useful are: : - tab completion (both commands and filenames) - very useful, not difficult Tab completion is nice. LFTP provides both local and remote filename completion, but remote completion can sometimes take awhile, so beware. : - transfer resume (thanks Iain Morgan, I almost forgot) - very useful, : not difficult Look at LFTP's interface for resuming ("continuing") a transfer. : - background transfer (possibly threads, or just fancy select() calls) - : useful, not very difficult Again, look at LFTP for ideas. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) From plambrechtsen at gmail.com Tue Mar 24 10:35:56 2009 From: plambrechtsen at gmail.com (Peter Lambrechtsen) Date: Tue, 24 Mar 2009 12:35:56 +1300 Subject: OpenSSH GSoC Project In-Reply-To: <20090323233035.GF29122@crawfish.ais.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> Message-ID: On Tue, Mar 24, 2009 at 12:30 PM, Jim Knoble wrote: > On 2009-03-23 16:05, Pavel Labath wrote: > > : So, what are the features we want a polished sftp to have? > > The best interactive terminal-based SFTP client i've used so far is LFTP > , by opening an URL like 'sftp://remote-host'. > > : The only thing mentioned so far is the recursive up/down load, which > : looks more like a thing for a two day hackfest than a all-summer-long > : $4.5k operation. > > Perhaps i misunderstand, but i think the intent of the GSoC description > is to make sftp(1) a potential replacement for scp(1), insofar as > non-interactive invocation from the shell prompt is concerned. ?Example: > > ? ?scp -p -r ./some_dir remote-host: > > Currently, sftp(1) understands neither '-p' nor '-r'. ?Obviously, > sftp(1) currently has some conflicting options, and it will be necessary > to balance compatibility with scp(1) against compatibilty with prior > versions of sftp(1). > > It may be that the best way to do some of this would be the same way > F-Secure's SSH does it: ?use scp2(1), which would eventually completely > replace scp(1). > > That said, i often use either rsync(1) or combinations of ssh(1) and > tar(1) to do transfers from a shell command-line. > > : Features i would consider useful are: > : - tab completion (both commands and filenames) - very useful, not difficult > > Tab completion is nice. ?LFTP provides both local and remote filename > completion, but remote completion can sometimes take awhile, so beware. > > : - transfer resume (thanks Iain Morgan, I almost forgot) - very useful, > : not difficult > > Look at LFTP's interface for resuming ("continuing") a transfer. > > : - background transfer (possibly threads, or just fancy select() calls) - > : useful, not very difficult > > Again, look at LFTP for ideas. > Few other nice to haves: Transferring open files. Such as a "tail -f" being able to copy a open log file, even if it is displayed as zero bytes try reading the file and seeing how far you can go. Plus one other wishlist I had is "man-in-the-middle" scp / sftp. ie scp user at hostname1:/file user2 at hostname2:/destdir. As I have a number of areas where I have a DMZ server that can access two remote servers in different zones, but the two servers cannot communicate with each other, and I need to find a way to copy from one server to the other, difficult if the DMZ server has a small amount of storage and you need to copy a large file. From rhouliha at us.ibm.com Tue Mar 24 11:05:34 2009 From: rhouliha at us.ibm.com (Rick Houlihan) Date: Mon, 23 Mar 2009 19:05:34 -0500 Subject: Issue with child process exits Message-ID: I recently started building a simulator using honeyd as an IP emulator and experienced an issue with hangs on exit from ssh and sftp sessions. A quick look at the OpenSSH source code revealed the following: In serverloop.c there is a signal handler defined for SIGCHLD as follows: static void sigchld_handler(int sig) { int save_errno = errno; debug("Received SIGCHLD."); child_terminated = 1; #ifndef _UNICOS mysignal(SIGCHLD, sigchld_handler); #endif notify_parent(); errno = save_errno; } As far as I can tell the primary purpose of this method is to set a value for child_terminated which is referenced by the following method: static void collect_children(void) { #ifndef HAVE_NETWARE pid_t pid; sigset_t oset, nset; int status; /* block SIGCHLD while we check for dead children */ sigemptyset(&nset); sigaddset(&nset, SIGCHLD); sigprocmask(SIG_BLOCK, &nset, &oset); if (child_terminated) { while ((pid = waitpid(-1, &status, WNOHANG)) > 0 || (pid < 0 && errno == EINTR)) if (pid > 0) session_close_by_pid(pid, status); child_terminated = 0; } sigprocmask(SIG_SETMASK, &oset, NULL); #endif } This code above seems quite odd in that it really should not be required to check the value of child_terminated before calling waitpid since WNOHANG is specified. If no child has had a state change then waitpid will return 0 which means that the while loop is not executed. The issue I was seeing is that SIGCHLD was not getting handled when sshd was started by honeyd using the -i flag. I commented out the if test on child_terminated and everything then worked as expected. My experience in general is that it is not good practice to rely on signals for IPC as they are not always reliable. In any case, I am not sure what the reason might be for such a convoluted mechanism just to avoid calling waitpid. Perhaps this code should just be modified to call waitpid whenever collect_children is executed? RH From pavelo at centrum.sk Tue Mar 24 11:48:54 2009 From: pavelo at centrum.sk (Pavel Labath) Date: Tue, 24 Mar 2009 01:48:54 +0100 Subject: OpenSSH GSoC Project In-Reply-To: <20090323233035.GF29122@crawfish.ais.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> Message-ID: <49C82DF6.705@centrum.sk> Thanks for the replies, Jim Knoble wrote: > Perhaps i misunderstand, but i think the intent of the GSoC description > is to make sftp(1) a potential replacement for scp(1), insofar as > non-interactive invocation from the shell prompt is concerned. Example: > > scp -p -r ./some_dir remote-host: > > Currently, sftp(1) understands neither '-p' nor '-r'. I agree, that's what the project description would seem to imply. However, both can be added in a matter of days. In fact the "get" command has a -P flag, so that just leaves -r and a command-line interface. And a comparison of man pages shows, that the remaining scp flags not available in sftp are: -2, -4, -6, -c cipher, -i identity, -q: implementation trivial - just pass to ssh -P port: the only complication is the presence of a conflicting switch -l limit: implementation fairly simple Hardly an all-summer project. That's why I suggested further improvements that could be done. to ke > It may be that the best way to do some of this would be the same way > F-Secure's SSH does it: use scp2(1), which would eventually completely > replace scp(1). I'll keep that in mind, thanks. > Again, look at LFTP for ideas. Actually, I did. :) Most of the suggestions are directly inspired by lftp. The other day I looked at man lftp, and was surprised that it can connect to sftp servers. So in a way, I would be duplicating work here, and that's one question I wanted answered (although I didn't state it explicitly). Is it worth it? One possible reason might be portability. I'm not sure, but I'd guess openssh runs of more arches than lftp, I'll have to check that. The other: we don't want them to be better than us :P Peter Lambrechtsen wrote: > Few other nice to haves: > > Transferring open files. Such as a "tail -f" being able to copy a > open log file, even if it is displayed as zero bytes try reading the > file and seeing how far you can go. An interesting idea, thank you. > Plus one other wishlist I had is "man-in-the-middle" scp / sftp. ie > scp user at hostname1:/file user2 at hostname2:/destdir. As I have a number > of areas where I have a DMZ server that can access two remote servers > in different zones, but the two servers cannot communicate with each > other, and I need to find a way to copy from one server to the other, > difficult if the DMZ server has a small amount of storage and you need > to copy a large file. Yes, that's what I meant be "server to server transfer". btw, scp claims to be able to do that. However, when I tried, it barked at me with the "remote host identification has changed" message. I'll try to figure it out when I am be able to keep my eyes open. peace, -- Pavel Labath From mouring at eviladmin.org Tue Mar 24 11:53:06 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 23 Mar 2009 19:53:06 -0500 Subject: OpenSSH GSoC Project In-Reply-To: <49C7F993.8040501@centrum.sk> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> Message-ID: On Mar 23, 2009, at 4:05 PM, Pavel Labath wrote: > Hi all, > > I too would like to apply for GSoC scholarship and work on sftp. > > I'm not sure if i should contact djm directly (you say he's swamped > with > emails, so i guess people are talking to him privately), but I thought > I'd write here. > > So, what are the features we want a polished sftp to have? The only > thing mentioned so far is the recursive up/down load, which looks more > like a thing for a two day hackfest than a all-summer-long $4.5k > operation. Features i would consider useful are: > - tab completion (both commands and filenames) - very useful, not > difficult A nearly completed version already exists. It just needs someone to do the final polish it and import it. The last version should be in bugzilla. - Ben From peter at stuge.se Tue Mar 24 12:54:47 2009 From: peter at stuge.se (Peter Stuge) Date: Tue, 24 Mar 2009 02:54:47 +0100 Subject: OpenSSH sftp GSoC Project In-Reply-To: <49C7F993.8040501@centrum.sk> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> Message-ID: <20090324015447.31717.qmail@stuge.se> Pavel Labath wrote: > Am I on the right track here? I definately think so! > PS: @Peter Stuge > What did you mean by the "internal structure in the sftp client > program"? You already answered that: > it doesn't have all the bells and whistles, > but that's what we're here to change. That was exactly what I meant. :) //Peter From sfandino at yahoo.com Tue Mar 24 22:13:18 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Tue, 24 Mar 2009 12:13:18 +0100 Subject: OpenSSH GSoC Project In-Reply-To: <20090323233035.GF29122@crawfish.ais.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> Message-ID: Jim Knoble wrote: > On 2009-03-23 16:05, Pavel Labath wrote: > > : So, what are the features we want a polished sftp to have? > > The best interactive terminal-based SFTP client i've used so far is LFTP > , by opening an URL like 'sftp://remote-host'. lftp is also my preferred SFTP (and FTP) client. One of these utilities I install on any machine I have to work with (if I can). > : The only thing mentioned so far is the recursive up/down load, which > : looks more like a thing for a two day hackfest than a all-summer-long > : $4.5k operation. > > Perhaps i misunderstand, but i think the intent of the GSoC description > is to make sftp(1) a potential replacement for scp(1), insofar as > non-interactive invocation from the shell prompt is concerned. Example: > > scp -p -r ./some_dir remote-host: > > Currently, sftp(1) understands neither '-p' nor '-r'. Obviously, > sftp(1) currently has some conflicting options, and it will be necessary > to balance compatibility with scp(1) against compatibilty with prior > versions of sftp(1). > > It may be that the best way to do some of this would be the same way > F-Secure's SSH does it: use scp2(1), which would eventually completely > replace scp(1). SFTP also has some drawbacks: - it is a talky protocol and so it doesn't perform too well on networks with (relatively) high latencies (though, it seems that the packet queue and packet size has been increased in latest OpenSSH versions, so this may not be the case anymore). - it is complex, there is no RFC, and implementations are based on the currently available and not completely compatible drafts. Interoperability is sometimes difficult. On the other hand... - even if there is no RFC for SCP, there is a reference implementation (rcp), and the protocol is so simple that it can be inferred just inspecting a couple of sessions. - It is very efficient when transferring large files. After some handshake, it just sends the file data over the ssh channel without any further protocol overhead or talk. - It is not unusual for administrators to disallow the sftp server as it gives too much power to the client, and allow remote file copy via scp only. Summarizing, IMO there is place for both protocols: SCP being simple, efficient and very interoperable and SFTP, allowing for more complex operations but with all the drawbacks that the higher complexity introduces. > That said, i often use either rsync(1) or combinations of ssh(1) and > tar(1) to do transfers from a shell command-line. Something I would find very useful would be some SFTP extension to allow implementation of some kind of rsync over SFTP. > : Features i would consider useful are: > : - tab completion (both commands and filenames) - very useful, not difficult > > Tab completion is nice. LFTP provides both local and remote filename > completion, but remote completion can sometimes take awhile, so beware. > > : - transfer resume (thanks Iain Morgan, I almost forgot) - very useful, > : not difficult > > Look at LFTP's interface for resuming ("continuing") a transfer. > > : - background transfer (possibly threads, or just fancy select() calls) - > : useful, not very difficult > > Again, look at LFTP for ideas. as LFTP already seems to do everything we need (and much more) and it is freely available, does really makes sense to reimplement its functionality inside sftp? why not just recommend it on the docs? I think that there are other more interesting areas to work on related to SFTP, for instance: - remove the max packet size limitation for read and write operations that forces SFTP clients to send/get data in chunks. File data could be moved directly between the network (actually from the slave SSH process pipes) and the on disk file without going to a memory buffer first. - implement an extension to allow rsync over SFTP (ssync :-) - implement fine grained access control for the SFTP server, limiting which SFTP operations are available (for instance, forbidding directory reading). - implement file locking - implement an extension to tell the client the encoding used on the server file system. - implement an extensible SFTP server in a high level language as Perl or Python. - etc. Cheers, - Salva From williamv at opera.com Wed Mar 25 00:59:54 2009 From: williamv at opera.com (William Viker) Date: Tue, 24 Mar 2009 14:59:54 +0100 Subject: A way to log what line of authorized_keys that was used Message-ID: Hi! I'm pretty sure that this isn't currently supported, so, I'll give it a shot and rather be rtfm-flamed instead of not trying :) Is there any way of logging what line of authorized_keys (and what file) that was used when a user logs in? It would be very nice to have to improve auditing logins of accounts with multiple publickeys. And, if there isn't - Would it be of interest to implement it in the future? Thanks! -- William Viker Opera Software ASA From mouring at eviladmin.org Wed Mar 25 02:08:10 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 24 Mar 2009 10:08:10 -0500 Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> Message-ID: On Mar 24, 2009, at 6:13 AM, Salvador Fandino wrote: > Jim Knoble wrote: >> On 2009-03-23 16:05, Pavel Labath wrote: [..] > - even if there is no RFC for SCP, there is a reference implementation > (rcp), and the protocol is so simple that it can be inferred just > inspecting a couple of sessions. - It is known to break very easily due to scp not being found in the user's path correctly (thus the reason "subsystems" came into being) - It is known to require double-escaping of arguments sometimes due to the interaction with shells on both sides. Which causes new users to complain that it is broken. For us to improve scp and make it a real program instead of a "tar | ssh tar"ish hack that it is right now. It would no longer be compatible with the existing scp. At that point, one may as well improve sftp since there is still time to nudge the draft into better shape. [..] >> That said, i often use either rsync(1) or combinations of ssh(1) and >> tar(1) to do transfers from a shell command-line. > > Something I would find very useful would be some SFTP extension to > allow > implementation of some kind of rsync over SFTP. I have a half-written rsync spec and proof of concept somewhere around my home directory. The problem with creating an rsync-like concept over sftp is the work needed to teach the sftp protocol how to correctly handle rolling checksums. No matter how I write the specs and how I implemented it the cost always felt too high, and in benchmarks against rsync it always lost out. sftp protocol doesn't lend itself well to it at this time. [..] >> Again, look at LFTP for ideas. > > as LFTP already seems to do everything we need (and much more) and > it is > freely available, does really makes sense to reimplement its > functionality inside sftp? why not just recommend it on the docs? Frankly, I don't want to install another 3rd party program and manage it along side OpenSSH. I'd rather have a reasonable sftp implementation so my users don't complain. > I think that there are other more interesting areas to work on related > to SFTP, for instance: > > - remove the max packet size limitation for read and write operations > that forces SFTP clients to send/get data in chunks. File data could > be > moved directly between the network (actually from the slave SSH > process > pipes) and the on disk file without going to a memory buffer first. I suspect that would break the current RFC draft. Thus would either an official way to detecting, or an unofficial hack, your talking to an older server. > - implement an extension to allow rsync over SFTP (ssync :-) > > - implement fine grained access control for the SFTP server, limiting > which SFTP operations are available (for instance, forbidding > directory > reading). The file permissions should be access control. Having yet another layer on top of it is silly. The only valid argument ftp has for doing such garbage is they support an "anonymous" mode where it isn't a real user. > - implement file locking > > - implement an extension to tell the client the encoding used on the > server file system. > > - implement an extensible SFTP server in a high level language as Perl > or Python. Ugh. No thank you. After dealing with broken scripts at least once a month I have no interest in seeing sftp-server become a script. Unless you don't use any CPAN modules there is no way to assure that your new sftp-server will be compatible with the perl version installed on the machine (nor is it installed on every class of machine). As for python it isn't installed by default under every OS. OpenSSH project already gets people whining that we have too many dependancies. - Ben From williamv at opera.com Wed Mar 25 02:27:49 2009 From: williamv at opera.com (William Viker) Date: Tue, 24 Mar 2009 16:27:49 +0100 Subject: A way to log what line of authorized_keys that was used In-Reply-To: <49C8F5A8.30005@fifthhorseman.net> References: <49C8F5A8.30005@fifthhorseman.net> Message-ID: On Tue, 24 Mar 2009 16:00:56 +0100, Daniel Kahn Gillmor wrote: > If you bump up LogLevel to VERBOSE in sshd_config, sshd will log the > fingerprint of the matching key. Is that sufficient for your purposes, > or do you want more detail? If you want more detail, what specifically > are you looking for? Hmm, yeah. Forgot that I've tried that before. It says something like Failed none for root from 213.236.208.22 port 26234 ssh2 Found matching DSA key: d7:6f:22:76:15:1c:11:10:86:9e:09:a5:d5:e7:7c:d7 Found matching DSA key: d7:6f:22:76:15:1c:11:10:86:9e:09:a5:d5:e7:7c:d7 Accepted publickey for root from 213.236.208.22 port 26234 ssh2 pam_unix(sshd:session): session opened for user root by (uid=0) There are only two problems 1) It doesn't say what file it found the keys in (but, it's probably semi-safe to assume (told user)/.ssh/authorized_keys 2) With many logins, could there be any chance that logentries get mixed? You don't get all information from the login on one line, or with a unique id/serial to follow 3) From the information the VERBOSE-log tells me, I cant see what TTY the user got. Would be nifty :) Just thinking :) -- William Viker Opera Software ASA From Jan.Pechanec at Sun.COM Wed Mar 25 02:29:36 2009 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Tue, 24 Mar 2009 16:29:36 +0100 (CET) Subject: A way to log what line of authorized_keys that was used In-Reply-To: References: Message-ID: On Tue, 24 Mar 2009, William Viker wrote: >Hi! > >I'm pretty sure that this isn't currently supported, so, I'll give it a >shot and rather be rtfm-flamed instead of not trying :) William, I don't think you want a line number since that piece of information can change in the future. What is supported is logging of the fingerprint of the matching key: fp = key_fingerprint(found, SSH_FP_MD5, SSH_FP_HEX); verbose("Found matching %s key: %s", key_type(found), fp); xfree(fp); see auth2-pub.c. You would have to raise the logging level from the default INFO to VERBOSE though. J. -- Jan Pechanec From dkg at fifthhorseman.net Wed Mar 25 02:40:33 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 24 Mar 2009 11:40:33 -0400 Subject: A way to log what line of authorized_keys that was used In-Reply-To: References: <49C8F5A8.30005@fifthhorseman.net> Message-ID: <49C8FEF1.30906@fifthhorseman.net> On 03/24/2009 11:27 AM, William Viker wrote: > There are only two problems > > 1) It doesn't say what file it found the keys in (but, it's > probably semi-safe to assume (told user)/.ssh/authorized_keys The file and matching line number appear to be emitted at LogLevel DEBUG1, though as Jan Pechanec noted, that info may change in the future (or even as a result of the specific ssh session!) > 2) With many logins, could there be any chance that logentries > get mixed? You don't get all information from the login on > one line, or with a unique id/serial to follow on my debian system, the data is logged in /var/log/auth.log, and prefixed by the process ID of the spawned sshd instance for the particular login. So you should be able to reconstruct individual threads by aggregating by process ID in most cases. > 3) From the information the VERBOSE-log tells me, I cant see > what TTY the user got. Would be nifty :) hey, that's three problems, not two problems! ;) sshd appears to produce the following line at DEBUG3: mm_answer_pty: tty /dev/pts/23 ptyfd 4 But as sshd_config(5) says: Logging with a DEBUG level violates the privacy of users and is not recommended. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090324/739e8d51/attachment.bin From dkg at fifthhorseman.net Wed Mar 25 02:00:56 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 24 Mar 2009 11:00:56 -0400 Subject: A way to log what line of authorized_keys that was used In-Reply-To: References: Message-ID: <49C8F5A8.30005@fifthhorseman.net> On 03/24/2009 09:59 AM, William Viker wrote: > I'm pretty sure that this isn't currently supported, so, I'll give it a > shot and rather be rtfm-flamed instead of not trying :) > > Is there any way of logging what line of authorized_keys (and what file) > that was used when a user logs in? It would be very nice to have to > improve auditing logins of accounts with multiple publickeys. If you bump up LogLevel to VERBOSE in sshd_config, sshd will log the fingerprint of the matching key. Is that sufficient for your purposes, or do you want more detail? If you want more detail, what specifically are you looking for? hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090324/65809d72/attachment.bin From gavinbeatty at gmail.com Wed Mar 25 04:07:12 2009 From: gavinbeatty at gmail.com (Gavin Beatty) Date: Tue, 24 Mar 2009 17:07:12 +0000 Subject: [PATCH] "Include" option for ssh configs Message-ID: Hello, Attached is a patch to add support for an "include" file in ssh configs. It is written against openssh-5.2p1. ## ~/.ssh/config Include ~/.ssh/config.contrib ## end - Leading ~/ expands to $HOME according to getpwuid_r?. - Leading ~username expands to $HOME for username according to getpwnam_r. - Fallbacks to /home/$USER are implemented for when struct passwd.pw_dir is NULL? after these calls. Files are parsed immediately in place and bad option counts are unique to each file. In this implementation, files that cannot be opened are error()d and ssh exits. There is rough documentation added to ssh_config.5. I haven't tested if the markup is correct as I don't know nroff. ? Note that I have used FOO_r functions. I will rewrite the patch if this does not fit your portability requirements or threads are not an issue or some such. ? I've never heard of this happening... -- Gavin Beatty SEMPER UBI SUB UBI -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-include.patch Type: text/x-patch Size: 5916 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090324/d3fed9d9/attachment.bin From imorgan at nas.nasa.gov Wed Mar 25 04:09:28 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 24 Mar 2009 10:09:28 -0700 Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> Message-ID: <20090324170928.GA31571@linux55.nas.nasa.gov> On Tue, Mar 24, 2009 at 06:13:18 -0500, Salvador Fandino wrote: > > > The best interactive terminal-based SFTP client i've used so far is LFTP > > , by opening an URL like 'sftp://remote-host'. > > lftp is also my preferred SFTP (and FTP) client. One of these utilities > I install on any machine I have to work with (if I can). > [snip] > > > Look at LFTP's interface for resuming ("continuing") a transfer. While lftp supports resuming, I'm not sure that it addresses the issue that the SFTP protocol allows file chunks to arrive out of order. Addressing this issue for get's is straightforward (Damien previously suggested a patch to sftp to address this) but addressing the issue for put's would (presumably) require server-side mods. [snip] > > Again, look at LFTP for ideas. > > as LFTP already seems to do everything we need (and much more) and it is > freely available, does really makes sense to reimplement its > functionality inside sftp? why not just recommend it on the docs? > While lftp has a rich user interface and supports a number of protocols, it does have some areas for improvement. As mentioned above, I'm not sure that it's resume support for SFTP is completely safe, but I haven't examined the code. The striping support is nice, but it only supports striped get's (pget) and has not support for striped put's. The striping model is also not ideal for single disk filesystems: it can cause a lot of head travel. However, the striping can improve preformance for high-latency connections. (It doesn't seem to be of benefit in the low-latency case.) I end up using a mixture of scp, sftp, and lftp for file transfers. If the command-line support for sftp were improved sufficiently, I would stop using scp. The biggest drawback for me with sftp is that it does not have good command-line support for uploading files. Downloading files is easy, but to upload you have to use batch mode. The main use I have for lftp is it's readlines support and striped transfers. I agree with Jim Knoble's comment that OpenSSH should provide a reasonable file transfer utility rather than recommending that users use a third-party utility. -- Iain Morgan From Jefferson.Ogata at noaa.gov Wed Mar 25 04:15:15 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 24 Mar 2009 17:15:15 +0000 Subject: [PATCH] "Include" option for ssh configs In-Reply-To: References: Message-ID: <49C91523.6080503@noaa.gov> On 2009-03-24 17:07, Gavin Beatty wrote: > - Fallbacks to /home/$USER are implemented for when struct passwd.pw_dir is > NULL? after these calls. That is a not such a hot idea. You don't know what /home/ is. On some systems it's an NFS mount. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From Jefferson.Ogata at noaa.gov Wed Mar 25 04:57:50 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 24 Mar 2009 17:57:50 +0000 Subject: [PATCH] "Include" option for ssh configs In-Reply-To: References: <49C91523.6080503@noaa.gov> Message-ID: <49C91F1E.7010700@noaa.gov> On 2009-03-24 17:39, Gavin Beatty wrote: > On Tue, Mar 24, 2009 at 5:15 PM, Jefferson Ogata > wrote: >> On 2009-03-24 17:07, Gavin Beatty wrote: >>> - Fallbacks to /home/$USER are implemented for when struct passwd.pw_dir is >>> NULL? after these calls. >> That is a not such a hot idea. You don't know what /home/ is. On some >> systems it's an NFS mount. > > It's a rather throwaway feature. If it's wanted, keep it. I thought > about gutting it out myself. Just delete two `else if' blocks whole. > > PS: I don't understand the significance of NFS in your example. The > probability of ~/.ssh/config also being on said NFS mount is near one. It's nowhere near one. Solaris traditionally uses /export/home for local home directories, and /home is an NFS mount point. IRIX traditionally uses /usr/people for home directories. Please don't make Linux-centric assumptions about people's filesystem layouts in a portable remote shell program. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From rob at nofocus.org Wed Mar 25 05:09:42 2009 From: rob at nofocus.org (Rob Banz) Date: Tue, 24 Mar 2009 18:09:42 +0000 Subject: [PATCH] "Include" option for ssh configs In-Reply-To: <49C91F1E.7010700@noaa.gov> References: <49C91523.6080503@noaa.gov> <49C91F1E.7010700@noaa.gov> Message-ID: > > It's nowhere near one. > > Solaris traditionally uses /export/home for local home directories, > and > /home is an NFS mount point. IRIX traditionally uses /usr/people for > home directories. Please don't make Linux-centric assumptions about > people's filesystem layouts in a portable remote shell program. > Agree; it should use what it gets from getpw* or nothing at all. Having it try to "guess" the person's home directory is just a $PATH to FAIL; heck, I've never used /export/home as a home directory on Solaris ;) -rob From jschauma at netmeister.org Wed Mar 25 03:33:16 2009 From: jschauma at netmeister.org (Jan Schaumann) Date: Tue, 24 Mar 2009 12:33:16 -0400 Subject: global no-agent-forwarding Message-ID: <20090324163315.GA25018@netmeister.org> Hi, I can disable agent-forwarding for any given key by prefixing it with "no-agent-forwarding", but it seems there's no global sshd_config setting for this (ie no "AgentForwarding [yes|no]"). Is this on purpose? If so, what's the rationale? -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090324/bd823264/attachment.bin From dkg at fifthhorseman.net Wed Mar 25 05:20:34 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 24 Mar 2009 14:20:34 -0400 Subject: global no-agent-forwarding In-Reply-To: <20090324163315.GA25018@netmeister.org> References: <20090324163315.GA25018@netmeister.org> Message-ID: <49C92472.3080401@fifthhorseman.net> On 03/24/2009 12:33 PM, Jan Schaumann wrote: > Hi, > > I can disable agent-forwarding for any given key by prefixing it with > "no-agent-forwarding", but it seems there's no global sshd_config > setting for this (ie no "AgentForwarding [yes|no]"). Is this on > purpose? If so, what's the rationale? sshd_config(5) shows: AllowAgentForwarding Specifies whether ssh-agent(1) forwarding is permitted. The default is ?yes?. Note that disabling agent forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090324/38826200/attachment.bin From jschauma at netmeister.org Wed Mar 25 05:39:00 2009 From: jschauma at netmeister.org (Jan Schaumann) Date: Tue, 24 Mar 2009 14:39:00 -0400 Subject: global no-agent-forwarding In-Reply-To: <49C92472.3080401@fifthhorseman.net> References: <20090324163315.GA25018@netmeister.org> <49C92472.3080401@fifthhorseman.net> Message-ID: <20090324183900.GC25018@netmeister.org> Daniel Kahn Gillmor wrote: > sshd_config(5) shows: > > AllowAgentForwarding Ah, only available since 5.1. Nevermind, then. Thanks, -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090324/1e0ae5d2/attachment.bin From jmknoble at pobox.com Wed Mar 25 05:51:39 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 24 Mar 2009 13:51:39 -0500 Subject: OpenSSH GSoC Project In-Reply-To: <20090324170928.GA31571@linux55.nas.nasa.gov> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <20090324170928.GA31571@linux55.nas.nasa.gov> Message-ID: <20090324185139.GI29122@crawfish.ais.com> On 2009-03-24 12:09, Iain Morgan wrote: : I agree with Jim Knoble's comment that OpenSSH should provide a : reasonable file transfer utility rather than recommending that users use : a third-party utility. Actually, that was Ben Lindstrom's comment, but i agree as well. :) -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) From mouring at eviladmin.org Wed Mar 25 06:56:32 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 24 Mar 2009 14:56:32 -0500 Subject: Match rules question In-Reply-To: <49C8FEF1.30906@fifthhorseman.net> References: <49C8F5A8.30005@fifthhorseman.net> <49C8FEF1.30906@fifthhorseman.net> Message-ID: Currently I see that "PubkeyAuthentication" is currently excluded as being usable with the Match command in 5.1 and 5.2. Is there a reason for this? There is a discussion in-house where we'd like to do: PubkeyAuthentication no Match Address [INTERNAL-IP-LIST] PubkeyAuthentication Yes The main reason is these are DMZ boxes where the primary authentication method should be RSA keyfobs, but there is a need for a few accounts (from the internal network only) to allow Public key authentication to push files. Looking at the list of what is acceptable to use with the Match command I can't find anything else that would let me do this. Suggestions for the short term (short of running two SSH servers)? And would it accepted to get that added to the Match support? - Ben From gavinbeatty at gmail.com Wed Mar 25 04:39:15 2009 From: gavinbeatty at gmail.com (Gavin Beatty) Date: Tue, 24 Mar 2009 17:39:15 +0000 Subject: [PATCH] "Include" option for ssh configs In-Reply-To: <49C91523.6080503@noaa.gov> References: <49C91523.6080503@noaa.gov> Message-ID: On Tue, Mar 24, 2009 at 5:15 PM, Jefferson Ogata wrote: > On 2009-03-24 17:07, Gavin Beatty wrote: >> - Fallbacks to /home/$USER are implemented for when struct passwd.pw_dir is >> NULL? after these calls. > > That is a not such a hot idea. You don't know what /home/ is. On some > systems it's an NFS mount. It's a rather throwaway feature. If it's wanted, keep it. I thought about gutting it out myself. Just delete two `else if' blocks whole. PS: I don't understand the significance of NFS in your example. The probability of ~/.ssh/config also being on said NFS mount is near one. -- Gavin Beatty SEMPER UBI SUB UBI From tortay at cc.in2p3.fr Wed Mar 25 07:35:51 2009 From: tortay at cc.in2p3.fr (Loic Tortay) Date: Tue, 24 Mar 2009 21:35:51 +0100 Subject: Match rules question In-Reply-To: References: <49C8F5A8.30005@fifthhorseman.net> <49C8FEF1.30906@fifthhorseman.net> Message-ID: <49C94427.6000807@cc.in2p3.fr> Ben Lindstrom wrote: > Currently I see that "PubkeyAuthentication" is currently excluded as > being usable with the Match command in 5.1 and 5.2. Is there a reason > for this? There is a discussion in-house where we'd like to do: > > PubkeyAuthentication no > > Match Address [INTERNAL-IP-LIST] > PubkeyAuthentication Yes > It's already available, this is a bug in the man page. Lo?c. -- From imorgan at nas.nasa.gov Wed Mar 25 08:38:34 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 24 Mar 2009 14:38:34 -0700 Subject: Match rules question In-Reply-To: References: <49C8F5A8.30005@fifthhorseman.net> <49C8FEF1.30906@fifthhorseman.net> Message-ID: <20090324213834.GA2360@linux55.nas.nasa.gov> On Tue, Mar 24, 2009 at 14:56:32 -0500, Ben Lindstrom wrote: > > Currently I see that "PubkeyAuthentication" is currently excluded as > being usable with the Match command in 5.1 and 5.2. Is there a reason > for this? There is a discussion in-house where we'd like to do: > > PubkeyAuthentication no > > Match Address [INTERNAL-IP-LIST] > PubkeyAuthentication Yes > Did you actually test this or are you going by the man page? I don't see pubkeyauthentication listed as one of the allowed options under the Match directive, but a glance at servconf.c indicates that it is supported. Likewise, sshd -t against an sshd_config similar to the one above does not complain. This looks to me like it's a documentation bug. In any case, please file a bug at https://bugzilla.mindrot.org so the issue does not get forgotten. -- Iain Morgan From imorgan at nas.nasa.gov Wed Mar 25 08:42:20 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 24 Mar 2009 14:42:20 -0700 Subject: OpenSSH GSoC Project In-Reply-To: <20090324185139.GI29122@crawfish.ais.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <20090324170928.GA31571@linux55.nas.nasa.gov> <20090324185139.GI29122@crawfish.ais.com> Message-ID: <20090324214220.GB2360@linux55.nas.nasa.gov> Thanks for the correction. Sorry for the wrong attribution. On Tue, Mar 24, 2009 at 13:51:39 -0500, Jim Knoble wrote: > On 2009-03-24 12:09, Iain Morgan wrote: > > : I agree with Jim Knoble's comment that OpenSSH should provide a > : reasonable file transfer utility rather than recommending that users use > : a third-party utility. > > Actually, that was Ben Lindstrom's comment, but i agree as well. :) > > -- > jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ > (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) > (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From mouring at eviladmin.org Wed Mar 25 09:36:58 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 24 Mar 2009 17:36:58 -0500 Subject: Match rules question In-Reply-To: <20090324213834.GA2360@linux55.nas.nasa.gov> References: <49C8F5A8.30005@fifthhorseman.net> <49C8FEF1.30906@fifthhorseman.net> <20090324213834.GA2360@linux55.nas.nasa.gov> Message-ID: <700C23A3-A62A-49DE-BCBC-1CC9A8B29616@eviladmin.org> On Mar 24, 2009, at 4:38 PM, Iain Morgan wrote: > On Tue, Mar 24, 2009 at 14:56:32 -0500, Ben Lindstrom wrote: >> >> Currently I see that "PubkeyAuthentication" is currently excluded as >> being usable with the Match command in 5.1 and 5.2. Is there a >> reason >> for this? There is a discussion in-house where we'd like to do: >> >> PubkeyAuthentication no >> >> Match Address [INTERNAL-IP-LIST] >> PubkeyAuthentication Yes >> > > Did you actually test this or are you going by the man page? I don't > see > pubkeyauthentication listed as one of the allowed options under the > Match directive, but a glance at servconf.c indicates that it is > supported. Likewise, sshd -t against an sshd_config similar to the one > above does not complain. Actually I assumed the manpage was right (one of the few projects that tends to have good manpages). > This looks to me like it's a documentation bug. In any case, please > file > a bug at https://bugzilla.mindrot.org so the issue does not get > forgotten. I'll valid it soon and throw a bug against it. Seemed odd to that it wouldn't be there. - Ben From djm at mindrot.org Wed Mar 25 12:41:00 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Mar 2009 12:41:00 +1100 (EST) Subject: 2009 Google Summer of Code Message-ID: Hi, Over the last two weeks I have received a large number of emails regarding OpenSSH's participation in the 2009 Google Summer of Code program. This email should answer the questions that you collectively asked. Please forgive this bulk reply - there are simply too many of you to reply to individually. If I have failed to answer your question, please feel free to email me again. If you haven't already done so, please read the GSoC FAQ: http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Here are the answers to your questions: 1. Applications Quite a few of you sent applications to participate to me directly. I'm not able to act on these unless they are made though the application tool on the GSoC website http://socghop.appspot.com/ so please make your application there. 2. Decision criteria When assessing the applications the things that I will be looking for will be: 1) A demonstration of understanding of the problem/idea that the student has chosen. 2) Evidence that they have the necessary skills to take it on. This may take the form of prior free software contributions, patch submissions or code samples that I can look at. Academic experience alone is likely to be insufficient. 3) A good schedule of tasks to implement the idea and a realistic time-line for completing them. We *strongly* favour decomposition of work into smaller units that can be reviewed and completed independently and it is not a coincidence that the ideas that we have listed can be broken down in this way. Students who go a little beyond the stated requirements (e.g. by including "stretch goals") while still remaining realistic in their proposals will be preferred. 3. Start date The official GSoC start date for contributors is May 23, but some of you have asked about starting early. Students starting the actual work early is OK, but I think there is some advantage of familiarising oneself with the project, its source code, practices and culture first. The GSoC includes two months of "Community Bonding Period" to facilitate this, but if the student feels that they are ready sooner then that is OK. 4. Level of commitment Some of you asked about how of your time you would have to dedicate to work on GSoC projects. This is completely up to you! You should decide your own level of commitment and base your proposals around that. Obviously, students with more ambitious proposals will have some advantage (so long as they are realistic), but we certainly don't want to burn you out and sour your experience with free software development. 5. Assessment This being the first time OpenSSH has participated in GSoC, I'm ignorant of what criteria the program will ask us to use when evaluating students' work. From my perspective, the main criteria will be "how much have they improved OpenSSH?" Bear in mind that improving OpenSSH means getting code completed, reviewed and committed to our CVS repository 6. Specific projects Many of the questions were about the specific ideas that we had listed on http://www.openssh.com/gsoc.html so here is some more detail on each: 6.1 Renovate sftp The motivation for this idea is to make sftp(1) a compelling replacement for scp(1). scp(1) has a very easy to use command-line interface, supports recursive copies ("scp -r") and is quite fast - it does not need a server round-trip for each file that it copies. Unfortunately scp(1) is unmaintainable - its protocol practically requires shell access and has no backwards compatibility or extensibility support. So this project would be adding these missing features to sftp(1) and exposing them via a commandline that is as compatible with scp(1)'s as possible. Beyond this baseline, there are a number of other things that may be done to improve sftp(1): - Implement tab-completion in interactive mode. Ben Lindstrom has written a patch to implement this, and it only needs a tiny amount of work to get it committed. - Improve the interactive interface. Right now, things like "get file1 file2 file3" don't work, or don't do what one might normally expect. Also, the sftp client currently requires read access to every component of the patch in which it is operating (i.e. traverse-only directories break it) - there is no protocol-level reason why this needs to be the case so this could be fixed fairly easily too. 6.2 Improved testing infrastructure There weren't too many questions on this. I hope the description given at http://www.openssh.com/gsoc.html#testing was enough explanation to get someone started. 6.3 Performance improvements There are three main metrics by which OpenSSH's performance may be measured when performing some operation such as transferring a directory of files, connect to a server or moving a fixed quantity of data: - How long does it take? - How much CPU time does it take? - How much memory does it take? Environmental considerations can affect these, especially network latency. Over the last couple of releases, we have worked to improve transfer speed on high bandwidth*delay links as well as general CPU performance, but there is certainly more that can be done especially in the area of memory consumption. The first step would be to develop some good benchmarks that measure various aspects of OpenSSH's performance. Ideally, these should be able to be run alongside the standard suite of regression tests so we can ensure that we do not regress performance-wise in the future. >From there, the student would need to identify and fix performance bottlenecks or waste. There is an external project http://www.psc.edu/networking/projects/hpn-ssh/ that has conducted quite a bit of work on making OpenSSH faster which a student could use as a resource. 6.4 Other projects There were a couple of people who suggested writing GUI frontends to parts of OpenSSH. This might be a good idea, but its not something that we would accept as a GSoC project - we aren't likely to ever ship GUI tools in OpenSSH and I personally lack the necessary experience to properly assess contributions in this area. ---- Thank you all very much for your interest, and please feel welcome to send any additional questions to myself or to the public OpenSSH mailing list: https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Regards, Damien Miller From sfandino at yahoo.com Wed Mar 25 18:48:34 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Wed, 25 Mar 2009 00:48:34 -0700 (PDT) Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> Message-ID: <457843.52100.qm@web52707.mail.re2.yahoo.com> ----- Original Message ---- > From: Ben Lindstrom > To: Salvador Fandino > Cc: openssh-unix-dev at mindrot.org > Sent: Tuesday, March 24, 2009 4:08:10 PM > Subject: Re: OpenSSH GSoC Project > > > - remove the max packet size limitation for read and write operations > > that forces SFTP clients to send/get data in chunks. File data could be > > moved directly between the network (actually from the slave SSH process > > pipes) and the on disk file without going to a memory buffer first. > > I suspect that would break the current RFC draft. Thus would either an official > way to detecting, or an unofficial hack, your talking to an older server. The draft requires the server to accept at least 32KB packets, but it doesn't limit the maximum size in any way. An entry on the INIT reply could be used to tell the client the maximum packet size. > > - implement an extension to allow rsync over SFTP (ssync :-) > > > > - implement fine grained access control for the SFTP server, limiting > > which SFTP operations are available (for instance, forbidding directory > > reading). > > The file permissions should be access control. Having yet another layer on top > of it is silly. The only valid argument ftp has for doing such garbage is they > support an "anonymous" mode where it isn't a real user. That's like saying that firewalls are useless because access control can be performed at the service level Being able to stablish policies from a central point would be a real advantage. > > - implement an extensible SFTP server in a high level language as Perl > > or Python. > > Ugh. No thank you. After dealing with broken scripts at least once a month I > have no interest in seeing sftp-server become a script. Unless you don't use > any CPAN modules there is no way to assure that your new sftp-server will be > compatible with the perl version installed on the machine (nor is it installed > on every class of machine). As for python it isn't installed by > default under every OS. I am not proposing to replace sftp-server with a Perl script, I am just saying that it wold be interesting to have an implementation in a high level language to allow others to extend it in any way they want: access control, loging, generating content on the fly, triggers, whatever... Cheers, - Salva From gavinbeatty at gmail.com Wed Mar 25 22:37:13 2009 From: gavinbeatty at gmail.com (Gavin Beatty) Date: Wed, 25 Mar 2009 11:37:13 +0000 Subject: [PATCH] "Include" option for ssh configs In-Reply-To: <49C91F1E.7010700@noaa.gov> References: <49C91523.6080503@noaa.gov> <49C91F1E.7010700@noaa.gov> Message-ID: On Tue, Mar 24, 2009 at 5:57 PM, Jefferson Ogata wrote: > On 2009-03-24 17:39, Gavin Beatty wrote: >> PS: I don't understand the significance of NFS in your example. The >> probability of ~/.ssh/config also being on said NFS mount is near one. > > It's nowhere near one. > > Solaris traditionally uses /export/home for local home directories, and > /home is an NFS mount point. IRIX traditionally uses /usr/people for > home directories. Please don't make Linux-centric assumptions about > people's filesystem layouts in a portable remote shell program. I wasn't intentionally wearing my Linux hat. Wrong is wrong though - apologies. SUSv3 is open again. I've removed the offending fallback and re-attached the patch. Also fixed is a bug where long usernames in ~someloooooongusername/config would truncate after L_cuserid chars, expanding to someloooo, say, whose passwd entry would be checked. Also, the expanded string would not be of the form $HOME/config for someloooo's home (not that that is the biggest problem). Big Bug. Now, username length is memory-bound. I take it that FOO_r functions are similarly not portable enough. Attached is another patch which incorporates the above changes _and_ uses the non-reentrant versions. Are there any other issues? On Tue, Mar 24, 2009 at 6:09 PM, Rob Banz wrote: > [snip] heck, I've never used /export/home as a home directory on > Solaris ;) +1 :S -- Gavin Beatty SEMPER UBI SUB UBI -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-include-no-home-fallback.patch Type: text/x-patch Size: 5743 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090325/e48c9760/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-include-no-home-fallback-no-reentrancy.patch Type: text/x-patch Size: 5293 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090325/e48c9760/attachment-0003.bin From djm at mindrot.org Wed Mar 25 23:06:24 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Mar 2009 23:06:24 +1100 (EST) Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: On Mon, 23 Mar 2009, Jan Pechanec wrote: > On Mon, 23 Mar 2009, Jawaad Ahmad wrote: > > >Also, I'm curious about the rationale for this. Why beef up sftp to > >handle this if scp already takes care of it? Do you envision cases in > >which scp is available but sftp is not? > > SFTP is a different protocol, a real one, and while still in a > draft, will hopefully become an RFC some day. It's rather a file system > protocol now. See this: > > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ Unfortunately, I think the changes of sftp becoming an RFC sunk when people started cramming it with irrelevant features ahead of actual implementation experience. IMO someone should pick the 03 version of the draft and publish it as an informational RFC - it is what everyone implements and its extension mechanism allows most of the features that others wanted anyway. -d From djm at mindrot.org Wed Mar 25 23:07:25 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Mar 2009 23:07:25 +1100 (EST) Subject: SFTP (was Re:GSoC) In-Reply-To: <78DD71C304F38B41885A242996B96F7301C85AE5@xyservd.XYPRO-23.LOCAL> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <78DD71C304F38B41885A242996B96F7301C85A9E@xyservd.XYPRO-23.LOCAL> <78DD71C304F38B41885A242996B96F7301C85AE5@xyservd.XYPRO-23.LOCAL> Message-ID: On Mon, 23 Mar 2009, Scott Neugroschl wrote: > > From: Jan.Pechanec at Sun.COM [mailto:Jan.Pechanec at Sun.COM] > > >Since SFTP appears to be on the RFC track, how does one go about > > >proposing > > >protocol extensions? In particular, an "append" command, similar to > > >that > > >of FTP? > > > > I don't think you need it, see O_APPEND in the draft. J. > > > Hi Jan, > > I assume you mean SSH_FXF_APPEND? > > Is there any reason it hasn't been implemented in sftp-server yet (as of > 5.2p1), or in the SFTP client? nobody has every asked for it before. -d From djm at mindrot.org Wed Mar 25 23:13:42 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Mar 2009 23:13:42 +1100 (EST) Subject: 2009 Google Summer of Code In-Reply-To: References: Message-ID: On Wed, 25 Mar 2009, Damien Miller wrote: > 6.1 Renovate sftp > > The motivation for this idea is to make sftp(1) a compelling replacement > for scp(1). scp(1) has a very easy to use command-line interface, > supports recursive copies ("scp -r") and is quite fast - it does not > need a server round-trip for each file that it copies. Unfortunately > scp(1) is unmaintainable - its protocol practically requires shell > access and has no backwards compatibility or extensibility support. > > So this project would be adding these missing features to sftp(1) and > exposing them via a commandline that is as compatible with scp(1)'s as > possible. Beyond this baseline, there are a number of other things that > may be done to improve sftp(1): > > - Implement tab-completion in interactive mode. Ben Lindstrom has written > a patch to implement this, and it only needs a tiny amount of work to > get it committed. > > - Improve the interactive interface. Right now, things like > "get file1 file2 file3" don't work, or don't do what one might normally > expect. > > Also, the sftp client currently requires read access to every > component of the patch in which it is operating (i.e. traverse-only > directories break it) - there is no protocol-level reason why this needs > to be the case so this could be fixed fairly easily too. Implementing an rsync-like protocol would be a great project for sftp as well. Such an implementation would need to be from scratch, since rsync's license is incompatible with our preferred license for OpenSSH. -d From djm at mindrot.org Wed Mar 25 23:18:54 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Mar 2009 23:18:54 +1100 (EST) Subject: OpenSSH GSoC Project In-Reply-To: <457843.52100.qm@web52707.mail.re2.yahoo.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <457843.52100.qm@web52707.mail.re2.yahoo.com> Message-ID: On Wed, 25 Mar 2009, Salvador Fandino wrote: > > > - remove the max packet size limitation for read and write operations > > > that forces SFTP clients to send/get data in chunks. File data could be > > > moved directly between the network (actually from the slave SSH process > > > pipes) and the on disk file without going to a memory buffer first. > > > > I suspect that would break the current RFC draft. Thus would either an official > > way to detecting, or an unofficial hack, your talking to an older server. > > The draft requires the server to accept at least 32KB packets, but it > doesn't limit the maximum size in any way. An entry on the INIT reply > could be used to tell the client the maximum packet size. Why bother? With the current packet size the overhead is something like 30KB per GB of data transferred, but increasing this makes the protocol perform worse for multiple concurrent operations (which we admittedly underutilise now) and less responsive to early aborts, etc. > > > - implement an extension to allow rsync over SFTP (ssync :-) > > > > > > - implement fine grained access control for the SFTP server, limiting > > > which SFTP operations are available (for instance, forbidding directory > > > reading). > > > > The file permissions should be access control. Having yet another > > layer on top of it is silly. The only valid argument ftp has for > > doing such garbage is they support an "anonymous" mode where it > > isn't a real user. > > That's like saying that firewalls are useless because access control > can be performed at the service level > > Being able to stablish policies from a central point would be a real > advantage. We have ChrootDirectory that can be used to limit sftp access to subtrees of the file system. Perhaps sftp-server could benefit from a read-only mode, but I think that too many access control options just lead to confusion. > I am not proposing to replace sftp-server with a Perl script, I am just > saying that it wold be interesting to have an implementation in a high > level language to allow others to extend it in any way they want: > access control, loging, generating content on the fly, triggers, > whatever... Something like this might be useful to improve testing of both the client and server. The sftp protocol is so simple that it would be quite easy to write. -d From peter at stuge.se Wed Mar 25 23:32:23 2009 From: peter at stuge.se (Peter Stuge) Date: Wed, 25 Mar 2009 13:32:23 +0100 Subject: OpenSSH GSoC Project In-Reply-To: <457843.52100.qm@web52707.mail.re2.yahoo.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <457843.52100.qm@web52707.mail.re2.yahoo.com> Message-ID: <20090325123223.14266.qmail@stuge.se> Salvador Fandino wrote: > I am just saying that it wold be interesting to have an > implementation in a high level language to allow others to extend > it in any way they want: > access control, loging, generating content on the fly, triggers, > whatever... Yes. Maybe you work with tree structures other than the filesystem. Accessing an RDBMS over SFTP is not a bad idea. :) //Peter From sfandino at yahoo.com Thu Mar 26 00:34:21 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Wed, 25 Mar 2009 06:34:21 -0700 (PDT) Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <457843.52100.qm@web52707.mail.re2.yahoo.com> Message-ID: <426836.87492.qm@web52708.mail.re2.yahoo.com> ----- Original Message ---- > From: Damien Miller > To: Salvador Fandino > Cc: Ben Lindstrom ; openssh-unix-dev at mindrot.org > Sent: Wednesday, March 25, 2009 1:18:54 PM > Subject: Re: OpenSSH GSoC Project > > Why bother? With the current packet size the overhead is something like > 30KB per GB of data transferred, but increasing this makes the protocol > perform worse for multiple concurrent operations (which we admittedly > underutilise now) and less responsive to early aborts, etc. The problem is not overhead but latency, at least in theory. With current configuration, we have 32KB packet-length * 64 max-packets-queued = 2MB of data on the "air", so for instance, if the communication line supports 4MB/s, but the roundtrip is 1 second, only 50% of the bandwidth will be used (AFAIK, the underlaying SSH transport does not use any ACK mechanism internally and so is not affected by round-trip, and TCP can handle that delays also). I suppose those would be rare cases in practice, so probably, it doesn't worth the trouble... - Salva From mouring at eviladmin.org Thu Mar 26 02:07:17 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 25 Mar 2009 10:07:17 -0500 Subject: OpenSSH GSoC Project In-Reply-To: <457843.52100.qm@web52707.mail.re2.yahoo.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <457843.52100.qm@web52707.mail.re2.yahoo.com> Message-ID: <547A347E-ED6C-4A0A-AAA7-6BB98CC62F58@eviladmin.org> On Mar 25, 2009, at 2:48 AM, Salvador Fandino wrote: >>> - implement fine grained access control for the SFTP server, >>> limiting >>> which SFTP operations are available (for instance, forbidding >>> directory >>> reading). >> >> The file permissions should be access control. Having yet another >> layer on top >> of it is silly. The only valid argument ftp has for doing such >> garbage is they >> support an "anonymous" mode where it isn't a real user. > > That's like saying that firewalls are useless because access control > can be performed at the service level > Being able to stablish policies from a central point would be a real > advantage. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You just gutted your argument right there and you are agreeing with my above comment. The "central point" for establishing policies is your filesystem and not the sftp-server. The sftp-server is a one-off method for file access (same with scp, ftp, rcp, http, samba, nfs, or any other "fille access" protocol), because it isn't the central source of truth but only the an additional restriction control for a single access point. By putting the restrictions in sftp-server you break the concept of setting policies in one spot and now have to go through two layers of "filesystem" like properties to figure out what is going on. - Ben From pavelo at centrum.sk Thu Mar 26 05:10:31 2009 From: pavelo at centrum.sk (Pavel Labath) Date: Wed, 25 Mar 2009 19:10:31 +0100 Subject: OpenSSH GSoC Project In-Reply-To: <20090324170928.GA31571@linux55.nas.nasa.gov> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <20090324170928.GA31571@linux55.nas.nasa.gov> Message-ID: <49CA7397.2010302@centrum.sk> Iain Morgan wrote: > While lftp supports resuming, I'm not sure that it addresses the issue > that the SFTP protocol allows file chunks to arrive out of order. > Addressing this issue for get's is straightforward (Damien previously > suggested a patch to sftp to address this) but addressing the issue for > put's would (presumably) require server-side mods. If the file for upload is opened in append mode (which isn't possible yet, but...), then the client would have to send (and the server process) chunks in sequence. The server can reorder requests, only if the overall effect remains the same (although I find the wording in the draft a bit ambiguous). Then it would be up to the client to deliver the requests in proper order, thereby ensuring that the file doesn't have "holes" even in case of a system failure. Performance shouldn't be affected since the current server processes the requests serially anyway (and I can't imagine, why it would be faster to do them out of order). Speaking of holes... What about sparse files? I don't know how many people actually transfer sparse files, but in case the protocol is used as a filesystem it could happen. Optimizing puts is easy. Gets would need an extension -- a flag telling that the chunk is empty. Or maybe just drop it and let ssh's compression deal with it? Also, I had an idea about decreasing latency on small file transfers. Right now a small (< chunk size) file needs 3 message-response pairs to transfer -- open, read/write, close (although the last could be, in theory, sent even before the second completes). However, if we add a message "open file X, read/write Y bytes and (possibly) close it" then it could be done in one round-trip. And one could send a bunch of these messages together. This works best for upload since you know the size of the file, but download could benefit as well. On the other hand, it complicates the protocol (what should be done if open succeeds, but write fails? ...) so I'm not sure if it's worth it, I'm just brainstorming here. I suppose testing would be needed. -- Pavel Labath From djm at mindrot.org Thu Mar 26 08:40:16 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Mar 2009 08:40:16 +1100 (EST) Subject: OpenSSH GSoC Project In-Reply-To: <426836.87492.qm@web52708.mail.re2.yahoo.com> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <457843.52100.qm@web52707.mail.re2.yahoo.com> <426836.87492.qm@web52708.mail.re2.yahoo.com> Message-ID: On Wed, 25 Mar 2009, Salvador Fandino wrote: > > From: Damien Miller > > To: Salvador Fandino > > Cc: Ben Lindstrom ; openssh-unix-dev at mindrot.org > > Sent: Wednesday, March 25, 2009 1:18:54 PM > > Subject: Re: OpenSSH GSoC Project > > > > Why bother? With the current packet size the overhead is something like > > 30KB per GB of data transferred, but increasing this makes the protocol > > perform worse for multiple concurrent operations (which we admittedly > > underutilise now) and less responsive to early aborts, etc. > > The problem is not overhead but latency, at least in theory. > > With current configuration, we have 32KB packet-length * 64 > max-packets-queued = 2MB of data on the "air", so for instance, if > the communication line supports 4MB/s, but the roundtrip is 1 second, > only 50% of the bandwidth will be used (AFAIK, the underlaying SSH > transport does not use any ACK mechanism internally and so is not > affected by round-trip, and TCP can handle that delays also). Sure, but this can be trivially changed from either the commandline or the code so it can hardly be used as an argument that sftp is inherently slow. It might be a good project for GSoC to make this automatically tune itself. -d From djm at mindrot.org Thu Mar 26 09:57:32 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Mar 2009 09:57:32 +1100 (EST) Subject: OpenSSH GSoC Project In-Reply-To: <49CA7397.2010302@centrum.sk> References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> <20090323165849.10363.qmail@stuge.se> <20090323201404.GA17426@linux55.nas.nasa.gov> <49C7F993.8040501@centrum.sk> <20090323233035.GF29122@crawfish.ais.com> <20090324170928.GA31571@linux55.nas.nasa.gov> <49CA7397.2010302@centrum.sk> Message-ID: On Wed, 25 Mar 2009, Pavel Labath wrote: > Also, I had an idea about decreasing latency on small file transfers. > Right now a small (< chunk size) file needs 3 message-response pairs to > transfer -- open, read/write, close (although the last could be, in > theory, sent even before the second completes). However, if we add a > message "open file X, read/write Y bytes and (possibly) close it" then > it could be done in one round-trip. And one could send a bunch of these > messages together. This works best for upload since you know the size of > the file, but download could benefit as well. On the other hand, it > complicates the protocol (what should be done if open succeeds, but > write fails? ...) so I'm not sure if it's worth it, I'm just > brainstorming here. I suppose testing would be needed. I think the way to do this is to pipeline the opens as well as the read/writes. I.e. open a (small) window of file handles at the start of a multi-file transfer and maintain this window as file transfers complete. So an upload session might look like this: C->S open(a) C->S open(b) S->C handle for a C->S open(c) S->C handle for b C->S open(d) S->C handle for c C->S block 0..512 for a S->C handle for d C->S block 512..1024 for a S->C ack for a C->S block 1024..1536 for a S->C ack for a C->S close(a) C->S open(e) S->C ack for a C->S block 0..512 for b S->C ack for close a S->C handle for e C->S block 512..1024 for b ... and so forth Also, we don't pipeline readdir() calls at the moment - this is another easy opportunity for improvement. -d From Jan.Pechanec at Sun.COM Thu Mar 26 22:35:41 2009 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Thu, 26 Mar 2009 12:35:41 +0100 (CET) Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: On Wed, 25 Mar 2009, Damien Miller wrote: >> SFTP is a different protocol, a real one, and while still in a >> draft, will hopefully become an RFC some day. It's rather a file system >> protocol now. See this: >> >> http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ > >Unfortunately, I think the changes of sftp becoming an RFC sunk when >people started cramming it with irrelevant features ahead of actual >implementation experience. IMO someone should pick the 03 version of >the draft and publish it as an informational RFC - it is what everyone >implements and its extension mechanism allows most of the features that >others wanted anyway. some SFTP implementations on Win platform support version 4. That's defined in draft-ietf-secsh-filexfer-04.txt, and the next -05.txt bumps up the version further to 5 which seems to make bigger changes. In contrast to version 3, version 4 supports ACLs which I think is a good thing. In general version 4 seems to make the protocol more system independent (I guess that might be why 4 is implemented in apps used on Win...). -- Jan Pechanec From sfandino at yahoo.com Thu Mar 26 22:48:39 2009 From: sfandino at yahoo.com (Salvador Fandino) Date: Thu, 26 Mar 2009 12:48:39 +0100 Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: Jan Pechanec wrote: > some SFTP implementations on Win platform support version 4. That's > defined in draft-ietf-secsh-filexfer-04.txt, and the next -05.txt bumps up draft-ietf-secsh-filexfer-02.txt defines version 3 of the protocol, draft-ietf-secsh-filexfer-03.txt defines version 4 of the protocol, ... Cheers, - Salva From djm at mindrot.org Thu Mar 26 22:56:42 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Mar 2009 22:56:42 +1100 (EST) Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: On Thu, 26 Mar 2009, Jan Pechanec wrote: > some SFTP implementations on Win platform support version 4. That's > defined in draft-ietf-secsh-filexfer-04.txt, and the next -05.txt bumps up > the version further to 5 which seems to make bigger changes. In contrast to > version 3, version 4 supports ACLs which I think is a good thing. There are many ways to implement ACLs; I'm not sure whether draft 04's representation is sufficiently general. Moreover, I don't think sftp should really aspire to be a universal remote filesystem protocol - It condemns us to re-implement every feature of every filesystem and we already have NFS for that :) > In general version 4 seems to make the protocol more system > independent (I guess that might be why 4 is implemented in apps used > on Win...). Yes, it added "text mode" transfers. This was one of the primary reasons that we stopped tracking newer versions of the drafts - "text mode" transfers are probably responsible for more corrupted files than all the bit-errors in the FTP protocol's life. -d From Jan.Pechanec at Sun.COM Thu Mar 26 22:59:32 2009 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Thu, 26 Mar 2009 12:59:32 +0100 (CET) Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: On Thu, 26 Mar 2009, Salvador Fandino wrote: >> some SFTP implementations on Win platform support version 4. That's >> defined in draft-ietf-secsh-filexfer-04.txt, and the next -05.txt bumps up > >draft-ietf-secsh-filexfer-02.txt defines version 3 of the protocol, >draft-ietf-secsh-filexfer-03.txt defines version 4 of the protocol, and that is updated in -04.txt so that's the one defining the version 4. J. -- Jan Pechanec From Jan.Pechanec at Sun.COM Thu Mar 26 23:11:25 2009 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Thu, 26 Mar 2009 13:11:25 +0100 (CET) Subject: OpenSSH GSoC Project In-Reply-To: References: <1237491407.20077.55.camel@garfield.waady.gotdns.org> <1237824028.20077.104.camel@garfield.waady.gotdns.org> Message-ID: On Thu, 26 Mar 2009, Damien Miller wrote: >There are many ways to implement ACLs; I'm not sure whether draft 04's >representation is sufficiently general. Moreover, I don't think sftp >should really aspire to be a universal remote filesystem protocol - it probably shouldn't and it very well could be the reason why the last version of the draft is from 2006. >It condemns us to re-implement every feature of every filesystem and we >already have NFS for that :) I agree with the yet-another filesystem protocol approach problem but for me personaly, ACLs with a file *transfer* are still OK because it could help to adopt the one common SFTP protocol version. >> In general version 4 seems to make the protocol more system >> independent (I guess that might be why 4 is implemented in apps used >> on Win...). > >Yes, it added "text mode" transfers. This was one of the primary reasons >that we stopped tracking newer versions of the drafts - "text mode" >transfers are probably responsible for more corrupted files than all the >bit-errors in the FTP protocol's life. ah, I see it now. I didn't know about that. Yeah, I always hated text mode transfers in FTP. My point was that if the version 4 could be a better candidate for the general consensus it might be worth it. Unfortunately the text mode is mandatory. On the other hand, if it's not the default transfer mode most people will not hit it and those who knows about it should know how to use it. -- Jan Pechanec From miguel.sanders at arcelormittal.com Sat Mar 28 04:29:32 2009 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Fri, 27 Mar 2009 18:29:32 +0100 Subject: Patch for default Kerbers realm in AIX Message-ID: <7DF29B50FFF41848BB2281EC2E71A206AF3A9A@GEN-MXB-V04.msad.arcelor.net> Hi I'm currently observing a rather bizarre situation when using password based Kerberos authentication in OpenSSH on AIX. Even though AIX can authenticate a user via Kerberos (using the KRB5A load module), OpenSSH cannot Kerberos authenticate this user. This is caused by the fact that the user has two attributes which OpenSSH doesn't take into account when forming the principal name of the user (attributes auth_name and auth_domain). If AIX user, myuser, has the attributes auth_name=someone and auth_domain=SOMEWHERE, then the Kerberos principal name would be someone at SOMEWHERE instead of myuser at DEFAULTREALM. By using the auth_domain attribute, requests are sent to to the SOMEWHERE realm instead of the default realm DEFAULTREALM, which is listed in the libdefaults section of the krb5.conf configuration file. If I look at the code I can see the following in auth-krb5.c on line 88, which causes this behaviour: problem = krb5_parse_name(authctxt->krb5_ctx, authctxt->pw->pw_name,&authctxt->krb5_user); Since authctxt->pw->pw_name contains only the user name (without a realm), the default realm will be automatically appended according to the documentation of the krb5_parse_name call. Since this isn't the correct realm name (the overwritten auth_domain is the correct one), Kerberos authentication fails. If the auth_domain attribute is not set, the default realm name will be used. Since this is rather new for me, I don't know what the procedure is to supply a patch for this. Any pointers? Thank you very much! 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 peter at stuge.se Sat Mar 28 06:28:29 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 27 Mar 2009 20:28:29 +0100 Subject: Patch for default Kerbers realm in AIX In-Reply-To: <7DF29B50FFF41848BB2281EC2E71A206AF3A9A@GEN-MXB-V04.msad.arcelor.net> References: <7DF29B50FFF41848BB2281EC2E71A206AF3A9A@GEN-MXB-V04.msad.arcelor.net> Message-ID: <20090327192829.8750.qmail@stuge.se> Interesting. If there are no gotchas I'm sure this is desirable for OpenSSH, but I know very little about krb5 so I can't say. miguel.sanders at arcelormittal.com wrote: > Since this is rather new for me, I don't know what the procedure is > to supply a patch for this. Any pointers? Simply send a patch to the mailing list for review and inclusion. Please make sure to check out the latest available sources from CVS and work out the patch from there. Thanks! //Peter From scott_n at xypro.com Sat Mar 28 06:35:17 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 27 Mar 2009 12:35:17 -0700 Subject: Patch for default Kerbers realm in AIX In-Reply-To: <20090327192829.8750.qmail@stuge.se> References: <7DF29B50FFF41848BB2281EC2E71A206AF3A9A@GEN-MXB-V04.msad.arcelor.net> <20090327192829.8750.qmail@stuge.se> Message-ID: <78DD71C304F38B41885A242996B96F7301C86026@xyservd.XYPRO-23.LOCAL> > Interesting. If there are no gotchas I'm sure this is desirable for > OpenSSH, but I know very little about krb5 so I can't say. > > miguel.sanders at arcelormittal.com wrote: > > Since this is rather new for me, I don't know what the procedure is > > to supply a patch for this. Any pointers? > > Simply send a patch to the mailing list for review and inclusion. > Please make sure to check out the latest available sources from CVS > and work out the patch from there. > I believe Simon Wilkinson reads this list, and he'd be a good person to review it. From miguel.sanders at arcelormittal.com Sat Mar 28 20:14:55 2009 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Sat, 28 Mar 2009 10:14:55 +0100 Subject: Patch for default Kerbers realm in AIX In-Reply-To: <20090327192829.8750.qmail@stuge.se> References: <7DF29B50FFF41848BB2281EC2E71A206AF3A9A@GEN-MXB-V04.msad.arcelor.net> <20090327192829.8750.qmail@stuge.se> Message-ID: <7DF29B50FFF41848BB2281EC2E71A206AF3AA6@GEN-MXB-V04.msad.arcelor.net> Thanks. I will make the patch and send it to the list for review. 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 -----Oorspronkelijk bericht----- Van: openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org [mailto:openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org] Namens Peter Stuge Verzonden: vrijdag 27 maart 2009 20:28 Aan: openssh-unix-dev at mindrot.org Onderwerp: Re: Patch for default Kerbers realm in AIX Interesting. If there are no gotchas I'm sure this is desirable for OpenSSH, but I know very little about krb5 so I can't say. miguel.sanders at arcelormittal.com wrote: > Since this is rather new for me, I don't know what the procedure is to > supply a patch for this. Any pointers? Simply send a patch to the mailing list for review and inclusion. Please make sure to check out the latest available sources from CVS and work out the patch from there. Thanks! //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev **** 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 aphexer at mailhaven.com Sun Mar 29 06:21:50 2009 From: aphexer at mailhaven.com (Alexander Prinsier) Date: Sat, 28 Mar 2009 20:21:50 +0100 Subject: ChrootDirectory security Message-ID: <49CE78CE.5030203@mailhaven.com> Hello, I've tried many places, finally ending up here to ask my question: why is it so vital that the directory used with the ChrootDirectory directive is root-owned? Like many people I'm trying to use this in a webhosting environment where several users get sftp-only access to some directory, usually something like /home/user/web/part-of-website. I can be sure that there are no setuid binaries in /home, so that rules out some possible vulnerabilities. Could anyone tell me what other problems a non-root-owned chroot directory could create? Thanks! (Please CC me). Alexander From thesource at ldb-jab.org Sun Mar 29 10:20:06 2009 From: thesource at ldb-jab.org (LDB) Date: Sat, 28 Mar 2009 19:20:06 -0400 Subject: ChrootDirectory security In-Reply-To: <49CE78CE.5030203@mailhaven.com> References: <49CE78CE.5030203@mailhaven.com> Message-ID: <49CEB0A6.6060704@master.ldb-jab.org> Alexander Prinsier wrote: > Hello, > > I've tried many places, finally ending up here to ask my question: why > is it so vital that the directory used with the ChrootDirectory > directive is root-owned? > > Like many people I'm trying to use this in a webhosting environment > where several users get sftp-only access to some directory, usually > something like /home/user/web/part-of-website. > > I can be sure that there are no setuid binaries in /home, so that rules > out some possible vulnerabilities. Could anyone tell me what other > problems a non-root-owned chroot directory could create? > > Thanks! > > (Please CC me). > > Alexander > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > I would say this pretty much answers your questions ... http://unixwiz.net/techtips/chroot-practices.html From djm at mindrot.org Sun Mar 29 19:54:21 2009 From: djm at mindrot.org (Damien Miller) Date: Sun, 29 Mar 2009 18:54:21 +1000 (EST) Subject: ChrootDirectory security In-Reply-To: <49CE78CE.5030203@mailhaven.com> References: <49CE78CE.5030203@mailhaven.com> Message-ID: On Sat, 28 Mar 2009, Alexander Prinsier wrote: > Hello, > > I've tried many places, finally ending up here to ask my question: why > is it so vital that the directory used with the ChrootDirectory > directive is root-owned? > > Like many people I'm trying to use this in a webhosting environment > where several users get sftp-only access to some directory, usually > something like /home/user/web/part-of-website. > > I can be sure that there are no setuid binaries in /home, so that rules > out some possible vulnerabilities. Could anyone tell me what other > problems a non-root-owned chroot directory could create? Basically because having a non-root-user-writable root directory (i.e. what chroot(2) without a root-ownership test gives you) can be exploited through setuid programs, and because sshd has no way of determining whether setuid programs exist in the chroot. -d From aphexer at mailhaven.com Mon Mar 30 10:39:56 2009 From: aphexer at mailhaven.com (Alexander Prinsier) Date: Mon, 30 Mar 2009 01:39:56 +0200 Subject: ChrootDirectory security In-Reply-To: References: <49CE78CE.5030203@mailhaven.com> Message-ID: <49D006CC.8080809@mailhaven.com> Damien Miller wrote: >> I can be sure that there are no setuid binaries in /home, so that rules >> out some possible vulnerabilities. Could anyone tell me what other >> problems a non-root-owned chroot directory could create? > > Basically because having a non-root-user-writable root directory (i.e. > what chroot(2) without a root-ownership test gives you) can be exploited > through setuid programs, and because sshd has no way of determining > whether setuid programs exist in the chroot. Thanks! I'm going to have to modify sshd to remove this root-ownership-check then. (I'm sure there are no setuid programs in /home, and never will be). Any chance there would once be an option to turn this check off in the config file? Alexander From peter at stuge.se Mon Mar 30 11:55:36 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 30 Mar 2009 02:55:36 +0200 Subject: ChrootDirectory security In-Reply-To: <49D006CC.8080809@mailhaven.com> References: <49CE78CE.5030203@mailhaven.com> <49D006CC.8080809@mailhaven.com> Message-ID: <20090330005536.21776.qmail@stuge.se> Hi, Alexander Prinsier wrote: > I'm sure there are no setuid programs in /home, and never will be How can you be sure? Do you enforce permissions? Are you sure no other part of the system can (accidentally, or with "help") write to /home? //Peter From aphexer at mailhaven.com Mon Mar 30 12:11:48 2009 From: aphexer at mailhaven.com (Alexander Prinsier) Date: Mon, 30 Mar 2009 03:11:48 +0200 Subject: ChrootDirectory security In-Reply-To: <20090330005536.21776.qmail@stuge.se> References: <49CE78CE.5030203@mailhaven.com> <49D006CC.8080809@mailhaven.com> <20090330005536.21776.qmail@stuge.se> Message-ID: <49D01C54.50406@mailhaven.com> Peter Stuge wrote: > Alexander Prinsier wrote: >> I'm sure there are no setuid programs in /home, and never will be > > How can you be sure? Do you enforce permissions? Are you sure no > other part of the system can (accidentally, or with "help") write > to /home? Well never 100% sure of course ;) But still... -How could a setuid program end up in /home? (Unless root, being me, does chmod u+s somewhere in /home (or a hardlinked file), but I'm assuming I'm not that stupid). -But on the other hand: suppose there is a setuid program in /home. I'm only offering sftp access. How could they execute the setuid program from within a sftp session? Alexander From Jefferson.Ogata at noaa.gov Mon Mar 30 12:17:46 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 30 Mar 2009 01:17:46 +0000 Subject: ChrootDirectory security In-Reply-To: <49D01C54.50406@mailhaven.com> References: <49CE78CE.5030203@mailhaven.com> <49D006CC.8080809@mailhaven.com> <20090330005536.21776.qmail@stuge.se> <49D01C54.50406@mailhaven.com> Message-ID: <49D01DBA.8000609@noaa.gov> On 2009-03-30 01:11, Alexander Prinsier wrote: > Well never 100% sure of course ;) But still... > > -How could a setuid program end up in /home? (Unless root, being me, > does chmod u+s somewhere in /home (or a hardlinked file), but I'm > assuming I'm not that stupid). > > -But on the other hand: suppose there is a setuid program in /home. I'm > only offering sftp access. How could they execute the setuid program > from within a sftp session? If you want to be sure, mount /home with the nosetuid option. -- 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 Mar 30 16:48:32 2009 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Mon, 30 Mar 2009 07:48:32 +0200 Subject: Patch for default Kerbers realm in AIX In-Reply-To: <7DF29B50FFF41848BB2281EC2E71A206AF3AA6@GEN-MXB-V04.msad.arcelor.net> References: <7DF29B50FFF41848BB2281EC2E71A206AF3A9A@GEN-MXB-V04.msad.arcelor.net><20090327192829.8750.qmail@stuge.se> <7DF29B50FFF41848BB2281EC2E71A206AF3AA6@GEN-MXB-V04.msad.arcelor.net> Message-ID: <7DF29B50FFF41848BB2281EC2E71A206AF3ABF@GEN-MXB-V04.msad.arcelor.net> Hi I made a patch which addresses this issue. Can someone please review this? Thanks! 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 -----Oorspronkelijk bericht----- Van: openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org [mailto:openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org] Namens miguel.sanders at arcelormittal.com Verzonden: zaterdag 28 maart 2009 10:15 Aan: openssh-unix-dev at mindrot.org Onderwerp: RE: Patch for default Kerbers realm in AIX Thanks. I will make the patch and send it to the list for review. 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 -----Oorspronkelijk bericht----- Van: openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org [mailto:openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org] Namens Peter Stuge Verzonden: vrijdag 27 maart 2009 20:28 Aan: openssh-unix-dev at mindrot.org Onderwerp: Re: Patch for default Kerbers realm in AIX Interesting. If there are no gotchas I'm sure this is desirable for OpenSSH, but I know very little about krb5 so I can't say. miguel.sanders at arcelormittal.com wrote: > Since this is rather new for me, I don't know what the procedure is to > supply a patch for this. Any pointers? Simply send a patch to the mailing list for review and inclusion. Please make sure to check out the latest available sources from CVS and work out the patch from there. Thanks! //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev **** 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. **** _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev **** 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 miguel.sanders at arcelormittal.com Mon Mar 30 17:02:14 2009 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Mon, 30 Mar 2009 08:02:14 +0200 Subject: Patch for default Kerbers realm in AIX In-Reply-To: <7DF29B50FFF41848BB2281EC2E71A206AF3ABF@GEN-MXB-V04.msad.arcelor.net> References: <7DF29B50FFF41848BB2281EC2E71A206AF3A9A@GEN-MXB-V04.msad.arcelor.net><20090327192829.8750.qmail@stuge.se><7DF29B50FFF41848BB2281EC2E71A206AF3AA6@GEN-MXB-V04.msad.arcelor.net> <7DF29B50FFF41848BB2281EC2E71A206AF3ABF@GEN-MXB-V04.msad.arcelor.net> Message-ID: <7DF29B50FFF41848BB2281EC2E71A206AF3AC6@GEN-MXB-V04.msad.arcelor.net> Apparently, there is a problem when submitting the patch via mail You can find it here aswell. ftp://6tvLa11g:ZB0b073qxZ at 193.121.250.205 Thanks for reviewing 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 -----Oorspronkelijk bericht----- Van: openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org [mailto:openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org] Namens miguel.sanders at arcelormittal.com Verzonden: maandag 30 maart 2009 7:49 Aan: openssh-unix-dev at mindrot.org Onderwerp: RE: Patch for default Kerbers realm in AIX Hi I made a patch which addresses this issue. Can someone please review this? Thanks! 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 -----Oorspronkelijk bericht----- Van: openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org [mailto:openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org] Namens miguel.sanders at arcelormittal.com Verzonden: zaterdag 28 maart 2009 10:15 Aan: openssh-unix-dev at mindrot.org Onderwerp: RE: Patch for default Kerbers realm in AIX Thanks. I will make the patch and send it to the list for review. 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 -----Oorspronkelijk bericht----- Van: openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org [mailto:openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org] Namens Peter Stuge Verzonden: vrijdag 27 maart 2009 20:28 Aan: openssh-unix-dev at mindrot.org Onderwerp: Re: Patch for default Kerbers realm in AIX Interesting. If there are no gotchas I'm sure this is desirable for OpenSSH, but I know very little about krb5 so I can't say. miguel.sanders at arcelormittal.com wrote: > Since this is rather new for me, I don't know what the procedure is to > supply a patch for this. Any pointers? Simply send a patch to the mailing list for review and inclusion. Please make sure to check out the latest available sources from CVS and work out the patch from there. Thanks! //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev **** 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. **** _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev **** 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. **** **** 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 peter at stuge.se Mon Mar 30 18:02:18 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 30 Mar 2009 09:02:18 +0200 Subject: Patch for default Kerbers realm in AIX In-Reply-To: <7DF29B50FFF41848BB2281EC2E71A206AF3AC6@GEN-MXB-V04.msad.arcelor.net> References: <7DF29B50FFF41848BB2281EC2E71A206AF3ABF@GEN-MXB-V04.msad.arcelor.net> <7DF29B50FFF41848BB2281EC2E71A206AF3AC6@GEN-MXB-V04.msad.arcelor.net> Message-ID: <20090330070218.17624.qmail@stuge.se> miguel.sanders at arcelormittal.com wrote: > Apparently, there is a problem when submitting the patch via mail Strange, I think a small patch like this should make it onto the list without problems. > You can find it here aswell. This is simple enough that it may not matter, but for the future please remember to use diff -U because the output is much more readable. Thanks! //Peter From miguel.sanders at arcelormittal.com Mon Mar 30 18:18:44 2009 From: miguel.sanders at arcelormittal.com (miguel.sanders at arcelormittal.com) Date: Mon, 30 Mar 2009 09:18:44 +0200 Subject: Patch for default Kerbers realm in AIX In-Reply-To: <20090330070218.17624.qmail@stuge.se> References: <7DF29B50FFF41848BB2281EC2E71A206AF3ABF@GEN-MXB-V04.msad.arcelor.net><7DF29B50FFF41848BB2281EC2E71A206AF3AC6@GEN-MXB-V04.msad.arcelor.net> <20090330070218.17624.qmail@stuge.se> Message-ID: <7DF29B50FFF41848BB2281EC2E71A206AF3B24@GEN-MXB-V04.msad.arcelor.net> Sorry for that. I'll think of it in the future! 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 -----Oorspronkelijk bericht----- Van: openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org [mailto:openssh-unix-dev-bounces+miguel.sanders=arcelormittal.com at mindrot.org] Namens Peter Stuge Verzonden: maandag 30 maart 2009 9:02 Aan: openssh-unix-dev at mindrot.org Onderwerp: Re: Patch for default Kerbers realm in AIX miguel.sanders at arcelormittal.com wrote: > Apparently, there is a problem when submitting the patch via mail Strange, I think a small patch like this should make it onto the list without problems. > You can find it here aswell. This is simple enough that it may not matter, but for the future please remember to use diff -U because the output is much more readable. Thanks! //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev **** 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 josterm at raytheon.com Tue Mar 31 00:39:43 2009 From: josterm at raytheon.com (Jason E Ostermann) Date: Mon, 30 Mar 2009 08:39:43 -0500 Subject: Jason Ostermann is out of the office. Message-ID: I will be out of the office starting Sun 03/22/2009 and will not return until Mon 04/06/2009. I am on travel until Apr but will check email and voicemail daily. If this is an urgent issue, please contact Kevin Cariker (kcarike at raytheon.com, 972-205-8399) or Barry Dowell (barry_dowell at raytheon.com, 972-205-6318) Thanks! Jason From ssahoo2 at illinois.edu Tue Mar 31 08:02:36 2009 From: ssahoo2 at illinois.edu (Swarup Kumar Sahoo) Date: Mon, 30 Mar 2009 16:02:36 -0500 (CDT) Subject: help needed for survey Message-ID: <20090330160236.BWI93738@expms5.cites.uiuc.edu> Hi, We are working on a project related to software bugs of server applications at univ of Illinois at Urbana Champaign. We need to do a survey based on lots of past bugs. It will of great help, if someone can point where I can get such a list of past and current bugs, possibly with the fixes for us to analyze. This is just a survey and there should not be any security related issues. Thanks in advance. Regards, Swarup. ************************************* Swarup Kumar Sahoo Thomas M. Siebel Center for Computer Science University of Illinois at Urbana Champaign 201 N Goodwin Avenue Urbana, IL-61801 Phone - 614 264 9574 From djm at mindrot.org Tue Mar 31 14:01:26 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 31 Mar 2009 13:01:26 +1000 (EST) Subject: help needed for survey In-Reply-To: <20090330160236.BWI93738@expms5.cites.uiuc.edu> References: <20090330160236.BWI93738@expms5.cites.uiuc.edu> Message-ID: On Mon, 30 Mar 2009, Swarup Kumar Sahoo wrote: > Hi, > We are working on a project related to software bugs of server > applications at univ of Illinois at Urbana Champaign. We need to do a > survey based on lots of past bugs. It will of great help, if someone > can point where I can get such a list of past and current bugs, > possibly with the fixes for us to analyze. This is just a survey and > there should not be any security related issues. Thanks in advance. Bugs are tracked at our bugzilla: https://bugzilla.mindrot.org/ Fixes will be in the CVS commits, we generally try to quote the bug number in the commit message. The CVS tree may be accessed anonymously using the instructions at: http://www.openssh.com/portable.html#cvs Hope this helps, Damien Miller From chrivers at iversen-net.dk Tue Mar 31 23:33:45 2009 From: chrivers at iversen-net.dk (Christian Iversen) Date: Tue, 31 Mar 2009 14:33:45 +0200 Subject: About multiple hosts with same hostname Message-ID: <49D20DA9.9040404@iversen-net.dk> Hello all I have a somewhat annoying problem with OpenSSH. Now, granted, it's certainly not a bug. I'm just wondering what the best course of action is. At work, we have multiple customers with machines named "fw0", "fs0", etc. This is all good, since it conforms to a standard naming scheme, so it's easier to administrate. However, when we go to our customers' sites, we often issue commands like "ssh user at fw0", which of course gives out endless warnings about MITM attacks, and essentially makes host keys worthless on the internal customer networks. It seems somewhat wrong to me. Isn't there some way to make OpenSSH save the host key using the FQDN instead of just the local part? That would solve this problem. Is there some other commonly accepted way of dealing with this that doesn't involve making all our host names unique? Bonus question: We have 2 storage servers (let's call them storage0 and storage1), and between them they run a floating IP address with a heartbeat-monitored NFS daemon (let's call that nfs0). Now, obviously the host key changes whenever there's been a failover, and so again we get this same kind of problem. What to do in this case? Any ideas? Thank you all for your time. -- Med venlig hilsen Christian Iversen