From mludvig at suse.cz Thu Jul 1 01:18:14 2004 From: mludvig at suse.cz (Michal Ludvig) Date: Wed, 30 Jun 2004 17:18:14 +0200 Subject: OpenSSL ENIGNE support for OpenSSH Message-ID: <40E2D9B6.2000500@suse.cz> Hi all, attached is a patch that enables using hardware crypto accelerators available through OpenSSL library for SSH operations. Especially in ssh/sshd it can bring a significant speed improvement. OTOH if no crypto engine is available, nothing bad happens and default software crypto routines are used. This patch is used in SUSE Linux OpenSSH package and proved to work (at least it didn't break anything) both with and without crypto engines. Tested also with VIA PadLock crypto engine (patches for OpenSSL are at http://www.logix.cz/michal/devel/padlock/ ) Would you consider including it in the official OpenSSH release? Thanks! Michal Ludvig -- SUSE Labs mludvig at suse.cz (+420) 296.545.396 http://www.suse.cz Personal homepage http://www.logix.cz/michal -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-3.8p1-engines.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040630/0ca79630/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040630/0ca79630/attachment.bin From dan at doxpara.com Thu Jul 1 06:51:26 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Jun 2004 13:51:26 -0700 Subject: OpenSSL ENIGNE support for OpenSSH In-Reply-To: <40E2D9B6.2000500@suse.cz> References: <40E2D9B6.2000500@suse.cz> Message-ID: <40E327CE.8060202@doxpara.com> Michal-- For what possible reason does OpenSSL not do engine initialization by default? --Dan Michal Ludvig wrote: >Hi all, > >attached is a patch that enables using hardware crypto accelerators >available through OpenSSL library for SSH operations. Especially in >ssh/sshd it can bring a significant speed improvement. OTOH if no crypto >engine is available, nothing bad happens and default software crypto >routines are used. > >This patch is used in SUSE Linux OpenSSH package and proved to work (at >least it didn't break anything) both with and without crypto engines. >Tested also with VIA PadLock crypto engine (patches for OpenSSL are at >http://www.logix.cz/michal/devel/padlock/ ) > >Would you consider including it in the official OpenSSH release? > >Thanks! > >Michal Ludvig > > >------------------------------------------------------------------------ > ># Load drivers for available hardware crypto accelerators. ># -- mludvig at suse.cz >Index: openssh-3.8p1/ssh-add.c >=================================================================== >--- openssh-3.8p1.orig/ssh-add.c >+++ openssh-3.8p1/ssh-add.c >@@ -38,6 +38,7 @@ > RCSID("$OpenBSD: ssh-add.c,v 1.69 2003/11/21 11:57:03 djm Exp $"); > > #include >+#include > > #include "ssh.h" > #include "rsa.h" >@@ -325,6 +326,10 @@ main(int argc, char **argv) > > SSLeay_add_all_algorithms(); > >+ /* Init available hardware crypto engines. */ >+ ENGINE_load_builtin_engines(); >+ ENGINE_register_all_complete(); >+ > /* At first, get a connection to the authentication agent. */ > ac = ssh_get_authentication_connection(); > if (ac == NULL) { >Index: openssh-3.8p1/ssh-agent.c >=================================================================== >--- openssh-3.8p1.orig/ssh-agent.c >+++ openssh-3.8p1/ssh-agent.c >@@ -39,6 +39,7 @@ RCSID("$OpenBSD: ssh-agent.c,v 1.117 200 > > #include > #include >+#include > > #include "ssh.h" > #include "rsa.h" >@@ -1025,6 +1026,10 @@ main(int ac, char **av) > > SSLeay_add_all_algorithms(); > >+ /* Init available hardware crypto engines. */ >+ ENGINE_load_builtin_engines(); >+ ENGINE_register_all_complete(); >+ > __progname = ssh_get_progname(av[0]); > init_rng(); > seed_rng(); >Index: openssh-3.8p1/ssh-keygen.c >=================================================================== >--- openssh-3.8p1.orig/ssh-keygen.c >+++ openssh-3.8p1/ssh-keygen.c >@@ -16,6 +16,7 @@ RCSID("$OpenBSD: ssh-keygen.c,v 1.113 20 > > #include > #include >+#include > > #include "xmalloc.h" > #include "key.h" >@@ -807,6 +808,11 @@ main(int ac, char **av) > __progname = ssh_get_progname(av[0]); > > SSLeay_add_all_algorithms(); >+ >+ /* Init available hardware crypto engines. */ >+ ENGINE_load_builtin_engines(); >+ ENGINE_register_all_complete(); >+ > log_init(av[0], SYSLOG_LEVEL_INFO, SYSLOG_FACILITY_USER, 1); > > init_rng(); >Index: openssh-3.8p1/ssh-keysign.c >=================================================================== >--- openssh-3.8p1.orig/ssh-keysign.c >+++ openssh-3.8p1/ssh-keysign.c >@@ -27,6 +27,7 @@ RCSID("$OpenBSD: ssh-keysign.c,v 1.15 20 > #include > #include > #include >+#include > > #include "log.h" > #include "key.h" >@@ -182,6 +183,11 @@ main(int argc, char **argv) > pw = pwcopy(pw); > > SSLeay_add_all_algorithms(); >+ >+ /* Init available hardware crypto engines. */ >+ ENGINE_load_builtin_engines(); >+ ENGINE_register_all_complete(); >+ > for (i = 0; i < 256; i++) > rnd[i] = arc4random(); > RAND_seed(rnd, sizeof(rnd)); >Index: openssh-3.8p1/ssh.c >=================================================================== >--- openssh-3.8p1.orig/ssh.c >+++ openssh-3.8p1/ssh.c >@@ -44,6 +44,7 @@ RCSID("$OpenBSD: ssh.c,v 1.206 2003/12/1 > > #include > #include >+#include > > #include "ssh.h" > #include "ssh1.h" >@@ -512,6 +513,10 @@ again: > SSLeay_add_all_algorithms(); > ERR_load_crypto_strings(); > >+ /* Init available hardware crypto engines. */ >+ ENGINE_load_builtin_engines(); >+ ENGINE_register_all_complete(); >+ > /* Initialize the command to execute on remote host. */ > buffer_init(&command); > >Index: openssh-3.8p1/sshd.c >=================================================================== >--- openssh-3.8p1.orig/sshd.c >+++ openssh-3.8p1/sshd.c >@@ -48,6 +48,7 @@ RCSID("$OpenBSD: sshd.c,v 1.286 2004/02/ > #include > #include > #include >+#include > #ifdef HAVE_SECUREWARE > #include > #include >@@ -991,6 +992,10 @@ main(int ac, char **av) > SSLeay_add_all_algorithms(); > channel_set_af(IPv4or6); > >+ /* Init available hardware crypto engines. */ >+ ENGINE_load_builtin_engines(); >+ ENGINE_register_all_complete(); >+ > /* > * Force logging to stderr until we have loaded the private host > * key (unless started from inetd) > > >------------------------------------------------------------------------ > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From holder at sw.oz.au Thu Jul 1 17:46:49 2004 From: holder at sw.oz.au (holder at sw.oz.au) Date: Thu, 01 Jul 2004 07:46:49 +0000 Subject: software In-Reply-To: References: Message-ID: <0A8G1FA606K9EB75@sw.oz.au> Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Our site is http://RpkcC.cnhdcdai.info/?h0jSj2hQWRoG3NNpK Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://wtGBLQB.gcabmebm.info/?ETaJGp8HhILxW88jlMf HFUOrWfE narBP jRbmurZ PKGrx yUTJHNq lThE FmtUmB vdLn fZTxZzi FRHdL oMuefGLm kqAu kMVHQHV XHEvHeE mXk pIBe eFjJrxW JYpVK k DDTzA From mludvig at suse.cz Thu Jul 1 20:11:05 2004 From: mludvig at suse.cz (Michal Ludvig) Date: Thu, 01 Jul 2004 12:11:05 +0200 Subject: OpenSSL ENIGNE support for OpenSSH In-Reply-To: <40E327CE.8060202@doxpara.com> References: <40E2D9B6.2000500@suse.cz> <40E327CE.8060202@doxpara.com> Message-ID: <40E3E339.3070204@suse.cz> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Kaminsky told me that: > Michal-- > > For what possible reason does OpenSSL not do engine initialization by > default? Hmm, who knows? All engines do startup checks whether or not the hardware is available so I don't see a reason why to not load them. I'll ask OpenSSL developers... Michal Ludvig - -- SUSE Labs mludvig at suse.cz (+420) 296.545.396 http://www.suse.cz Personal homepage http://www.logix.cz/michal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA4+M3DDolCcRbIhgRAjSZAKCLU0AHzQdmEIejtTaCRC4gmF0oqQCdGP+p wOf4A1nT/v2pX/mExnGaW+0= =+LV5 -----END PGP SIGNATURE----- From inouk at igt.net Thu Jul 1 21:02:26 2004 From: inouk at igt.net (Eric LeBlanc) Date: Thu, 1 Jul 2004 07:02:26 -0400 (EDT) Subject: How create multiples ssh on same host without asking same password Message-ID: Hello, I used the SecureShell windows client from ssh.com and it have a cool feature: Once I logged on a server with ssh, I was able to create more terminals without being asked for a password again. It seems that it use the 'same channel' created from the first ssh client. So, it's possible with openssh on linux/bsd? If yes, how? If not, can you add this feature? Why I ask taht? Because it's really annoying when I have a SecureID key, and I must wait 1 minute between login.. When I want to open 10 terms, it will take more than 10 minutes and 30 seconds just to log in. Also, I like to enter the password ONE time. Thanks for your help! E. -- Eric LeBlanc inouk at igt.net -------------------------------------------------- UNIX is user friendly. It's just selective about who its friends are. ================================================== From dtucker at zip.com.au Thu Jul 1 21:11:07 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 01 Jul 2004 21:11:07 +1000 Subject: How create multiples ssh on same host without asking same password In-Reply-To: References: Message-ID: <40E3F14B.9020300@zip.com.au> Eric LeBlanc wrote: > I used the SecureShell windows client from ssh.com and it have a cool > feature: Once I logged on a server with ssh, I was able to create more > terminals without being asked for a password again. It seems that it use > the 'same channel' created from the first ssh client. > > So, it's possible with openssh on linux/bsd? If yes, how? If not, can you > add this feature? Yes, but only in the development version, it hasn't made it to a release yet. Try a development snapshot: ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ and check the man page entries for ControlMaster and ControlPath. -- 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 djm at mindrot.org Thu Jul 1 21:10:48 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 01 Jul 2004 21:10:48 +1000 Subject: How create multiples ssh on same host without asking same password In-Reply-To: References: Message-ID: <40E3F138.10609@mindrot.org> Eric LeBlanc wrote: > Hello, > > I used the SecureShell windows client from ssh.com and it have a cool > feature: Once I logged on a server with ssh, I was able to create more > terminals without being asked for a password again. It seems that it use > the 'same channel' created from the first ssh client. > > So, it's possible with openssh on linux/bsd? If yes, how? If not, can you > add this feature? Already done - see ControlMaster in the ssh_config manpage of the current CVS version. This will be in the next release. -d From sunmedia at s8.dion.ne.jp Thu Jul 1 23:03:29 2004 From: sunmedia at s8.dion.ne.jp (sunmedia at s8.dion.ne.jp) Date: Thu, 01 Jul 2004 22:03:29 +0900 Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoGyhCIBskQjNKMEIhKkVFT0MbKEI=?= =?iso-2022-jp?b?GyRCMkNGfjgiSE5HZBsoQiAbKEpcGyhCNCwwMDA=?= =?iso-2022-jp?b?GyRCIUEbKEI=?= Message-ID: <20040701130704984.00000.26.a692990630@K-WAKAMI.dmail.s8.dion.ne.jp> ??????????????????????? ?????????????????????????????????? ???????????????????? ??????????????????????? ??????????????????????????????????? ?????????? ????????5-28-28 042-708-0888 ????????????????? ???????????????????????? ???????????????????????? ??????????????????????? sunmedia at s8.dion.ne.jp??????????????? ????REFUSE????????? ???????????????????????????????? ??? ?????????????? ??? ???????????????????????/???? ??? ???????????????????????????????? ????????????????,????????????????? ???????????????????????????????? ???????????????????????????????? ?????????????????????????????????????????????? ???????????????????????????????? ??? ??????????????? ? ???????????????????? ? ??,??? ???????????????????????? ? ??,??? ????????????????????? ? ??,??? ???????????? ???????????? ??http://www.sun-media.co.jp/personal/personal_01.html ???????????????????????????? ??????????????????????? ??http://www.sun-media.co.jp/ ???????????????????????????? ??????????????????????? ???????????????????????????????????? ?----------------------------------------------------? ??????????? ?????????5-28-28 ?TEL 042-708-0888 ?FAX 042-708-0887 ?E-mail?mail at sun-media.co.jp ?http://www.sun-media.co.jp/ ??? 10:00?18:00 ???? ?----------------------------------------------------? From inouk at igt.net Thu Jul 1 23:46:53 2004 From: inouk at igt.net (Eric LeBlanc) Date: Thu, 1 Jul 2004 09:46:53 -0400 (EDT) Subject: How create multiples ssh on same host without asking same password In-Reply-To: <40E3F138.10609@mindrot.org> Message-ID: On Thu, 1 Jul 2004, Damien Miller wrote: > Eric LeBlanc wrote: > > Hello, > > > > I used the SecureShell windows client from ssh.com and it have a cool > > feature: Once I logged on a server with ssh, I was able to create more > > terminals without being asked for a password again. It seems that it use > > the 'same channel' created from the first ssh client. > > > > So, it's possible with openssh on linux/bsd? If yes, how? If not, can you > > add this feature? > > Already done - see ControlMaster in the ssh_config manpage of the > current CVS version. > > This will be in the next release. > > -d > Hello, Thank you, it works very well, but I think that the man page need more details about it. For example, it's not pratical (if I understand well) to set the ControlPath and ControlMaster directly on ssh_config. The problem is when I setup like this: ControlMaster=yes ControlPath=/wathever/you/want Every time I start SSH, it's alway considered as master, so ssh will ask the password. They 'better' way is: ssh -M -S /path/to/control/file username at host.domain and for next sessions using the same channel: ssh -S /path/to/control/file username at host.domain I've created a mini script that does the 'dirty' job: ---- cut ------------------------------------------- SOCKET=/tmp/BLAH SSH=/usr/local/bin/ssh if [ ! -S ${SOCKET} ] then ${SSH} -M -S ${SOCKET} myserver.domain else ${SSH} -S ${SOCKET} myserver.domain fi ---- cut ------------------------------------------- Am I wrong? Or, the flag to disable the Master in ssh command is there but missing in the man page? I know that it is the default (No master), but when it configured in ssh_config, it will be always considered as master. Or else, it currently in devel and it's not finished and I must wait before talking about it? Finally, a little note: when I specify the flag -S, I know that I don't need to specify the server, but SSH will return an error. So, if it not corrected, well, I will send to you this little patch: ----------------------------------- CUT ---------------------------------- --- ssh_bak.c 2004-07-01 09:33:20.000000000 -0400 +++ ssh.c 2004-07-01 09:37:45.000000000 -0400 @@ -485,7 +485,7 @@ } /* Check that we got a host name. */ - if (!host) + if ( (!host) && (strlen(options.control_path) != 0) && (options.control_master != -1) ) usage(); SSLeay_add_all_algorithms(); ---------------------------------- CUT ------------------------------------ E. -- Eric LeBlanc inouk at igt.net -------------------------------------------------- UNIX is user friendly. It's just selective about who its friends are. ================================================== From pedrajas at duck.syd.de Fri Jul 2 00:54:21 2004 From: pedrajas at duck.syd.de (pedrajas at duck.syd.de) Date: Thu, 01 Jul 2004 14:54:21 +0000 Subject: software In-Reply-To: <635AA0J3A2BDL628@mindrot.org> References: <635AA0J3A2BDL628@mindrot.org> Message-ID: <8LB5549K1KG2DHGJ@duck.syd.de> Microsoft Windows XP Professional 2002 Retail price: $270.99 Our low Price: $50.00 You Save: $220.00 Adobe Photoshop 7.0 Retail price: $609.99 Our low Price: $60.00 You Save: $550.00 Microsoft Office XP Professional 2002 Retail price: $579.99 Our low Price: $60.00 You Save: $510.00 Adobe Illustrator 10 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Corel Draw Graphics Suite 11 Retail price: $270.99 Our low Price: $60.00 You Save: $210.00 Delphi 7 Retail price: $404.99 Our low Price: $60.00 You Save: $335.00 And more!!! Our site is http://zdWNdPI.gcabmebm.info/?ETaJGp8HhILxW88YzLt Why so cheap? All the software is OEM- Meaning that you don't get the box and the manual with your software. All you will receive is the actual software and your unique registration code. All the software is in the English language for PC. Our offers are unbeatable and we always update our prices to make sure we provide you with the best possible offers. Hurry up and place your order, because our supplies are limited. Our site is http://UkTQrmM.gcabmebm.info/?ETaJGp8HhILxW88WTNX THyDKITA vtEqW TtFGHrO BDItW WgROUPI Colm YVNtdr KZaT FHBYxcB gwxdD pTyhCawN muIc MMuyLur rcTpzWR Ftp IWGC uNeujTT FDKtp f RdAjv From mouring at etoh.eviladmin.org Fri Jul 2 02:29:01 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 1 Jul 2004 11:29:01 -0500 (CDT) Subject: How create multiples ssh on same host without asking same password In-Reply-To: Message-ID: On Thu, 1 Jul 2004, Eric LeBlanc wrote: > On Thu, 1 Jul 2004, Damien Miller wrote: > > Eric LeBlanc wrote: > > > Hello, > > > > > > I used the SecureShell windows client from ssh.com and it have a cool > > > feature: Once I logged on a server with ssh, I was able to create more > > > terminals without being asked for a password again. It seems that it use > > > the 'same channel' created from the first ssh client. > > > > > > So, it's possible with openssh on linux/bsd? If yes, how? If not, can you > > > add this feature? > > > > Already done - see ControlMaster in the ssh_config manpage of the > > current CVS version. > > > > This will be in the next release. > > > > -d > > > > Hello, > > Thank you, it works very well, but I think that the man page need > more details about it. > > For example, it's not pratical (if I understand well) to set the > ControlPath and ControlMaster directly on ssh_config. The problem is when > I setup like this: > > ControlMaster=yes > ControlPath=/wathever/you/want > Nada. You want. yume:~ mouring$ cat ~/.ssh/config Host site-m Hostname site.org ControlMaster yes ControlPath ~/.ssh/site Host eviladmin-s ControlPath ~/.ssh/site yume:~ mouring$ Then you can use "site-m" to create the initial connection and "site-s" to establish channels. Even works with sftp and scp nicely. - Ben From ltclau2000 at yahoo.com.hk Fri Jul 2 08:45:45 2004 From: ltclau2000 at yahoo.com.hk (=?big5?q?lambert=20lau?=) Date: Fri, 2 Jul 2004 06:45:45 +0800 (CST) Subject: AIX lssrc command error after installed OpenSSH Message-ID: <20040701224545.34669.qmail@web50708.mail.yahoo.com> Hi, We compiled and successfully installed OpenSSH 3.8.1p1 (or earlier version), but has false respond from lssrc -a command. Example error message as: openssh daemon itself - "opensshd tcpip inoperative" or other daemon - "0513-001 The System Resource Controller daemon is not active" We've installed the following filesets on several AIX servers (both 5.1 and 5.2): SCBprngd.rte 0.9.26.0 C F Pseudo Randon Number Generator SCBsshd.rte 3.8.1.1 C F OpenSSH Daemon 3.8.1p1 Portable SCBssl.rte 0.9.7.4 C F OpenSSL Utilities 0.9.7d SCBtcpwr.rte 7.6.0.0 C F TCPWrappers 7.6 Portable for AIX SCBzlib.rte 1.2.1.0 C F Zlib compression utilities ssh appears to work OK but we are getting problems with the System Recourse Controller, after the install of OpenSSH the System Resource Controller hangs. This means we cannot query, stop, start or refresh any of the services under the control of SRC, these include NIS NFS and inetd. But if we deinstall the above filesets the SRC responds as normal. Any idea what's going wrong? _________________________________________________________ ??????????... ???? ???? http://us.rd.yahoo.com/evt=22281/*http://ringtone.yahoo.com.hk/ From inouk at igt.net Fri Jul 2 06:42:48 2004 From: inouk at igt.net (Eric LeBlanc) Date: Thu, 1 Jul 2004 16:42:48 -0400 (EDT) Subject: How create multiples ssh on same host without asking same password In-Reply-To: <20040701171211.GA15913@folly> Message-ID: On Thu, 1 Jul 2004, Markus Friedl wrote: > > For example, it's not pratical (if I understand well) to set the > > ControlPath and ControlMaster directly on ssh_config. The problem is when > > I setup like this: > > > > ControlMaster=yes > > ControlPath=/wathever/you/want > > > > Every time I start SSH, it's alway considered as master, so ssh will ask > > the password. They 'better' way is: > > > > ssh -M -S /path/to/control/file username at host.domain > > > > and for next sessions using the same channel: > > > > ssh -S /path/to/control/file username at host.domain > > no, it's better to do it this way > > Host foo > ControlMaster yes > ControlPath /wathever/you/want > Host bar > ControlPath /wathever/you/want > > so after > ssh foo > you can use > ssh bar > to connect to foo via the first connection. > It's clear now, Thank you for your patience! E. -- Eric LeBlanc inouk at igt.net -------------------------------------------------- UNIX is user friendly. It's just selective about who its friends are. ================================================== From markus at openbsd.org Fri Jul 2 03:12:11 2004 From: markus at openbsd.org (Markus Friedl) Date: Thu, 1 Jul 2004 19:12:11 +0200 Subject: How create multiples ssh on same host without asking same password In-Reply-To: References: <40E3F138.10609@mindrot.org> Message-ID: <20040701171211.GA15913@folly> On Thu, Jul 01, 2004 at 09:46:53AM -0400, Eric LeBlanc wrote: > On Thu, 1 Jul 2004, Damien Miller wrote: > > Eric LeBlanc wrote: > > > Hello, > > > > > > I used the SecureShell windows client from ssh.com and it have a cool > > > feature: Once I logged on a server with ssh, I was able to create more > > > terminals without being asked for a password again. It seems that it use > > > the 'same channel' created from the first ssh client. > > > > > > So, it's possible with openssh on linux/bsd? If yes, how? If not, can you > > > add this feature? > > > > Already done - see ControlMaster in the ssh_config manpage of the > > current CVS version. > > > > This will be in the next release. > > > > -d > > > > Hello, > > Thank you, it works very well, but I think that the man page need > more details about it. > > For example, it's not pratical (if I understand well) to set the > ControlPath and ControlMaster directly on ssh_config. The problem is when > I setup like this: > > ControlMaster=yes > ControlPath=/wathever/you/want > > Every time I start SSH, it's alway considered as master, so ssh will ask > the password. They 'better' way is: > > ssh -M -S /path/to/control/file username at host.domain > > and for next sessions using the same channel: > > ssh -S /path/to/control/file username at host.domain no, it's better to do it this way Host foo ControlMaster yes ControlPath /wathever/you/want Host bar ControlPath /wathever/you/want so after ssh foo you can use ssh bar to connect to foo via the first connection. From mike.miller at techguardsecurity.com Thu Jul 1 22:09:38 2004 From: mike.miller at techguardsecurity.com (Michael Miller) Date: Thu, 1 Jul 2004 07:09:38 -0500 Subject: fips update? Message-ID: <200407010709.38555.mike.miller@techguardsecurity.com> I read openssl is trying to get FIPS certified. Anyone have any updates or information on this? When will openssl get it's FIPS certification? Thanks. From tim at multitalents.net Fri Jul 2 11:07:00 2004 From: tim at multitalents.net (Tim Rice) Date: Thu, 1 Jul 2004 18:07:00 -0700 (PDT) Subject: AIX lssrc command error after installed OpenSSH In-Reply-To: <20040701224545.34669.qmail@web50708.mail.yahoo.com> References: <20040701224545.34669.qmail@web50708.mail.yahoo.com> Message-ID: On Fri, 2 Jul 2004, [big5] lambert lau wrote: > Hi, > We've installed the following filesets on several AIX > servers (both 5.1 and 5.2): > > SCBprngd.rte 0.9.26.0 C F > Pseudo Randon Number Generator > SCBsshd.rte 3.8.1.1 C F > OpenSSH Daemon 3.8.1p1 Portable > SCBssl.rte 0.9.7.4 C F > OpenSSL Utilities 0.9.7d > SCBtcpwr.rte 7.6.0.0 C F > TCPWrappers 7.6 Portable for AIX > SCBzlib.rte 1.2.1.0 C F Zlib > compression utilities > > ssh appears to work OK but we are getting problems > with the System Recourse Controller, after the install > of OpenSSH the System Resource Controller hangs. This > means we cannot query, stop, start or refresh any of > the services under the control of SRC, these include > NIS NFS and inetd. But if we deinstall the above > filesets the SRC responds as normal. > > Any idea what's going wrong? What happens if you install all except SCBsshd.rte? Does System Resource Controller still have problems? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From djm at mindrot.org Fri Jul 2 11:27:03 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 02 Jul 2004 11:27:03 +1000 Subject: fips update? In-Reply-To: <200407010709.38555.mike.miller@techguardsecurity.com> References: <200407010709.38555.mike.miller@techguardsecurity.com> Message-ID: <40E4B9E7.3080904@mindrot.org> Michael Miller wrote: > I read openssl is trying to get FIPS certified. Anyone have any updates or > information on this? When will openssl get it's FIPS certification? You should ask the OpenSSL developers. -d From dtucker at zip.com.au Fri Jul 2 12:51:19 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 02 Jul 2004 12:51:19 +1000 Subject: AIX lssrc command error after installed OpenSSH In-Reply-To: <20040701224545.34669.qmail@web50708.mail.yahoo.com> References: <20040701224545.34669.qmail@web50708.mail.yahoo.com> Message-ID: <40E4CDA7.9090008@zip.com.au> lambert lau wrote: > We compiled and successfully installed OpenSSH 3.8.1p1 > (or earlier version), but has false respond from lssrc > -a command. Example error message as: > > openssh daemon itself - "opensshd tcpip > inoperative" It difficult to tell without knowing what the package has done, but would guess that the subsystem was created without the "-D" flag being passed to sshd and that as a result sshd is constantly respawning, which is keeping SRC too busy to respond to commands. (The first copy started would have been able to bind to port 22, daemonize and serve requests, which would explain why sshd works OK). If that's the case, you can fix that with: chssys -s opensshd -a '-D' Failing that, you really need to talk to whoever made your packages and find out how the subsystem was created. -- 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 isentropic-gajnlbtxgiwlxh at msn.com Sun Jul 4 02:24:31 2004 From: isentropic-gajnlbtxgiwlxh at msn.com (Ricky Duffy) Date: Sat, 03 Jul 2004 17:24:31 +0100 Subject: grow confident? Message-ID: <8895zydwy$331a@wlkkhj49580.dog.xjoorovdhox@msn.com> Really lay the PIPE to the next girl you screw... http://chap.mnvbrfc.com/vp5 take off- http://parquet.mnvbrfc.com/a.html radii guile merlin From Sielmowski at inhousemedia.net Sat Jul 3 16:02:28 2004 From: Sielmowski at inhousemedia.net (Sielmowski at inhousemedia.net) Date: Sat, 03 Jul 2004 06:02:28 +0000 Subject: LowCost SoftWare OnCD In-Reply-To: References: Message-ID: http://CkBEA.aeamdgi.info/?O1knkziYnSpb4OOcVkaG From dtucker at zip.com.au Sat Jul 3 20:56:21 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 03 Jul 2004 20:56:21 +1000 Subject: Extra newlines in sshd login messages Message-ID: <40E690D5.4080102@zip.com.au> Hi. Some people have reported that login messages reported by sshd have extra newlines. It looks like there are 2 causes of this: a) some PAM modules like to return messages of "", which sshd dutifully appends a newline to and stores for later display. b) display_loginmsg appends a newline too (I think this dates back to before PAM supplied its own newlines). The attached (trivial) patch fixes this: it auth-pam will not append newlines, and loginmsg is displayed as a literal string (so any newlines needed must be supplied by whatever is appending to loginmsg). -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-pam-no_extra_newlines.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040703/bbfb59f0/attachment.ksh From dtucker at zip.com.au Sun Jul 4 11:39:07 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 04 Jul 2004 11:39:07 +1000 Subject: OpenSSL ENIGNE support for OpenSSH In-Reply-To: <40E2D9B6.2000500@suse.cz> References: <40E2D9B6.2000500@suse.cz> Message-ID: <40E75FBB.9060500@zip.com.au> Michal Ludvig wrote: > attached is a patch that enables using hardware crypto accelerators > available through OpenSSL library for SSH operations. Especially in > ssh/sshd it can bring a significant speed improvement. OTOH if no crypto > engine is available, nothing bad happens and default software crypto > routines are used. The ENGINE functionality is not available in all OpenSSL versions that OpenSSH supports (it's not in 0.9.5 and it's a separate package for 0.9.6), so your patch will fail to compile on those. I don't know about adding it to the main tree.. comments? If it is, it should be either detected automatically at build time or be a configure option (eg --with-ssl-engine). Maybe just something like this in defines.h: #if defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER > 0x0090700f) # define USE_OPENSSL_ENGINE #endif -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sun Jul 4 12:10:52 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 04 Jul 2004 12:10:52 +1000 Subject: OpenSSL ENIGNE support for OpenSSH In-Reply-To: <40E75FBB.9060500@zip.com.au> References: <40E2D9B6.2000500@suse.cz> <40E75FBB.9060500@zip.com.au> Message-ID: <40E7672C.1080506@zip.com.au> Darren Tucker wrote: > #if defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER > > 0x0090700f) Argh! Make that "&&" not "||" > # define USE_OPENSSL_ENGINE > #endif -- 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 chloe at meshera.com Sun Jul 4 20:53:53 2004 From: chloe at meshera.com (Soft) Date: Sun, 04 Jul 2004 10:53:53 +0000 Subject: Message-ID: <20040704121301.9240027C196@shitei.mindrot.org> 463 Best Soft for the accessible prices!!! 732 304 MS Windows XP Professional - $ 80 536 660 Microsoft Office 2003 Professional - $ 120 393 556 Adobe Photoshop 8.0 - $ 100 271 561 Macromedia Studio MX 2004 - $ 180 586 135 Adobe Acrobat 6.0 Professional - $ 150 498 118 Norton Internet Security Pro 2004 - $ 50 922 169 Quicken 2004 Premier Home & Biz - $ 40 498 932 Ahead NERO 6.3 POWERPACK - $ 60 740 198 QuickBooks 2004 Premier Edition - $ 120 586 852 WinFax Pro 10.03 - $ 40 343 024 Adobe Illustrator CS /full new version - $ 100 758 368 Adobe InDesign CS /full new version - $ 100 113 273 SYMANTEC pcANYWHERE 11.0 - $ 60 514 VIEW FULL LIST OF PRODUCTS... http://plcbun.info/index.php?s=1078 549 666 920 704 708 192 759 500 From Sergio.Gelato at astro.su.se Mon Jul 5 00:54:53 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Sun, 4 Jul 2004 16:54:53 +0200 Subject: OpenSSL ENIGNE support for OpenSSH In-Reply-To: <40E75FBB.9060500@zip.com.au> References: <40E2D9B6.2000500@suse.cz> <40E75FBB.9060500@zip.com.au> Message-ID: <20040704145452.GD24302@astro.su.se> * Darren Tucker [2004-07-04 11:39:07 +1000]: > The ENGINE functionality is not available in all OpenSSL versions that > OpenSSH supports (it's not in 0.9.5 and it's a separate package for > 0.9.6), so your patch will fail to compile on those. Also, the changelog for OpenSSL 0.9.7a reveals that the developers have seen it fit to allow ENGINE support to be disabled at compile time. > > I don't know about adding it to the main tree.. comments? I don't know either, but would expect the OpenBSD development team to have a reasonably informed opinion about this. As to why the OpenSSL developers don't turn ENGINE support on by default, perhaps one can interpolate some of their reasons from the contents of README.ENGINE in recent OpenSSL releases. If I understood it right, their concerns include: not getting blamed for bugs in third-party plug-ins; the fact that the ENGINE support is still not feature-complete; and the limited amount of testing it has had so far. But please don't take my word for this; read theirs and decide for yourselves on the interpretation. > If it is, it > should be either detected automatically at build time or be a configure > option (eg --with-ssl-engine). Maybe just something like this in defines.h: > > #if defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER > 0x0090700f) > # define USE_OPENSSL_ENGINE > #endif In light of the changelog entry I just mentioned, this seems a little too simple. (Even after the s/||/&&/ bugfix.) That leaves us with configure-time detection/selection. From mouring at etoh.eviladmin.org Mon Jul 5 11:43:19 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 4 Jul 2004 20:43:19 -0500 (CDT) Subject: OpenSSL ENIGNE support for OpenSSH In-Reply-To: <40E75FBB.9060500@zip.com.au> Message-ID: On Sun, 4 Jul 2004, Darren Tucker wrote: > Michal Ludvig wrote: > > attached is a patch that enables using hardware crypto accelerators > > available through OpenSSL library for SSH operations. Especially in > > ssh/sshd it can bring a significant speed improvement. OTOH if no crypto > > engine is available, nothing bad happens and default software crypto > > routines are used. > > The ENGINE functionality is not available in all OpenSSL versions that > OpenSSH supports (it's not in 0.9.5 and it's a separate package for > 0.9.6), so your patch will fail to compile on those. > > I don't know about adding it to the main tree.. comments? If it is, it > should be either detected automatically at build time or be a configure > option (eg --with-ssl-engine). Maybe just something like this in defines.h: > > #if defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER > 0x0090700f) > # define USE_OPENSSL_ENGINE > #endif > I'd rather see OpenSSL team correct their code so we don't have to do this type of crap work. There is no reason why we should have to initialize the OpenSSL ENGINE code. As far as I know OpenSSH works just fine with software/hardware encryption via OpenSSL without these changes. I think we are best off waiting until they get their act together. - Ben From mouring at etoh.eviladmin.org Mon Jul 5 12:02:26 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 4 Jul 2004 21:02:26 -0500 (CDT) Subject: OpenSSL ENIGNE support for OpenSSH In-Reply-To: Message-ID: On Sun, 4 Jul 2004, Ben Lindstrom wrote: [..] > > As far as I know OpenSSH works just fine with software/hardware encryption > via OpenSSL without these changes. > Minor Clarification. =) I'm refering to OpenBSD's intree OpenSSL. Not virgin OpenSSL. - Ben From dtucker at zip.com.au Mon Jul 5 16:48:31 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 05 Jul 2004 16:48:31 +1000 Subject: ssh daemon fails to call pam when user does not exist in /etc/passwd In-Reply-To: <40E8F687.4030408@tusker.org> References: <40CEBE06.4020802@cisco.com> <40CEC259.1070208@zip.com.au> <40E8F687.4030408@tusker.org> Message-ID: <40E8F9BF.4040503@zip.com.au> Damien Mascord wrote: > I am attempting to use a new NSS method for logins (libnss-mysql), and > have come across this behaviour as well. [...] > It seems as though the account is thought of as expired: > > debug3: mm_answer_pwnamallow > debug3: auth_shadow_acctexpired: today 12604 sp_expire 0 days left -12604 That check only happens if PAM is disabled (just checked the 3.8.1p1 code, it's auth.c line 91 or so). Do you have "UsePAM yes" in your sshd_config? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Jul 5 17:21:55 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 05 Jul 2004 17:21:55 +1000 Subject: ssh daemon fails to call pam when user does not exist in /etc/passwd In-Reply-To: <40E8FDD6.8080001@tusker.org> References: <40CEBE06.4020802@cisco.com> <40CEC259.1070208@zip.com.au> <40E8F687.4030408@tusker.org> <40E8F9BF.4040503@zip.com.au> <40E8FDD6.8080001@tusker.org> Message-ID: <40E90193.4070102@zip.com.au> Damien Mascord wrote: > It was in my unpatched sshd_config, but wasn't present in the (patched) > /usr/local/etc version. Thanks for the heads up. > > With or without the patch, I am able to login correctly. It seems as > though a restart of ssh was needed to enable the new NSS methods for > some reason. Not sure what the cause of the issue was, if I notice it > on a new installation, I will try and narrow this down, thanks for your > help. Probably picked up at initialisation time by libc and not checked again. > Since this is the case, I am assuming that PAM is required if alternate > NSS methods are in use ? Is there any way around this? Provide getpwnam and friends behave as sshd expects (ie the same as for a local account), no, PAM should not be required. In your case, sshd thinks the account is expired because sp_expire == 0 (which sshd considers to mean that your account expired some time in 1970 :-), whereas sshd expects "-1" if account expiry is disabled. It might be reasonable to check for zero too, *provided* that does not have a special meaning on some platform. (sp_lstchg == 0 is used on many platforms to indicate a root-forced password change, but I don't know if sp_expire is used for something similar). -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-shadow-zeroexpire.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040705/62576adc/attachment.ksh From tusker at tusker.org Mon Jul 5 16:34:47 2004 From: tusker at tusker.org (Damien Mascord) Date: Mon, 05 Jul 2004 14:34:47 +0800 Subject: ssh daemon fails to call pam when user does not exist in /etc/passwd In-Reply-To: <40CEC259.1070208@zip.com.au> References: <40CEBE06.4020802@cisco.com> <40CEC259.1070208@zip.com.au> Message-ID: <40E8F687.4030408@tusker.org> Hi Darren, I am attempting to use a new NSS method for logins (libnss-mysql), and have come across this behaviour as well. Using su - it works as expected, and uses pam_unix and then nss-mysql to authenticate. Using ssh, it doesn't even seem to get to pam_unix at all. How does kerberos or ldap only installations work ? Even this patch does not seem to enable the new NSS method to work. It seems as though the account is thought of as expired: debug3: mm_answer_pwnamallow debug3: auth_shadow_acctexpired: today 12604 sp_expire 0 days left -12604 debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 0 Hmm... ok... after restarting ssh, without the patch, it allows the user to login now: debug3: mm_answer_pwnamallow debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 So, I suppose this email is to let you know that the patch breaks something in 3.8.1p1 :) Damien Darren Tucker wrote: > Jayarama Vijay Kumar wrote: > >> We recenlty ugraded to openssh-3.7.1p2. Our architecture is >> ssh daemon uses pam module which sends request to remote >> radius/tacacs+ servers based on configuration. >> Now if I create the user in /etc/passwd, then ssh daemon calls pam >> and everthing works fine. >> But if the user is not present in /etc/passwd, then ssh daemon is not >> calling pam. The debug log is given below. All these were working in >> prior versions. Any idea why there is dependency on local user >> accounts ? I have also given sshd's pam file > > > I posted a patch for this a while back (attached). It's only been > lightly tested but it's worth a try. > > > ------------------------------------------------------------------------ > > Index: auth2-chall.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth2-chall.c,v > retrieving revision 1.22 > diff -u -p -r1.22 auth2-chall.c > --- auth2-chall.c 26 May 2003 11:36:13 -0000 1.22 > +++ auth2-chall.c 1 Jun 2004 23:55:21 -0000 > @@ -275,12 +275,10 @@ input_userauth_info_response(int type, u > } > packet_check_eom(); > > - if (authctxt->valid) { > - res = kbdintctxt->device->respond(kbdintctxt->ctxt, > - nresp, response); > - } else { > - res = -1; > - } > + res = kbdintctxt->device->respond(kbdintctxt->ctxt, > + nresp, response); > + if (!authctxt->valid) > + res = 1; /* keep going if login invalid */ > > for (i = 0; i < nresp; i++) { > memset(response[i], 'r', strlen(response[i])); > > > ------------------------------------------------------------------------ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Damien Mascord (tusker at tusker dot org) GPG key 2CB181BE / 93B2 EF21 0C7C F022 F467 7966 219E 92B3 2CB1 81BE -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-debug.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040705/6fafa718/attachment.txt From dtucker at zip.com.au Mon Jul 5 23:48:58 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 05 Jul 2004 23:48:58 +1000 Subject: ssh daemon fails to call pam when user does not exist in /etc/passwd In-Reply-To: <40E90D61.8030103@tusker.org> References: <40CEBE06.4020802@cisco.com> <40CEC259.1070208@zip.com.au> <40E8F687.4030408@tusker.org> <40E8F9BF.4040503@zip.com.au> <40E8FDD6.8080001@tusker.org> <40E90193.4070102@zip.com.au> <40E90D61.8030103@tusker.org> Message-ID: <40E95C4A.9030304@zip.com.au> Damien Mascord wrote: > Setting the sp_expire flag to -1 causes the following to happen: > > debug3: channel 0: close_fds r -1 w -1 e -1 > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for > (current) UNIX password: > > Seems as though ssh and/or PAM now thinks that the password is now expired. Probably sshd rather than PAM. sp_lstchg is probably zero (the value will be in the debug trace). If you can, set it to -1 too. -- 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 tusker at tusker.org Mon Jul 5 17:05:58 2004 From: tusker at tusker.org (Damien Mascord) Date: Mon, 05 Jul 2004 15:05:58 +0800 Subject: ssh daemon fails to call pam when user does not exist in /etc/passwd In-Reply-To: <40E8F9BF.4040503@zip.com.au> References: <40CEBE06.4020802@cisco.com> <40CEC259.1070208@zip.com.au> <40E8F687.4030408@tusker.org> <40E8F9BF.4040503@zip.com.au> Message-ID: <40E8FDD6.8080001@tusker.org> Darren Tucker wrote: > Damien Mascord wrote: > >> I am attempting to use a new NSS method for logins (libnss-mysql), and >> have come across this behaviour as well. > > [...] > >> It seems as though the account is thought of as expired: >> >> debug3: mm_answer_pwnamallow >> debug3: auth_shadow_acctexpired: today 12604 sp_expire 0 days left -12604 > > > That check only happens if PAM is disabled (just checked the 3.8.1p1 > code, it's auth.c line 91 or so). Do you have "UsePAM yes" in your > sshd_config? > It was in my unpatched sshd_config, but wasn't present in the (patched) /usr/local/etc version. Thanks for the heads up. With or without the patch, I am able to login correctly. It seems as though a restart of ssh was needed to enable the new NSS methods for some reason. Not sure what the cause of the issue was, if I notice it on a new installation, I will try and narrow this down, thanks for your help. Since this is the case, I am assuming that PAM is required if alternate NSS methods are in use ? Is there any way around this? Thanks again for your quick response, Damien -- Damien Mascord (tusker at tusker dot org) GPG key 2CB181BE / 93B2 EF21 0C7C F022 F467 7966 219E 92B3 2CB1 81BE From andy.tompkins at autozone.com Wed Jul 7 02:05:18 2004 From: andy.tompkins at autozone.com (andy.tompkins at autozone.com) Date: Tue, 6 Jul 2004 11:05:18 -0500 Subject: AIX and zlib Message-ID: I noticed that AIX now comes with a version of zlib installed in /usr. (I'm working on 5.2) My first inclination was to simply uninstall it and use the one we compile (and put in /usr/local). However, IBM has made zlib part of the RPM package itself! So, I cannot uninstall it without removing RPM.... Next, I tried passing --with-zlib=/usr/local to configure for ssh. This seems to work, but after compilation an ldd on ssh reveals that it is still trying to use the one in /usr/lib. I then modified the Makefile so that blibpath has /usr/local/lib in it before /usr/lib, and this works as expected. Should configure be doing that for me on AIX? Thanks Andy ------------------------------------------------------------------------ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From gert at greenie.muc.de Wed Jul 7 05:36:40 2004 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 6 Jul 2004 21:36:40 +0200 Subject: AIX and zlib In-Reply-To: ; from andy.tompkins@autozone.com on Tue, Jul 06, 2004 at 11:05:18AM -0500 References: Message-ID: <20040706213639.Z7999@greenie.muc.de> Hi, On Tue, Jul 06, 2004 at 11:05:18AM -0500, andy.tompkins at autozone.com wrote: > I then modified the Makefile so that blibpath has /usr/local/lib in it > before /usr/lib, and this works as expected. > Should configure be doing that for me on AIX? What's wrong with using the system default, if one is already there? 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 andy.tompkins at autozone.com Wed Jul 7 06:24:45 2004 From: andy.tompkins at autozone.com (andy.tompkins at autozone.com) Date: Tue, 6 Jul 2004 15:24:45 -0500 Subject: AIX and zlib Message-ID: Nothing wrong per se.....just that when I told it --with-zlib=/usr/local I expected it to actually use that one... Andy Gert Doering cc: openssh-unix-dev at mindrot.org Subject: Re: AIX and zlib 07/06/2004 02:36 PM Hi, On Tue, Jul 06, 2004 at 11:05:18AM -0500, andy.tompkins at autozone.com wrote: > I then modified the Makefile so that blibpath has /usr/local/lib in it > before /usr/lib, and this works as expected. > Should configure be doing that for me on AIX? What's wrong with using the system default, if one is already there? 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 ------------------------------------------------------------------------ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From andy.tompkins at autozone.com Wed Jul 7 06:29:59 2004 From: andy.tompkins at autozone.com (andy.tompkins at autozone.com) Date: Tue, 6 Jul 2004 15:29:59 -0500 Subject: AIX and zlib Message-ID: I did have a situation this morning. We have an in house application that was linked to the zlib in /usr/local. A user who uses that application had to have their LIBPATH=/usr/local/lib. When they tried to run sftp it failed because the zlib in /usr/local was not the same as what ssh was linked against. Andy |---------+---------------------------------------------------------------> | | Gert Doering | | | Sent by: | | | openssh-unix-dev-bounces+andy.tompkins=autozone.com@| | | mindrot.org | | | | | | | | | 07/06/2004 02:36 PM | | | | |---------+---------------------------------------------------------------> >-------------------------------------------------------------------------------------------| | | | To: andy.tompkins at autozone.com | | cc: openssh-unix-dev at mindrot.org | | Subject: Re: AIX and zlib | >-------------------------------------------------------------------------------------------| Hi, On Tue, Jul 06, 2004 at 11:05:18AM -0500, andy.tompkins at autozone.com wrote: > I then modified the Makefile so that blibpath has /usr/local/lib in it > before /usr/lib, and this works as expected. > Should configure be doing that for me on AIX? What's wrong with using the system default, if one is already there? 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev ------------------------------------------------------------------------ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From dtucker at zip.com.au Wed Jul 7 07:18:59 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 07 Jul 2004 07:18:59 +1000 Subject: AIX and zlib In-Reply-To: References: Message-ID: <40EB1743.6080108@zip.com.au> andy.tompkins at autozone.com wrote: > Next, I tried passing --with-zlib=/usr/local to configure for ssh. > This seems to work, but after compilation an ldd on ssh reveals that it is > still trying to use the one in /usr/lib. > > I then modified the Makefile so that blibpath has /usr/local/lib in it > before /usr/lib, and this works as expected. > Should configure be doing that for me on AIX? Probably. Please try the attached patch (you will need to run "autoconf" to rebuild configure). -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-aix-zlib-blibpath.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040707/cc18fd5d/attachment.ksh From dtucker at zip.com.au Wed Jul 7 07:27:54 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 07 Jul 2004 07:27:54 +1000 Subject: AIX and zlib In-Reply-To: <40EB1743.6080108@zip.com.au> References: <40EB1743.6080108@zip.com.au> Message-ID: <40EB195A.20202@zip.com.au> Darren Tucker wrote: > andy.tompkins at autozone.com wrote: >> I then modified the Makefile so that blibpath has /usr/local/lib in it >> before /usr/lib, and this works as expected. >> Should configure be doing that for me on AIX? > > Probably. Please try the attached patch (you will need to run > "autoconf" to rebuild configure). I've changed my mind, doing that is a very bad idea: "./configure --with-zlib=../zlib-1.1.4" or "./configure --with-zlib=/tmp/zlib-1.1.4" will result in binaries that are exploitable via a library injection attack (including ssh-keysign which is setuid root). You can specify blibpath at configure time: blibpath=/lib:/usr/lib:/usr/local/lib ./configure && make -- 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 tusker at tusker.org Mon Jul 5 18:12:17 2004 From: tusker at tusker.org (Damien Mascord) Date: Mon, 05 Jul 2004 16:12:17 +0800 Subject: ssh daemon fails to call pam when user does not exist in /etc/passwd In-Reply-To: <40E90193.4070102@zip.com.au> References: <40CEBE06.4020802@cisco.com> <40CEC259.1070208@zip.com.au> <40E8F687.4030408@tusker.org> <40E8F9BF.4040503@zip.com.au> <40E8FDD6.8080001@tusker.org> <40E90193.4070102@zip.com.au> Message-ID: <40E90D61.8030103@tusker.org> Hi Darren, Setting the sp_expire flag to -1 causes the following to happen: debug3: channel 0: close_fds r -1 w -1 e -1 WARNING: Your password has expired. You must change your password now and login again! Changing password for (current) UNIX password: Seems as though ssh and/or PAM now thinks that the password is now expired. Now, even though i set sp_expire back to 0, it still thinks the password is expired... upon a reboot, it thinks it's not expired again. Could this be a possible bug within the nss module? Is there an RFC that refers to the sp_expire field to see what the "official" behaviour should be ? Damien Darren Tucker wrote: > Damien Mascord wrote: > >> It was in my unpatched sshd_config, but wasn't present in the >> (patched) /usr/local/etc version. Thanks for the heads up. >> >> With or without the patch, I am able to login correctly. It seems as >> though a restart of ssh was needed to enable the new NSS methods for >> some reason. Not sure what the cause of the issue was, if I notice it >> on a new installation, I will try and narrow this down, thanks for >> your help. > > > Probably picked up at initialisation time by libc and not checked again. > >> Since this is the case, I am assuming that PAM is required if >> alternate NSS methods are in use ? Is there any way around this? > > > Provide getpwnam and friends behave as sshd expects (ie the same as for > a local account), no, PAM should not be required. In your case, sshd > thinks the account is expired because sp_expire == 0 (which sshd > considers to mean that your account expired some time in 1970 :-), > whereas sshd expects "-1" if account expiry is disabled. > > It might be reasonable to check for zero too, *provided* that does not > have a special meaning on some platform. (sp_lstchg == 0 is used on > many platforms to indicate a root-forced password change, but I don't > know if sp_expire is used for something similar). > > > ------------------------------------------------------------------------ > > Index: auth-shadow.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-shadow.c,v > retrieving revision 1.5 > diff -u -p -r1.5 auth-shadow.c > --- auth-shadow.c 21 Feb 2004 23:22:05 -0000 1.5 > +++ auth-shadow.c 5 Jul 2004 07:17:23 -0000 > @@ -57,7 +57,7 @@ auth_shadow_acctexpired(struct spwd *spw > debug3("%s: today %d sp_expire %d days left %d", __func__, (int)today, > (int)spw->sp_expire, daysleft); > > - if (spw->sp_expire == -1) { > + if (spw->sp_expire == -1 || spw->sp_expire == 0) { > debug3("account expiration disabled"); > } else if (daysleft < 0) { > logit("Account %.100s has expired", spw->sp_namp); > > > ------------------------------------------------------------------------ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Damien Mascord (tusker at tusker dot org) GPG key 2CB181BE / 93B2 EF21 0C7C F022 F467 7966 219E 92B3 2CB1 81BE From vangyzen at stat.duke.edu Thu Jul 8 04:13:58 2004 From: vangyzen at stat.duke.edu (Eric van Gyzen) Date: Wed, 07 Jul 2004 14:13:58 -0400 Subject: scp man page: source vs. destination Message-ID: <40EC3D66.3000205@stat.duke.edu> As a fairly experienced Unix user, it's obvious to me that scp copies files from left to right -- that is, that the last [host:]file on the command line is the destination. However, this might not be so obvious to users with less experience. It pains me to suggest this, but perhaps the scp man page should be edited to make this more obvious. For example, from the [Free]BSD cp(1) man page: SYNOPSIS cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] source_file target_file cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] source_file ... target_directory DESCRIPTION In the first synopsis form, the cp utility copies the contents of the source_file to the target_file. In the second synopsis form, the contents of each named source_file is copied to the destination target_directory. Eric -- Eric van Gyzen Sr. Systems Programmer http://www.stat.duke.edu/~vangyzen/ ISDS, Duke University From stevensm at gmail.com Thu Jul 8 04:51:53 2004 From: stevensm at gmail.com (Michael Stevens) Date: Wed, 7 Jul 2004 14:51:53 -0400 Subject: DynamicWindow Patch Message-ID: <70621a460407071151437a9778@mail.gmail.com> We have developed a patch that enables changing the SSH window size using the tcp window size as the source. This allows SSH to obtain maximum use of the bandwidth on high BDP links. We also have a page that describes the changes and performance. http://www.psc.edu/~rapier/hpn-ssh/ The patch against CVS is included here. Common subdirectories: src/usr.bin/ssh/CVS and ssh/CVS diff -u src/usr.bin/ssh/buffer.c ssh/buffer.c --- src/usr.bin/ssh/buffer.c 2003-11-21 06:57:03.000000000 -0500 +++ ssh/buffer.c 2004-07-07 10:04:27.000000000 -0400 @@ -18,6 +18,14 @@ #include "buffer.h" #include "log.h" +static int unlimited = 0; + +void +set_unlimited(Buffer *buffer, int new_value) +{ + buffer->unlimited = new_value; +} + /* Initializes the buffer structure. */ void @@ -30,6 +38,7 @@ buffer->alloc = len; buffer->offset = 0; buffer->end = 0; + buffer->unlimited = 0; } /* Frees any memory used for the buffer. */ @@ -78,7 +87,7 @@ u_int newlen; void *p; - if (len > 0x100000) + if (!buffer->unlimited && len > 0x100000) fatal("buffer_append_space: len %u not supported", len); /* If the buffer is empty, start using it from the beginning. */ @@ -107,7 +116,7 @@ /* Increase the size of the buffer and retry. */ newlen = buffer->alloc + len + 32768; - if (newlen > 0xa00000) + if (!buffer->unlimited && newlen > 0xa00000) fatal("buffer_append_space: alloc %u not supported", newlen); buffer->buf = xrealloc(buffer->buf, newlen); diff -u src/usr.bin/ssh/buffer.h ssh/buffer.h --- src/usr.bin/ssh/buffer.h 2002-03-04 12:27:39.000000000 -0500 +++ ssh/buffer.h 2004-07-07 10:02:24.000000000 -0400 @@ -21,8 +21,11 @@ u_int alloc; /* Number of bytes allocated for data. */ u_int offset; /* Offset of first byte containing data. */ u_int end; /* Offset of last byte containing data. */ + u_int unlimited; } Buffer; +void set_unlimited(Buffer *,int); + void buffer_init(Buffer *); void buffer_clear(Buffer *); void buffer_free(Buffer *); diff -u src/usr.bin/ssh/channels.c ssh/channels.c --- src/usr.bin/ssh/channels.c 2004-06-13 21:44:38.000000000 -0400 +++ ssh/channels.c 2004-07-07 10:02:24.000000000 -0400 @@ -255,6 +255,7 @@ c->local_window_max = window; c->local_consumed = 0; c->local_maxpacket = maxpack; + c->dynamic_window = 0; c->remote_id = -1; c->remote_name = xstrdup(remote_name); c->remote_window = 0; @@ -1520,14 +1521,26 @@ !(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) && c->local_window < c->local_window_max/2 && c->local_consumed > 0) { + u_int32_t tcpwinsz = 0; + socklen_t optsz = sizeof(tcpwinsz); + int ret = -1; + u_int32_t addition = 0; + if (c->dynamic_window) + ret = getsockopt(packet_get_connection_in(), + SOL_SOCKET, SO_RCVBUF, &tcpwinsz, &optsz); + if (c->dynamic_window && (ret == 0) && + (tcpwinsz > c->local_window_max)) { + addition = 2 * tcpwinsz - c->local_window_max; + c->local_window_max += addition; + } packet_start(SSH2_MSG_CHANNEL_WINDOW_ADJUST); packet_put_int(c->remote_id); - packet_put_int(c->local_consumed); + packet_put_int(c->local_consumed + addition); packet_send(); debug2("channel %d: window %d sent adjust %d", c->self, c->local_window, c->local_consumed); - c->local_window += c->local_consumed; + c->local_window += c->local_consumed + addition; c->local_consumed = 0; } return 1; Only in ssh: channels.c~ diff -u src/usr.bin/ssh/channels.h ssh/channels.h --- src/usr.bin/ssh/channels.h 2004-06-13 11:03:02.000000000 -0400 +++ ssh/channels.h 2004-07-07 10:02:24.000000000 -0400 @@ -97,6 +97,7 @@ u_int local_window_max; u_int local_consumed; u_int local_maxpacket; + int dynamic_window; int extended_usage; int single_connection; Common subdirectories: src/usr.bin/ssh/lib and ssh/lib Common subdirectories: src/usr.bin/ssh/scard and ssh/scard Common subdirectories: src/usr.bin/ssh/scp and ssh/scp diff -u src/usr.bin/ssh/serverloop.c ssh/serverloop.c --- src/usr.bin/ssh/serverloop.c 2004-05-21 07:33:11.000000000 -0400 +++ ssh/serverloop.c 2004-07-07 10:02:24.000000000 -0400 @@ -892,6 +892,9 @@ c = channel_new("session", SSH_CHANNEL_LARVAL, -1, -1, -1, /*window size*/0, CHAN_SES_PACKET_DEFAULT, 0, "server-session", 1); + set_unlimited(&c->input,1); + set_unlimited(&c->output,1); + c->dynamic_window = 1; if (session_open(the_authctxt, c->self) != 1) { debug("session open failed, free channel %d", c->self); channel_free(c); Only in ssh: serverloop.c~ Common subdirectories: src/usr.bin/ssh/sftp and ssh/sftp Common subdirectories: src/usr.bin/ssh/sftp-server and ssh/sftp-server Common subdirectories: src/usr.bin/ssh/ssh and ssh/ssh Common subdirectories: src/usr.bin/ssh/ssh-add and ssh/ssh-add Common subdirectories: src/usr.bin/ssh/ssh-agent and ssh/ssh-agent Common subdirectories: src/usr.bin/ssh/ssh-keygen and ssh/ssh-keygen Common subdirectories: src/usr.bin/ssh/ssh-keyscan and ssh/ssh-keyscan Common subdirectories: src/usr.bin/ssh/ssh-keysign and ssh/ssh-keysign diff -u src/usr.bin/ssh/ssh.c ssh/ssh.c --- src/usr.bin/ssh/ssh.c 2004-06-13 11:03:02.000000000 -0400 +++ ssh/ssh.c 2004-07-07 10:02:24.000000000 -0400 @@ -1125,7 +1125,11 @@ "session", SSH_CHANNEL_OPENING, in, out, err, window, packetmax, CHAN_EXTENDED_WRITE, "client-session", /*nonblock*/0); - + if (!tty_flag) { + c->dynamic_window = 1; + set_unlimited(&c->input,1); + set_unlimited(&c->output,1); + } debug3("ssh_session2_open: channel_new: %d", c->self); channel_send_open(c->self); Only in ssh: ssh.c~ Common subdirectories: src/usr.bin/ssh/sshd and ssh/sshd From markus at openbsd.org Thu Jul 8 07:44:31 2004 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Jul 2004 23:44:31 +0200 Subject: DynamicWindow Patch In-Reply-To: <70621a460407071151437a9778@mail.gmail.com> References: <70621a460407071151437a9778@mail.gmail.com> Message-ID: <20040707214431.GA29787@folly> On Wed, Jul 07, 2004 at 02:51:53PM -0400, Michael Stevens wrote: > We have developed a patch that enables changing the SSH window size > using the tcp window size as the source. This allows SSH to obtain > maximum use of the bandwidth on high BDP links. > > We also have a page that describes the changes and performance. > http://www.psc.edu/~rapier/hpn-ssh/ > > The patch against CVS is included here. > - if (len > 0x100000) > + if (!buffer->unlimited && len > 0x100000) > fatal("buffer_append_space: len %u not supported", len); that's dangerous, is it really necessary? we could crank the 0x100000. > + u_int32_t tcpwinsz = 0; > + socklen_t optsz = sizeof(tcpwinsz); > + int ret = -1; > + u_int32_t addition = 0; > + if (c->dynamic_window) > + ret = getsockopt(packet_get_connection_in(), > + SOL_SOCKET, SO_RCVBUF, &tcpwinsz, &optsz); > + if (c->dynamic_window && (ret == 0) && > + (tcpwinsz > c->local_window_max)) { > + addition = 2 * tcpwinsz - c->local_window_max; > + c->local_window_max += addition; > + } why do you need to do this here? why not just announce a bigger window when the channel is created? does SO_RCVBUF change during the session? otherwise we could do this instead. but i agree, we should really improve the WINDOW_ADJUST handling. Index: ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.222 diff -u -r1.222 ssh.c --- ssh.c 23 Jun 2004 14:31:01 -0000 1.222 +++ ssh.c 7 Jul 2004 21:21:53 -0000 @@ -1096,6 +1096,8 @@ { Channel *c; int window, packetmax, in, out, err; + u_int32_t tcpwinsz = 0; + socklen_t optsz = sizeof(tcpwinsz); if (stdin_null_flag) { in = open(_PATH_DEVNULL, O_RDONLY); @@ -1122,6 +1124,10 @@ window >>= 1; packetmax >>= 1; } + if (getsockopt(packet_get_connection_in(),SOL_SOCKET, SO_RCVBUF, + &tcpwinsz, &optsz) == 0) + window = 2 * tcpwinsz; + c = channel_new( "session", SSH_CHANNEL_OPENING, in, out, err, window, packetmax, CHAN_EXTENDED_WRITE, From stevensm at gmail.com Thu Jul 8 12:19:49 2004 From: stevensm at gmail.com (Michael Stevens) Date: Wed, 7 Jul 2004 22:19:49 -0400 Subject: DynamicWindow Patch In-Reply-To: <20040707214431.GA29787@folly> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> Message-ID: <70621a4604070719192d16f2de@mail.gmail.com> > > - if (len > 0x100000) > > + if (!buffer->unlimited && len > 0x100000) > > fatal("buffer_append_space: len %u not supported", len); > > that's dangerous, is it really necessary? we could > crank the 0x100000. I'm not sure I see where the danger is coming from besides memory consumption when the user locally sets a large window. The problem I see with that is now instead of unlimited, you can only go up to that static size. The unlimited flag is only set for the buffers in/out buffer on the channel. > > > + u_int32_t tcpwinsz = 0; > > + socklen_t optsz = sizeof(tcpwinsz); > > + int ret = -1; > > + u_int32_t addition = 0; > > + if (c->dynamic_window) > > + ret = getsockopt(packet_get_connection_in(), > > + SOL_SOCKET, SO_RCVBUF, &tcpwinsz, &optsz); > > + if (c->dynamic_window && (ret == 0) && > > + (tcpwinsz > c->local_window_max)) { > > + addition = 2 * tcpwinsz - c->local_window_max; > > + c->local_window_max += addition; > > + } > > why do you need to do this here? why not just announce a bigger > window when the channel is created? > > does SO_RCVBUF change during the session? otherwise we could do > this instead. but i agree, we should really improve the WINDOW_ADJUST > handling. It is specifically to allow the ssh window to grow when the tcp window does. There are tools that allow you to change the tcpbuffer while the program runs, autotuning tcp stacks being one of them. Mike From markus at openbsd.org Thu Jul 8 17:53:57 2004 From: markus at openbsd.org (Markus Friedl) Date: Thu, 8 Jul 2004 09:53:57 +0200 Subject: DynamicWindow Patch In-Reply-To: <70621a4604070719192d16f2de@mail.gmail.com> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> Message-ID: <20040708075356.GA1663@folly> On Wed, Jul 07, 2004 at 10:19:49PM -0400, Michael Stevens wrote: > > > - if (len > 0x100000) > > > + if (!buffer->unlimited && len > 0x100000) > > > fatal("buffer_append_space: len %u not supported", len); > > > > that's dangerous, is it really necessary? we could > > crank the 0x100000. > > I'm not sure I see where the danger is coming from besides memory you want to avoid overflows in + and *. From markus at openbsd.org Thu Jul 8 17:55:05 2004 From: markus at openbsd.org (Markus Friedl) Date: Thu, 8 Jul 2004 09:55:05 +0200 Subject: DynamicWindow Patch In-Reply-To: <40ECC335.60802@psc.edu> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> Message-ID: <20040708075505.GB1663@folly> On Wed, Jul 07, 2004 at 11:44:53PM -0400, Chris Rapier wrote: > Michael Stevens wrote: > >>>- if (len > 0x100000) > >>>+ if (!buffer->unlimited && len > 0x100000) > >>> fatal("buffer_append_space: len %u not supported", len); > >> > >>that's dangerous, is it really necessary? we could > >>crank the 0x100000. > > > > > >I'm not sure I see where the danger is coming from besides memory > >consumption when the user locally sets a large window. The problem I > >see with that is now instead of unlimited, you can only go up to that > >static size. The unlimited flag is only set for the buffers in/out > >buffer on the channel. > > Something to keep in mind is that uping any static limit on the buffer > size only pushes the problem off on to people down the line. The fact of still, how does this matter if the tcp send and receive space are big enough? From tawi at gruft.de Thu Jul 8 19:28:05 2004 From: tawi at gruft.de (Tanja Wittke) Date: Thu, 8 Jul 2004 11:28:05 +0200 Subject: How to use publickey from x509 certificate? Message-ID: <20040708092804.GA94530@gruft.de> Hello, I have the following problem: I want to use publickey authentication by using the publickey of a x509 certificate stored on a java card. I can already extract the publickey of the certificate and write it into a file. The problem i have is that i don't know how to convert the certificate's publickey into an rsa publickey format that openssh will accept. Does anybody have a hint for me? Thank you in advance, tawi From dtucker at zip.com.au Thu Jul 8 20:15:22 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 08 Jul 2004 20:15:22 +1000 Subject: AIX lssrc command error after installed OpenSSH In-Reply-To: References: Message-ID: <40ED1EBA.1070202@zip.com.au> Lambert.Lau at hk.standardchartered.com wrote: > I did try the chsys command and it worked, an lssrc > showed it subsystem as active for a while but the SRC > stopped responding a short while later. Then ran > chssys -s prngd -a '-D' which had no effect. Instead of "-D" you will need the flag for prngd that tells it not to fork (for my copy of prngd that's "-f"). > I get a > message telling me that the System Resource Controller > daemon is not active. > > The only way I am able to fix the SRC hang is to > deinstall SCBprngd.rte and SCBsshd.rte Does a package built without prngd with the supplied package builder (contrib/aix/buildbff.sh) behave the same way? Regardless, it sould like you're triggering a bug in SRC, you should report it to IBM. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Jul 8 20:26:05 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 08 Jul 2004 20:26:05 +1000 Subject: urgent bug to report In-Reply-To: References: Message-ID: <40ED213D.4080208@zip.com.au> djekels at citistreetonline.com wrote: > OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 > > On HP-UX 11.11 ? sshd runs fine for days, then for some strange reason > we get > > ssh_exchange_identification: Connection closed by remote host What do the server logs say? Does the server have PAM enabled? -- 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 djm at mindrot.org Thu Jul 8 22:19:42 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 08 Jul 2004 22:19:42 +1000 Subject: How to use publickey from x509 certificate? In-Reply-To: <20040708092804.GA94530@gruft.de> References: <20040708092804.GA94530@gruft.de> Message-ID: <40ED3BDE.3000508@mindrot.org> Tanja Wittke wrote: > Hello, > > I have the following problem: I want to use publickey authentication by > using the publickey of a x509 certificate stored on a java card. I can > already extract the publickey of the certificate and write it into a > file. The problem i have is that i don't know how to convert the > certificate's publickey into an rsa publickey format that openssh will > accept. You will need the private key if you want to do ssh authentication too, this isn't contained in the certificate. Most smartcards are configured not to allow extraction of the private key. The public key is easy to extract: $ openssl x509 -pubkey -noout -in newcert.pem -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCiax2Tn3aXOVOqSw5EP+Hc+Euy hyfm5XxYFFhCI8KOw9UcUZ5uaZ4u+hca8DlM6vrP4GnU1f8RQK77D/uLRrwGb+5k X0In4/sbSipOG3mxnPN9LC5gS06t1JSbOwhWbGECtWwbYCz0XF/HsFf5gP06Sexa aYMN/isaJQjBSXBECQIDAQAB -----END PUBLIC KEY----- (this assumes your certificate is PEM encoded) -d From rapier at psc.edu Thu Jul 8 22:39:44 2004 From: rapier at psc.edu (Chris Rapier) Date: Thu, 08 Jul 2004 08:39:44 -0400 Subject: DynamicWindow Patch References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> <20040708075505.GB1663@folly> Message-ID: <40ED4090.8080008@psc.edu> Markus Friedl wrote: > On Wed, Jul 07, 2004 at 11:44:53PM -0400, Chris Rapier wrote: > >>Michael Stevens wrote: >> >>>>>- if (len > 0x100000) >>>>>+ if (!buffer->unlimited && len > 0x100000) >>>>> fatal("buffer_append_space: len %u not supported", len); >>>> >>>>that's dangerous, is it really necessary? we could >>>>crank the 0x100000. >>> >>> >>>I'm not sure I see where the danger is coming from besides memory >>>consumption when the user locally sets a large window. The problem I >>>see with that is now instead of unlimited, you can only go up to that >>>static size. The unlimited flag is only set for the buffers in/out >>>buffer on the channel. >> >>Something to keep in mind is that uping any static limit on the buffer >>size only pushes the problem off on to people down the line. The fact of > > > still, how does this matter if the tcp send and receive space are big enough? How do you determine what is big enough so that 3 or 5 years from now we don't have to crank up that limit again? From dtucker at zip.com.au Thu Jul 8 22:41:28 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 08 Jul 2004 22:41:28 +1000 Subject: urgent bug to report In-Reply-To: References: Message-ID: <40ED40F8.60000@zip.com.au> djekels at citistreetonline.com wrote: > What type of logs are we looking at, syslog? Yes, any syslog messages from sshd (probably in authlog, but that will depend on the settings of SyslogFacility and your syslog.conf). > Yes PAM is enabled. Check if there are extra "sshd [pam]" processes running, you might be running out of resources. (This is because sshd 3.8p1 and 3.8.1p1 fail to clean up the PAM child process under some conditions). If so, please try the attached patch. -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-pam-cleanup.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040708/6a02af0b/attachment.ksh From mstevens at cmu.edu Thu Jul 8 22:49:56 2004 From: mstevens at cmu.edu (Michael A Stevens) Date: Thu, 8 Jul 2004 08:49:56 -0400 (EDT) Subject: DynamicWindow Patch In-Reply-To: <20040708075505.GB1663@folly> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> <20040708075505.GB1663@folly> Message-ID: On Thu, 8 Jul 2004, Markus Friedl wrote: > On Wed, Jul 07, 2004 at 11:44:53PM -0400, Chris Rapier wrote: > > Michael Stevens wrote: > > >>>- if (len > 0x100000) > > >>>+ if (!buffer->unlimited && len > 0x100000) > > >>> fatal("buffer_append_space: len %u not supported", len); > > >> > > >>that's dangerous, is it really necessary? we could > > >>crank the 0x100000. > > > > > > > > >I'm not sure I see where the danger is coming from besides memory > > >consumption when the user locally sets a large window. The problem I > > >see with that is now instead of unlimited, you can only go up to that > > >static size. The unlimited flag is only set for the buffers in/out > > >buffer on the channel. > > > > Something to keep in mind is that uping any static limit on the buffer > > size only pushes the problem off on to people down the line. The fact of > > still, how does this matter if the tcp send and receive space are big enough? It also creates the need for some ugly hack where you know the maximum size of the buffer in the dynamic window code. Mike From djm at mindrot.org Thu Jul 8 22:52:34 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 08 Jul 2004 22:52:34 +1000 Subject: DynamicWindow Patch In-Reply-To: <40ED4090.8080008@psc.edu> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> <20040708075505.GB1663@folly> <40ED4090.8080008@psc.edu> Message-ID: <40ED4392.9000700@mindrot.org> Chris Rapier wrote: > How do you determine what is big enough so that 3 or 5 years from now we > don't have to crank up that limit again? There are other limits that may need to change over 3 to 5 years, so this isn't a terrible problem. Anyway making it "unlimited" just means "unlimited until you run into the edge of size_t". -d From djm at mindrot.org Thu Jul 8 23:02:56 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 08 Jul 2004 23:02:56 +1000 Subject: DynamicWindow Patch In-Reply-To: References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> <20040708075505.GB1663@folly> Message-ID: <40ED4600.1020302@mindrot.org> Michael A Stevens wrote: >>still, how does this matter if the tcp send and receive space are big enough? > > > It also creates the need for some ugly hack where you know the maximum > size of the buffer in the dynamic window code. It will need to have an idea of the limit anyway, otherwise how would it stop from overflowing size_t? The max TCP window is 2^32, size_t is 2^31-1 and we need at least one bit of headroom to be safe against arithmetic overflows. -d From mstevens at cmu.edu Thu Jul 8 23:12:26 2004 From: mstevens at cmu.edu (Michael A Stevens) Date: Thu, 8 Jul 2004 09:12:26 -0400 (EDT) Subject: DynamicWindow Patch In-Reply-To: <40ED4600.1020302@mindrot.org> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> <20040708075505.GB1663@folly> <40ED4600.1020302@mindrot.org> Message-ID: On Thu, 8 Jul 2004, Damien Miller wrote: > Michael A Stevens wrote: > >>still, how does this matter if the tcp send and receive space are big enough? > > > > > > It also creates the need for some ugly hack where you know the maximum > > size of the buffer in the dynamic window code. > > It will need to have an idea of the limit anyway, otherwise how would it > stop from overflowing size_t? The max TCP window is 2^32, size_t is > 2^31-1 and we need at least one bit of headroom to be safe against > arithmetic overflows. > So the max size we should allow is 2^30-1? Mike From rapier at psc.edu Fri Jul 9 01:02:57 2004 From: rapier at psc.edu (Christopher Rapier) Date: Thu, 8 Jul 2004 11:02:57 -0400 Subject: DynamicWindow Patch In-Reply-To: <40ED4392.9000700@mindrot.org> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> <20040708075505.GB1663@folly> <40ED4090.8080008@psc.edu> <40ED4392.9000700@mindrot.org> Message-ID: On Jul 8, 2004, at 8:52 AM, Damien Miller wrote: > Chris Rapier wrote: > >> How do you determine what is big enough so that 3 or 5 years from now >> we >> don't have to crank up that limit again? > > There are other limits that may need to change over 3 to 5 years, so > this isn't a terrible problem. > > Anyway making it "unlimited" just means "unlimited until you run into > the edge of size_t". This is a good point and something, I am ashamed to say, I did not consider. I'm really just thinking about what are probably extreme situations and a 2^30-1 buffer should be more than enough to cover even those (a 60gbit single stream transpacific would end up being buffer limited but for now I think thats sufficiently far enough away to not worry about it). From djekels at citistreetonline.com Thu Jul 8 22:47:18 2004 From: djekels at citistreetonline.com (djekels at citistreetonline.com) Date: Thu, 8 Jul 2004 08:47:18 -0400 Subject: urgent bug to report Message-ID: Ok, thanks, I will check into the server logs when I get to the office. I will also try the patch. Donny -----Original Message----- From: dtucker at zip.com.au [mailto:dtucker at zip.com.au] Sent: Thursday, July 08, 2004 8:41 AM To: Donny Jekels Cc: openssh-unix-dev at mindrot.org Subject: Re: urgent bug to report djekels at citistreetonline.com wrote: > What type of logs are we looking at, syslog? Yes, any syslog messages from sshd (probably in authlog, but that will depend on the settings of SyslogFacility and your syslog.conf). > Yes PAM is enabled. Check if there are extra "sshd [pam]" processes running, you might be running out of resources. (This is because sshd 3.8p1 and 3.8.1p1 fail to clean up the PAM child process under some conditions). If so, please try the attached patch. -- 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 tawi at gruft.de Thu Jul 8 19:28:05 2004 From: tawi at gruft.de (Tanja Wittke) Date: Thu, 8 Jul 2004 11:28:05 +0200 Subject: How to use publickey from x509 certificate? Message-ID: <20040708092804.GA94530@gruft.de> Hello, I have the following problem: I want to use publickey authentication by using the publickey of a x509 certificate stored on a java card. I can already extract the publickey of the certificate and write it into a file. The problem i have is that i don't know how to convert the certificate's publickey into an rsa publickey format that openssh will accept. Does anybody have a hint for me? Thank you in advance, tawi From rac at tenzing.org Fri Jul 9 02:31:40 2004 From: rac at tenzing.org (Roger Cornelius) Date: Thu, 8 Jul 2004 12:31:40 -0400 Subject: openssh 3.8.1p1 problem on SCO 5.0.7 Message-ID: <200407081631.i68GVei20316@tenzing.org> On SCO 5.0.7 and openssh 3.8.1p1, two entries are written to /etc/wtmp and /etc/wtmpx each time a user logs in via ssh. This can be demonstrated using the last(C) command. Any user connected via ssh will have two identical login and logout entries. On SCO, login_write() in loginrec.c calls both wtmp_write_entry() and wtmpx_write_entry() (USE_WTMP and USE_WTMPX are defined). wtmp_write_entry() writes the first entry to /etc/wtmp. wtmpx_write_entry() ultimately calls updwtmpx() (HAVE_UPDWTMPX is defined) to write the /etc/wtmpx entry. But updwtmpx() writes entries to both the wtmp and wtmpx files on SCO, so now we have two entries in /etc/wtmp and one in /etc/wtmpx. I'm guessing updwtmpx() then synchronizes wtmpx with wtmp, since a second entry ends up in wtmpx as well. I think this behaviour of updwtmpx() is also true of other OSs. Here's the relevant section of the getutx(S) man page: updwtmpx(S) checks the existence of wfilex and its parallel file wfile, whose name is obtained by removing the final ``x'' from wfilex. If only one of them exists, the other is created and initialized to reflect the state of the existing file. utmpx is written to wfilex, and the corresponding utmp structure is written to the parallel file. If neither file exists nothing happens. My quick fix is to not define HAVE_UPDWTMPX, which causes alternate code in wtmpx_write() to be used. -- Roger Cornelius rac at tenzing.org From rick.jones2 at hp.com Fri Jul 9 03:12:32 2004 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 08 Jul 2004 10:12:32 -0700 Subject: DynamicWindow Patch In-Reply-To: <40ED4090.8080008@psc.edu> References: <70621a460407071151437a9778@mail.gmail.com> <20040707214431.GA29787@folly> <70621a4604070719192d16f2de@mail.gmail.com> <40ECC335.60802@psc.edu> <20040708075505.GB1663@folly> <40ED4090.8080008@psc.edu> Message-ID: <40ED8080.7060300@hp.com> >>> Something to keep in mind is that uping any static limit on the >>> buffer size only pushes the problem off on to people down the line. >>> The fact of >> still, how does this matter if the tcp send and receive space are big >> enough? > How do you determine what is big enough so that 3 or 5 years from now we > don't have to crank up that limit again? The chances of the maximum TCP window size growing beyond current limits, while non-zero, is likely small - perhaps even only a couple multiples of epsilon. And besides, if the TCP folks decide to up that limit, I suspect there will be the better part of a year's advance warning before anything finalized in the IETF. rick jones From djekels at citistreetonline.com Thu Jul 8 22:26:58 2004 From: djekels at citistreetonline.com (djekels at citistreetonline.com) Date: Thu, 8 Jul 2004 08:26:58 -0400 Subject: urgent bug to report Message-ID: What type of logs are we looking at, syslog? Yes PAM is enabled. -----Original Message----- From: dtucker at zip.com.au [mailto:dtucker at zip.com.au] Sent: Thursday, July 08, 2004 6:26 AM To: Donny Jekels Cc: openssh-unix-dev at mindrot.org Subject: Re: urgent bug to report djekels at citistreetonline.com wrote: > OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004 > > On HP-UX 11.11 - sshd runs fine for days, then for some strange reason > we get > > ssh_exchange_identification: Connection closed by remote host What do the server logs say? Does the server have PAM enabled? -- 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 tawi at gruft.de Fri Jul 9 10:14:27 2004 From: tawi at gruft.de (Tanja Wittke) Date: Fri, 9 Jul 2004 02:14:27 +0200 Subject: How to use publickey from x509 certificate? In-Reply-To: <40ED3BDE.3000508@mindrot.org> References: <20040708092804.GA94530@gruft.de> <40ED3BDE.3000508@mindrot.org> Message-ID: <20040709001427.GC47081@gruft.de> Hello, On Thu, Jul 08, 2004 at 10:19:42PM +1000, Damien Miller wrote: > The public key is easy to extract: > > $ openssl x509 -pubkey -noout -in newcert.pem > -----BEGIN PUBLIC KEY----- > MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCiax2Tn3aXOVOqSw5EP+Hc+Euy > hyfm5XxYFFhCI8KOw9UcUZ5uaZ4u+hca8DlM6vrP4GnU1f8RQK77D/uLRrwGb+5k > X0In4/sbSipOG3mxnPN9LC5gS06t1JSbOwhWbGECtWwbYCz0XF/HsFf5gP06Sexa > aYMN/isaJQjBSXBECQIDAQAB > -----END PUBLIC KEY----- Yes, but that's not what I meant. A ssh RSA public key looks like ssh-rsa optional comment But I think this key blob isn't the complete key (modulus,exponent) extracted from the certificate. Maybe just the modulus? Or is there something else I don't see about the ssh RSA public key structure? Thank you, tawi From Clovis.Souza at dbla.com Fri Jul 9 10:33:27 2004 From: Clovis.Souza at dbla.com (Souza, Clovis) Date: Fri, 9 Jul 2004 02:33:27 +0200 Subject: Strong Encryption Message-ID: Does anyone knows which one is the strongest and which is the fastest encryption algorithms used in OpenSSH 3.7.1p2 from the list below aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, arcfour, aes192-cbc, aes256-cbc, rijndael-cbc at lysator.liu.se, aes128-ctr, aes192-ctr, aes256-ctr Strong Encryption OpenSSH supports 3DES, Blowfish, AES and arcfour as encryption algorithms. These are patent free. Triple DES is a time proven and well understood cipher that provides strong encryption. Blowfish is a fast block cipher invented by Bruce Schneier that can be used by people that require faster encryption. AES is the US Federal Information Processing Standard (FIPS) Advanced Encryption Standard developed as a replacement for DES. It is a fast block cipher. Arcfour is a fast stream cipher. It is believed to be compatible with RC4[TM], a proprietary cipher of RSA Security Inc. Encryption is started before authentication, and no passwords or other information is transmitted in the clear. Encryption is also used to protect against spoofed packets. Clovis Gomes de Souza Dresdner Bank Brasil Dresdner Bank Lateinamerika AG Unix and DBA support Network and Telecommunication S?o Paulo Tel: (+55 11) 5188.6923 Fax: (+55 11) 5188.6905 Email: clovis.souza at dbla.com Internet: http://www.dbla.com/ From thesource at ldb-jab.org Fri Jul 9 10:42:49 2004 From: thesource at ldb-jab.org (Lawrence Bowie) Date: Thu, 08 Jul 2004 20:42:49 -0400 Subject: Strong Encryption In-Reply-To: References: Message-ID: <40EDEA09.6040501@ldb-jab.org> Strongest aes-256 (possible attacks on it are differential and linear crytanalysis) or even 3des (because there are known attacks on it becauseit E(E(E(M))), M being the plaintext and E being the encryption function) but they are slower ...Fastest blowfish LDB Souza, Clovis wrote: >Does anyone knows which one is the strongest and which is the fastest >encryption algorithms >used in OpenSSH 3.7.1p2 from the list below > >aes128-cbc, >3des-cbc, >blowfish-cbc, >cast128-cbc, >arcfour, >aes192-cbc, >aes256-cbc, >rijndael-cbc at lysator.liu.se, >aes128-ctr, >aes192-ctr, >aes256-ctr > >Strong Encryption >OpenSSH supports 3DES, Blowfish, AES and arcfour as encryption algorithms. >These are patent free. >Triple DES is a time proven and well understood cipher that provides strong >encryption. >Blowfish is a fast block cipher invented by Bruce Schneier that can be used >by people that require faster encryption. >AES is the US Federal Information Processing >Standard (FIPS) Advanced Encryption Standard developed as a replacement for >DES. It is a fast block cipher. >Arcfour is a fast stream cipher. It is believed to be compatible with >RC4[TM], a proprietary cipher of RSA Security Inc. >Encryption is started before authentication, and no passwords or other >information is transmitted in the clear. Encryption is also used to protect >against spoofed packets. > > > > Clovis Gomes de Souza >Dresdner Bank Brasil >Dresdner Bank Lateinamerika AG >Unix and DBA support >Network and Telecommunication >S?o Paulo >Tel: (+55 11) 5188.6923 >Fax: (+55 11) 5188.6905 >Email: clovis.souza at dbla.com >Internet: http://www.dbla.com/ > > > > > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > From mouring at etoh.eviladmin.org Fri Jul 9 11:32:18 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 8 Jul 2004 20:32:18 -0500 (CDT) Subject: Strong Encryption In-Reply-To: <40EDEA09.6040501@ldb-jab.org> Message-ID: On Thu, 8 Jul 2004, Lawrence Bowie wrote: > Strongest aes-256 (possible attacks on it are differential and linear > crytanalysis) > or even 3des (because there are known attacks on it becauseit E(E(E(M))), > M being the plaintext and E being the encryption function) but they are > slower > > > ...Fastest blowfish > Actually arcfour is the fastest of the listed ones. - Ben From djm at mindrot.org Fri Jul 9 13:34:14 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 09 Jul 2004 13:34:14 +1000 Subject: How to use publickey from x509 certificate? In-Reply-To: <20040709001427.GC47081@gruft.de> References: <20040708092804.GA94530@gruft.de> <40ED3BDE.3000508@mindrot.org> <20040709001427.GC47081@gruft.de> Message-ID: <40EE1236.7040608@mindrot.org> Tanja Wittke wrote: > > Yes, but that's not what I meant. A ssh RSA public key looks like > > ssh-rsa optional comment > > But I think this key blob isn't the complete key (modulus,exponent) > extracted from the certificate. Maybe just the modulus? Or is there > something else I don't see about the ssh RSA public key structure? These can be created from "openssl rsa -pubout -in privatekey.pem" -d From djm at mindrot.org Fri Jul 9 14:36:27 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 09 Jul 2004 14:36:27 +1000 Subject: Strong Encryption In-Reply-To: References: Message-ID: <40EE20CB.3060004@mindrot.org> Souza, Clovis wrote: > Does anyone knows which one is the strongest and which is the fastest > encryption algorithms > used in OpenSSH 3.7.1p2 from the list below The crypto bottleneck in ssh is the MAC, not the cipher. -d From HGRKUBHJNQVCT at hushmail.com Fri Jul 9 17:05:25 2004 From: HGRKUBHJNQVCT at hushmail.com (Rachel Ventura) Date: Fri, 09 Jul 2004 05:05:25 -0200 Subject: you need to come in and find out if you like what you see Message-ID: HELLO...what's up? I'm Rachel ..I'm nice-looking with a webcam...think you'll like what you see;-);-) http://www.s2khost.biz/goodcams/rachel.php?RID=sexyme From vinschen at redhat.com Fri Jul 9 19:43:27 2004 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 9 Jul 2004 11:43:27 +0200 Subject: [PATCH] Tiny correction in Cygwin README Message-ID: <20040709094327.GA7176@cygbert.vinschen.de> Hi, could somebody apply the below patch? It just mentiones that the minires-devel package is needed to build OpenSSH on Cygwin. Thanks, Corinna Index: contrib/cygwin/README =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v retrieving revision 1.14 diff -p -u -r1.14 README --- contrib/cygwin/README 23 Jan 2004 10:35:44 -0000 1.14 +++ contrib/cygwin/README 9 Jul 2004 09:33:01 -0000 @@ -212,8 +212,8 @@ in the Cygwin binary distribution, insta cd /tmp/cygwin-ssh find * \! -type d | tar cvjfT my-openssh.tar.bz2 - -You must have installed the zlib and openssl-devel packages to be able to -build OpenSSH! +You must have installed the zlib, the openssl-devel and the minires-devel +packages to be able to build OpenSSH! Please send requests, error reports etc. to cygwin at cygwin.com. -- Corinna Vinschen Cygwin Co-Project Leader Red Hat, Inc. From cjwatson at debian.org Fri Jul 9 22:35:13 2004 From: cjwatson at debian.org (Colin Watson) Date: Fri, 9 Jul 2004 13:35:13 +0100 Subject: Bug#252676: sshd failure In-Reply-To: <20040604172054.GA12082@kitenet.net> References: <20040604172054.GA12082@kitenet.net> Message-ID: <20040709123513.GA3316@riva.ucam.org> On Fri, Jun 04, 2004 at 01:20:54PM -0400, Joey Hess wrote: > My colocated server was refusing both ssh and ssl telnet connections. > It looked like this: > > joey:~>ssh -v kite > OpenSSH_3.8.1p1 Debian 1:3.8.1p1-4, OpenSSL 0.9.7d 17 Mar 2004 > debug1: Reading configuration data /home/joey/.ssh/config > debug1: Applying options for kite > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connecting to kite [64.62.161.42] port 22. > debug1: Connection established. > debug1: identity file /home/joey/.ssh/identity type -1 > debug1: identity file /home/joey/.ssh/id_rsa type -1 > debug1: identity file /home/joey/.ssh/id_dsa type 2 > ssh_exchange_identification: Connection closed by remote host > > Telnet also hung up before I got to a login prompt. The rest of the serivces > seemed ok. I got a root shell via other means, and tried restarting ssh. No > luck. Tried upgrading the whole system to current unstable, again, no luck. > Then I noticed something strange in ps: > > 14515 ? S 0:00 sshd: joey [pam] > 32215 ? S 0:00 sshd: bdragon [pam] > 8978 ? S 0:00 sshd: joeyh [pam] > > There were a few more that I've elided because they may contain preveligded > information. I don't have a "bdragon" or "joeyh" user, and there were some > other weird users listed. None of these users were really logged in, > that I could tell. We're also seeing these symptoms on a server at work, although they're highly intermittent and very difficult to track down. Debian ssh 3.8.1p1-4 is basically OpenSSH 3.8.1p1 plus Darren Tucker's auth-pam.c patch to kill the PAM thread if the privsep slave dies plus a few other changes which I'm pretty sure are unrelated. In all cases where it goes wrong, the [pam] processes are left lying around either after attempting to log in as a nonexistent user or Ctrl-Cing ssh at a Password: prompt. We're running with UsePrivilegeSeparation yes, UsePAM yes, and PasswordAuthentication no. We noticed this at the end of a diff of auth.log output between when the [pam] processes were left lying around and when they aren't: debug3: ssh_msg_send: type 1 debug3: ssh_msg_recv entering debug3: mm_request_send entering: type 51 debug3: mm_request_receive entering - debug1: do_cleanup fatal: PAM: authentication thread exited unexpectedly debug1: do_cleanup + debug1: PAM: cleanup + debug3: PAM: sshpam_thread_cleanup entering It looks to me as if sshpam_cleanup() and sshpam_thread_cleanup() aren't getting called under all circumstances when they should be, and that the result of this is that the [pam] threads lie around forever until they choke the server. Yet do_cleanup() *is* getting called. Since I believe that neither KRB5 nor GSSAPI is compiled in, this means that either: (a) we're in the login shell child (should certainly hope not, authentication fails) (b) do_cleanup() has been called already in this process (c) authctxt is NULL (which I don't think can be possible, since do_cleanup() must be getting called from cleanup_exit()) So I think I see the problem: if do_cleanup() happens to get called from the "wrong" thread (perhaps the authentication thread itself?), then it doesn't manage to do all the cleanup but nevertheless sets called to 1, and when the main thread comes along later it doesn't do the PAM cleanup. I wish I could provide you with a reliable reproduction recipe, but perhaps this is good enough for a pthreads expert on openssh-unix-dev to work it out? Thanks, -- Colin Watson [cjwatson at flatline.org.uk] From djm at mindrot.org Fri Jul 9 22:51:22 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 09 Jul 2004 22:51:22 +1000 Subject: Bug#252676: sshd failure In-Reply-To: <20040709123513.GA3316@riva.ucam.org> References: <20040604172054.GA12082@kitenet.net> <20040709123513.GA3316@riva.ucam.org> Message-ID: <40EE94CA.1060706@mindrot.org> Colin Watson wrote: > I wish I could provide you with a reliable reproduction recipe, but > perhaps this is good enough for a pthreads expert on openssh-unix-dev to > work it out? Are you compiling with USE_POSIX_THREADS? -d From cjwatson at debian.org Fri Jul 9 23:15:52 2004 From: cjwatson at debian.org (Colin Watson) Date: Fri, 9 Jul 2004 14:15:52 +0100 Subject: Bug#252676: sshd failure In-Reply-To: <40EE94CA.1060706@mindrot.org> References: <20040604172054.GA12082@kitenet.net> <20040709123513.GA3316@riva.ucam.org> <40EE94CA.1060706@mindrot.org> Message-ID: <20040709131552.GE27068@riva.ucam.org> On Fri, Jul 09, 2004 at 10:51:22PM +1000, Damien Miller wrote: > Colin Watson wrote: > > I wish I could provide you with a reliable reproduction recipe, but > > perhaps this is good enough for a pthreads expert on openssh-unix-dev to > > work it out? > > Are you compiling with USE_POSIX_THREADS? No. -- Colin Watson [cjwatson at flatline.org.uk] From gwyllion at ace.ulyssis.org Fri Jul 9 23:15:53 2004 From: gwyllion at ace.ulyssis.org (Dries Schellekens) Date: Fri, 9 Jul 2004 15:15:53 +0200 (CEST) Subject: Strong Encryption In-Reply-To: <40EDEA09.6040501@ldb-jab.org> References: <40EDEA09.6040501@ldb-jab.org> Message-ID: On Thu, 8 Jul 2004, Lawrence Bowie wrote: > Strongest aes-256 (possible attacks on it are differential and linear > crytanalysis) The best possible attack is exhaustive key search. Differential and linear cryptanalysis have a lower complexity (than a brute force attack) only in case of a reduced round version of AES. Yes, there is/was a lot of hype regarding algebraic attacks, but finally it has been proven that they don't work :-) > or even 3des (because there are known attacks on it becauseit E(E(E(M))), > M being the plaintext and E being the encryption function) but they are > slower 3DES is EDE (encrypt-decrypt-encrypt) with 3 keys. This encryption algorithm should not be used as it is much slower than AES and provides no extra security over AES-192 and AES-256. > ...Fastest blowfish Ben already said RC4 is the fastest encryption algorithm supported by SSH, but it has some cryptographic weaknesses. The preferred encryption method is the counter mode CTR. CBC has some small weaknesses; I personally don't consider them that severe. Cheers, Dries -- Dries Schellekens email: gwyllion at ulyssis.org From djm at mindrot.org Thu Jul 8 22:19:42 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 08 Jul 2004 22:19:42 +1000 Subject: How to use publickey from x509 certificate? In-Reply-To: <20040708092804.GA94530@gruft.de> References: <20040708092804.GA94530@gruft.de> Message-ID: <40ED3BDE.3000508@mindrot.org> Tanja Wittke wrote: > Hello, > > I have the following problem: I want to use publickey authentication by > using the publickey of a x509 certificate stored on a java card. I can > already extract the publickey of the certificate and write it into a > file. The problem i have is that i don't know how to convert the > certificate's publickey into an rsa publickey format that openssh will > accept. You will need the private key if you want to do ssh authentication too, this isn't contained in the certificate. Most smartcards are configured not to allow extraction of the private key. The public key is easy to extract: $ openssl x509 -pubkey -noout -in newcert.pem -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCiax2Tn3aXOVOqSw5EP+Hc+Euy hyfm5XxYFFhCI8KOw9UcUZ5uaZ4u+hca8DlM6vrP4GnU1f8RQK77D/uLRrwGb+5k X0In4/sbSipOG3mxnPN9LC5gS06t1JSbOwhWbGECtWwbYCz0XF/HsFf5gP06Sexa aYMN/isaJQjBSXBECQIDAQAB -----END PUBLIC KEY----- (this assumes your certificate is PEM encoded) -d From dtucker at zip.com.au Sat Jul 10 00:36:00 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 10 Jul 2004 00:36:00 +1000 Subject: Bug#252676: sshd failure In-Reply-To: <20040709123513.GA3316@riva.ucam.org> References: <20040604172054.GA12082@kitenet.net> <20040709123513.GA3316@riva.ucam.org> Message-ID: <40EEAD50.8020200@zip.com.au> Colin Watson wrote: [snip bug details] > We're also seeing these symptoms on a server at work, although they're > highly intermittent and very difficult to track down. I will look at this tomorrow. Could you please provide the sshd PAM configs for the machine(s) exhibiting the problem? In particular, are there any PAM modules that might use fork/exec themselves? -- 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 dan at doxpara.com Sat Jul 10 00:17:16 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 09 Jul 2004 07:17:16 -0700 Subject: Strong Encryption In-Reply-To: References: <40EDEA09.6040501@ldb-jab.org> Message-ID: <40EEA8EC.2000501@doxpara.com> >The best possible attack is exhaustive key search. Differential and linear >cryptanalysis have a lower complexity (than a brute force attack) only in >case of a reduced round version of AES. Yes, there is/was a lot of hype >regarding algebraic attacks, but finally it has been proven that they >don't work :-) > > > Were the algebraic attacks formally disproven? (This would be a nice thing.) >>or even 3des (because there are known attacks on it becauseit E(E(E(M))), >>M being the plaintext and E being the encryption function) but they are >>slower >> >> > >3DES is EDE (encrypt-decrypt-encrypt) with 3 keys. This encryption >algorithm should not be used as it is much slower than AES and provides no >extra security over AES-192 and AES-256. > > > 3DES is probably the most analyzed cipher on the planet; that should count for something. FWIW, there's 168 bits of key material, with 112 bits of effective keyspace due to the best possible attack. It's considered a 128-bit class cipher because, well, it's the gold standard of ciphers, and if it wasn't dog slow AES would never have seen the light of day >>...Fastest blowfish >> >> > >Ben already said RC4 is the fastest encryption algorithm supported by SSH, >but it has some cryptographic weaknesses. > > Some? :-) Heh, since when was SHA-1 slower than ciphering? >The preferred encryption method is the counter mode CTR. CBC has some >small weaknesses; I personally don't consider them that severe. > > Given that SSH operates over TCP and thus has perfect record ordering and reconstruction, the advantages of CTR aren't nearly as great. I'm open to being corrected on this assertion, though :-) --Dan From djm at mindrot.org Thu Jul 8 22:19:42 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 08 Jul 2004 22:19:42 +1000 Subject: How to use publickey from x509 certificate? In-Reply-To: <20040708092804.GA94530@gruft.de> References: <20040708092804.GA94530@gruft.de> Message-ID: <40ED3BDE.3000508@mindrot.org> Tanja Wittke wrote: > Hello, > > I have the following problem: I want to use publickey authentication by > using the publickey of a x509 certificate stored on a java card. I can > already extract the publickey of the certificate and write it into a > file. The problem i have is that i don't know how to convert the > certificate's publickey into an rsa publickey format that openssh will > accept. You will need the private key if you want to do ssh authentication too, this isn't contained in the certificate. Most smartcards are configured not to allow extraction of the private key. The public key is easy to extract: $ openssl x509 -pubkey -noout -in newcert.pem -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCiax2Tn3aXOVOqSw5EP+Hc+Euy hyfm5XxYFFhCI8KOw9UcUZ5uaZ4u+hca8DlM6vrP4GnU1f8RQK77D/uLRrwGb+5k X0In4/sbSipOG3mxnPN9LC5gS06t1JSbOwhWbGECtWwbYCz0XF/HsFf5gP06Sexa aYMN/isaJQjBSXBECQIDAQAB -----END PUBLIC KEY----- (this assumes your certificate is PEM encoded) -d From djm at mindrot.org Fri Jul 9 13:34:14 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 09 Jul 2004 13:34:14 +1000 Subject: How to use publickey from x509 certificate? In-Reply-To: <20040709001427.GC47081@gruft.de> References: <20040708092804.GA94530@gruft.de> <40ED3BDE.3000508@mindrot.org> <20040709001427.GC47081@gruft.de> Message-ID: <40EE1236.7040608@mindrot.org> Tanja Wittke wrote: > > Yes, but that's not what I meant. A ssh RSA public key looks like > > ssh-rsa optional comment > > But I think this key blob isn't the complete key (modulus,exponent) > extracted from the certificate. Maybe just the modulus? Or is there > something else I don't see about the ssh RSA public key structure? These can be created from "openssl rsa -pubout -in privatekey.pem" -d From djm at mindrot.org Fri Jul 9 13:34:14 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 09 Jul 2004 13:34:14 +1000 Subject: How to use publickey from x509 certificate? In-Reply-To: <20040709001427.GC47081@gruft.de> References: <20040708092804.GA94530@gruft.de> <40ED3BDE.3000508@mindrot.org> <20040709001427.GC47081@gruft.de> Message-ID: <40EE1236.7040608@mindrot.org> Tanja Wittke wrote: > > Yes, but that's not what I meant. A ssh RSA public key looks like > > ssh-rsa optional comment > > But I think this key blob isn't the complete key (modulus,exponent) > extracted from the certificate. Maybe just the modulus? Or is there > something else I don't see about the ssh RSA public key structure? These can be created from "openssl rsa -pubout -in privatekey.pem" -d From djm at mindrot.org Sat Jul 10 01:08:10 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Jul 2004 01:08:10 +1000 Subject: Strong Encryption In-Reply-To: <40EEA8EC.2000501@doxpara.com> References: <40EDEA09.6040501@ldb-jab.org> <40EEA8EC.2000501@doxpara.com> Message-ID: <40EEB4DA.70401@mindrot.org> Dan Kaminsky wrote: >>Ben already said RC4 is the fastest encryption algorithm supported by SSH, >>but it has some cryptographic weaknesses. > > Some? :-) It has a bias and some key material leakage, though I doubt that these could be used to build a practical attack, at last not in the context of SSH. See: http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps Remember that cryptographers have very different versions of "attack" and "weakness" to the rest of the world. > Heh, since when was SHA-1 slower than ciphering? type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha1 4121.41k 12750.30k 30907.53k 47681.66k 56379.43k rc4 79799.42k 87071.85k 94870.19k 95988.28k 96742.29k HMAC is probably slower still and these numbers probably don't reflect the speed that we achieve because currently we do a MAC ctx setup per packet (IIRC). Markus can post his AES benchmarks from his little VIA processor, they are more fun still :) >>The preferred encryption method is the counter mode CTR. CBC has some >>small weaknesses; I personally don't consider them that severe. > > Given that SSH operates over TCP and thus has perfect record ordering > and reconstruction, the advantages of CTR aren't nearly as great. I'm > open to being corrected on this assertion, though :-) See the discussion of cryptographic weaknesses in the SSH protocol relating to the use of CBC and encrypt-then-MAC on ietf-ssh@ list about 18 months ago - again, (IMO) these were theoretical concerns. -d From tawi at gruft.de Sat Jul 10 01:29:26 2004 From: tawi at gruft.de (Tanja Wittke) Date: Fri, 9 Jul 2004 17:29:26 +0200 Subject: How to use publickey from x509 certificate? In-Reply-To: <000101c465c5$24c046c0$b3c80a0a@MIROGE> References: <20040709001427.GC47081@gruft.de> <000101c465c5$24c046c0$b3c80a0a@MIROGE> Message-ID: <20040709152925.GF47081@gruft.de> On Fri, Jul 09, 2004 at 10:58:05AM -0400, Paul Myers wrote: > An SSH RSA1 Key looks like the one you describe as used in SSH1 for example. > > An SSH RSA Key looks like the one extracted I believe. > > Please correct me if I am wrong... Sorry, but using ssh-keygen -t rsa -f creates the following (test) pubkey for ssh2: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAuaJIafCnHyrItU1PGBwdPrdh8lUcHYmw YtnYnXIcm+Oaf+5uNBAfPbcKWVe8SyJDW3Y5WigB4rMswHzYr8mzwT6fgsmbw9u2il26 IlaIiesbwmuEjJ76u5uGAHiI6zI8Dts079wPMPJzo+ks8LYKFZZiPKs8+Myom+7BVs8D Vrc= blablubb (Well, in one line of course, i just inserted line breaks for the mail). Using ssh-keygen -t rsa1 -f creates keys in RSA1 for SSH1 which look different. My problem is that openssh keys are different from the key structure explained in draft-ietf-secsh-transport. And the only information i have found so far is "openssh keys use a different format". But not, which one... I know that the key consists of a header, a base64 encoded key blob and a comment. But my key blob still seems to be broken, that's why I asked here. - tawi From gwyllion at ace.ulyssis.org Sat Jul 10 01:30:12 2004 From: gwyllion at ace.ulyssis.org (Dries Schellekens) Date: Fri, 9 Jul 2004 17:30:12 +0200 (CEST) Subject: Strong Encryption In-Reply-To: <40EEA8EC.2000501@doxpara.com> References: <40EDEA09.6040501@ldb-jab.org> <40EEA8EC.2000501@doxpara.com> Message-ID: On Fri, 9 Jul 2004, Dan Kaminsky wrote: > >The best possible attack is exhaustive key search. Differential and linear > >cryptanalysis have a lower complexity (than a brute force attack) only in > >case of a reduced round version of AES. Yes, there is/was a lot of hype > >regarding algebraic attacks, but finally it has been proven that they > >don't work :-) > > Were the algebraic attacks formally disproven? (This would be a nice > thing.) Algebraic attacks are in theory possible. But the algorithms proposed by Courtois and other, XL and XSL, are broken. There will be proofs that the complexity of these algorithms is not subexponential (which was claimed by Courtois). A collegue of mine has reviewed an number of papers (by different authors) for some upcoming crypto conferences which prove other bounds for the complexity. Recently I saw a presentation by Claus Diem, a German mathematician, proving that the XL algorithm doesn't pose any danger for the AES algorithm. > >The preferred encryption method is the counter mode CTR. CBC has some > >small weaknesses; I personally don't consider them that severe. > > > > > Given that SSH operates over TCP and thus has perfect record ordering > and reconstruction, the advantages of CTR aren't nearly as great. I'm > open to being corrected on this assertion, though :-) http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-02.txt especially 5.2 Encryption Method Considerations Cheers, Dries -- Dries Schellekens email: gwyllion at ulyssis.org From djm at mindrot.org Sat Jul 10 01:38:23 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Jul 2004 01:38:23 +1000 Subject: How to use publickey from x509 certificate? In-Reply-To: <20040709152925.GF47081@gruft.de> References: <20040709001427.GC47081@gruft.de> <000101c465c5$24c046c0$b3c80a0a@MIROGE> <20040709152925.GF47081@gruft.de> Message-ID: <40EEBBEF.6010603@mindrot.org> Sorry, I had you backwards - I thought that you wanted a PEM public key for your smartcard, not an OpenSSH public key from your smartcard. An OpenSSH private key is just a PEM RSA key, so you can extract a OpenSSH-formatted public key using: ssh-keygen -yf privatekey.pem I don't know of any easy way to convert a PEM public key into an OpenSSH public key. It probably wouldn't be very difficult to modify ssh-keygen to do this. -d From tawi at gruft.de Fri Jul 9 10:14:27 2004 From: tawi at gruft.de (Tanja Wittke) Date: Fri, 9 Jul 2004 02:14:27 +0200 Subject: How to use publickey from x509 certificate? In-Reply-To: <40ED3BDE.3000508@mindrot.org> References: <20040708092804.GA94530@gruft.de> <40ED3BDE.3000508@mindrot.org> Message-ID: <20040709001427.GC47081@gruft.de> Hello, On Thu, Jul 08, 2004 at 10:19:42PM +1000, Damien Miller wrote: > The public key is easy to extract: > > $ openssl x509 -pubkey -noout -in newcert.pem > -----BEGIN PUBLIC KEY----- > MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCiax2Tn3aXOVOqSw5EP+Hc+Euy > hyfm5XxYFFhCI8KOw9UcUZ5uaZ4u+hca8DlM6vrP4GnU1f8RQK77D/uLRrwGb+5k > X0In4/sbSipOG3mxnPN9LC5gS06t1JSbOwhWbGECtWwbYCz0XF/HsFf5gP06Sexa > aYMN/isaJQjBSXBECQIDAQAB > -----END PUBLIC KEY----- Yes, but that's not what I meant. A ssh RSA public key looks like ssh-rsa optional comment But I think this key blob isn't the complete key (modulus,exponent) extracted from the certificate. Maybe just the modulus? Or is there something else I don't see about the ssh RSA public key structure? Thank you, tawi From appro at fy.chalmers.se Sat Jul 10 03:06:05 2004 From: appro at fy.chalmers.se (Andy Polyakov) Date: Fri, 09 Jul 2004 19:06:05 +0200 Subject: Strong Encryption In-Reply-To: <40EEB4DA.70401@mindrot.org> References: <40EDEA09.6040501@ldb-jab.org> <40EEA8EC.2000501@doxpara.com> <40EEB4DA.70401@mindrot.org> Message-ID: <40EED07D.5010806@fy.chalmers.se> >>Heh, since when was SHA-1 slower than ciphering? > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > sha1 4121.41k 12750.30k 30907.53k 47681.66k 56379.43k > rc4 79799.42k 87071.85k 94870.19k 95988.28k 96742.29k If these are numbers for Pentium 4 CPU, then it should be noted that OpenSSL SHA-1 assembler implementation was performing suboptimally on P4. This was fixed in 0.9.7d. I for example get: sha1 9489.58k 32274.82k 91089.08k 165553.74k 215638.02k rc4 77315.06k 86091.19k 87813.80k 89298.28k 88544.83k A. From tim at multitalents.net Sat Jul 10 03:47:30 2004 From: tim at multitalents.net (Tim Rice) Date: Fri, 9 Jul 2004 10:47:30 -0700 (PDT) Subject: [PATCH] Tiny correction in Cygwin README In-Reply-To: <20040709094327.GA7176@cygbert.vinschen.de> References: <20040709094327.GA7176@cygbert.vinschen.de> Message-ID: On Fri, 9 Jul 2004, Corinna Vinschen wrote: > Hi, > > could somebody apply the below patch? It just mentiones that the > minires-devel package is needed to build OpenSSH on Cygwin. Done. > > Thanks, > Corinna > > Index: contrib/cygwin/README > =================================================================== [snip] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Sat Jul 10 13:14:34 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 10 Jul 2004 13:14:34 +1000 Subject: Bug#252676: sshd failure In-Reply-To: <40EEAD50.8020200@zip.com.au> References: <20040604172054.GA12082@kitenet.net> <20040709123513.GA3316@riva.ucam.org> <40EEAD50.8020200@zip.com.au> Message-ID: <40EF5F1A.8070608@zip.com.au> Darren Tucker wrote: > Colin Watson wrote: > [snip bug details] > >> We're also seeing these symptoms on a server at work, although they're >> highly intermittent and very difficult to track down. > > I will look at this tomorrow. I was able to sometimes reproduce this on Debian by connecting to the server PreferredAuthentications=keyboard-interactive then *immediately* cancelling the authentication with ctrl-C. After some digging I think I have found the cause: waitpid will return zero if the process has not exited and none of the conditions listed under "ERRORS" in the man page have been met. Attached is a patch to test for this too (which it should have done in the first place, sigh). I have not been able to reproduce the problem with this patch. (Interestingly, I was not able to reproduce it on Redhat by doing the same thing. I'm not sure why, but Debian is running on faster, dual CPU box so it could be a timing issue.) -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-pam-wait.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040710/e168410e/attachment.ksh From dilinger at voxel.net Sat Jul 10 13:48:11 2004 From: dilinger at voxel.net (Andres Salomon) Date: Fri, 09 Jul 2004 23:48:11 -0400 Subject: Bug#252676: sshd failure In-Reply-To: <40EF5F1A.8070608@zip.com.au> References: <20040604172054.GA12082@kitenet.net> <20040709123513.GA3316@riva.ucam.org> <40EEAD50.8020200@zip.com.au> <40EF5F1A.8070608@zip.com.au> Message-ID: <1089431291.5141.19.camel@toaster.hq.voxel.net> On Sat, 2004-07-10 at 13:14 +1000, Darren Tucker wrote: > After some digging I think I have found the cause: waitpid will > return > zero if the process has not exited and none of the conditions listed > under "ERRORS" in the man page have been met. Attached is a patch to > test for this too (which it should have done in the first place, > sigh). > > I have not been able to reproduce the problem with this patch. Thanks. I've built and installed packages w/ the patch applied; if I see the bug again, I'll let you folks know. -- Andres Salomon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040709/215a9cb2/attachment.bin From solomon at conceptshopping.com Sat Jul 10 21:15:19 2004 From: solomon at conceptshopping.com (Marvin Solomon) Date: Sat, 10 Jul 2004 06:15:19 -0500 Subject: Dangling link to release notes Message-ID: <40EFCFC7.8040107@conceptshopping.com> The first line of ftp://mirror.cs.wisc.edu/pub/mirrors/OpenBSD/OpenSSH/portable/README says See http://www.openssh.com/txt/release-3.8.1 for the release notes. But an attempt to get that page yeilds Not Found The requested URL /txt/release-3.8.1 was not found on this server. Apache/1.3.27 Server at www.openssh.org Port 80 There is, however, a /txt/release-3.8. I can't see what else is there, because http://www.openssh.com/txt gives me Forbidden You don't have permission to access /txt/ on this server. From cjwatson at debian.org Sat Jul 10 22:33:00 2004 From: cjwatson at debian.org (Colin Watson) Date: Sat, 10 Jul 2004 13:33:00 +0100 Subject: Bug#252676: sshd failure In-Reply-To: <40EF5F1A.8070608@zip.com.au> References: <20040604172054.GA12082@kitenet.net> <20040709123513.GA3316@riva.ucam.org> <40EEAD50.8020200@zip.com.au> <40EF5F1A.8070608@zip.com.au> Message-ID: <20040710123300.GH18366@riva.ucam.org> On Sat, Jul 10, 2004 at 01:14:34PM +1000, Darren Tucker wrote: > I was able to sometimes reproduce this on Debian by connecting to the > server PreferredAuthentications=keyboard-interactive then *immediately* > cancelling the authentication with ctrl-C. > > After some digging I think I have found the cause: waitpid will return > zero if the process has not exited and none of the conditions listed > under "ERRORS" in the man page have been met. Attached is a patch to > test for this too (which it should have done in the first place, sigh). > > I have not been able to reproduce the problem with this patch. That makes good sense to me, since in an strace here I'm seeing waitpid() returning zero. > (Interestingly, I was not able to reproduce it on Redhat by doing the > same thing. I'm not sure why, but Debian is running on faster, dual CPU > box so it could be a timing issue.) I can't reproduce it on Debian powerpc, which had been doing my head in; I can well believe a timing issue. I'm applying your patch and will upload shortly after a bit of testing. Thanks! -- Colin Watson [cjwatson at flatline.org.uk] From djm at mindrot.org Sat Jul 10 22:38:40 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Jul 2004 22:38:40 +1000 Subject: Dangling link to release notes In-Reply-To: <40EFCFC7.8040107@conceptshopping.com> References: <40EFCFC7.8040107@conceptshopping.com> Message-ID: <40EFE350.5080704@mindrot.org> See http://www.openssh.com/txt/release-3.8.1p1 for the real release notes. We'll correct the link in the next release. Marvin Solomon wrote: > The first line of > ftp://mirror.cs.wisc.edu/pub/mirrors/OpenBSD/OpenSSH/portable/README > says > See http://www.openssh.com/txt/release-3.8.1 for the release notes. > But an attempt to get that page yeilds > Not Found > The requested URL /txt/release-3.8.1 was not found on this server. > > Apache/1.3.27 Server at www.openssh.org Port 80 > There is, however, a /txt/release-3.8. I can't see what else is there, > because http://www.openssh.com/txt gives me > Forbidden > You don't have permission to access /txt/ on this server. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From stevensm at gmail.com Wed Jul 14 04:15:35 2004 From: stevensm at gmail.com (Michael Stevens) Date: Tue, 13 Jul 2004 14:15:35 -0400 Subject: channel->input buffer bug and patch Message-ID: <70621a4604071311157676320c@mail.gmail.com> In our work with enabling large windows for openssh we found 1) that if a window > 0x10000 is advertised to openssh's sshd 2) the sshd tries to send more than 0x10000 bytes of data 3) the receiver does not consume them 4) the input buffer will grow larger than the size allowed by buffer.c and fatal(). We believe the correct behavior is to limit reading into the channel input buffer to the maximum buffer size. Attached here is a patch, it should work against CVS or portable. diff -u openssh-3.8.1p1/channels.c openssh-3.8.1p1-bugfix/channels.c --- openssh-3.8.1p1/channels.c 2004-01-20 19:02:09.000000000 -0500 +++ openssh-3.8.1p1-bugfix/channels.c 2004-07-13 09:37:20.000000000 -0400 @@ -702,6 +702,8 @@ channel_pre_open(Channel *c, fd_set * readset, fd_set * writeset) { u_int limit = compat20 ? c->remote_window : packet_get_maxsize(); + if (limit > 0x10000) + limit = 0x10000; if (c->istate == CHAN_INPUT_OPEN && limit > 0 && Common subdirectories: openssh-3.8.1p1/contrib and openssh-3.8.1p1-bugfix/contrib Common subdirectories: openssh-3.8.1p1/openbsd-compat and openssh-3.8.1p1-bugfix/openbsd-compat Common subdirectories: openssh-3.8.1p1/regress and openssh-3.8.1p1-bugfix/regress Common subdirectories: openssh-3.8.1p1/scard and openssh-3.8.1p1-bugfix/scard From mouring at etoh.eviladmin.org Wed Jul 14 05:00:04 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 13 Jul 2004 14:00:04 -0500 (CDT) Subject: channel->input buffer bug and patch In-Reply-To: <70621a4604071311157676320c@mail.gmail.com> Message-ID: On Tue, 13 Jul 2004, Michael Stevens wrote: > In our work with enabling large windows for openssh we found > > 1) that if a window > 0x10000 is advertised to openssh's sshd > 2) the sshd tries to send more than 0x10000 bytes of data > 3) the receiver does not consume them > 4) the input buffer will grow larger than the size allowed by buffer.c > and fatal(). > > We believe the correct behavior is to limit reading into the channel > input buffer to the maximum buffer size. Attached here is a patch, it > should work against CVS or portable. > > diff -u openssh-3.8.1p1/channels.c openssh-3.8.1p1-bugfix/channels.c > --- openssh-3.8.1p1/channels.c 2004-01-20 19:02:09.000000000 -0500 > +++ openssh-3.8.1p1-bugfix/channels.c 2004-07-13 09:37:20.000000000 -0400 > @@ -702,6 +702,8 @@ > channel_pre_open(Channel *c, fd_set * readset, fd_set * writeset) > { > u_int limit = compat20 ? c->remote_window : packet_get_maxsize(); > + if (limit > 0x10000) > + limit = 0x10000; > I'm interested in which is returning a greater limit. c->remote_window or packet_get_maxsize() function. Since both are used all over the place for checking buffer sizes and such. So if there is a limiting problem I suspect this may be then the wrong place to handle it. - Ben From keld at dkuug.dk Wed Jul 14 05:13:47 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Tue, 13 Jul 2004 21:13:47 +0200 Subject: vulnerability with ssh-agent Message-ID: <20040713191347.GA3297@rap.rap.dk> Hi I have written a small introduction to newbies in Danish on ssh and friends. Now some people are questioning my advice and I think they have a point. I am advocating people to use DSA-keys and a config file with this: Protocol 2 ForwardAgent yes ForwardX11 yes Compression yes CompressionLevel 9 and running ssh-agent and ssh-add, and then loggin in without giving keys. One commenter said that this has big holes. An intruder with root privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found in /tmp, and he could also find the keys in the /proc area for the ssh-agent. Is that true? Are the keys visible under Linux in the /proc memory mapping for ssh-agent? Could there be done something to better these vulnerabilities? I was thinking along the lines of deleting the socket in temp, if an option "delete_ssk_auth_socket" was given in config, and then only processes that inherited the socket via fork() would have access to the socket, via an open file descriptor. An intruder would then need to program opening of an inode that was deleted, which is much harder than just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. This would work fine in the standard setup, where ssh-agent is launched as part of the initiation of X. If forwardagent is on would there be keys stored in the memory on the machine logged in to (thus findable in /proc), or will ssh-agent there always refer back to the machine logged in from? Would there be a way for ssh-agent to have the keys stored in memory, so that is not easily found in /proc? Best regards Keld Simonsen From stevensm at gmail.com Wed Jul 14 06:05:04 2004 From: stevensm at gmail.com (Michael Stevens) Date: Tue, 13 Jul 2004 16:05:04 -0400 Subject: vulnerability with ssh-agent In-Reply-To: <20040713191347.GA3297@rap.rap.dk> References: <20040713191347.GA3297@rap.rap.dk> Message-ID: <70621a460407131305194e633a@mail.gmail.com> If its in memory, you should assume that root can see it. Mike On Tue, 13 Jul 2004 21:13:47 +0200, Keld J?rn Simonsen wrote: > Hi > > I have written a small introduction to newbies in Danish on ssh and > friends. Now some people are questioning my advice and I think they have > a point. > > I am advocating people to use DSA-keys and a config file with this: > > Protocol 2 > ForwardAgent yes > ForwardX11 yes > Compression yes > CompressionLevel 9 > > and running ssh-agent and ssh-add, and then loggin in without giving > keys. > > One commenter said that this has big holes. An intruder with root > privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found in > /tmp, and he could also find the keys in the /proc area for the > ssh-agent. > > Is that true? > Are the keys visible under Linux in the /proc memory mapping for ssh-agent? > > Could there be done something to better these vulnerabilities? > > I was thinking along the lines of deleting the socket in temp, if an > option "delete_ssk_auth_socket" was given in config, and then only > processes that inherited the socket via fork() would have access to the > socket, via an open file descriptor. An intruder would then need to > program opening of an inode that was deleted, which is much harder than > just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. > This would work fine in the standard setup, where ssh-agent is launched > as part of the initiation of X. > > If forwardagent is on would there be keys stored in the memory on the > machine logged in to (thus findable in /proc), or will ssh-agent there always > refer back to the machine logged in from? > > Would there be a way for ssh-agent to have the keys stored in memory, so > that is not easily found in /proc? > > Best regards > Keld Simonsen > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From Jefferson.Ogata at noaa.gov Wed Jul 14 06:40:11 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 13 Jul 2004 16:40:11 -0400 Subject: vulnerability with ssh-agent In-Reply-To: <20040713191347.GA3297@rap.rap.dk> References: <20040713191347.GA3297@rap.rap.dk> Message-ID: <40F448AB.8020700@noaa.gov> Keld J?rn Simonsen wrote: > I was thinking along the lines of deleting the socket in temp, if an > option "delete_ssk_auth_socket" was given in config, and then only > processes that inherited the socket via fork() would have access to the > socket, via an open file descriptor. An intruder would then need to > program opening of an inode that was deleted, which is much harder than > just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. > This would work fine in the standard setup, where ssh-agent is launched > as part of the initiation of X. Even if you could make this work, the socket would still be accessible to root on Linux under /proc/pid/fd. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From jcs at rt.fm Wed Jul 14 06:21:45 2004 From: jcs at rt.fm (joshua stein) Date: Tue, 13 Jul 2004 15:21:45 -0500 Subject: vulnerability with ssh-agent In-Reply-To: <20040713191347.GA3297@rap.rap.dk> References: <20040713191347.GA3297@rap.rap.dk> Message-ID: <20040713202145.GB7675@rt.fm> > One commenter said that this has big holes. An intruder with root > privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found in > /tmp, and he could also find the keys in the /proc area for the > ssh-agent. if you have "an intruder with root privileges", you have bigger problems > Could there be done something to better these vulnerabilities? don't forward your agent to untrusted machines From gtsang at lnxw.com Wed Jul 14 10:01:53 2004 From: gtsang at lnxw.com (Gilbert Tsang) Date: Tue, 13 Jul 2004 17:01:53 -0700 Subject: OpenSSH Port to Lynxos 4 In-Reply-To: <40EED07D.5010806@fy.chalmers.se> Message-ID: <001501c46935$c5fb9940$2e7f11ac@gtsang3> I am working on a port of 3.8.1p1 to LynxOs 4. The problem I'm encountering now is on "sftp": the symptom is that after password authentication, the call to fgets() (sftp.c, line 1186) by sftp client returns NULL and thus the client exit before the user can enter any command. fgets() eventually call read() and the call fails because of an errno of 0x2 (ENOENT). At this point I'm quite puzzled at what's happening as it seem the forked ssh program has access to stdin (as it was able to get the entered password) but not the parent sftp client program that interacts with user (sftp.c line 1240)? If some kind soul can shed light on this problem I'm willing to try out and share my findings. (First time poster to this mailing list so pardon me if I've missed some etiquette). Cheers, Gilbert. P.S. I have attached a detailed log as follows: gtsang1# sftp -vvv gtsang at localhost Connecting to localhost... OpenSSH_3.8.1p1, OpenSSL 0.9.6 24 Sep 2000 debug1: Reading configuration data /usr/local/etc/ssh_config debug3: Seeding PRNG from /usr/local/libexec/ssh-rand-helper debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 debug3: RNG is ready, skipping seeding debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 124/256 debug2: bits set: 525/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host 'localhost' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:2 debug2: bits set: 487/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/id_rsa (0) debug2: key: /.ssh/id_dsa (0) debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: start over, passed a different list publickey,password,keyboard-interact ive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/id_rsa debug3: no such identity: /.ssh/id_rsa debug1: Trying private key: /.ssh/id_dsa debug3: no such identity: /.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password gtsang at localhost's password: debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug2: fd 5 setting O_NONBLOCK debug2: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: ssh_session2_setup: id 0 debug1: Sending subsystem: sftp debug2: channel 0: request subsystem debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: Remote version: 3 debug3: Sent message fd 3 T:16 I:1 debug3: SSH_FXP_REALPATH . -> / sftp> debug2: channel 0: read<=0 rfd 5 len 0 errno=No such file or directory (0x2) debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel 0: close_fds r -1 w -1 e 7 debug1: fd 0 clearing O_NONBLOCK debug2: fd 1 is not O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0 gtsang1# From rhertzog at hrnet.fr Wed Jul 14 02:40:58 2004 From: rhertzog at hrnet.fr (Raphael Hertzog) Date: Tue, 13 Jul 2004 18:40:58 +0200 Subject: Runnin SSH on slow CPU (386 40Mhz 8Mb RAM) Message-ID: <20040713164058.GA9844@home.ouaza.com> Hello everybody, I'd like to use OpenSSH (client & server, for shell & sftp) on an embedded PC with limited resources (processor 386 SX 40Mhz 8Mb RAM). I have Linux running on it. In the past, I tried to use OpenSSH on it just to see if it could work but each connection required an incredible long time to start. I suppose that the key generation is too expensive for that processor. Is there something I can try to make it work better ? Can we change the key length or use another encryption algorythm which is less CPU-expensive ? Which one of the available cipher is the less CPU expensive ? Can I change ServerKeyBits in sshd_config without breaking interoperability ? Any inputs point me somewhere where I can look further is welcomed. Feel free to point me to the right documentation if such one exists, but my search have been unsuccessfull until now (including the search on the list archive). Thank you for your help. Cheers, -- Rapha?l Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org From gtsang at lnxw.com Wed Jul 14 10:35:38 2004 From: gtsang at lnxw.com (Gilbert Tsang) Date: Tue, 13 Jul 2004 17:35:38 -0700 Subject: OpenSSH Port to Lynxos 4 In-Reply-To: <001501c46935$c5fb9940$2e7f11ac@gtsang3> Message-ID: <001601c4693a$7d081d80$2e7f11ac@gtsang3> Forgot to mention: the symptom is the same no matter I invoke sftp against the sshd on a Linux box or LynxOS box - so the problem lies on the sftp client side. Gilbert. -----Original Message----- From: openssh-unix-dev-bounces+gtsang=lnxw.com at mindrot.org [mailto:openssh-unix-dev-bounces+gtsang=lnxw.com at mindrot.org]On Behalf Of Gilbert Tsang Sent: Tuesday, July 13, 2004 5:02 PM To: openssh-unix-dev at mindrot.org Subject: OpenSSH Port to Lynxos 4 I am working on a port of 3.8.1p1 to LynxOs 4. The problem I'm encountering now is on "sftp": the symptom is that after password authentication, the call to fgets() (sftp.c, line 1186) by sftp client returns NULL and thus the client exit before the user can enter any command. fgets() eventually call read() and the call fails because of an errno of 0x2 (ENOENT). At this point I'm quite puzzled at what's happening as it seem the forked ssh program has access to stdin (as it was able to get the entered password) but not the parent sftp client program that interacts with user (sftp.c line 1240)? If some kind soul can shed light on this problem I'm willing to try out and share my findings. (First time poster to this mailing list so pardon me if I've missed some etiquette). Cheers, Gilbert. P.S. I have attached a detailed log as follows: gtsang1# sftp -vvv gtsang at localhost Connecting to localhost... OpenSSH_3.8.1p1, OpenSSL 0.9.6 24 Sep 2000 debug1: Reading configuration data /usr/local/etc/ssh_config debug3: Seeding PRNG from /usr/local/libexec/ssh-rand-helper debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1 debug1: match: OpenSSH_3.8.1p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 debug3: RNG is ready, skipping seeding debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes2 56-c tr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at open ssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 124/256 debug2: bits set: 525/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host 'localhost' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:2 debug2: bits set: 487/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/id_rsa (0) debug2: key: /.ssh/id_dsa (0) debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: start over, passed a different list publickey,password,keyboard-interact ive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/id_rsa debug3: no such identity: /.ssh/id_rsa debug1: Trying private key: /.ssh/id_dsa debug3: no such identity: /.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password gtsang at localhost's password: debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug2: fd 5 setting O_NONBLOCK debug2: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: ssh_session2_setup: id 0 debug1: Sending subsystem: sftp debug2: channel 0: request subsystem debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: Remote version: 3 debug3: Sent message fd 3 T:16 I:1 debug3: SSH_FXP_REALPATH . -> / sftp> debug2: channel 0: read<=0 rfd 5 len 0 errno=No such file or directory (0x2) debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1) debug3: channel 0: close_fds r -1 w -1 e 7 debug1: fd 0 clearing O_NONBLOCK debug2: fd 1 is not O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0 gtsang1# _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Wed Jul 14 12:07:03 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 14 Jul 2004 12:07:03 +1000 Subject: Runnin SSH on slow CPU (386 40Mhz 8Mb RAM) In-Reply-To: <20040713164058.GA9844@home.ouaza.com> References: <20040713164058.GA9844@home.ouaza.com> Message-ID: <40F49547.5020303@zip.com.au> Raphael Hertzog wrote: > I'd like to use OpenSSH (client & server, for shell & sftp) on > an embedded PC with limited resources (processor 386 SX 40Mhz > 8Mb RAM). I have Linux running on it. > > In the past, I tried to use OpenSSH on it just to see if it could > work but each connection required an incredible long time to start. I > suppose that the key generation is too expensive for that processor. Run ssh -vvv and you will be able to see which steps are taking the most time. > Is there something I can try to make it work better ? Can we change > the key length or use another encryption algorythm which is less > CPU-expensive ? Which one of the available cipher is the less CPU > expensive ? Usually arcfour for symmetric ciphers, but it's probably the public-key stuff (DH, RSA or DSA) that's killing you. > Can I change ServerKeyBits in sshd_config without breaking > interoperability ? Probably yes (within reason) but that will only affect SSHv1 connections. > Any inputs point me somewhere where I can look further is welcomed. Feel > free to point me to the right documentation if such one exists, but my > search have been unsuccessfull until now (including the search on the > list archive). http://www.openssh.com/faq.html#3.3 -- 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 mouring at etoh.eviladmin.org Wed Jul 14 13:32:46 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 13 Jul 2004 22:32:46 -0500 (CDT) Subject: OpenSSH Port to Lynxos 4 In-Reply-To: <001501c46935$c5fb9940$2e7f11ac@gtsang3> Message-ID: On Tue, 13 Jul 2004, Gilbert Tsang wrote: > I am working on a port of 3.8.1p1 to LynxOs 4. > I guess the first few questions should be: 1. What changes have you made to the ssh client? 2. What changes have you made to the sftp client? > The problem I'm encountering now is on "sftp": the symptom is that after > password authentication, the call to fgets() (sftp.c, line 1186) by sftp > client returns NULL and thus the client exit before the user can enter any > command. fgets() eventually call read() and the call fails because of an > errno of 0x2 (ENOENT). At this point I'm quite puzzled at what's happening > as it seem the forked ssh program has access to stdin (as it was able to get > the entered password) but not the parent sftp client program that interacts > with user (sftp.c line 1240)? > could see see a ktrace (or the equiv) around the place where the sftp> prompt is displayed. We should see something like: 28753 sftp RET write 41/0x29 28753 sftp CALL write(0x1,0x13000,0x6) 28753 sftp GIO fd 1 wrote 6 bytes "sftp> " 28753 sftp RET write 6 28753 sftp CALL read(0,0x23000,0x10000) 28753 sftp GIO fd 0 read 5 bytes "quit " 28753 sftp RET read 5 28753 sftp CALL close(0x3) I'm interested to see if it is different. And how. Also do you have HAVE_SETVBUF set in your config.h? If it is set, try unsetting it and recompiling sftp. I'm suspecting lynxos doesn't like how we are setting up the input buffer. That is about all I can think of right off hand. - Ben From pr0gm4 at linoratix.com Thu Jul 15 01:39:54 2004 From: pr0gm4 at linoratix.com (Jan Gehring) Date: Wed, 14 Jul 2004 15:39:54 -0000 Subject: Logging of wrong pubkey auth Message-ID: Hello ml, i've set up a ssh server with public-key authentication. But soon i realized that wrong pubkey authentications are not shown in the logs. So i wrote a small patch for monitor.c included as attachement. patch against 3.8.1p1 $ patch -p0 < /path/to/keyauth-loggin.patch Kindly regards, Jan Gehring From pr0gm4 at linoratix.com Thu Jul 15 03:10:28 2004 From: pr0gm4 at linoratix.com (Jan Gehring) Date: Wed, 14 Jul 2004 19:10:28 +0200 Subject: Logging of wrong pubkey auth In-Reply-To: References: Message-ID: <20040714191028.727cebf5.pr0gm4@linoratix.com> Hm, the attachement was cut ... -----8<-----8<-------8<------- *** monitor.c.orig 2004-07-14 17:26:44.329962192 +0200 --- monitor.c 2004-07-14 17:27:06.511590072 +0200 *************** *** 990,995 **** --- 990,999 ---- debug3("%s: key %p is %s", __func__, key, allowed ? "allowed" : "disallowed"); + if(! allowed) { + logit("Illegal user %.100s from %.100s", authctxt->user,get_remote_ipaddr()); + } + buffer_clear(m); buffer_put_int(m, allowed); buffer_put_int(m, forced_command != NULL); -----8<-----8<-------8<------- > patch against 3.8.1p1 > $ patch -p0 < /path/to/keyauth-loggin.patch > > > Kindly regards, > > Jan Gehring > > From stevensm at gmail.com Thu Jul 15 04:53:23 2004 From: stevensm at gmail.com (Michael Stevens) Date: Wed, 14 Jul 2004 14:53:23 -0400 Subject: New dynamic window patch (with limits) Message-ID: <70621a4604071411537c9936@mail.gmail.com> As before, it is described on our website. This should apply fairly cleanly to both portable and openbsd ssh. http://www.psc.edu/networking/hpn-ssh/ Only in openssh-3.8.1p1-dynwindow: Makefile diff -u openssh-3.8.1p1/buffer.c openssh-3.8.1p1-dynwindow/buffer.c --- openssh-3.8.1p1/buffer.c 2003-11-21 07:56:47.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/buffer.c 2004-07-12 07:49:29.000000000 -0400 @@ -18,6 +18,12 @@ #include "buffer.h" #include "log.h" +void +set_unlimited(Buffer *buffer, int new_value) +{ + buffer->unlimited = new_value; +} + /* Initializes the buffer structure. */ void @@ -30,6 +36,7 @@ buffer->alloc = len; buffer->offset = 0; buffer->end = 0; + buffer->unlimited = 0; } /* Frees any memory used for the buffer. */ @@ -78,7 +85,8 @@ u_int newlen; void *p; - if (len > 0x100000) + if ((buffer->unlimited && len > MAXBUFSZ) || + (!buffer->unlimited && len > 0x100000)) fatal("buffer_append_space: len %u not supported", len); /* If the buffer is empty, start using it from the beginning. */ @@ -107,7 +115,8 @@ /* Increase the size of the buffer and retry. */ newlen = buffer->alloc + len + 32768; - if (newlen > 0xa00000) + if ((buffer->unlimited && newlen > MAXBUFSZ) || + (!buffer->unlimited && newlen > 0xa00000)) fatal("buffer_append_space: alloc %u not supported", newlen); buffer->buf = xrealloc(buffer->buf, newlen); diff -u openssh-3.8.1p1/buffer.h openssh-3.8.1p1-dynwindow/buffer.h --- openssh-3.8.1p1/buffer.h 2002-03-04 20:53:04.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/buffer.h 2004-07-08 07:26:13.000000000 -0400 @@ -16,13 +16,18 @@ #ifndef BUFFER_H #define BUFFER_H +#define MAXBUFSZ (2<<29)-1 + typedef struct { u_char *buf; /* Buffer for data. */ u_int alloc; /* Number of bytes allocated for data. */ u_int offset; /* Offset of first byte containing data. */ u_int end; /* Offset of last byte containing data. */ + u_int unlimited; } Buffer; +void set_unlimited(Buffer *,int); + void buffer_init(Buffer *); void buffer_clear(Buffer *); void buffer_free(Buffer *); diff -u openssh-3.8.1p1/channels.c openssh-3.8.1p1-dynwindow/channels.c --- openssh-3.8.1p1/channels.c 2004-01-20 19:02:09.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/channels.c 2004-07-13 09:46:58.000000000 -0400 @@ -255,6 +255,7 @@ c->local_window_max = window; c->local_consumed = 0; c->local_maxpacket = maxpack; + c->dynamic_window = 0; c->remote_id = -1; c->remote_name = xstrdup(remote_name); c->remote_window = 0; @@ -702,6 +703,10 @@ channel_pre_open(Channel *c, fd_set * readset, fd_set * writeset) { u_int limit = compat20 ? c->remote_window : packet_get_maxsize(); + if (!c->input.unlimited && limit > 0x10000) + limit = 0x10000; + else if (c->input.unlimited && limit > MAXBUFSZ) + limit = MAXBUFSZ; if (c->istate == CHAN_INPUT_OPEN && limit > 0 && @@ -1488,14 +1493,29 @@ !(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) && c->local_window < c->local_window_max/2 && c->local_consumed > 0) { + u_int32_t tcpwinsz = 0; + socklen_t optsz = sizeof(tcpwinsz); + int ret = -1; + u_int32_t addition = 0; + if (c->dynamic_window) { + ret = getsockopt(packet_get_connection_in(), + SOL_SOCKET, SO_RCVBUF, &tcpwinsz, &optsz); + if ((ret == 0) && tcpwinsz/2 > MAXBUFSZ) + tcpwinsz = MAXBUFSZ/2; + } + if (c->dynamic_window && (ret == 0) && + (2*tcpwinsz > c->local_window_max)) { + addition = 2 * tcpwinsz - c->local_window_max; + c->local_window_max += addition; + } packet_start(SSH2_MSG_CHANNEL_WINDOW_ADJUST); packet_put_int(c->remote_id); - packet_put_int(c->local_consumed); + packet_put_int(c->local_consumed + addition); packet_send(); debug2("channel %d: window %d sent adjust %d", c->self, c->local_window, c->local_consumed); - c->local_window += c->local_consumed; + c->local_window += c->local_consumed + addition; c->local_consumed = 0; } return 1; diff -u openssh-3.8.1p1/channels.h openssh-3.8.1p1-dynwindow/channels.h --- openssh-3.8.1p1/channels.h 2003-10-02 02:17:00.000000000 -0400 +++ openssh-3.8.1p1-dynwindow/channels.h 2004-07-07 09:54:55.000000000 -0400 @@ -97,6 +97,7 @@ u_int local_window_max; u_int local_consumed; u_int local_maxpacket; + int dynamic_window; int extended_usage; int single_connection; Only in openssh-3.8.1p1-dynwindow: config.h Only in openssh-3.8.1p1-dynwindow: config.status Common subdirectories: openssh-3.8.1p1/contrib and openssh-3.8.1p1-dynwindow/contrib Common subdirectories: openssh-3.8.1p1/openbsd-compat and openssh-3.8.1p1-dynwindow/openbsd-compat Common subdirectories: openssh-3.8.1p1/regress and openssh-3.8.1p1-dynwindow/regress Common subdirectories: openssh-3.8.1p1/scard and openssh-3.8.1p1-dynwindow/scard diff -u openssh-3.8.1p1/serverloop.c openssh-3.8.1p1-dynwindow/serverloop.c --- openssh-3.8.1p1/serverloop.c 2004-01-20 19:02:50.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/serverloop.c 2004-07-07 09:53:44.000000000 -0400 @@ -894,6 +894,9 @@ c = channel_new("session", SSH_CHANNEL_LARVAL, -1, -1, -1, /*window size*/0, CHAN_SES_PACKET_DEFAULT, 0, "server-session", 1); + set_unlimited(&c->input,1); + set_unlimited(&c->output,1); + c->dynamic_window = 1; if (session_open(the_authctxt, c->self) != 1) { debug("session open failed, free channel %d", c->self); channel_free(c); diff -u openssh-3.8.1p1/ssh.c openssh-3.8.1p1-dynwindow/ssh.c --- openssh-3.8.1p1/ssh.c 2004-03-21 17:36:01.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/ssh.c 2004-07-07 09:54:03.000000000 -0400 @@ -1117,7 +1117,11 @@ "session", SSH_CHANNEL_OPENING, in, out, err, window, packetmax, CHAN_EXTENDED_WRITE, "client-session", /*nonblock*/0); - + if (!tty_flag) { + c->dynamic_window = 1; + set_unlimited(&c->input,1); + set_unlimited(&c->output,1); + } debug3("ssh_session2_open: channel_new: %d", c->self); channel_send_open(c->self); Only in openssh-3.8.1p1-dynwindow: ssh_prng_cmds From keld at dkuug.dk Thu Jul 15 05:09:54 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Wed, 14 Jul 2004 21:09:54 +0200 Subject: vulnerability with ssh-agent Message-ID: <20040714190954.GA29691@rap.rap.dk> Michael Stevens wrote: > If its in memory, you should assume that root can see it. yes, that is of cause true, but I am not sure that the dsa key is in the memory of the ssh-agent, and I am not sure that it will be easily visible. I had a try if I could find my dsa key in the /proc/pid/exe file of the ssh-agent with strings, but I could not find it. Does anybody know if ssh-agent has the keys stored in memory, and how? best regards keld From keld at dkuug.dk Thu Jul 15 05:16:27 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Wed, 14 Jul 2004 21:16:27 +0200 Subject: vulnerability with ssh-agent Message-ID: <20040714191627.GA29706@rap.rap.dk> joshua stein wrote: > I wrote: > > One commenter said that this has big holes. An intruder with root > > privileges could set SSH_AUTH_SOCKET to at socket for ssh-agent found > > in /tmp, and he could also find the keys in the /proc area for the > > ssh-agent. > > if you have "an intruder with root privileges", you have bigger > problems Actually not necessarily so. The intruder with root privileges may have broken in on my home system, but that is something I can deal with. The intruder can via these techniques get access to some servers where I have stored my dsa keys, and that would be a much bigger problem. Best regards Keld From keld at dkuug.dk Thu Jul 15 05:26:27 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Wed, 14 Jul 2004 21:26:27 +0200 Subject: vulnerability with ssh-agent Message-ID: <20040714192627.GA29719@rap.rap.dk> Jefferson Ogata wrote: > Keld J?rn Simonsen wrote: > > I was thinking along the lines of deleting the socket in temp, if an > > option "delete_ssk_auth_socket" was given in config, and then only > > processes that inherited the socket via fork() would have access to > > the socket, via an open file descriptor. An intruder would then need to > > program opening of an inode that was deleted, which is much harder > > than just using readily available ssh with an easy-to-find SSH_AUTH_SOCKET. > > This would work fine in the standard setup, where ssh-agent is > > launched as part of the initiation of X. > > Even if you could make this work, the socket would still be accessible > to root on Linux under /proc/pid/fd. Hmm, I had a look, and sure, there were file descriptors in /proc/pid/fd . But they did not have the same inode description as the ones in /tmp/ssh-*/ Can these fd's be used in the SSH_AUTH_SOCKET ? and what are they good for anyway? Who uses them, and could they be removed (out of the kernel) as a kind of security option? Or could there be invented other ways so that the ssh-agent could not be misused by an intruder with root privileges? Best regards keld From jcs at rt.fm Thu Jul 15 06:02:38 2004 From: jcs at rt.fm (joshua stein) Date: Wed, 14 Jul 2004 15:02:38 -0500 Subject: vulnerability with ssh-agent In-Reply-To: <20040714191627.GA29706@rap.rap.dk> References: <20040714191627.GA29706@rap.rap.dk> Message-ID: <20040714200238.GB18228@rt.fm> > > if you have "an intruder with root privileges", you have bigger > > problems > > Actually not necessarily so. The intruder with root privileges may have > broken in on my home system, but that is something I can deal with. > The intruder can via these techniques get access to some servers > where I have stored my dsa keys, and that would be a much bigger problem. and if i had root on your machine, what's to stop me from backdooring the ssh client/server, terminal handling, or anything else to completely bypass whatever changes you're requesting be made here? From markus at openbsd.org Thu Jul 15 06:07:16 2004 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Jul 2004 22:07:16 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040714190954.GA29691@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> Message-ID: <20040714200715.GA7882@folly> On Wed, Jul 14, 2004 at 09:09:54PM +0200, Keld J?rn Simonsen wrote: > Does anybody know if ssh-agent has the keys stored in memory, and how? of course they are in the memory (unless you have a smartcard). where else? From keld at dkuug.dk Thu Jul 15 06:25:04 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Wed, 14 Jul 2004 22:25:04 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040714200238.GB18228@rt.fm> References: <20040714191627.GA29706@rap.rap.dk> <20040714200238.GB18228@rt.fm> Message-ID: <20040714202504.GA29790@rap.rap.dk> On Wed, Jul 14, 2004 at 03:02:38PM -0500, joshua stein wrote: > > > if you have "an intruder with root privileges", you have bigger > > > problems > > > > Actually not necessarily so. The intruder with root privileges may have > > broken in on my home system, but that is something I can deal with. > > The intruder can via these techniques get access to some servers > > where I have stored my dsa keys, and that would be a much bigger problem. > > and if i had root on your machine, what's to stop me from > backdooring the ssh client/server, terminal handling, or anything > else to completely bypass whatever changes you're requesting be made > here? I don't know, but it would easily take you more time than just saying: SSH_AUTH_SOCKET=/tmp/ssh-Cgk15536/agent.15536 ssh trusted.com Furthermore my surveilance will report that you tampered with my ssh, and you cannot get my dsa key out of the running ssh-agent. You will have to wait for me to type in my passphrase again. Chances are that I will detect you before that is done. best regards keld From keld at dkuug.dk Thu Jul 15 06:29:11 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Wed, 14 Jul 2004 22:29:11 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040714200715.GA7882@folly> References: <20040714190954.GA29691@rap.rap.dk> <20040714200715.GA7882@folly> Message-ID: <20040714202911.GB29790@rap.rap.dk> On Wed, Jul 14, 2004 at 10:07:16PM +0200, Markus Friedl wrote: > On Wed, Jul 14, 2004 at 09:09:54PM +0200, Keld J?rn Simonsen wrote: > > Does anybody know if ssh-agent has the keys stored in memory, and how? > > of course they are in the memory (unless you > have a smartcard). where else? are they also stored in memory, if you use forwardagent (on the intermediate machine)? And how are they stored, have something been done to make them harder to retrieve from a dump? best regards keld From dtucker at zip.com.au Thu Jul 15 07:34:44 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Jul 2004 07:34:44 +1000 Subject: Logging of wrong pubkey auth In-Reply-To: <20040714191028.727cebf5.pr0gm4@linoratix.com> References: <20040714191028.727cebf5.pr0gm4@linoratix.com> Message-ID: <40F5A6F4.1050007@zip.com.au> Jan Gehring wrote: > + if(! allowed) { > + logit("Illegal user %.100s from %.100s", authctxt->user,get_remote_ipaddr()); "Illegal user" has a different meaning to "this particular authentication failed". Anyway, this wouldn't this be logged in auth.c:auth_log() (subject to the thresholds in there) ? -- 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 djm at mindrot.org Thu Jul 15 08:11:56 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Jul 2004 08:11:56 +1000 Subject: vulnerability with ssh-agent In-Reply-To: <20040714202911.GB29790@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> <20040714200715.GA7882@folly> <20040714202911.GB29790@rap.rap.dk> Message-ID: <40F5AFAC.30601@mindrot.org> Keld J?rn Simonsen wrote: > On Wed, Jul 14, 2004 at 10:07:16PM +0200, Markus Friedl wrote: >>of course they are in the memory (unless you >>have a smartcard). where else? > > are they also stored in memory, if you use forwardagent (on the > intermediate machine)? No, because there is no agent running there, just sshd relaying a connection. Use "ssh-add -c" if you are paranoid about unauthorised agent use (I do). > And how are they stored, have something been done to make them harder to > retrieve from a dump? We disable coredumps and connections from different non-root users. Beyond that, there isn't anything we can do that isn't just obscurity. -d From gtsang at lnxw.com Thu Jul 15 09:17:18 2004 From: gtsang at lnxw.com (Gilbert Tsang) Date: Wed, 14 Jul 2004 16:17:18 -0700 Subject: OpenSSH Port to Lynxos 4 In-Reply-To: Message-ID: <003f01c469f8$b59281e0$2e7f11ac@gtsang3> Hi Ben, To answer your questions, I have not modified the source code of ssh and sftp during the port. Actually you are quite right on the fact that setvbuf(infile, NULL, _IOLBF, 0) does something funny on LynxOS. So I took out HAVE_SETVBUF and recompile and sftp works! The only drawback is that the -b option of sftp is broken and so I work around that by using stdin redirection. I'll see if I can figure out what's so different about setvbuf(). Many thanks Ben! Regards, Gilbert. -----Original Message----- From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org] Sent: Tuesday, July 13, 2004 8:33 PM To: Gilbert Tsang Cc: openssh-unix-dev at mindrot.org Subject: Re: OpenSSH Port to Lynxos 4 On Tue, 13 Jul 2004, Gilbert Tsang wrote: > I am working on a port of 3.8.1p1 to LynxOs 4. > I guess the first few questions should be: 1. What changes have you made to the ssh client? 2. What changes have you made to the sftp client? > The problem I'm encountering now is on "sftp": the symptom is that after > password authentication, the call to fgets() (sftp.c, line 1186) by sftp > client returns NULL and thus the client exit before the user can enter any > command. fgets() eventually call read() and the call fails because of an > errno of 0x2 (ENOENT). At this point I'm quite puzzled at what's happening > as it seem the forked ssh program has access to stdin (as it was able to get > the entered password) but not the parent sftp client program that interacts > with user (sftp.c line 1240)? > could see see a ktrace (or the equiv) around the place where the sftp> prompt is displayed. We should see something like: 28753 sftp RET write 41/0x29 28753 sftp CALL write(0x1,0x13000,0x6) 28753 sftp GIO fd 1 wrote 6 bytes "sftp> " 28753 sftp RET write 6 28753 sftp CALL read(0,0x23000,0x10000) 28753 sftp GIO fd 0 read 5 bytes "quit " 28753 sftp RET read 5 28753 sftp CALL close(0x3) I'm interested to see if it is different. And how. Also do you have HAVE_SETVBUF set in your config.h? If it is set, try unsetting it and recompiling sftp. I'm suspecting lynxos doesn't like how we are setting up the input buffer. That is about all I can think of right off hand. - Ben From djm at mindrot.org Thu Jul 15 12:39:25 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Jul 2004 12:39:25 +1000 Subject: New dynamic window patch (with limits) In-Reply-To: <70621a4604071411537c9936@mail.gmail.com> References: <70621a4604071411537c9936@mail.gmail.com> Message-ID: <40F5EE5D.8000509@mindrot.org> Michael Stevens wrote: > Only in openssh-3.8.1p1-dynwindow: Makefile > diff -u openssh-3.8.1p1/buffer.c openssh-3.8.1p1-dynwindow/buffer.c > --- openssh-3.8.1p1/buffer.c 2003-11-21 07:56:47.000000000 -0500 > +++ openssh-3.8.1p1-dynwindow/buffer.c 2004-07-12 07:49:29.000000000 -0400 > @@ -18,6 +18,12 @@ > #include "buffer.h" > #include "log.h" > > +void > +set_unlimited(Buffer *buffer, int new_value) > +{ > + buffer->unlimited = new_value; > +} > + I really don't think we should add options to the buffer code. If we need to increase the buffer size limits, then we should just choose a safe maximum and crank them for all users. -d From pr0gm4 at linoratix.com Thu Jul 15 18:08:58 2004 From: pr0gm4 at linoratix.com (Jan Gehring) Date: Thu, 15 Jul 2004 08:08:58 -0000 Subject: Logging of wrong pubkey auth Message-ID: Darren Tucker wrote: > Jan Gehring wrote: > > + if(! allowed) { > > + logit("Illegal user %.100s from %.100s", authctxt->user,get_remote_ipaddr()); > > "Illegal user" has a different meaning to "this particular > authentication failed". > > Anyway, this wouldn't this be logged in auth.c:auth_log() (subject to > the thresholds in there) ? Well, you're right. Seems i have overlooked this function. Imho, it should have been logged. Best regards, Jan Gehring From markus at openbsd.org Thu Jul 15 18:10:33 2004 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Jul 2004 10:10:33 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040714202911.GB29790@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> <20040714200715.GA7882@folly> <20040714202911.GB29790@rap.rap.dk> Message-ID: <20040715081033.GA26615@folly> On Wed, Jul 14, 2004 at 10:29:11PM +0200, Keld J?rn Simonsen wrote: > On Wed, Jul 14, 2004 at 10:07:16PM +0200, Markus Friedl wrote: > > On Wed, Jul 14, 2004 at 09:09:54PM +0200, Keld J?rn Simonsen wrote: > > > Does anybody know if ssh-agent has the keys stored in memory, and how? > > > > of course they are in the memory (unless you > > have a smartcard). where else? > > are they also stored in memory, if you use forwardagent (on the > intermediate machine)? no, that's the point of the agent. the keys never leave the agent. the agent does operations for you using the keys, but it never gives away the secret keys. > And how are they stored, have something been done to make them harder to > retrieve from a dump? no. From mrsallman at hotmail.com Thu Jul 15 19:27:54 2004 From: mrsallman at hotmail.com (sallman ouarrak) Date: Thu, 15 Jul 2004 09:27:54 +0000 Subject: I ask about a openSSH Message-ID: Hello, Since which version of OPENSSH the authentification by certificates x509V3 accepts. Thankyou, _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp From dtucker at zip.com.au Thu Jul 15 19:38:03 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Jul 2004 19:38:03 +1000 Subject: I ask about a openSSH In-Reply-To: References: Message-ID: <40F6507B.9080803@zip.com.au> sallman ouarrak wrote: > Since which version of OPENSSH the authentification by certificates > x509V3 accepts. The regular OpenSSH distribution does not do x509 at all. Roumen Petrov maintains a patch that does do x509 v3 at: http://roumenpetrov.info/openssh/ -- 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 stevensm at gmail.com Fri Jul 16 00:00:19 2004 From: stevensm at gmail.com (Michael Stevens) Date: Thu, 15 Jul 2004 10:00:19 -0400 Subject: New dynamic window patch (with limits) In-Reply-To: <40F5EE5D.8000509@mindrot.org> References: <70621a4604071411537c9936@mail.gmail.com> <40F5EE5D.8000509@mindrot.org> Message-ID: <70621a4604071507003097c42b@mail.gmail.com> It would be nice, but I'm not sure that this won't let someone remotely consume large amounts of memory in some other part of the code. I don't know the code well enough to say that would be fine. If there would be no problems with that, I wouldn't have a problem changing the patch. Mike On Thu, 15 Jul 2004 12:39:25 +1000, Damien Miller wrote: > Michael Stevens wrote: > > > Only in openssh-3.8.1p1-dynwindow: Makefile > > diff -u openssh-3.8.1p1/buffer.c openssh-3.8.1p1-dynwindow/buffer.c > > --- openssh-3.8.1p1/buffer.c 2003-11-21 07:56:47.000000000 -0500 > > +++ openssh-3.8.1p1-dynwindow/buffer.c 2004-07-12 07:49:29.000000000 -0400 > > @@ -18,6 +18,12 @@ > > #include "buffer.h" > > #include "log.h" > > > > +void > > +set_unlimited(Buffer *buffer, int new_value) > > +{ > > + buffer->unlimited = new_value; > > +} > > + > > I really don't think we should add options to the buffer code. If we > need to increase the buffer size limits, then we should just choose a > safe maximum and crank them for all users. > > -d > > From aavtwrrao at enature.net Thu Jul 15 22:37:36 2004 From: aavtwrrao at enature.net (Meri Kunzman) Date: Thu, 15 Jul 2004 08:37:36 -0400 Subject: Investor Alert, Don't Miss This One,GDNO braces Message-ID: <20040715223030.2DE5427C187@shitei.mindrot.org> machine widemouthed uproarious ***GDNO****GDNO****GDNO****GDNO****GDNO****GDNO*** Recommendation:_Strong_Profits_Get_Immediately The SPECULATIVE NEAR TERM TARGET PRICE is - $1.35 The SPECULATIVE NEAR TERM TARGET PRICE is - $1.90 HUGE news just released: Golden Opportunity Resources Inc. - Big Snowy Encounters Multiple Oil and Gas Bearing Zones in Bolero 1-23 Well 6000 Feet Northwest of Golden Opportunity Hole Stock Set to Explode on Thursday July 15th - Numerous newsletters will profile the company. ++..Trading_Alert..++ Company Profile Golden Opportunity Resources, Inc., TICKER:_GDNO Current Price:_0.35 Rating:_Undervalued The SPECULATIVE NEAR TERM TARGET PRICE is - $1.35 The SPECULATIVE NEAR TERM TARGET PRICE is - $1.90 --------->>>__NEWS__<<<------------------- MISSOULA, MT, Jul 13, 2004 /PRNewswire-FirstCall via COMTEX/ Golden Opportunity Resources, Inc., (OTC Pink: GDNO) a Nevada Corporation. Golden Opportunity Resources (GDNO-PK) has been informed by the company's joint venture partner and project operator, Big Snowy Resources LP, that the drilling of a well located 6,000 feet northwest of the hole Golden Opportunity is set to drill has been completed to target depth. The Bolero 1-23 Well has been cased and cemented. The primary target, the Tyler C Sand, was successfully intersected at 2,830 feet to 2,860 feet (863 to 872 metres). Schlumberger Oilfield Services Inc. completed two log reports to ensure accuracy of the data and has provided estimates for the potential of oil and gas in each of the five zones encountered. All five zones demonstrate potential commercial-grade and significant quantity of hydrocarbons (oil and gas), which is further corroborated by similarities to other neighboring offset wells, both within 400 feet (122 metres) of the Bolero 1-23 well. President of Golden Opportunity Resources William Morton stated "We at Golden Opportunity are extremely encouraged by the recent discovery made just 6,000 feet from our hole which is set to be drilled in the next 10 days. Big Snowy has advised the company that the discovery hole is in the same Tyler formation as Golden Opportunity's hole to be drilled. This recent development just affirms our belief that the program we are set to embark upon is first rate. We are pleased to be working with Big Snowy and their team of experts with vast experience in this area." **** Don't Miss This One Get It Immediately **** Disc ,laimer In compliance with Section 17(b), we disclose the holding of GDNO shares prior to the publication of this report. Be aware of an inherent conflict of interest resulting from such holdings due to our intent to profit from the liquidation of these shares. Shares may be sold at any time, even after positive statements have been made regarding the above company. Since we own shares, there is an inherent conflict of interest in our statements and opinions. Readers of this publication are cautioned not to place undue reliance on forward-looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties, that could cause results to differ materially from those set forth in the forward- looking statements. Please be advised that nothing within this email shall constitute a solicitation or an offer to buy or sell any security mentioned herein. This newsletter is neither a registered investment advisor nor affiliated with any broker or dealer. All statements made are our express opinion only and should be treated as such. We may own, buy and sell any securities mentioned at any time. This report includes forward-looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. These statements may include terms as "expect", "believe", "may", "will", "move","undervalued" and "intend" or similar terms. This newsletter was paid $6500 from third party to send this report. PLEASE DO YOUR OWN DUE DILIGENCE BEFORE INVESTING IN ANY PROFILED COMPANY. You may lose money from investing in Penny Stocks. To be removed from further emails send email to aoyemr at ilqdjr.jp 26O 17 20 My net will be stretched out over him, and he will be taken in my cords, and I will send him to Babylon, and there I will be his judge for the wrong which he has done against me. 10O 17 25 And Absalom put Amasa at the head of the army in place of Joab. Now Amasa was the son of a man named Ithra the Ishmaelite, who had been the lover of Abigail, the daughter of Jesse, sister of Zeruiah, Joab's mother. From dtucker at zip.com.au Fri Jul 16 18:35:10 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 16 Jul 2004 18:35:10 +1000 Subject: vulnerability with ssh-agent In-Reply-To: <40F5AFAC.30601@mindrot.org> References: <20040714190954.GA29691@rap.rap.dk> <20040714200715.GA7882@folly> <20040714202911.GB29790@rap.rap.dk> <40F5AFAC.30601@mindrot.org> Message-ID: <40F7933E.308@zip.com.au> Damien Miller wrote: > No, because there is no agent running there, just sshd relaying a > connection. Use "ssh-add -c" if you are paranoid about unauthorised > agent use (I do). I also have a patch somewhere that adds an escape (~A) to ssh that toggles reponses to agent forward requests. You can connect with it enabled, then disable/enable it as you require it. It would also be possible to add an option like "ForwardAgent passive" to set up the connection with request forwarding enabled, but responses disabled, so it would need to be enabled via the toggle before it could be used. [digs through patch dir] found it, attached. -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-disable-agentfwd2.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040716/3dc7253e/attachment.ksh From nlarsch at compuserve.de Thu Jul 15 05:31:11 2004 From: nlarsch at compuserve.de (Nils Larsch) Date: Wed, 14 Jul 2004 21:31:11 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040714190954.GA29691@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> Message-ID: <40F589FF.8010200@compuserve.de> Keld J?rn Simonsen wrote: > Michael Stevens wrote: > > >>If its in memory, you should assume that root can see it. > > > yes, that is of cause true, but I am not sure that the dsa key > is in the memory of the ssh-agent, and I am not sure that it will be > easily visible. I had a try if I could find my dsa key in the /proc/pid/exe > file of the ssh-agent with strings, but I could not find it. /proc/$PID/exe is a link to the executable file and _not_ the process memory, for that you have /proc/$PID/mem (or /proc/kcore) see the proc manpage Nils From keld at dkuug.dk Sun Jul 18 01:04:15 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sat, 17 Jul 2004 17:04:15 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <40F589FF.8010200@compuserve.de> References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> Message-ID: <20040717150415.GA11214@rap.rap.dk> On Wed, Jul 14, 2004 at 09:31:11PM +0200, Nils Larsch wrote: > Keld J?rn Simonsen wrote: > >Michael Stevens wrote: > > > > > >>If its in memory, you should assume that root can see it. > > > > > >yes, that is of cause true, but I am not sure that the dsa key > >is in the memory of the ssh-agent, and I am not sure that it will be > >easily visible. I had a try if I could find my dsa key in the /proc/pid/exe > >file of the ssh-agent with strings, but I could not find it. > > /proc/$PID/exe is a link to the executable file and _not_ the > process memory, for that you have /proc/$PID/mem (or /proc/kcore) > see the proc manpage Yes, I already found out, but it was a bit embarrassing to correct my mistake on the list. As you may have noticed, I am not a regular openssh hacker. My idea was to then use something like gdb to access the /proc/pid/mem to see if the keys were encrypted or not. I have taken the sources and done a little hacking, and I noticed a remark that the encryption of sensitive information in ssh-agent was a "TODO". So somebody else than me, and with some status in the project, enough to make comment on what to do, has also considered it a good idea, to encrypt keys and other stuff. I understand that my level of competence here is way lower than that of a openssh hacker, but anyway, where there is a will, there is a way. I am appauled by the ease it is to use the ssh-agent for an intruder. So I have begun to do some hacking, and noticed that tcsh actually closes all its inherited file descriptors, so that fork() inheritance of fd's don't work. However, in bash the fd's survive. I have also found out that there is a separate namespace for sockets - I think the name is socket:[number] but I am not sure of this. This is the name that is recorded in /proc/pid/fd and it is probably accessible for a program with root permissions without inheriting the fd. Furthermore I noticed that there is something called anonymeous sockets, and that is probably the way forward. I am not sure tho, that you can listen to it, so that you may have more sockets open, from different ssh clients, or if it is necessary - there may be one fd that several processes can use concurrently. But an anonymeous socket would probably not be accessible to processes that don't inherit it, or get it as a gift, so that would be safe. I have also considered other ways of doing inter-process communication in a safe way, but sockets are probably the way to go. I also need to consider whether the ssh -c option is enough for me and my small advisory, and if it works as I would like it to do. Anyway, I don't expect that people from the list comment on this. I understand that I need to show something more concrete to the list, and I think I will find the time to dwelve into it, but if you feel like it, you are welcome to comment and save me some hours on digging out documentation and hacking. Best regards Keld From stuge-openssh-unix-dev at cdy.org Sun Jul 18 01:41:31 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 17 Jul 2004 17:41:31 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040717150415.GA11214@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> Message-ID: <20040717154131.GA9095@foo.birdnet.se> On Sat, Jul 17, 2004 at 05:04:15PM +0200, Keld J?rn Simonsen wrote: > I understand that my level of competence here is way lower than that of > a openssh hacker, but anyway, where there is a will, there is a way. Not always.. I don't want Windows to crash.. > I am appauled by the ease it is to use the ssh-agent for an intruder. So don't use it. I'm being redundant now, but you can not protect regular user resources from root priviledge. If someone gets root in your system, game over, do restore and/or reinstall. > socket:[number] but I am not sure of this. This is the name that is > recorded in /proc/pid/fd This is just the Linux kernel (procfs, specifically) way of telling you that the fd is a socket. The number is likely an internal kernal reference to it. > and it is probably accessible for a program with root permissions > without inheriting the fd. Again, being redundant; _everything_ in the system is accessible for a program with root permissions. Absolutely everything. Unless.. ..you really want to lock your system down, in that case please have a look at systrace, which allows very precise control over what userspace software can do and can not do to the system. > I also need to consider whether the ssh -c option is enough for me > and my small advisory, and if it works as I would like it to do. Not ssh -c, ssh-add -c. It's as good as it can get with the agent. > Anyway, I don't expect that people from the list comment on this. I > understand that I need to show something more concrete to the list, > and I think I will find the time to dwelve into it, but if you feel > like it, you are welcome to comment and save me some hours on > digging out documentation and hacking. Keep in mind that the agent and your private keys should only be on trusted systems, otherwise you'll lose just the same. :) Hope this helps. //Peter From mouring at etoh.eviladmin.org Sun Jul 18 01:59:41 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 17 Jul 2004 10:59:41 -0500 (CDT) Subject: vulnerability with ssh-agent In-Reply-To: <20040717150415.GA11214@rap.rap.dk> Message-ID: On Sat, 17 Jul 2004, Keld [iso-8859-1] J?rn Simonsen wrote: > On Wed, Jul 14, 2004 at 09:31:11PM +0200, Nils Larsch wrote: > > Keld J?rn Simonsen wrote: > > >Michael Stevens wrote: > > > > > > > > >>If its in memory, you should assume that root can see it. > > > > > > > > >yes, that is of cause true, but I am not sure that the dsa key > > >is in the memory of the ssh-agent, and I am not sure that it will be > > >easily visible. I had a try if I could find my dsa key in the /proc/pid/exe > > >file of the ssh-agent with strings, but I could not find it. > > > > /proc/$PID/exe is a link to the executable file and _not_ the > > process memory, for that you have /proc/$PID/mem (or /proc/kcore) > > see the proc manpage > > Yes, I already found out, but it was a bit embarrassing to correct my > mistake on the list. As you may have noticed, I am not a regular openssh > hacker. My idea was to then use something like gdb to access the > /proc/pid/mem to see if the keys were encrypted or not. > > I have taken the sources and done a little hacking, and I noticed a > remark that the encryption of sensitive information in ssh-agent was a > "TODO". So somebody else than me, and with some status in the project, > enough to make comment on what to do, has also considered it a good > idea, to encrypt keys and other stuff. > You're misunderstanding the comment. The comment is suggesting when ssh-agent is locked that all private data should be encrypted beyond setting the "locked" flag. It is not an over all "keep everything encrypted that is private". - Ben From markus at openbsd.org Sun Jul 18 02:04:01 2004 From: markus at openbsd.org (Markus Friedl) Date: Sat, 17 Jul 2004 18:04:01 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040717150415.GA11214@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> Message-ID: <20040717160400.GB11422@folly> On Sat, Jul 17, 2004 at 05:04:15PM +0200, Keld J?rn Simonsen wrote: > I understand that my level of competence here is way lower than that of > a openssh hacker, but anyway, where there is a will, there is a way. > I am appauled by the ease it is to use the ssh-agent for an intruder. i think there is not point in using inherited file descriptors instead of a socket. it's just a waste of time, and there even was (broken) code in older versions of ssh for doing this, but it got removed for several reasons. moreover, there is no way to protect the agent against root. the agent already protectes the private keys against all non-root users. they cannot can access the key material (the agent disables coredumps and make ptrace impossible because it's setgid), and if you use a smartcard it even gets impossible for root users. the agent never discloses the private key over the socket. additionally, the agent disallows use of the key for users with a different uid prevented (with getpeereuid(2)). if you need additional access control, then use ssh-add -c. > I have also considered other ways of doing inter-process communication > in a safe way, but sockets are probably the way to go. there is no safe way. From mouring at etoh.eviladmin.org Sun Jul 18 02:22:09 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 17 Jul 2004 11:22:09 -0500 (CDT) Subject: vulnerability with ssh-agent In-Reply-To: <20040717154131.GA9095@foo.birdnet.se> Message-ID: On Sat, 17 Jul 2004, Peter Stuge wrote: > On Sat, Jul 17, 2004 at 05:04:15PM +0200, Keld J?rn Simonsen wrote: [..] > Again, being redundant; _everything_ in the system is accessible for > a program with root permissions. Absolutely everything. > > Unless.. > > ..you really want to lock your system down, in that case please have > a look at systrace, which allows very precise control over what > userspace software can do and can not do to the system. > Even that root can bypass systrace rules if he/she so wished. Trusted UNIX or extend ACL that enforce permissions even at the root level are the only effect ways. Problem with all Trusted UNIX systems is frankly they are over designed and add soo much code in the common code paths they are asking to be breached (Again, my person belief.. but I'm no one so I can be safely ignored =). > > > I also need to consider whether the ssh -c option is enough for me > > and my small advisory, and if it works as I would like it to do. > > Not ssh -c, ssh-add -c. It's as good as it can get with the agent. > And only useful if the attacker is coming in the front door and you are on an X-terminal to recieve the messages. Rather worthless if you are on a console or remote ssh connection using ssh-agent on another trusted remote machine. Oh any modern UNIX there should be getpeereid() which is the best you can hope for to keep people off your private sockets other than file permissions. ssh-add -t / ssh-agent -t may be more useful. Mainly if you know your key will be used for the next XX minutes and then not used for a long time afterwards. This would limit the unencrypted key material in memory. Only thing that would be interesting to try would be to add a key with -t then lock the agent. and see if the agent still reaps the key after the lifetime has expired (Never tried it mysef since I rarely use ssh-agent, and when I do it is from my laptop). Going off on a side thought.. The reason why ssh-agent doesn't encrypt private data by default is that the key to decrypt it would have to be either laying around in memory or the user would have to be prompted for it everytime. Where the latter would defeat the whole reason for ssh-agent. The former would just be obscurity and wouldn't really stop someone from compermising the decrypted key material. - Ben From keld at dkuug.dk Sun Jul 18 02:17:02 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sat, 17 Jul 2004 18:17:02 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040717154131.GA9095@foo.birdnet.se> References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> <20040717154131.GA9095@foo.birdnet.se> Message-ID: <20040717161702.GA11552@rap.rap.dk> On Sat, Jul 17, 2004 at 05:41:31PM +0200, Peter Stuge wrote: > On Sat, Jul 17, 2004 at 05:04:15PM +0200, Keld J?rn Simonsen wrote: > > > I am appauled by the ease it is to use the ssh-agent for an intruder. > > So don't use it. ssh is much better than the alternatives... And openssh is the best:-) That is why I would like to improve it. > I'm being redundant now, but you can not protect regular user resources > from root priviledge. If someone gets root in your system, game over, > do restore and/or reinstall. Yes, so much I understand. For the system that has been broken into. But that is not my concern. I am trying to prevent that the damage spreads to *other* systems, not yet intruded. > > and it is probably accessible for a program with root permissions > > without inheriting the fd. > > Again, being redundant; _everything_ in the system is accessible for > a program with root permissions. Absolutely everything. Yes, of cause. But it may be more difficult than just giving a single shell command, which is quite obvious. What I am suggesting would need a lot of hacking to break, I think. But I am not sure. Maybe it is easy to just take the code out of the libraries and the kernel, and then hack it a little, and then you have your own implementation of sockets, with a twist. And then again, I was unsure that even root could do everything - maybe the kernel would not allow root to do some things that the system calls do not support, such as writing to a socket which the kernel knows that the particular root process does not have access to. Also some of the information is availiable on other systems, eg via forwardagent, so that root does not have immediate access to it. > Unless.. > > ..you really want to lock your system down, in that case please have > a look at systrace, which allows very precise control over what > userspace software can do and can not do to the system. Yes, I will take a look. > > Hope this helps. Yes, thanks for the input. best regards keld From keld at dkuug.dk Sun Jul 18 02:42:22 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sat, 17 Jul 2004 18:42:22 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040717160400.GB11422@folly> References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> <20040717160400.GB11422@folly> Message-ID: <20040717164222.GB11552@rap.rap.dk> On Sat, Jul 17, 2004 at 06:04:01PM +0200, Markus Friedl wrote: > On Sat, Jul 17, 2004 at 05:04:15PM +0200, Keld J?rn Simonsen wrote: > > I understand that my level of competence here is way lower than that of > > a openssh hacker, but anyway, where there is a will, there is a way. > > I am appauled by the ease it is to use the ssh-agent for an intruder. > > i think there is not point in using inherited file descriptors > instead of a socket. it's just a waste of time, and there even was > (broken) code in older versions of ssh for doing this, but it got > removed for several reasons. Yes, maybe it is not doable. I just want to avoid really obvious ways of misusing ssh-agent. I think all I ask for is a little uncomprehensiveness, that the root intruder cannot just break things with obvious use of standard tools, but that he will have to do some programming. Care to tell me the reasons for removing inherited sockets? Then I could possibly take my crazy ideas off my mind. > moreover, there is no way to protect the agent against root. I was thinking of things that only could be done if the system calls were allowable. > > the agent never discloses the private key over the socket. additionally, > the agent disallows use of the key for users with a different uid prevented > (with getpeereuid(2)). Hmm, could you prevent it to root? I know, root can do everything. But you could check the uid and euid. Then root needs to make both to the actual user. Hmm, login user.... best regards keld From keld at dkuug.dk Sun Jul 18 03:00:10 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sat, 17 Jul 2004 19:00:10 +0200 Subject: vulnerability with ssh-agent In-Reply-To: References: <20040717150415.GA11214@rap.rap.dk> Message-ID: <20040717170009.GC11552@rap.rap.dk> On Sat, Jul 17, 2004 at 10:59:41AM -0500, Ben Lindstrom wrote: > > > On Sat, 17 Jul 2004, Keld [iso-8859-1] J?rn Simonsen wrote: > > > I have taken the sources and done a little hacking, and I noticed a > > remark that the encryption of sensitive information in ssh-agent was a > > "TODO". So somebody else than me, and with some status in the project, > > enough to make comment on what to do, has also considered it a good > > idea, to encrypt keys and other stuff. > > You're misunderstanding the comment. The comment is suggesting when > ssh-agent is locked that all private data should be encrypted beyond > setting the "locked" flag. > > It is not an over all "keep everything encrypted that is private". OK, sorry. What would be the difference between always keeping the data encrypted, and only when it is locked? It would be the same data, if I understand it correctly? I am looking for some obsfucation. I think, currently, the keys can be obtained by a root intruder by just using a standard debugger. I would like him to sweat a little. Best regards keld From robmccau at radonc.duke.edu Sun Jul 18 03:10:40 2004 From: robmccau at radonc.duke.edu (Rob McCauley) Date: Sat, 17 Jul 2004 13:10:40 -0400 (EDT) Subject: vulnerability with ssh-agent In-Reply-To: <20040717161702.GA11552@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> <20040717154131.GA9095@foo.birdnet.se> <20040717161702.GA11552@rap.rap.dk> Message-ID: > > I'm being redundant now, but you can not protect regular user resources > > from root priviledge. If someone gets root in your system, game over, > > do restore and/or reinstall. > > Yes, so much I understand. For the system that has been broken into. > But that is not my concern. I am trying to prevent that the damage > spreads to *other* systems, not yet intruded. With all due respect, no you don't. Remote system is compromised. The intruder is, for all intents and purposes, any user account on the system or all of them. With a little patience, the remote intruder WILL get into your system if you permit logins from that compromised system. You simply can't expect a compromised system to protect you. All this talk about playing around with the kernel is all nice and good--where you have access to the kernel code. That's quite often not the case. I'm sorry, but if you *really* need this functionality, I think the closest you're going to get is one time passwords, and even they can be intercepted by root on the remote system. The intruder logs in via the captured password, the real user gets a failure message and things "Oops, I fat fingered my password." tries with the next one time password and gets in, none the wiser that YOUR box has just been compromised. Audit and investigate ANY time a one time password use fails, perhaps. I truly think that part of your answer lies in policy. If you need this level of security, you simply don't allow passwordless logins from anywhere. You REQUIRE appropriate security and auditing on the remote end. You don't allow remote connections from anywhere you don't require them. Maybe you don't connect to the internet at all. You aggresively audit your local users to make sure they're acting like they always do. I think you're looking for a silver bullet. A layer of complexity that will confuse you enough to feel safe, but some intrepid hacker will walk right through. You think your solution will take "a lot of hacking." If you're right, someone will do that lot of hacking and distribute the code. I think you're much better off understanding the risk and taking appropriate steps to mitigate it. You raise a valid point, but it's a fundamental weakness of Unix, not of openssh. Actually just a fundamental weakness in operating systems. Something has to be the gatekeeper to the physical bits. Compromise the gatekeeper and you own the system, whether that gatekeeper is a UID, process, kernel, or chip. Rob -- ------------------------------------------------------------------------------ Rob McCauley, GCFA Senior IT Analyst Radiation Oncology Duke University Medical Center From robmccau at radonc.duke.edu Sun Jul 18 03:13:47 2004 From: robmccau at radonc.duke.edu (Rob McCauley) Date: Sat, 17 Jul 2004 13:13:47 -0400 (EDT) Subject: vulnerability with ssh-agent In-Reply-To: <20040717170009.GC11552@rap.rap.dk> References: <20040717150415.GA11214@rap.rap.dk> <20040717170009.GC11552@rap.rap.dk> Message-ID: On Sat, 17 Jul 2004, Keld [iso-8859-1] J?rn Simonsen wrote: > I am looking for some obsfucation. Bingo. Obfuscation is not security. Obfuscation with open source code is entirely pointless. The method for un-obfuscating would be documented in the source code. Rob -- ------------------------------------------------------------------------------ Rob McCauley Senior IT Analyst Radiation Oncology Duke University Medical Center From mouring at etoh.eviladmin.org Sun Jul 18 03:31:10 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 17 Jul 2004 12:31:10 -0500 (CDT) Subject: vulnerability with ssh-agent In-Reply-To: <20040717170009.GC11552@rap.rap.dk> Message-ID: On Sat, 17 Jul 2004, Keld [iso-8859-1] J?rn Simonsen wrote: > On Sat, Jul 17, 2004 at 10:59:41AM -0500, Ben Lindstrom wrote: > > > > > > On Sat, 17 Jul 2004, Keld [iso-8859-1] J?rn Simonsen wrote: > > > > > I have taken the sources and done a little hacking, and I noticed a > > > remark that the encryption of sensitive information in ssh-agent was a > > > "TODO". So somebody else than me, and with some status in the project, > > > enough to make comment on what to do, has also considered it a good > > > idea, to encrypt keys and other stuff. > > > > You're misunderstanding the comment. The comment is suggesting when > > ssh-agent is locked that all private data should be encrypted beyond > > setting the "locked" flag. > > > > It is not an over all "keep everything encrypted that is private". > > OK, sorry. What would be the difference between always keeping the data > encrypted, and only when it is locked? It would be the same data, if I > understand it correctly? I am looking for some obsfucation. I think, > currently, the keys can be obtained by a root intruder by just using a > standard debugger. I would like him to sweat a little. > One doesn't leave the locking passphrase in memory, and the other one does. Thus it adds nothing for security in the latter case. Obsecurity is almost never worth the time spent. A day or two after it hits the CVS tree the real crackers have already updated their attacking code, and a month later it filters down to the kiddy scripters. This is more so true for open source / free software projects who's changes are open for the world to see. So what does obsecurity gain you in this case? I'd rather have time spent on real improvements then pissing away time doing obsecurity tricks that will never last. Even worse there has been times when these tricks have actually introduced new security holes. If you are looking for obsecurity instead of real security then you'll find yourself writing it yourself and upkeeping it yourself. From keld at dkuug.dk Sun Jul 18 03:53:18 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sat, 17 Jul 2004 19:53:18 +0200 Subject: vulnerability with ssh-agent In-Reply-To: References: <20040717170009.GC11552@rap.rap.dk> Message-ID: <20040717175317.GB11804@rap.rap.dk> On Sat, Jul 17, 2004 at 12:31:10PM -0500, Ben Lindstrom wrote: > > If you are looking for obsecurity instead of real security then you'll > find yourself writing it yourself and upkeeping it yourself. I get your point. keld From keld at dkuug.dk Sun Jul 18 06:54:57 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sat, 17 Jul 2004 22:54:57 +0200 Subject: vulnerability with ssh-agent In-Reply-To: References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> <20040717154131.GA9095@foo.birdnet.se> <20040717161702.GA11552@rap.rap.dk> Message-ID: <20040717205457.GB12680@rap.rap.dk> On Sat, Jul 17, 2004 at 01:10:40PM -0400, Rob McCauley wrote: > > > > I'm being redundant now, but you can not protect regular user resources > > > from root priviledge. If someone gets root in your system, game over, > > > do restore and/or reinstall. > > > > Yes, so much I understand. For the system that has been broken into. > > But that is not my concern. I am trying to prevent that the damage > > spreads to *other* systems, not yet intruded. > > With all due respect, no you don't. Remote system is compromised. The > intruder is, for all intents and purposes, any user account on the system > or all of them. With a little patience, the remote intruder WILL get into > your system if you permit logins from that compromised system. You simply > can't expect a compromised system to protect you. Yes, an intruder probably could get in to my server if my laptop was compromised. But would he not need the dsa key? Or maybe my passwd? And the only place he can get it is in the ssh-agent? Or is the id_dsa file enough? Or could he crack the id_dsa key? I thought this was difficult (took long time), with 1024 bits. > I'm sorry, but if you *really* need this functionality, I think the > closest you're going to get is one time passwords, and even they can be > intercepted by root on the remote system. The intruder logs in via the > captured password, the real user gets a failure message and things "Oops, > I fat fingered my password." tries with the next one time password and > gets in, none the wiser that YOUR box has just been compromised. Audit > and investigate ANY time a one time password use fails, perhaps. I would like to avoid typing passwords and keys, not just because it is cumbersome, but because it is unsafe. That is, if my system is compromised, most rootkits have a keylogger, and then I am sold. My aim is that I have written a guide for average users, and a commenter said there were holes in it. I am trying to see if I can mend the holes. > I think you're looking for a silver bullet. A layer of complexity that > will confuse you enough to feel safe, but some intrepid hacker will walk > right through. You think your solution will take "a lot of hacking." If > you're right, someone will do that lot of hacking and distribute the code. > I think you're much better off understanding the risk and taking > appropriate steps to mitigate it. yes, but it is difficult to see where the pitfalls are. It was not clear to me how vulnerable my server would be if my laptop was compromised. I probably should set up the server to only accept dsa, not passwd, which is only 64 bit and crackable. best regards keld From keld at dkuug.dk Sun Jul 18 07:14:22 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sat, 17 Jul 2004 23:14:22 +0200 Subject: vulnerability with ssh-agent In-Reply-To: References: <20040717154131.GA9095@foo.birdnet.se> Message-ID: <20040717211422.GC12680@rap.rap.dk> Hi, Thanks for all your help on this. I tried out the ssh-add -c option, and well, it was a bit of a surprise. When later I used ssh to connect to a remote site, I was asked to enter the passphrase. Well, I should not really be surprised, but my whole exercise is to avoid typing in passwords, as this is easy for a keylogger to pick up. So would it not be more secure if there only was a kind of "yes" answer to be given? And also that the asking of the confirmation should be done by ssh-agent, not by ssh. I am not sure if that is done now. Best regards keld From gert at greenie.muc.de Sun Jul 18 08:17:12 2004 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 18 Jul 2004 00:17:12 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040717205457.GB12680@rap.rap.dk>; from keld@dkuug.dk on Sat, Jul 17, 2004 at 10:54:57PM +0200 References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> <20040717154131.GA9095@foo.birdnet.se> <20040717161702.GA11552@rap.rap.dk> <20040717205457.GB12680@rap.rap.dk> Message-ID: <20040718001712.X7999@greenie.muc.de> Hi, On Sat, Jul 17, 2004 at 10:54:57PM +0200, Keld J?rn Simonsen wrote: > I would like to avoid typing passwords and keys, not just because it is > cumbersome, but because it is unsafe. That is, if my system is > compromised, most rootkits have a keylogger, and then I am sold. If your laptop is compromised, *anything* you do to log into your server can be compromised as well. A root user on your laptop could give you a trojaned ssh client, which will execute additional commands on the server after you login, for example... ...or just takeover your client tty after you have logged in, not requiring any ssh client modification... There are myriads of ways to compromise whichever machine you go to if you start from a compromised host. 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 mouring at etoh.eviladmin.org Sun Jul 18 12:05:38 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 17 Jul 2004 21:05:38 -0500 (CDT) Subject: vulnerability with ssh-agent In-Reply-To: <20040717211422.GC12680@rap.rap.dk> Message-ID: Sounds like ssh-agent coundn't talk to the askpass program for gnome/x11. As a result ssh-agent returns a denied and ssh falls back to prompting you for the passphrase of the key. - Ben On Sat, 17 Jul 2004, Keld [iso-8859-1] J?rn Simonsen wrote: > Hi, > > Thanks for all your help on this. > > I tried out the ssh-add -c option, and well, it was a bit of a surprise. > When later I used ssh to connect to a remote site, I was asked to enter > the passphrase. Well, I should not really be surprised, but my whole > exercise is to avoid typing in passwords, as this is easy for a > keylogger to pick up. > > So would it not be more secure if there only was a kind of "yes" > answer to be given? And also that the asking of the confirmation should > be done by ssh-agent, not by ssh. I am not sure if that is done now. > > Best regards > keld > From djm at mindrot.org Sun Jul 18 16:14:20 2004 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Jul 2004 16:14:20 +1000 Subject: vulnerability with ssh-agent In-Reply-To: <20040717150415.GA11214@rap.rap.dk> References: <20040714190954.GA29691@rap.rap.dk> <40F589FF.8010200@compuserve.de> <20040717150415.GA11214@rap.rap.dk> Message-ID: <40FA153C.2010203@mindrot.org> Keld J?rn Simonsen wrote: > I have taken the sources and done a little hacking, and I noticed a > remark that the encryption of sensitive information in ssh-agent was a > "TODO". So somebody else than me, and with some status in the project, > enough to make comment on what to do, has also considered it a good > idea, to encrypt keys and other stuff. It is a broken TODO then, because there is no way to do it. Sure, you can have the agent encrypt its memory, but it also has to store the key, so this is just an obscurity measure. Don't expose your keys to a system that you don't trust (I'd hope that this is just common sense). -d From keld at dkuug.dk Mon Jul 19 02:44:55 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Sun, 18 Jul 2004 18:44:55 +0200 Subject: vulnerability with ssh-agent In-Reply-To: References: <20040717211422.GC12680@rap.rap.dk> Message-ID: <20040718164455.GA13346@rap.rap.dk> On Sat, Jul 17, 2004 at 09:05:38PM -0500, Ben Lindstrom wrote: > > Sounds like ssh-agent coundn't talk to the askpass program for gnome/x11. > As a result ssh-agent returns a denied and ssh falls back to prompting you > for the passphrase of the key. Yes, that was true, and I installed gnome-ssh-askpass and set the shell variable. Then it worked. But, but. I would like that it was not ssh that initiated this verification, instead it should be ssh-agent. And ssh should not default to asking for key/passwd, when programs are not found, it should be the job of ssh-agent IMHO. A scenario: somebody has cracked my password, and can log in as a normal user on my home server over the internet. With an open ssh-agent he can log in further to my other servers. If it was the ssh-agent's job to ask for the confirmation then I would get a notice at my X window and I would not grant the intruder. That would mean that ssh-agent at some time would get the information that a specific ssh-askpass program should be used. Maybe this would be at launch time of ssh-agent, maybe that would be when invoking ssh-add -c (or what option this feature should have). This would also give me a modest shield against a root intruder doing the same thing. Best regards Keld From ghowardw at yahoo.com Mon Jul 19 03:29:55 2004 From: ghowardw at yahoo.com (Howard Williams) Date: Sun, 18 Jul 2004 10:29:55 -0700 (PDT) Subject: HPUX and privsep Message-ID: <20040718172955.29786.qmail@web41310.mail.yahoo.com> Subject: HPUX and privsep Anyone solved or see the same connection I do with these two issues on HPUX if Privilege Separation is turned off ? Logname not found (3.7.1p2, 3.8.1p1) Login prematurely quits during session setup (mm_send_fd: sendmsg(3): Bad file number | mm_receive_fd: recvmsg: expected received 1 got 0) (3.8.1p1) Seems the mm_xxxx_() functions arent called when PrivSep is off. The utmpx line field isnt filled in correctly (loginrec.c:line_abbrevname() - easy to fix) but doenst seem to affect these problems. This was found on HP's site with no solution : http://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1089735097108+28353475&threadId=43106 Something mentioned was a change in logname to use getsid() instead of getlogin(). Doesn't solve the 3.8.1 problem of no login. George Williams Security Architect TEK systems __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ From mouring at etoh.eviladmin.org Mon Jul 19 04:21:42 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 18 Jul 2004 13:21:42 -0500 (CDT) Subject: vulnerability with ssh-agent In-Reply-To: <20040718164455.GA13346@rap.rap.dk> Message-ID: On Sun, 18 Jul 2004, Keld [iso-8859-1] J?rn Simonsen wrote: > On Sat, Jul 17, 2004 at 09:05:38PM -0500, Ben Lindstrom wrote: > > > > Sounds like ssh-agent coundn't talk to the askpass program for gnome/x11. > > As a result ssh-agent returns a denied and ssh falls back to prompting you > > for the passphrase of the key. > > Yes, that was true, and I installed gnome-ssh-askpass and set the shell > variable. Then it worked. But, but. I would like that it was not ssh > that initiated this verification, instead it should be ssh-agent. Please take this up with the IETF if you don't agree with it. This is how the RFC drafts are written, and to change would break compatibility with every other SSH server in the world. > And ssh should not default to asking for key/passwd, when programs are > not found, it should be the job of ssh-agent IMHO. > I like most don't agree, but you don't seem to get the reason for ssh-agent in the first place. ssh-agent is there to allow you to safely (for SHORT periods in time) decrypt your private key for verification. If all you are doing is using one key to login your remote shell server every once in a while then ssh-agent is not the correct tool. It is used for short bursts of setting up large amount of connections. Or in the case of most developers long CVS ci/co sessions while coding. - Ben From stuge-openssh-unix-dev at cdy.org Mon Jul 19 04:26:42 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 18 Jul 2004 20:26:42 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040718164455.GA13346@rap.rap.dk> References: <20040717211422.GC12680@rap.rap.dk> <20040718164455.GA13346@rap.rap.dk> Message-ID: <20040718182642.GA2790@foo.birdnet.se> On Sun, Jul 18, 2004 at 06:44:55PM +0200, Keld J?rn Simonsen wrote: > Yes, that was true, and I installed gnome-ssh-askpass and set the > shell variable. Then it worked. But, but. I would like that it was > not ssh that initiated this verification, instead it should be > ssh-agent. It is. When ssh asks ssh-agent for the key, ssh-agent asks the user for permission. //Peter From stuge-openssh-unix-dev at cdy.org Mon Jul 19 04:35:35 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 18 Jul 2004 20:35:35 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <20040718182642.GA2790@foo.birdnet.se> References: <20040717211422.GC12680@rap.rap.dk> <20040718164455.GA13346@rap.rap.dk> <20040718182642.GA2790@foo.birdnet.se> Message-ID: <20040718183535.GB2790@foo.birdnet.se> On Sun, Jul 18, 2004 at 08:26:42PM +0200, Peter Stuge wrote: > It is. When ssh asks ssh-agent for the key, ssh-agent asks the user > for permission. To clarify, ssh doesn't ask for the key and more importantly ssh-agent doesn't give it out. ssh asks ssh-agent to USE the key. ssh-agent asks the user for permission. Sorry for any confusion. //Peter From djm at mindrot.org Mon Jul 19 07:47:32 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Jul 2004 07:47:32 +1000 Subject: vulnerability with ssh-agent In-Reply-To: <20040718164455.GA13346@rap.rap.dk> References: <20040717211422.GC12680@rap.rap.dk> <20040718164455.GA13346@rap.rap.dk> Message-ID: <40FAEFF4.1080508@mindrot.org> Keld J?rn Simonsen wrote: > Yes, that was true, and I installed gnome-ssh-askpass and set the shell > variable. Then it worked. But, but. I would like that it was not ssh > that initiated this verification, instead it should be ssh-agent. > And ssh should not default to asking for key/passwd, when programs are > not found, it should be the job of ssh-agent IMHO. You have this completely wrong. When ssh-agent is improperly configured (e.g. no $DISPLAY environment variable set when it is run) then it will always refuse requests to use any keys it may have loaded with the confirm option on. ssh will fall back to trying the keys in ~/.ssh directly. > A scenario: somebody has cracked my password, and can log in as a > normal user on my home server over the internet. With an open ssh-agent he > can log in further to my other servers. If it was the ssh-agent's job to > ask for the confirmation then I would get a notice at my X window and I > would not grant the intruder. That would mean that ssh-agent at some > time would get the information that a specific ssh-askpass program > should be used. Maybe this would be at launch time of ssh-agent, maybe > that would be when invoking ssh-add -c (or what option this feature > should have). This is what happens now. Please read and understand the manpages. -d From bob at proulx.com Mon Jul 19 09:24:29 2004 From: bob at proulx.com (Bob Proulx) Date: Sun, 18 Jul 2004 17:24:29 -0600 Subject: vulnerability with ssh-agent In-Reply-To: <20040713191347.GA3297@rap.rap.dk> References: <20040713191347.GA3297@rap.rap.dk> Message-ID: <20040718232429.GB24332@misery.proulx.com> Keld J?rn Simonsen wrote: > I have written a small introduction to newbies in Danish on ssh and > friends. Now some people are questioning my advice and I think they have > a point. > > I am advocating people to use DSA-keys and a config file with this: As I understand it RSA keys are both faster and more secure for the same number of key bits. Which is why DSA keys must be much bigger than RSA keys to provide a similar level of strength. Both of which makes DSA keys slower. As I understand it the only reason for DSA keys was to avoid the RSA patent now expired by four years. But is is now expired and so longer poses a restriction. I would use RSA keys. They are strong, fast and compact. Bob From bob at proulx.com Mon Jul 19 09:27:24 2004 From: bob at proulx.com (Bob Proulx) Date: Sun, 18 Jul 2004 17:27:24 -0600 Subject: Logging of wrong pubkey auth In-Reply-To: <20040714191028.727cebf5.pr0gm4@linoratix.com> References: <20040714191028.727cebf5.pr0gm4@linoratix.com> Message-ID: <20040718232724.GC24332@misery.proulx.com> Jan Gehring wrote: > + logit("Illegal user %.100s from %.100s", authctxt->user,get_remote_ipaddr()); Under what government is this illegal? I would like to avoid such a police state. :-) I think you mean "invalid" here, not "illegal". s/Illegal/Invalid/g Bob From keld at dkuug.dk Mon Jul 19 10:28:47 2004 From: keld at dkuug.dk (Keld =?iso-8859-1?Q?J=F8rn?= Simonsen) Date: Mon, 19 Jul 2004 02:28:47 +0200 Subject: vulnerability with ssh-agent In-Reply-To: <40FAEFF4.1080508@mindrot.org> References: <20040717211422.GC12680@rap.rap.dk> <20040718164455.GA13346@rap.rap.dk> <40FAEFF4.1080508@mindrot.org> Message-ID: <20040719002847.GA3211@rap.rap.dk> On Mon, Jul 19, 2004 at 07:47:32AM +1000, Damien Miller wrote: > Keld J?rn Simonsen wrote: > > > A scenario: somebody has cracked my password, and can log in as a > > normal user on my home server over the internet. With an open ssh-agent he > > can log in further to my other servers. If it was the ssh-agent's job to > > ask for the confirmation then I would get a notice at my X window and I > > would not grant the intruder. That would mean that ssh-agent at some > > time would get the information that a specific ssh-askpass program > > should be used. Maybe this would be at launch time of ssh-agent, maybe > > that would be when invoking ssh-add -c (or what option this feature > > should have). > > This is what happens now. Please read and understand the manpages. Yes, this is how it works. Got it working now! Thanks for your patience with me. In some sense it is good to know that the way I wanted it to work, is the way it actually works. Then I am not totally off target. I will add a recommendation of using ssh-add -c References: <200407081631.i68GVei20316@tenzing.org> Message-ID: On Thu, 8 Jul 2004, Roger Cornelius wrote: > On SCO 5.0.7 and openssh 3.8.1p1, two entries are written to /etc/wtmp > and /etc/wtmpx each time a user logs in via ssh. This can be > demonstrated using the last(C) command. Any user connected via ssh will > have two identical login and logout entries. [snip] Thanks for the report. I've duplicated the problem on 5.0.4 & 5.0.7 and checked in a fix for both HEAD and V_3_8_1 branch. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From owner-mutt-users at mutt.org Tue Jul 20 07:51:28 2004 From: owner-mutt-users at mutt.org (owner-mutt-users at mutt.org) Date: 19 Jul 2004 21:51:28 -0000 Subject: mutt-users@mutt.org: Non-member submission from openssh-unix-dev@mindrot.org Message-ID: <20040719215128.16472.qmail@agent57.gbnet.net> Your submission to the list has been forwarded to the list owner for approval because you do not seem to be on that list. If you want to join the list, send email to , with "subscribe mutt-users" in the message text (not the subject). From glemtp at yahoo.com Fri Jul 23 06:36:06 2004 From: glemtp at yahoo.com (Greg Lambert) Date: Thu, 22 Jul 2004 13:36:06 -0700 (PDT) Subject: ebcdic problem in bufaux.c Message-ID: <20040722203606.37355.qmail@web52604.mail.yahoo.com> I am working on a port of Openssh 3.8p1 after already having done a port of Openssh 3.5p1. There are a couple of new lines in buffer_get_bignum2() that are causing me problems: if (len > 0 && (bin[0] & 0x80)) fatal("buffer_get_bignum2: negative numbers not supported"); The "& 0x80" check is not relevant in ebcdic. Does anyone know why this check was added? What are the consequences of removing it? Does anyone have any idea how I could get the same result as this check in ebcdic? Thank You, Greg Lambert __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/ From djm at mindrot.org Fri Jul 23 08:02:34 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Jul 2004 08:02:34 +1000 Subject: ebcdic problem in bufaux.c In-Reply-To: <20040722203606.37355.qmail@web52604.mail.yahoo.com> References: <20040722203606.37355.qmail@web52604.mail.yahoo.com> Message-ID: <4100397A.1060104@mindrot.org> Greg Lambert wrote: > I am working on a port of Openssh 3.8p1 after already > having done a port of Openssh 3.5p1. There are a > couple of new lines in buffer_get_bignum2() that are > causing me problems: > > if (len > 0 && (bin[0] & 0x80)) > fatal("buffer_get_bignum2: negative > numbers not supported"); > > The "& 0x80" check is not relevant in ebcdic. Why not? The contents of a bignum are binary, not text. > Does anyone know why this check was added? > What are the consequences of removing it? These should be obvious from the error message. -d From markus at openbsd.org Fri Jul 23 08:17:20 2004 From: markus at openbsd.org (Markus Friedl) Date: Fri, 23 Jul 2004 00:17:20 +0200 Subject: ebcdic problem in bufaux.c In-Reply-To: <20040722203606.37355.qmail@web52604.mail.yahoo.com> References: <20040722203606.37355.qmail@web52604.mail.yahoo.com> Message-ID: <20040722221720.GA16166@folly> On Thu, Jul 22, 2004 at 01:36:06PM -0700, Greg Lambert wrote: > I am working on a port of Openssh 3.8p1 after already > having done a port of Openssh 3.5p1. There are a > couple of new lines in buffer_get_bignum2() that are > causing me problems: > > if (len > 0 && (bin[0] & 0x80)) > fatal("buffer_get_bignum2: negative > numbers not supported"); > > The "& 0x80" check is not relevant in ebcdic. > > Does anyone know why this check was added? because negative numbers are not supported by our buffer_get_bignum2. see below > What are the consequences of removing it? > > Does anyone have any idea how I could get the same > result as this check in ebcdic? bin[] is not a character, it's just a byte. here's a quote from the secsh-architecture draft: mpint Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data. By convention, a number that is used in modular computations in Z_n SHOULD be represented in the range 0 <= x < n. Examples: value (hex) representation (hex) --------------------------------------------------------------- 0 00 00 00 00 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 80 00 00 00 02 00 80 -1234 00 00 00 02 ed cc -deadbeef 00 00 00 05 ff 21 52 41 11 From phil at usc.edu Fri Jul 23 09:51:11 2004 From: phil at usc.edu (Phil Dibowitz) Date: Thu, 22 Jul 2004 16:51:11 -0700 Subject: Potential Patch Message-ID: <20040722235111.GW849@usc.edu> Hey folks, Here at USC we have a few changes we make to the source code for various reasons -- and we have to make them for each new version. I always shrugged off sending a patch in because the changes felt very internal, but the more I think about it, the more I think perhaps they would be good for the main tree. Additionally, the more of this that gets into the main tree the easier upgrades become for us, which is always a plus. So if you would be willing to put the following changes into the main tree, I will clean up my patch to 3.8p1 and send it in. Feed back welcome: Changes: 1. Solaris BSM/Auditd supprt This is properly ifdef'd out, and I added support in the autoconf stuff to only enable it in Solaris. For those unfamiliar there is a special logging system you can optionally enable in solaris that logs every occurance of a certain (definable) subset of system calls. It has a kernel counterpart to compliment the deamon that runs and ensure there is no tampering from userspace. The root of the process tree must have an auditd handle, and then every subprocess inherets it. So every login system (login, telnetd, ftpd, rsh, etc.) in Solaris sets up the auditd handle -- and if openssh was started by someone who logged in, it would work, but since its started by init, nothing done via an openssh connection gets logged in auditd logs. A co-worker wrote a small stub to initialize auditd support in sshd, and I added the appropriate hooks (only about 10 lines), plus a few extra lines to add "txt" entries (essentially comments so our security staff can more easily sift through the somewhat hard-to-read logs. If interested, I need to get approval from the guy who wrote the auditd stub, though I don't expect him to mind. Having this in would be a hugely wonderful thing. Sun's SSH adds this support to openssh, but theirs is usually too far behind for my taste. 2. We add a logit() call for people doing "ssh host command" to log the user and commadn (2 places in session.c). Requested by our security staff. Currently my patch does not make this a configuration or compile time option, but I could probably do that without too much work. 3. Makefile.in change to break up install a bit more. Currently it has an "install" and "install-nokeys". I further broke it into "install" "install-nokeys" and "install-nosysconf" which doesn't try to write anything to the configuration directory (this could be useful when the person installing doesn't have access to that dir, or doesn't want to write to it, or its read-only, or...). Thanks. -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040722/667af94f/attachment.bin From mouring at etoh.eviladmin.org Fri Jul 23 10:56:58 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 22 Jul 2004 19:56:58 -0500 (CDT) Subject: Potential Patch In-Reply-To: <20040722235111.GW849@usc.edu> Message-ID: On Thu, 22 Jul 2004, Phil Dibowitz wrote: [..] > Changes: > 1. Solaris BSM/Auditd supprt > This is properly ifdef'd out, and I added support in the autoconf stuff to [..] Compare it to http://bugzilla.mindrot.org/show_bug.cgi?id=125 and add to that bugzilla report. [..] > 2. We add a logit() call for people doing "ssh host command" to log the user > and commadn (2 places in session.c). Requested by our security staff. > Currently my patch does not make this a configuration or compile time option, > but I could probably do that without too much work. > Either they should exist.. or not exist.. We don't care for odd compile time options. > 3. Makefile.in change to break up install a bit more. Currently it has an > "install" and "install-nokeys". I further broke it into "install" > "install-nokeys" and "install-nosysconf" which doesn't try to write anything > to the configuration directory (this could be useful when the person > installing doesn't have access to that dir, or doesn't want to write to it, or > its read-only, or...). > Makes sense in some cases. I'd like to see the patch first. - Ben From phil at usc.edu Fri Jul 23 12:13:36 2004 From: phil at usc.edu (Phil Dibowitz) Date: Thu, 22 Jul 2004 19:13:36 -0700 Subject: Potential Patch In-Reply-To: References: <20040722235111.GW849@usc.edu> Message-ID: <20040723021336.GY849@usc.edu> On Thu, Jul 22, 2004 at 07:56:58PM -0500, Ben Lindstrom wrote: > > Changes: > > 1. Solaris BSM/Auditd supprt > > This is properly ifdef'd out, and I added support in the autoconf stuff to > [..] > > Compare it to http://bugzilla.mindrot.org/show_bug.cgi?id=125 and add to > that bugzilla report. I think that looks to be a lot more complete then my patch. My patch only really enables the auditd handle -- this patch seems to add in all sorts of other wonderful goodness. Is this expected for inclusion in the next version? It appears its been "pending" since about 3.4. > > 2. We add a logit() call for people doing "ssh host command" to log the user > > and commadn (2 places in session.c). Requested by our security staff. > > Currently my patch does not make this a configuration or compile time option, > > but I could probably do that without too much work. > > > > Either they should exist.. or not exist.. We don't care for odd compile > time options. Fair enough. The question is, do the developers believe these two lines should exist? I will always have to add them in, so if they could be added, that would be stellar. I don't think they clutter logs, though it's something some people may not expect to see in their logs. --- session.c.orig Sat Feb 28 21:19:25 2004 +++ session.c Sat Feb 28 21:21:59 2004 @@ -340,6 +340,8 @@ if (type == SSH_CMSG_EXEC_CMD) { command = packet_get_string(&dlen); debug("Exec command '%.500s'", command); + /* USC CHANGE: We log this */ + logit("User %.100s attempting to executed comand '%.5 00s' on command line", s->pw->pw_name, command); do_exec(s, command); xfree(command); } else { @@ -1804,6 +1806,8 @@ u_int len; char *command = packet_get_string(&len); packet_check_eom(); + /* USC CHANGE: We log this */ + logit("User %.100s attempting to executed comand '%.500s' on command line", s ->pw->pw_name, command); do_exec(s, command); xfree(command); return 1; > > 3. Makefile.in change to break up install a bit more. Currently it has an > > "install" and "install-nokeys". I further broke it into "install" > > "install-nokeys" and "install-nosysconf" which doesn't try to write anything > > to the configuration directory (this could be useful when the person > > installing doesn't have access to that dir, or doesn't want to write to it, or > > its read-only, or...). > > > > Makes sense in some cases. I'd like to see the patch first. Sure! I've attached that portion of the patch -- sans cleaning up comments and such -- just so you can see the Makefile.in changes I made. If you like it, and depending on whether you like the above or not, I'll make a nicer patch of the both of them and send it in. -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040722/19094438/attachment.bin From dann at godzilla.ics.uci.edu Fri Jul 23 14:57:45 2004 From: dann at godzilla.ics.uci.edu (Dan Nicolaescu) Date: Thu, 22 Jul 2004 21:57:45 -0700 Subject: x11 forwarding problem on solaris Message-ID: <200407230457.i6N4vnGK017520@scanner2.ics.uci.edu> Hi! I am having problems using openssh-3.8.1p1 on sparc-sun-solaris2.8 to connect to another sparc-solaris or x86-linux machine with X11 forwarding enabled. After connecting tot the remote box if I start emacs, type a few characters and then try to select the text with the mouse emacs crashes. This reproduces reliably on a number of solaris/linux machines. Here is the output of ssh -v debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 35652 debug1: channel 1: new [x11] debug1: confirm x11 debug1: channel 1: FORCE input drain X protocol error: BadWindow (invalid Window parameter) on protocol request 38 debug1: channel 1: free: x11, nchannels 2 [1] Abort emacs (core dumped) This reproduces reliably openssh-3.7.1p2, works just fine. openssh-3.7.1p2 was configured/compiled with the same command line as openssh-3.8.1p1, both using the same statically linked zlib-1.1.4 and openssl-0.9.7d. Using the SUN Forte-7 compiler or gcc-3.4.0, turning off optimization does not make any difference. Is this a known issue? Thanks. --dan From dtucker at zip.com.au Fri Jul 23 15:07:54 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 23 Jul 2004 15:07:54 +1000 Subject: x11 forwarding problem on solaris In-Reply-To: <200407230457.i6N4vnGK017520@scanner2.ics.uci.edu> References: <200407230457.i6N4vnGK017520@scanner2.ics.uci.edu> Message-ID: <41009D2A.8030601@zip.com.au> Dan Nicolaescu wrote: > I am having problems using openssh-3.8.1p1 on sparc-sun-solaris2.8 to > connect to another sparc-solaris or x86-linux machine with X11 > forwarding enabled. [...] > X protocol error: BadWindow (invalid Window parameter) on protocol request 38 > debug1: channel 1: free: x11, nchannels 2 http://www.openssh.com/faq.html#3.13 -- 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 glemtp at yahoo.com Sat Jul 24 00:59:58 2004 From: glemtp at yahoo.com (Greg Lambert) Date: Fri, 23 Jul 2004 07:59:58 -0700 (PDT) Subject: ebcdic problem in bufaux.c Message-ID: <20040723145958.2062.qmail@web52610.mail.yahoo.com> Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An embedded message was scrubbed... From: Greg Lambert Subject: Re: ebcdic problem in bufaux.c Date: Fri, 23 Jul 2004 07:58:27 -0700 (PDT) Size: 2242 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040723/775cc09b/attachment.mht From ken at sith.com Sat Jul 24 15:39:04 2004 From: ken at sith.com (ken) Date: Sat, 24 Jul 2004 14:39:04 +0900 Subject: =?iso-2022-jp?b?GyRCTDU+NUJ6OS05cCF2TDU9JEA1NDBBNCUqJWolOCVKGyhC?= =?iso-2022-jp?b?GyRCJWtBRz9NJU8lYTsjJGpOIiNEI1YjRBsoQg==?= Message-ID: <20040724143904759004_ken@sith.com> ????? The Sith co,LTD http://sith.h.fc2.com/ ?????????????????????????????????????? ????????hidekazu5544 at yahoo.co.jp???E-mail??????????? http://sith.h.fc2.com/ ??????http://pksp.jp/1231402/ ?????????????????????????????????????? ?????????????????????????????????????? ?????????DVD??????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?http://sith.h.fc2.com/?????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ????????????????????????????????????? ??????????????????????? The Sith co,LTD ???????? hidekazu5544 at yahoo.co.jp 202-0014 ????????-??-?? tel/fax 03-3378-2453 http://sith.h.fc2.com/ From ken at sith.com Sat Jul 24 17:40:36 2004 From: ken at sith.com (ken) Date: Sat, 24 Jul 2004 16:40:36 +0900 Subject: =?iso-2022-jp?b?GyRCTDU+NUJ6OS05cCF2TDU9JEA1NDBBNCUqJWolOCVKGyhC?= =?iso-2022-jp?b?GyRCJWtBRz9NJU8lYTsjJGpOIiNEI1YjRBsoQg==?= Message-ID: <20040724164036744002_ken@sith.com> ????? The Sith co,LTD http://sith.h.fc2.com/ ?????????????????????????????????????? ????????hidekazu5544 at yahoo.co.jp???E-mail??????????? http://sith.h.fc2.com/ ??????http://pksp.jp/1231402/ ?????????????????????????????????????? ?????????????????????????????????????? ?????????DVD??????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ?http://sith.h.fc2.com/?????????????????????????? ?????????????????????????????????????? ?????????????????????????????????????? ????????????????????????????????????? ??????????????????????? The Sith co,LTD ???????? hidekazu5544 at yahoo.co.jp 202-0014 ????????-??-?? tel/fax 03-3378-2453 http://sith.h.fc2.com/ From Sergio.Gelato at astro.su.se Sun Jul 25 01:56:25 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Sat, 24 Jul 2004 17:56:25 +0200 Subject: Potential Patch In-Reply-To: <20040722235111.GW849@usc.edu> References: <20040722235111.GW849@usc.edu> Message-ID: <20040724155625.GA18884@astro.su.se> * Phil Dibowitz [2004-07-22 16:51:11 -0700]: > 1. Solaris BSM/Auditd supprt > This is properly ifdef'd out, and I added support in the autoconf stuff to > only enable it in Solaris. Is this really Solaris-only? I'm wondering because I've noticed that the sshd shipped by Apple in Mac OS 10.3.4 has a number of "BSM audit:" strings including BSM audit: solaris_audit_record failed to write "%s" record: %s That's http://www.opensource.apple.com/darwinsource/tarballs/other/OpenSSH-41.tar.gz for those who are curious. > 2. We add a logit() call for people doing "ssh host command" to log the user > and commadn (2 places in session.c). Requested by our security staff. Do you also log all input to the command? If not, what does this extra logging buy you over ordinary process accounting? From mouring at etoh.eviladmin.org Sun Jul 25 02:35:00 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 24 Jul 2004 11:35:00 -0500 (CDT) Subject: Potential Patch In-Reply-To: <20040724155625.GA18884@astro.su.se> Message-ID: On Sat, 24 Jul 2004, Sergio Gelato wrote: > * Phil Dibowitz [2004-07-22 16:51:11 -0700]: > > 1. Solaris BSM/Auditd supprt > > This is properly ifdef'd out, and I added support in the autoconf stuff to > > only enable it in Solaris. > > Is this really Solaris-only? I'm wondering because I've noticed that the > sshd shipped by Apple in Mac OS 10.3.4 has a number of "BSM audit:" strings > including > BSM audit: solaris_audit_record failed to write "%s" record: %s > 10.3.x ships with BSM and looks to be compiled in by default, but is is not active on the OS/X desktop by default. This may not be the case for OS/X Server version. In any respects, I dont see any manpages on the topic which makes me less inclined to suggest any official support for that platform. However, it may be something to consider and ensure BSM is more general if Apple is also planning on using it. [..] > > 2. We add a logit() call for people doing "ssh host command" to log the user > > and commadn (2 places in session.c). Requested by our security staff. > > Do you also log all input to the command? If not, what does this extra logging > buy you over ordinary process accounting? > I honestly don't care to see these session.c mods. I really only care about the Makefile change at this point. - Ben From openssh-unix-dev at mlists.thewrittenword.com Sun Jul 25 12:38:23 2004 From: openssh-unix-dev at mlists.thewrittenword.com (Albert Chin) Date: Sat, 24 Jul 2004 21:38:23 -0500 Subject: x11 forwarding problem on solaris In-Reply-To: <41009D2A.8030601@zip.com.au> References: <200407230457.i6N4vnGK017520@scanner2.ics.uci.edu> <41009D2A.8030601@zip.com.au> Message-ID: <20040725023822.GG43240@mail1.thewrittenword.com> On Fri, Jul 23, 2004 at 03:07:54PM +1000, Darren Tucker wrote: > Dan Nicolaescu wrote: > >I am having problems using openssh-3.8.1p1 on sparc-sun-solaris2.8 to > >connect to another sparc-solaris or x86-linux machine with X11 > >forwarding enabled. > [...] > >X protocol error: BadWindow (invalid Window parameter) on protocol request > >38 > >debug1: channel 1: free: x11, nchannels 2 > > http://www.openssh.com/faq.html#3.13 I'm running OpenSSH 3.8.1p1 client/server and see a similar problem. We upgraded Ethereal (network protocol analyzer) from 0.10.2 to 0.10.5 and now get the following when trying to save a protocol trace: Gdk-ERROR **: BadWindow (invalid Window parameter) serial 12171 error_code 3 request_code 15 minor_code 0 This is with Ethereal built against GTK+ 1.2.10. Building Ethereal against GTK+ 2.4.4 works fine. Setting "ForwardX11Trusted yes" in ssh_config doesn't help. And this is with a Debian OpenSSH 3.8.1p1 client and a host of servers (Solaris, HP-UX, AIX, Tru64 UNIX, Redhat, IRIX). If I telnet into the remote server and run Ethereal, no problems. Only when using OpenSSH do I see a problem. Prior to the 3.8.1p1 upgrade, we were running 3.7p1 on the servers and using a 3.6p1 client on the Debian box. Same problem. -- albert chin (china at thewrittenword.com) From dtucker at zip.com.au Sun Jul 25 12:53:18 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 25 Jul 2004 12:53:18 +1000 Subject: x11 forwarding problem on solaris In-Reply-To: <20040725023822.GG43240@mail1.thewrittenword.com> References: <200407230457.i6N4vnGK017520@scanner2.ics.uci.edu> <41009D2A.8030601@zip.com.au> <20040725023822.GG43240@mail1.thewrittenword.com> Message-ID: <4103209E.6070703@zip.com.au> Albert Chin wrote: > I'm running OpenSSH 3.8.1p1 client/server and see a similar problem. We > upgraded Ethereal (network protocol analyzer) from 0.10.2 to 0.10.5 > and now get the following when trying to save a protocol trace: > Gdk-ERROR **: BadWindow (invalid Window parameter) > serial 12171 error_code 3 request_code 15 minor_code 0 > > This is with Ethereal built against GTK+ 1.2.10. Building Ethereal > against GTK+ 2.4.4 works fine. > > Setting "ForwardX11Trusted yes" in ssh_config doesn't help. That's odd, I would have thought that would fix it. That was the client's ssh_config? Does "ssh -o ForwardX11Trusted=yes yourserver" do the same thing? You can also try "X11UseLocalhost no" in the server's sshd_config (you will need to restart sshd). -- 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 openssh-unix-dev at mlists.thewrittenword.com Sun Jul 25 14:31:21 2004 From: openssh-unix-dev at mlists.thewrittenword.com (Albert Chin) Date: Sat, 24 Jul 2004 23:31:21 -0500 Subject: x11 forwarding problem on solaris In-Reply-To: <4103209E.6070703@zip.com.au> References: <200407230457.i6N4vnGK017520@scanner2.ics.uci.edu> <41009D2A.8030601@zip.com.au> <20040725023822.GG43240@mail1.thewrittenword.com> <4103209E.6070703@zip.com.au> Message-ID: <20040725043121.GI43240@mail1.thewrittenword.com> On Sun, Jul 25, 2004 at 12:53:18PM +1000, Darren Tucker wrote: > Albert Chin wrote: > >I'm running OpenSSH 3.8.1p1 client/server and see a similar problem. We > >upgraded Ethereal (network protocol analyzer) from 0.10.2 to 0.10.5 > >and now get the following when trying to save a protocol trace: > > Gdk-ERROR **: BadWindow (invalid Window parameter) > > serial 12171 error_code 3 request_code 15 minor_code 0 > > > >This is with Ethereal built against GTK+ 1.2.10. Building Ethereal > >against GTK+ 2.4.4 works fine. > > > >Setting "ForwardX11Trusted yes" in ssh_config doesn't help. > > That's odd, I would have thought that would fix it. That was the > client's ssh_config? Does "ssh -o ForwardX11Trusted=yes yourserver" do > the same thing? Yes, it does the same thing. I don't think the problem has anything to do with 3.8.1 though as it was broken with a 3.7p1 server as well (with 3.6 client). > You can also try "X11UseLocalhost no" in the server's sshd_config (you > will need to restart sshd). Tested on RHEL 2.1 and saw the same problem. But, Ethereal does come up. It's just when trying to save the capture from the GUI that we run into the problem. I think we'll just ditch the GTK+ 1.2 Ethereal build in favor of the GTK+ 2.4.4 build. It's probably a local problem as I don't see posts to the Ethereal list complaining. There was one report but ldconfig fixed it for them (strange solution). -- albert chin (china at thewrittenword.com) From VUZAAZZMTCCEWA at psyk.vsso.sll.se Mon Jul 26 20:16:30 2004 From: VUZAAZZMTCCEWA at psyk.vsso.sll.se (Angel Meredith) Date: Mon, 26 Jul 2004 04:16:30 -0600 Subject: Mon, 26 Jul 2004 04:23:30 -0600 Message-ID: Giving away 25$ to all new acc0unts. No dep0s1t reqd http://clubhouse.raft.network74.net Orlando From bbraun at synack.net Tue Jul 27 01:15:42 2004 From: bbraun at synack.net (Rob Braun) Date: Mon, 26 Jul 2004 08:15:42 -0700 Subject: Potential Patch In-Reply-To: References: <20040724155625.GA18884@astro.su.se> Message-ID: <20040726151542.GC384@synack.net> On Sat, Jul 24, 2004 at 11:35:00AM -0500, Ben Lindstrom wrote: > > 10.3.x ships with BSM and looks to be compiled in by default, but is is > not active on the OS/X desktop by default. This may not be the case for > OS/X Server version. The OS X Server and desktop versions both ship with the same OpenSSH. BSM is compiled in, but auditing is not enabled by default on both systems. > In any respects, I dont see any manpages on the topic which makes me less > inclined to suggest any official support for that platform. > > However, it may be something to consider and ensure BSM is more general if > Apple is also planning on using it. Apple is definitely currently using it, and will continue to be using it for the forseeable future. I'd definitely like to see more generic BSM support. Seeing solaris in the ssh logs on an OS X system is a little bizarre. Rob From mouring at etoh.eviladmin.org Tue Jul 27 06:09:09 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 26 Jul 2004 15:09:09 -0500 (CDT) Subject: Potential Patch In-Reply-To: <20040726151542.GC384@synack.net> Message-ID: On Mon, 26 Jul 2004, Rob Braun wrote: [..] > > > > However, it may be something to consider and ensure BSM is more general if > > Apple is also planning on using it. > > Apple is definitely currently using it, and will continue to be using it > for the forseeable future. I'd definitely like to see more generic BSM > support. Seeing solaris in the ssh logs on an OS X system is a little > bizarre. > Then Apple should take the time to document via manpages the API they are using. I would be nice to see a generic BSM, and I have no quarms with that. I have a big bitch about using APIs aren't document since that tends to mean they are under flux. Which definitely shows when you look at what Apple did to Sun's BSM patch. - Ben From bbraun at synack.net Tue Jul 27 06:17:01 2004 From: bbraun at synack.net (Rob Braun) Date: Mon, 26 Jul 2004 13:17:01 -0700 Subject: Potential Patch In-Reply-To: References: <20040726151542.GC384@synack.net> Message-ID: <20040726201701.GD384@synack.net> On Mon, Jul 26, 2004 at 03:09:09PM -0500, Ben Lindstrom wrote: > > > On Mon, 26 Jul 2004, Rob Braun wrote: > [..] > > > > > > However, it may be something to consider and ensure BSM is more general if > > > Apple is also planning on using it. > > > > Apple is definitely currently using it, and will continue to be using it > > for the forseeable future. I'd definitely like to see more generic BSM > > support. Seeing solaris in the ssh logs on an OS X system is a little > > bizarre. > > > > Then Apple should take the time to document via manpages the API they are > using. I would be nice to see a generic BSM, and I have no quarms with > that. I have a big bitch about using APIs aren't document since that > tends to mean they are under flux. I agree completely, the APIs should be documented, if they want people to use them. I would not accept patches from Apple that use unsupported and undocumented API. Your original comment sounded like you were unsure if Apple were going to use BSM with OpenSSH, and I wanted to lay to rest any uncertainty in that area. It would be great if OpenSSH could cooperate with Apple in incorporating generic BSM support, but the hold up is more likely Apple cooperating with OpenSSH in this regard. Rob From mouring at etoh.eviladmin.org Tue Jul 27 06:45:11 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 26 Jul 2004 15:45:11 -0500 (CDT) Subject: Potential Patch In-Reply-To: <20040726201701.GD384@synack.net> Message-ID: On Mon, 26 Jul 2004, Rob Braun wrote: > On Mon, Jul 26, 2004 at 03:09:09PM -0500, Ben Lindstrom wrote: > > > > > > On Mon, 26 Jul 2004, Rob Braun wrote: > > [..] > > > > > > > > However, it may be something to consider and ensure BSM is more general if > > > > Apple is also planning on using it. > > > > > > Apple is definitely currently using it, and will continue to be using it > > > for the forseeable future. I'd definitely like to see more generic BSM > > > support. Seeing solaris in the ssh logs on an OS X system is a little > > > bizarre. > > > > > > > Then Apple should take the time to document via manpages the API they are > > using. I would be nice to see a generic BSM, and I have no quarms with > > that. I have a big bitch about using APIs aren't document since that > > tends to mean they are under flux. > > I agree completely, the APIs should be documented, if they want people > to use them. I would not accept patches from Apple that use unsupported > and undocumented API. Your original comment sounded like you were > unsure if Apple were going to use BSM with OpenSSH, and I wanted to lay > to rest any uncertainty in that area. I was uncertian if OS/X Server has BSM enabled by default at the OS level. I know the desktop doesn't since I'm running that with a custom OpenSSH server and have none of the tradition issues. > It would be great if OpenSSH could cooperate with Apple in incorporating > generic BSM support, but the hold up is more likely Apple cooperating > with OpenSSH in this regard. > Would be nice if Apple would cooperate with us. I've not seen hide nor hair of them on this mailinglist. Nor have I been contacted by them in regards to the KRB5/zlib header bug I pointed out almost 5 months now. Nor about the existances of a "getpeereuid()" manpage, but the lack of it's real existance. I'm kinda disappointed at that since I've seen Sun, IBM, Cray, random Linux distros, etc reps hang out here to help sort out such issues in the past. - Ben From Darren.Moffat at Sun.COM Tue Jul 27 08:29:30 2004 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Mon, 26 Jul 2004 15:29:30 -0700 Subject: Potential Patch In-Reply-To: References: Message-ID: <1090880970.2086.74.camel@braveheart> On Sat, 2004-07-24 at 09:35, Ben Lindstrom wrote: > 10.3.x ships with BSM and looks to be compiled in by default, but is is > not active on the OS/X desktop by default. This may not be the case for > OS/X Server version. Thats very surprising to me, however I can't verify it since I don't have acess to an OS/X system. The BSM audit APIs were written by Sun and are very specific to Solaris and the system calls that we have. They were never part of any standard or proposed standard. I don't believe we (Sun) actually documented them sufficiently enough for anyone to clone them just to use them, and even then our docs are pretty poor/hard to use in this area. The actual audit events themselves and the data that gets recorded are sometimes even specific to a given Solaris release. I've looked in the Darwin CVS and they don't have the Solaris BSM audit patch applied there. However I can't see any reason why Apple would add that patch unless they had the support. So are you really 100% sure that the sshd you were looking at was the one that Apple shipped ? -- Darren J Moffat From mouring at etoh.eviladmin.org Tue Jul 27 09:03:04 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 26 Jul 2004 18:03:04 -0500 (CDT) Subject: Potential Patch In-Reply-To: <1090880970.2086.74.camel@braveheart> Message-ID: On Mon, 26 Jul 2004, Darren J Moffat wrote: [..] > > The BSM audit APIs were written by Sun and are very specific to Solaris > and the system calls that we have. They were never part of any standard > or proposed standard. I don't believe we (Sun) actually documented them > sufficiently enough for anyone to clone them just to use them, and even > then our docs are pretty poor/hard to use in this area. The actual > audit events themselves and the data that gets recorded are sometimes > even specific to a given Solaris release. > No clue.. They could have attempted to mimic the BSM API. Without an Apple contact this can all be just guess work. > I've looked in the Darwin CVS and they don't have the Solaris BSM audit > patch applied there. However I can't see any reason why Apple would add > that patch unless they had the support. > I see it in their drop code they provide. They have an openbsd-compat/solaris*.c file that has some #ifdef __APPLE__ hacks within in it . > So are you really 100% sure that the sshd you were looking at was the > one that Apple shipped ? > Virgin sshd on my OS/X laptop. yume:~ mouring$ strings /usr/sbin/sshd | grep -i solaris mm_solaris_audit_bad_pw mm_solaris_audit_maxtrys mm_solaris_audit_not_console BSM audit: solaris_audit_record failed to write "%s" record: %s BSM audit: solaris_audit_session_setup: %s failed: %s BSM solaris_audit_setup_session: calling get_terminal_id yume:~ mouring$ uname -a Darwin yume.local 7.4.0 Darwin Kernel Version 7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu-517.7.7.obj~7/RELEASE_PPC Power Macintosh powerpc yume:~ mouring$ sshd -V sshd: option requires an argument -- V sshd version OpenSSH_3.6.1p1+CAN-2003-0693 I've been ignoring this up to now due to tack of documentation and apple contacts to chat wih on the topic. - Ben From phil at usc.edu Tue Jul 27 09:49:12 2004 From: phil at usc.edu (Phil Dibowitz) Date: Mon, 26 Jul 2004 16:49:12 -0700 Subject: Potential Patch In-Reply-To: <20040724155625.GA18884@astro.su.se> References: <20040722235111.GW849@usc.edu> <20040724155625.GA18884@astro.su.se> Message-ID: <20040726234912.GU19709@usc.edu> On Sat, Jul 24, 2004 at 05:56:25PM +0200, Sergio Gelato wrote: > * Phil Dibowitz [2004-07-22 16:51:11 -0700]: > > 1. Solaris BSM/Auditd supprt > > This is properly ifdef'd out, and I added support in the autoconf stuff to > > only enable it in Solaris. > > Is this really Solaris-only? I'm wondering because I've noticed that the > sshd shipped by Apple in Mac OS 10.3.4 has a number of "BSM audit:" strings > including > BSM audit: solaris_audit_record failed to write "%s" record: %s AFAIK, yeah... but maybe Apple wrote their own version... > Do you also log all input to the command? If not, what does this extra logging > buy you over ordinary process accounting? Yes. That's all in the 'cmd' variable which is logged. -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040726/d56a98b9/attachment.bin From dtucker at zip.com.au Tue Jul 27 11:11:15 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 27 Jul 2004 11:11:15 +1000 Subject: Potential Patch In-Reply-To: <20040726234912.GU19709@usc.edu> References: <20040722235111.GW849@usc.edu> <20040724155625.GA18884@astro.su.se> <20040726234912.GU19709@usc.edu> Message-ID: <4105ABB3.3060103@zip.com.au> Phil Dibowitz wrote: > On Sat, Jul 24, 2004 at 05:56:25PM +0200, Sergio Gelato wrote: >>Do you also log all input to the command? If not, what does this extra logging >>buy you over ordinary process accounting? > > Yes. That's all in the 'cmd' variable which is logged. And if someone does, eg, echo "(cd /tmp; ls)" | ssh yourserver /bin/sh ? -- 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 phil at usc.edu Tue Jul 27 11:50:14 2004 From: phil at usc.edu (Phil Dibowitz) Date: Mon, 26 Jul 2004 18:50:14 -0700 Subject: Potential Patch In-Reply-To: <4105ABB3.3060103@zip.com.au> References: <20040722235111.GW849@usc.edu> <20040724155625.GA18884@astro.su.se> <20040726234912.GU19709@usc.edu> <4105ABB3.3060103@zip.com.au> Message-ID: <20040727015014.GC21084@usc.edu> On Tue, Jul 27, 2004 at 11:11:15AM +1000, Darren Tucker wrote: > Phil Dibowitz wrote: > >On Sat, Jul 24, 2004 at 05:56:25PM +0200, Sergio Gelato wrote: > >>Do you also log all input to the command? If not, what does this extra > >>logging > >>buy you over ordinary process accounting? > > > >Yes. That's all in the 'cmd' variable which is logged. > > And if someone does, eg, > echo "(cd /tmp; ls)" | ssh yourserver /bin/sh Then the security folks would see 'sh' and go to the pacct or auditd logs. Its not fool proof, but they find it makes their jobs easier, its more often they can look in only once place, I guess. I don't do security auditing, I just added the feature they requested. -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040726/e2a8f1d9/attachment.bin From bbraun at synack.net Wed Jul 28 09:44:38 2004 From: bbraun at synack.net (Rob Braun) Date: Tue, 27 Jul 2004 16:44:38 -0700 Subject: Potential Patch In-Reply-To: <1090880970.2086.74.camel@braveheart> References: <1090880970.2086.74.camel@braveheart> Message-ID: <20040727234438.GF25201@synack.net> On Mon, Jul 26, 2004 at 03:29:30PM -0700, Darren J Moffat wrote: > even specific to a given Solaris release. > > I've looked in the Darwin CVS and they don't have the Solaris BSM audit > patch applied there. However I can't see any reason why Apple would add > that patch unless they had the support. There is no real Darwin CVS anymore. The only link to a CVS server on the Apple Darwin web site is to OpenDarwin's cvs server, which isn't the same thing. The authoritative location for sources from Apple is here: http://www.opensource.apple.com/darwinsource/index.html This is the URL Apple gives on it's Darwin website. > So are you really 100% sure that the sshd you were looking at was the > one that Apple shipped ? I can confirm that Apple did indeed ship OpenSSH with the Solaris BSM support enabled. Rob From srinivas_gopaladasu at net.com Thu Jul 29 03:50:28 2004 From: srinivas_gopaladasu at net.com (Srinivas Gopaladasu) Date: Wed, 28 Jul 2004 10:50:28 -0700 Subject: Solaris password requirements not enforced Message-ID: <4107E764.9000301@net.com> Hi, The Solaris password requirements like a. no empty password b. minimum 6 chars etc for a regualr user are not enforced when a password expired user is changing password at the SSH login prompt. The version of openSSH I am using is 3.8.1 and Solaris 8 is where the sshd is running. Is anybody aware of this problem? Is there some configuration option I can use to enforce these password requirements? If its a bug, is there a patch already? I appreciate any help on this. Thanks Srini From johanwantwerp at excite.com Thu Jul 29 07:40:59 2004 From: johanwantwerp at excite.com (johanwantwerp at excite.com) Date: Wed, 28 Jul 2004 17:40:59 -0400 (EDT) Subject: restrict sshd connections to local network? Message-ID: <20040728214059.C1A3BB6F4@xprdmailfe14.nwk.excite.com> I'm using FreeBSD 4.10. Is there any way to configure sshd to restrict connections to the local network? _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From djm at mindrot.org Thu Jul 29 07:56:08 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Jul 2004 07:56:08 +1000 Subject: restrict sshd connections to local network? In-Reply-To: <20040728214059.C1A3BB6F4@xprdmailfe14.nwk.excite.com> References: <20040728214059.C1A3BB6F4@xprdmailfe14.nwk.excite.com> Message-ID: <410820F8.5060306@mindrot.org> johanwantwerp at excite.com wrote: > I'm using FreeBSD 4.10. Is there any way to configure sshd to restrict connections to the local network? hosts.allow or a packet filter -d From love_love at lovemedo.jp Thu Jul 29 17:16:58 2004 From: love_love at lovemedo.jp (=?ISO-2022-JP?B?GyRCPU89dyEmPGM6ShsoQg==?=) Date: Thu, 29 Jul 2004 16:16:58 +0900 Subject: =?iso-2022-jp?b?GyRCO341axsoQjUwMDAbJEIxXzBKPmUhIyUoJUMlQSQiGyhC?= =?iso-2022-jp?b?GyRCJGobKEI=?= Message-ID: <20040729071510.A7F5C27C18A@shitei.mindrot.org> ????????????????? ????????????????????????????????????? http://www.000-net.com/shosuto ??????????????? ?????????????????? ?????????????????????????????? ?????????????????? http://www.000-net.com/shosuto From dtucker at zip.com.au Thu Jul 29 21:28:22 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 29 Jul 2004 21:28:22 +1000 Subject: Solaris password requirements not enforced In-Reply-To: <4106AEFA.8030506@net.com> References: <4106AEFA.8030506@net.com> Message-ID: <4108DF56.9070502@zip.com.au> Srinivas Gopaladasu wrote: > The Solaris password requirements like > a. no empty password > b. minimum 6 chars > etc for a regular user are not enforced when a password expired user is > changing password at the SSH login prompt. It would appear that those restrictions are implemented in /usr/bin/passwd and not the PAM modules. Since sshd just calls pam_chauthtok(), if PAM allows changing to a short or empty password, then that's what happens. This is probably a bug or design misfeature in the Solaris PAM module (others, eg LinuxPAM, enforce such restrictions). You can disable PAM, or force sshd to use passwd instead of chauthtok with the attached patch. -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chauthtok.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040729/7049cfbd/attachment.ksh From dtucker at zip.com.au Thu Jul 29 21:28:22 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 29 Jul 2004 21:28:22 +1000 Subject: Solaris password requirements not enforced In-Reply-To: <4106AEFA.8030506@net.com> References: <4106AEFA.8030506@net.com> Message-ID: <4108DF56.9070502@zip.com.au> Srinivas Gopaladasu wrote: > The Solaris password requirements like > a. no empty password > b. minimum 6 chars > etc for a regular user are not enforced when a password expired user is > changing password at the SSH login prompt. It would appear that those restrictions are implemented in /usr/bin/passwd and not the PAM modules. Since sshd just calls pam_chauthtok(), if PAM allows changing to a short or empty password, then that's what happens. This is probably a bug or design misfeature in the Solaris PAM module (others, eg LinuxPAM, enforce such restrictions). You can disable PAM, or force sshd to use passwd instead of chauthtok with the attached patch. -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chauthtok.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040729/7049cfbd/attachment-0001.ksh From tjiva at ing.hj.se Sat Jul 31 00:43:30 2004 From: tjiva at ing.hj.se (Tjavdar Ivanov) Date: Fri, 30 Jul 2004 16:43:30 +0200 (CEST) Subject: Command-line parsing bug? Message-ID: Hi, There seems to be no way to scp a file containig ":" in its name, e.g., scp file-with-colon-in-its-name: user at localhost: results in err-msg: ssh: file-with-colon-in-its-name: Name or service not known Best regards, Tjavdar Tjavdar Ivanov Dept. of Mathematics, School of Engineering, J?nk?ping University, P.O Box 1026 : SE-551 11 J?nk?ping, Sweden tel. 036-15 78 56 (off), 036-10 04 08 (h), 0709-20 36 11 (mobile) From michal at pasternak.w.lub.pl Sat Jul 31 00:51:10 2004 From: michal at pasternak.w.lub.pl (Michal Pasternak) Date: Fri, 30 Jul 2004 16:51:10 +0200 Subject: Command-line parsing bug? In-Reply-To: References: Message-ID: <20040730145110.GA20343@pasternak.w.lub.pl> Tjavdar Ivanov [Fri, Jul 30, 2004 at 04:43:30PM +0200]: > > Hi, > > There seems to be no way to scp a file containig ":" in its name, e.g., > > scp file-with-colon-in-its-name: user at localhost: Try: scp ./file-with-colon-in-its-name: user at localhost: -- The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python. -- seen at http://www.paulgraham.com/gh.html From dtucker at zip.com.au Thu Jul 29 21:28:22 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 29 Jul 2004 21:28:22 +1000 Subject: Solaris password requirements not enforced In-Reply-To: <4106AEFA.8030506@net.com> References: <4106AEFA.8030506@net.com> Message-ID: <4108DF56.9070502@zip.com.au> Srinivas Gopaladasu wrote: > The Solaris password requirements like > a. no empty password > b. minimum 6 chars > etc for a regular user are not enforced when a password expired user is > changing password at the SSH login prompt. It would appear that those restrictions are implemented in /usr/bin/passwd and not the PAM modules. Since sshd just calls pam_chauthtok(), if PAM allows changing to a short or empty password, then that's what happens. This is probably a bug or design misfeature in the Solaris PAM module (others, eg LinuxPAM, enforce such restrictions). You can disable PAM, or force sshd to use passwd instead of chauthtok with the attached patch. -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chauthtok.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040729/7049cfbd/attachment-0002.ksh From thekiller101 at freesurf.fr Sat Jul 31 19:27:43 2004 From: thekiller101 at freesurf.fr (Teka) Date: Sat, 31 Jul 2004 11:27:43 +0200 Subject: Improvment Message-ID: <410B660F.1090004@freesurf.fr> Hi everybody, I love openssh but some features are missing in sftp. So i have implemented some control features on sftp, like "stay in home" features and bandwidth limit (upload / download). To limit the user on sftp only, i have started a new shell with config file to apply new settings available in sftp-server :-). In attachment, we can found the patch to apply to sftp-server.c, i'm developing under Linux (Debian) so it's possible that the code need some modification to improve the compatibility PS: sorry for my english, i'm a frenchi :-) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sftp-server.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040731/b2a6830b/attachment.ksh