From briang at OasisAdvancedEngineering.com Fri Nov 1 03:28:11 2002 From: briang at OasisAdvancedEngineering.com (Brian Genisio) Date: Thu, 31 Oct 2002 11:28:11 -0500 Subject: TCP_NODELAY in Cygwin port Message-ID: Hello SSH developers, I am sorry if this is not really a bug, and I am missing something, but I am running into an issue with port forwarding in SSH. I am using 3.4p1 of SSH on both sides. I am running the ssh daemon on a Slackware Linux 8.0 machine, and the ssh client is running in Cywgin version 1.3.13. The ssh client is creating about 7 port forwards in a mix of local and remote forwarding types. Everything with this setup works great. I have an application that runs on the linux side that port forwards to the Cygwin side, and sends a small control packet (4-8 bytes) at a rate of 30 times per second to an application on the Cygwin side. Because of this, the control application uses TCP_NODELAY in order to send it out as soon as it can. If I do not use SSH port forwarding, the control packets are sent at a steady rate. If I use the SSH port forwarding, the data is buffered, and sent in bursts. With this, the packets build up, so nothing is sent for 6 to 10 frames, and then all are sent at once. This makes for jerky control. I have looked into the OpenSSH release notes, and noticed that you added TCP_NODELAY on your endpoints for TCP port forwarding, though it does not seem like it is working properly. Unfortunately, I have been unable to tell weather the burst is happening between the sshd and the ssh, or the ssh and the application. As I mentioned, if my control program connects directly to the application, no buffering is used. Do you have any idea to why this is happening? Is there something wrong with the port forwarding implementation of SSH and TCP_NODELAY in Cygwin possibly? I ran both sides in debug mode, and it stated that TCP_NODELAY was indeed set. I'm perplexed. Thanks for your time, Brian Genisio From tim_maletic at yahoo.com Sat Nov 2 02:32:30 2002 From: tim_maletic at yahoo.com (Tim Maletic) Date: Fri, 1 Nov 2002 07:32:30 -0800 (PST) Subject: 3.5p1 hpux 11.X .ssh/environment ignored Message-ID: <20021101153230.76452.qmail@web12702.mail.yahoo.com> Am I missing something, or is this a bug? I'm using OpenSSH 3.5p1 on (non-trusted) HP-UX 11.00 and 11.11, compiled without pam support, but with the stock sshd_config (in particular, with privsep), and sshd ignores my client's ~/.ssh/environment file. It worked fine under previous versions. Thanks! -Tim __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ From bugzilla-daemon at mindrot.org Sat Nov 2 02:38:29 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Nov 2002 02:38:29 +1100 (EST) Subject: [Bug 423] New: Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20021101153829.5AA663D153@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 Summary: Workaround for pw change in privsep mode (3.5.p1) Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: michael_steffens at hp.com The attached patch provides a workaround for changing expired passwords on login with sshd running in privsep mode. It does so by delegating the the change dialog to a suid helper program. (Yes, yet another one :) The patch incorporates the HP-UX trusted system patch by Dan Wanek, submitted with [BUG 419]. I have tested this patch successfully on Linux (Debian with libpam0g 0.72-32) HP-UX 11.00 and 11.11, both trusted and non-trusted mode Solaris 2.7 It seems to be even a bit more robust than the builtin change routine for non-privsep mode, which crashes on trusted systems when using the dialog options for random generated passwords. (No idea why, unfortunately) The ssh-chauthtok-helper passed them flawlessly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Nov 2 02:40:21 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Nov 2002 02:40:21 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20021101154021.4E9E53D15F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2002-11-02 02:40 ------- Created an attachment (id=162) --> (http://bugzilla.mindrot.org/attachment.cgi?id=162&action=view) Patch: Workaround for pw change in privsep mode (3.5.p1) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Sat Nov 2 02:38:03 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 1 Nov 2002 09:38:03 -0600 (CST) Subject: 3.5p1 hpux 11.X .ssh/environment ignored In-Reply-To: <20021101153230.76452.qmail@web12702.mail.yahoo.com> Message-ID: sshd_config [..] #PermitUserEnvironment no This was in the OpenSSH 3.5 Announcement. Uncomment and change to yes. - Ben On Fri, 1 Nov 2002, Tim Maletic wrote: > Am I missing something, or is this a bug? I'm using > OpenSSH 3.5p1 on (non-trusted) HP-UX 11.00 and 11.11, > compiled without pam support, but with the stock > sshd_config (in particular, with privsep), and sshd > ignores my client's ~/.ssh/environment file. > > It worked fine under previous versions. > > Thanks! > -Tim > > __________________________________________________ > Do you Yahoo!? > HotJobs - Search new jobs daily now > http://hotjobs.yahoo.com/ > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Sat Nov 2 03:37:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Nov 2002 03:37:34 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20021101163734.70C843D15D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From mouring at eviladmin.org 2002-11-02 03:37 ------- *** Bug 419 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Nov 2 03:37:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Nov 2002 03:37:16 +1100 (EST) Subject: [Bug 419] HP-UX PAM problems with 3.5p1 Message-ID: <20021101163716.134E33D138@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=419 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From mouring at eviladmin.org 2002-11-02 03:36 ------- please don't open up multiple entries for a single bug *** This bug has been marked as a duplicate of 423 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Nov 2 07:36:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 2 Nov 2002 07:36:37 +1100 (EST) Subject: [Bug 424] New: scp mishandles files with spaces in names Message-ID: <20021101203637.B36D63D152@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=424 Summary: scp mishandles files with spaces in names Product: Portable OpenSSH Version: older versions Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: david at desjardins.org Reproduce as follows: % touch "123 456" % scp "123 456" 789 cp: copying multiple files, but last argument `789' is not a directory Try `cp --help' for more information. Using 'cp' works fine in this case. The same problem occurs in many other cases, e.g., when using scp -r with a directory which has a space in its name. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Darren.Moffat at Sun.COM Sat Nov 2 10:53:58 2002 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Fri, 1 Nov 2002 15:53:58 -0800 (PST) Subject: Selective blocking of password authentication In-Reply-To: <20021029004746.A32659@google.com> Message-ID: On Tue, 29 Oct 2002, Frank Cusack wrote: > If you're not willing to do the admin piece, then you can just lock > those users accounts, this typically prefaces their crypted passwd > entry with '!' thereby disabling password auth. However, this will *LK* in Solaris. > break as PAM modules are fixed to check this in the account module. > (Since the pubkey path correctly still does a PAM 'account' check.) > > I think Solaris 9 has this fixed, for one. Yes pam_unix_acct now checks that the hashed password string isn't *LK* so that locked accounts are locked for public key via ssh and for cron. -- Darren J Moffat From fcusack at fcusack.com Sat Nov 2 11:23:01 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 1 Nov 2002 16:23:01 -0800 Subject: Selective blocking of password authentication In-Reply-To: ; from Darren.Moffat@Sun.COM on Fri, Nov 01, 2002 at 03:53:58PM -0800 References: <20021029004746.A32659@google.com> Message-ID: <20021101162300.A15045@google.com> On Fri, Nov 01, 2002 at 03:53:58PM -0800, Darren J Moffat wrote: > On Tue, 29 Oct 2002, Frank Cusack wrote: > > > If you're not willing to do the admin piece, then you can just lock > > those users accounts, this typically prefaces their crypted passwd > > entry with '!' thereby disabling password auth. However, this will > > *LK* in Solaris. Isn't that broken? You can't unlock the person's account and restore their old password. (Which may be desirable, but I'm not convinced this is wise for the system to ENFORCE.) /fc From mozilla at attbi.com Sun Nov 3 08:33:53 2002 From: mozilla at attbi.com (Donnie Cranford) Date: Sat, 02 Nov 2002 15:33:53 -0600 Subject: OpenSSH CVS Message-ID: <3DC444C1.6060304@attbi.com> Hello I am trying to get some fixes that are in the OpenSSH CVS 3.5 branch I am having trouble figuring out the CVS tags that you guys use, could someone please tell me what the CVS tag for the 3.5 branch is and what you use as standards?? like cvs co -r OpenSSH_V_3_5 openssh should work but doesnt so what do you use as your tags.... Thanks again Donnie Cranford Senior Unix Systems Admin ING Americas From tim at multitalents.net Sun Nov 3 09:06:04 2002 From: tim at multitalents.net (Tim Rice) Date: Sat, 2 Nov 2002 14:06:04 -0800 (PST) Subject: OpenSSH CVS In-Reply-To: <3DC444C1.6060304@attbi.com> Message-ID: On Sat, 2 Nov 2002, Donnie Cranford wrote: > Hello > > I am trying to get some fixes that are in the OpenSSH CVS 3.5 branch > > I am having trouble figuring out the CVS tags that you guys use, could > someone please > > tell me what the CVS tag for the 3.5 branch is and what you use as > standards?? > > like cvs co -r OpenSSH_V_3_5 openssh should work but doesnt co -r V_3_5 openssh > so what do you use as your tags.... > > Thanks again > > Donnie Cranford > Senior Unix Systems Admin > ING Americas > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mozilla at attbi.com Sun Nov 3 09:11:17 2002 From: mozilla at attbi.com (Donnie Cranford) Date: Sat, 02 Nov 2002 16:11:17 -0600 Subject: OpenSSH CVS References: Message-ID: <3DC44D85.60508@attbi.com> So do all the openssh cvs mirrors hold the branches?? I am sure I tried that and it did not work with the CVS server you specify on the ports page Tim Rice wrote: >On Sat, 2 Nov 2002, Donnie Cranford wrote: > > > >>Hello >> >>I am trying to get some fixes that are in the OpenSSH CVS 3.5 branch >> >>I am having trouble figuring out the CVS tags that you guys use, could >>someone please >> >>tell me what the CVS tag for the 3.5 branch is and what you use as >>standards?? >> >>like cvs co -r OpenSSH_V_3_5 openssh should work but doesnt >> >> > >co -r V_3_5 openssh > > > >>so what do you use as your tags.... >> >>Thanks again >> >>Donnie Cranford >>Senior Unix Systems Admin >>ING Americas >> >> >> >>_______________________________________________ >>openssh-unix-dev at mindrot.org mailing list >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> >> > > > From tim at multitalents.net Sun Nov 3 09:05:22 2002 From: tim at multitalents.net (Tim Rice) Date: Sat, 2 Nov 2002 14:05:22 -0800 (PST) Subject: CVS Tags In-Reply-To: <200210300336.g9U3aCa03549@sunadmin1.us.americas.intranet> Message-ID: V3.5 has been tagged V_3_5 On Tue, 29 Oct 2002, Super-User wrote: > I am trying to bring down the latest CVS of the V3.5 branch, could someone please tell me what branch to use, and please update the website as to what you use for branches in the ports tree. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Sun Nov 3 09:05:44 2002 From: tim at multitalents.net (Tim Rice) Date: Sat, 2 Nov 2002 14:05:44 -0800 (PST) Subject: CVS Tags In-Reply-To: <200210300336.g9U3aCa03549@sunadmin1.us.americas.intranet> Message-ID: V3.5 has been tagged V_3_5 On Tue, 29 Oct 2002, Super-User wrote: > I am trying to bring down the latest CVS of the V3.5 branch, could someone please tell me what branch to use, and please update the website as to what you use for branches in the ports tree. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Sun Nov 3 09:54:02 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 2 Nov 2002 16:54:02 -0600 (CST) Subject: OpenSSH CVS In-Reply-To: <3DC44D85.60508@attbi.com> Message-ID: $ export CVSROOT=openssh at anoncvs.be.openbsd.org:/cvs $ export CVS_RSH=/usr/bin/ssh $ cvs co -r V_3_5 openssh seems to work just fine for me. - Ben On Sat, 2 Nov 2002, Donnie Cranford wrote: > So do all the openssh cvs mirrors hold the branches?? > > I am sure I tried that and it did not work with the CVS server you > specify on the ports page > > > > Tim Rice wrote: > > >On Sat, 2 Nov 2002, Donnie Cranford wrote: > > > > > > > >>Hello > >> > >>I am trying to get some fixes that are in the OpenSSH CVS 3.5 branch > >> > >>I am having trouble figuring out the CVS tags that you guys use, could > >>someone please > >> > >>tell me what the CVS tag for the 3.5 branch is and what you use as > >>standards?? > >> > >>like cvs co -r OpenSSH_V_3_5 openssh should work but doesnt > >> > >> > > > >co -r V_3_5 openssh > > > > > > > >>so what do you use as your tags.... > >> > >>Thanks again > >> > >>Donnie Cranford > >>Senior Unix Systems Admin > >>ING Americas > >> > >> > >> > >>_______________________________________________ > >>openssh-unix-dev at mindrot.org mailing list > >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > >> > >> > >> > > > > > > > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From godot at ulyssis.org Mon Nov 4 04:14:57 2002 From: godot at ulyssis.org (Danny De Cock) Date: Sun, 3 Nov 2002 18:14:57 +0100 (CET) Subject: playing with smartcard: rsa key upload? In-Reply-To: Message-ID: hi, the attachment contains a source file which solves the segmentation faults: a few type conflicts caused fatal misunderstandings between several routines of openssl and openssh. the current status is that the smartcard holds a private key and a corresponding certificate, and the server holds the key pair's public key, but when connecting to that server, no smartcard authentication seems to happen. any suggestions? `ssh -I 0 g -v` OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to g [192.168.1.5] port 22. debug1: Connection established. debug1: sc_get_keys called: reader id = 0 debug1: sc_read_pubkey() with cert id 45 debug1: fingerprint 1024 d7:32:98:fa:bc:33:3f:26:fb:ab:09:66:14:5e:a4:4a debug1: identity file /home/decockd/.ssh/identity type -1 debug1: identity file /home/decockd/.ssh/id_rsa type 1 debug1: identity file /home/decockd/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-1 debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.5p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 124/256 debug1: bits set: 1605/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'g' is known and matches the RSA host key. debug1: Found key in /home/decockd/.ssh/known_hosts:4 debug1: bits set: 1597/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is publickey debug1: try pubkey: smartcard key debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: try privkey: /home/decockd/.ssh/identity debug1: try pubkey: /home/decockd/.ssh/id_rsa debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: try privkey: /home/decockd/.ssh/id_dsa debug1: next auth method to try is keyboard-interactive debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is password decockd at g's password: On Wed, 30 Oct 2002, Danny De Cock wrote: > hi, > > some additional information after some straightforward debugging > learns me this: > > the segmentation fault occurs in the openssl-package source file > crypto/engine/engine_lib.c. more precisely, it happens the second time > ENGINE_init(...) is called when trying to accomplish the assignment: > if((e->funct_ref == 0) && e->init){ > /* This is the first functional reference and the engine > * requires initialisation so we do it now. */ > to_return = e->init(); > } > > so the first time ENGINE_init(...) is executed, there is no problem, and > the second time is triggered by sc_read_pubkey(), which calls > RSA_set_method. it is this RSA_set_method that triggers the segmentation > fault. > > for the record: I am using the binaries produced by opensc-snap-20021029, > openssl-engine-0.9.6g.tar.gz and openssh-3.5p1.tar.gz. > > cu, danny. > > On Wed, 30 Oct 2002, Danny De Cock wrote: > > > hi, > > > > my the subscription to this list is still in progress, i.e., could you > > include my emailaddress when replying to this email. > > > > I am using the opensc-cvs-snapshot of october 29th, in combination > > with openssh 3.5p1 on a woody debian machine with pcsclite-1.1.2, and > > have been trying to get a gemplus gpk16000 smartcard working with > > openssh. > > > > the problem I am faced with is a segmentation fault of a command such > > as `ssh -I 0 server` > > > > the commands I have been using are these: > > > > pkcs15-init -dddddd -E -C > > pkcs15-init -dddddd -P -a 45 -i 45 > > pkcs15-init -dddddd -S privkey.pem -a 45 -i 45 > > pkcs15-init -dddddd -X cert.pem > > ssh -I 0 192.168.1.2 -v > > > > the log file /var/log/auth.log of the other machine indicates this after > > the ssh-client has failed: > > Oct 30 13:00:13 g sshd[24750]: Did not receive identification string from 192.168.1.11 > > > > fyi: the led of the smartcard reader starts to blink just before the > > segmentation fault. > > > > does any of you have any idea how to solve this problem? > > > > many thanks, danny. > > > > --------------------------- > > > > the first four these commands have accomplished their tasks > > succesfully: > > > > > > Connecting to card in reader Towitoko Chipdrive Reader 0 0... > > Using card driver: Gemplus GPK driver > > Trying to find a PKCS#15 compatible card... > > Found OpenSC Card! > > Card has 1 certificate(s). > > > > X.509 Certificate [Certificate] > > Flags : 2 > > Authority: no > > Path : 3F0050159000 > > ID : 45 > > > > Card has 1 private key(s). > > > > Private RSA Key [Private Key] > > Com. Flags : 1D > > Usage : [0x4], sign > > Access Flags: [0x0] > > ModLength : 1024 > > Key ref : 0 > > Native : yes > > Path : 3F0050150006 > > Auth ID : 45 > > ID : 45 > > > > Card has 2 PIN code(s). > > > > PIN [Security Officer PIN] > > Com. Flags: 0x3 > > Auth ID : FF > > Flags : [0xB2], local, initialized, needs-padding, soPin > > Length : 6..8 > > Pad char : 0x00 > > Reference : 8 > > Type : 1 > > Path : 3F005015 > > > > PIN [] > > Com. Flags: 0x3 > > Auth ID : 45 > > Flags : [0x32], local, initialized, needs-padding > > Length : 4..8 > > Pad char : 0x00 > > Reference : 12 > > Type : 1 > > Path : 3F005015 > > > > but the fifth command fails badly: > > > > ssh -I 0 192.168.1.2 -v > > OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f > > debug1: Reading configuration data /usr/local/etc/ssh_config > > debug1: Rhosts Authentication disabled, originating port will not be trusted. > > debug1: ssh_connect: needpriv 0 > > debug1: Connecting to lien [192.168.1.2] port 22. > > debug1: Connection established. > > debug1: sc_get_keys called: id = 0 > > debug1: sc_read_pubkey() with cert id 45 > > Segmentation fault > > > > > > > On Thu, 17 Oct 2002, Andreas Hasenack wrote: > > > > > > > Is there a tool to upload an openssh rsa key to a smart card so that I > > > > can use it with ssh -I later on? Should I just upload it as a regular > > > > file? Any pointers to some documentation explaining how to do this with > > > > openssh? > > > > > > The current SC related code in openssh is a bit absurd anyway. > > > I'm currently rewriting the code into some more generic, > > > like pkcs#11 support. After this you can use opensc-pkcs11.so > > > to upload your keys. > > > > > > Hopefully Theo and the rest of OpenSSH guys are willing to > > > ditch the current code base, ugly sectok and less ugly opensc > > > support entirely. > > > > > > -Antti > > > > > > _______________________________________________ > > > openssh-unix-dev at mindrot.org mailing list > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > > > > -- ----------------------------------------------------------------------------- Don't kid yourself. Little is relevant, and nothing lasts forever. ----------------------------------------------------------------------------- Mail : Danny.DeCock at esat.kuleuven.ac.be daniel.decock at postbox.be WWW : http://ace.ulyssis.org/~godot godot at advalvas.be -------------- next part -------------- /* * Copyright (c) 2002 Juha Yrj?l?. All rights reserved. * Copyright (c) 2001 Markus Friedl. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include "includes.h" #if defined(SMARTCARD) && defined(USE_OPENSC) #include #include #include #include #include "key.h" #include "log.h" #include "xmalloc.h" #include "readpass.h" #include "scard.h" #if OPENSSL_VERSION_NUMBER < 0x00907000L && defined(CRYPTO_LOCK_ENGINE) #define USE_ENGINE #define RSA_get_default_method RSA_get_default_openssl_method #else #endif #ifdef USE_ENGINE #include #define sc_get_rsa sc_get_engine #else #define sc_get_rsa sc_get_rsa_method #endif static int sc_reader_id; static sc_context_t *ctx = NULL; static sc_card_t *card = NULL; static sc_pkcs15_card_t *p15card = NULL; static char *sc_pin = NULL; struct sc_priv_data { struct sc_pkcs15_id cert_id; int ref_count; }; void sc_close(void) { if (p15card) { sc_pkcs15_unbind(p15card); p15card = NULL; } if (card) { sc_disconnect_card(card, 0); card = NULL; } if (ctx) { sc_release_context(ctx); ctx = NULL; } } static int sc_init(void) { int r; r = sc_establish_context(&ctx, "openssh"); if (r) goto err; r = sc_connect_card(ctx->reader[sc_reader_id], 0, &card); if (r) goto err; r = sc_pkcs15_bind(card, &p15card); if (r) goto err; return 0; err: sc_close(); return r; } /* private key operations */ static int sc_prkey_op_init(RSA *rsa, struct sc_pkcs15_object **key_obj_out) { int r; struct sc_priv_data *priv; struct sc_pkcs15_object *key_obj; struct sc_pkcs15_prkey_info *key; struct sc_pkcs15_object *pin_obj; struct sc_pkcs15_pin_info *pin; priv = (struct sc_priv_data *) RSA_get_app_data(rsa); if (priv == NULL) return -1; if (p15card == NULL) { sc_close(); r = sc_init(); if (r) { error("SmartCard init failed: %s", sc_strerror(r)); goto err; } } r = sc_pkcs15_find_prkey_by_id(p15card, &priv->cert_id, &key_obj); if (r) { error("Unable to find private key from SmartCard: %s", sc_strerror(r)); goto err; } key = key_obj->data; r = sc_pkcs15_find_pin_by_auth_id(p15card, &key_obj->auth_id, &pin_obj); if (r) { error("Unable to find PIN object from SmartCard: %s", sc_strerror(r)); goto err; } pin = pin_obj->data; r = sc_lock(card); if (r) { error("Unable to lock smartcard: %s", sc_strerror(r)); goto err; } if (sc_pin != NULL) { r = sc_pkcs15_verify_pin(p15card, pin, sc_pin, strlen(sc_pin)); if (r) { sc_unlock(card); error("PIN code verification failed: %s", sc_strerror(r)); goto err; } } *key_obj_out = key_obj; return 0; err: sc_close(); return -1; } static int sc_private_decrypt(int flen, u_char *from, u_char *to, RSA *rsa, int padding) { struct sc_pkcs15_object *key_obj; int r; if (padding != RSA_PKCS1_PADDING) return -1; r = sc_prkey_op_init(rsa, &key_obj); if (r) return -1; r = sc_pkcs15_decipher(p15card, key_obj, 0, from, flen, to, flen); sc_unlock(card); if (r < 0) { error("sc_pkcs15_decipher() failed: %s", sc_strerror(r)); goto err; } return r; err: sc_close(); return -1; } static int sc_sign(int type, u_char *m, unsigned int m_len, unsigned char *sigret, unsigned int *siglen, RSA *rsa) { struct sc_pkcs15_object *key_obj; int r; unsigned long flags = 0; r = sc_prkey_op_init(rsa, &key_obj); if (r) return -1; /* FIXME: length of sigret correct? */ /* FIXME: check 'type' and modify flags accordingly */ flags = SC_ALGORITHM_RSA_PAD_PKCS1 | SC_ALGORITHM_RSA_HASH_SHA1; r = sc_pkcs15_compute_signature(p15card, key_obj, flags, m, m_len, sigret, RSA_size(rsa)); sc_unlock(card); if (r < 0) { error("sc_pkcs15_compute_signature() failed: %s", sc_strerror(r)); goto err; } *siglen = r; return 1; err: sc_close(); return 0; } static int sc_private_encrypt(int flen, u_char *from, u_char *to, RSA *rsa, int padding) { error("Private key encryption not supported"); return -1; } /* called on free */ static int (*orig_finish)(RSA *rsa) = NULL; static int sc_finish(RSA *rsa) { struct sc_priv_data *priv; priv = RSA_get_app_data(rsa); priv->ref_count--; if (priv->ref_count == 0) { free(priv); sc_close(); } if (orig_finish) orig_finish(rsa); return 1; } /* engine for overloading private key operations */ static ENGINE * sc_get_rsa_method(void) {static ENGINE *engine=NULL; static RSA_METHOD smart_rsa; const RSA_METHOD *def = RSA_get_default_method(); /* use the OpenSSL version */ memcpy(&smart_rsa, def, sizeof(smart_rsa)); smart_rsa.name = "opensc"; /* overload */ smart_rsa.rsa_priv_enc = sc_private_encrypt; smart_rsa.rsa_priv_dec = sc_private_decrypt; smart_rsa.rsa_sign = sc_sign; /* save original */ orig_finish = def->finish; if (!ENGINE_init(engine)){ return 0; } smart_rsa.finish = sc_finish; if (!ENGINE_init(engine)){ return 0; } ENGINE_set_RSA(engine,&smart_rsa); return &smart_rsa; return engine; } #ifdef USE_ENGINE static ENGINE * sc_get_engine(void) { static ENGINE *smart_engine = NULL; if ((smart_engine = ENGINE_new()) == NULL) fatal("ENGINE_new failed"); ENGINE_set_id(smart_engine, "opensc"); ENGINE_set_name(smart_engine, "OpenSC"); ENGINE_set_RSA(smart_engine, ENGINE_get_RSA(sc_get_rsa_method())); ENGINE_set_DSA(smart_engine, DSA_get_default_openssl_method()); ENGINE_set_DH(smart_engine, DH_get_default_openssl_method()); ENGINE_set_RAND(smart_engine, RAND_SSLeay()); ENGINE_set_BN_mod_exp(smart_engine, BN_mod_exp); return smart_engine; } #endif static void convert_rsa_to_rsa1(Key * in, Key * out) { struct sc_priv_data *priv; ENGINE *engine=NULL; out->rsa->flags = in->rsa->flags; out->flags = in->flags; if (!ENGINE_init(engine)){ return 0; } ENGINE_set_RSA(engine,RSA_get_method(in->rsa)); RSA_set_method(out->rsa,engine); BN_copy(out->rsa->n, in->rsa->n); BN_copy(out->rsa->e, in->rsa->e); priv = RSA_get_app_data(in->rsa); priv->ref_count++; RSA_set_app_data(out->rsa, priv); return; } static int sc_read_pubkey(Key * k, const struct sc_pkcs15_object *cert_obj) { int r; sc_pkcs15_cert_t *cert = NULL; struct sc_priv_data *priv = NULL; sc_pkcs15_cert_info_t *cinfo = cert_obj->data; X509 *x509 = NULL; EVP_PKEY *pubkey = NULL; u8 *p; char *tmp; debug("sc_read_pubkey() with cert id %02X", cinfo->id.value[0]); r = sc_pkcs15_read_certificate(p15card, cinfo, &cert); if (r) { log("Certificate read failed: %s", sc_strerror(r)); goto err; } x509 = X509_new(); if (x509 == NULL) { r = -1; goto err; } p = cert->data; if (!d2i_X509(&x509, &p, cert->data_len)) { log("Unable to parse X.509 certificate"); r = -1; goto err; } sc_pkcs15_free_certificate(cert); cert = NULL; pubkey = X509_get_pubkey(x509); X509_free(x509); x509 = NULL; if (pubkey->type != EVP_PKEY_RSA) { log("Public key is of unknown type"); r = -1; goto err; } k->rsa = EVP_PKEY_get1_RSA(pubkey); EVP_PKEY_free(pubkey); k->rsa->flags |= RSA_FLAG_SIGN_VER; { ENGINE *e=sc_get_rsa_method(); RSA_set_method(k->rsa, e); } priv = xmalloc(sizeof(struct sc_priv_data)); priv->cert_id = cinfo->id; priv->ref_count = 1; RSA_set_app_data(k->rsa, priv); k->flags = KEY_FLAG_EXT; tmp = key_fingerprint(k, SSH_FP_MD5, SSH_FP_HEX); debug("fingerprint %d %s", key_size(k), tmp); xfree(tmp); return 0; err: if (cert) sc_pkcs15_free_certificate(cert); if (pubkey) EVP_PKEY_free(pubkey); if (x509) X509_free(x509); return r; } Key ** sc_get_keys(const char *id, const char *pin) { Key *k, **keys; int i, r, real_count = 0, key_count; sc_pkcs15_id_t cert_id; sc_pkcs15_object_t *certs[32]; char *buf = xstrdup(id), *p; debug("sc_get_keys called: reader id = %s", id); if (sc_pin != NULL) xfree(sc_pin); sc_pin = (pin == NULL) ? NULL : xstrdup(pin); cert_id.len = 0; if ((p = strchr(buf, ':')) != NULL) { *p = 0; p++; sc_pkcs15_hex_string_to_id(p, &cert_id); } r = sscanf(buf, "%d", &sc_reader_id); xfree(buf); if (r != 1) goto err; if (p15card == NULL) { sc_close(); r = sc_init(); if (r) { error("Smartcard init failed: %s", sc_strerror(r)); goto err; } } if (cert_id.len) { r = sc_pkcs15_find_cert_by_id(p15card, &cert_id, &certs[0]); if (r < 0) goto err; key_count = 1; } else { r = sc_pkcs15_get_objects(p15card, SC_PKCS15_TYPE_CERT_X509, certs, 32); if (r == 0) { log("No certificates found on smartcard"); r = -1; goto err; } else if (r < 0) { error("Certificate enumeration failed: %s", sc_strerror(r)); goto err; } key_count = r; } /* FIXME: only keep entries with a corresponding private key */ keys = xmalloc(sizeof(Key *) * (key_count*2+1)); for (i = 0; i < key_count; i++) { k = key_new(KEY_RSA); if (k == NULL) break; r = sc_read_pubkey(k, certs[i]); if (r) { error("sc_read_pubkey failed: %s", sc_strerror(r)); key_free(k); continue; } keys[real_count] = k; real_count++; k = key_new(KEY_RSA1); if (k == NULL){ break; } convert_rsa_to_rsa1(keys[real_count-1], k); keys[real_count] = k; real_count++; } keys[real_count] = NULL; return keys; err: sc_close(); return NULL; } int sc_put_key(Key *prv, const char *id) { error("key uploading not yet supported"); return -1; } #endif /* SMARTCARD */ From markus at openbsd.org Mon Nov 4 20:28:49 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 4 Nov 2002 10:28:49 +0100 Subject: playing with smartcard: rsa key upload? In-Reply-To: References: Message-ID: <20021104092849.GA17474@folly> On Sun, Nov 03, 2002 at 06:14:57PM +0100, Danny De Cock wrote: > the attachment contains a source file which solves the segmentation > faults: a few type conflicts caused fatal misunderstandings between > several routines of openssl and openssh. no, 'fatal misunderstandings' is wrong. OpenSSL has 2 different interfaces for overloading the RSA routines (engine and non-engine). check scard.c for a way to work around this problem (->USE_ENGINE). (btw, please send diffs instead of complete files). -m From bugzilla-daemon at mindrot.org Mon Nov 4 21:47:08 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 4 Nov 2002 21:47:08 +1100 (EST) Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <20021104104708.912E03D14E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2002-11-04 21:47 ------- Created an attachment (id=163) --> (http://bugzilla.mindrot.org/attachment.cgi?id=163&action=view) Non-privsep pw change failure on HP-UX trusted systems Found why the password change dialog in non-privsep mode on a HP-UX 11.x trusted system fails when the user selects random password options. It's because OpenSSH's log function interferes with a log stub in /usr/lib/libsec.2: Program received signal SIGSEGV, Segmentation fault. 0xc00fadf0 in _doprnt+0x188 () from /usr/lib/libc.2 (gdb) bt #0 0xc00fadf0 in _doprnt+0x188 () from /usr/lib/libc.2 #1 0xc010b80c in vsnprintf+0x54 () from /usr/lib/libc.2 #2 0x4f94c in do_log (level=SYSLOG_LEVEL_INFO, fmt=0xcb000000 , args=0x7f7f417c) at log.c:387 #3 0x4f20c in log (fmt=0xcb000000 ) at log.c:135 #4 0xc0164360 in passlen+0xa0 () from /usr/lib/libsec.2 #5 0xc1e8b2a4 in pwd_get_random+0x69c () from /usr/lib/security/libpam_unix.1 #6 0xc1e8ca28 in chauthtok_get_pwd+0x78 () from /usr/lib/security/libpam_unix.1 #7 0xc1e8139c in get_newpasswd+0x4a4 () from /usr/lib/security/libpam_unix.1 #8 0xc1e7f5fc in __update_authtok+0x30c () from /usr/lib/security/libpam_unix.1 #9 0xc1e7e6d0 in pam_sm_chauthtok+0xf8 () from /usr/lib/security/libpam_unix.1 #10 0xc06571b0 in pam_chauthtok+0x100 () from /usr/lib/libpam.1 #11 0x22660 in do_pam_chauthtok () at auth-pam.c:422 #12 0x2ea44 in do_login (s=0x40015fd0, command=0x0) at session.c:755 #13 0x2e594 in do_exec_pty (s=0x40015fd0, command=0x0) at session.c:616 #14 0x2e898 in do_exec (s=0x40015fd0, command=0x0) at session.c:709 #15 0x2df68 in do_authenticated1 (authctxt=0x4001cb90) at session.c:402 #16 0x2daec in do_authenticated (authctxt=0x4001cb90) at session.c:221 #17 0x16704 in main (ac=1, av=0x7f7e07f4) at sshd.c:1528 Renaming function log() to sshlog() in log.h resolves this conflict. See attached patch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Nov 5 04:44:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 5 Nov 2002 04:44:17 +1100 (EST) Subject: [Bug 425] New: Integer overflow in mm_zalloc Message-ID: <20021104174417.DEBB13D13D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=425 Summary: Integer overflow in mm_zalloc Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: siw at goneko.de 3.5p1 is better than 3.4p1, but still not perfect (on platforms where size_t is larger than u_int). This patch should fix it, although I can't test it: --- openssh-3.5p1/monitor.c-orig Fri Sep 27 05:26:02 2002 +++ openssh-3.5p1/monitor.c Mon Nov 4 18:06:24 2002 @@ -1551,7 +1551,7 @@ void * mm_zalloc(struct mm_master *mm, u_int ncount, u_int size) { - size_t len = size * ncount; + size_t len = (size_t) size * ncount; void *address; if (len == 0 || ncount > SIZE_T_MAX / size) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From GaryF at livevault.com Wed Nov 6 02:33:00 2002 From: GaryF at livevault.com (Gary Fernandez) Date: Tue, 5 Nov 2002 10:33:00 -0500 Subject: [PATCH] Add readonly mode to scp, sftp_server Message-ID: <66E3249CDB0D774DA1A0372C870DE9F101BE12F2@corp3.netint.com> This patch adds a readonly mode to scp and sftp_server. This allows clients to only read files from the server, but not to write them. Patch is based on OpenSSH 3.4p1 *** scp.c@@\main\1 Tue Oct 1 17:25:16 2002 --- scp.c Wed Oct 2 06:05:14 2002 *************** *** 122,127 **** --- 122,130 ---- /* This is set to zero if the progressmeter is not desired. */ int showprogress = 1; + /* deny client write operations */ + int readonly = 0; + /* This is the program to execute for the secured connection. ("ssh" or -S) */ char *ssh_program = _PATH_SSH_PROGRAM; *************** *** 307,312 **** --- 310,319 ---- exit(errs != 0); } if (tflag) { + if (readonly) { + run_err("permission denied"); + exit(1); + } /* Receive data. */ sink(argc, argv); exit(errs != 0); *** sftp-server.c@@\main\1 Tue Oct 1 17:27:26 2002 --- sftp-server.c Tue Nov 5 10:07:54 2002 *************** *** 52,57 **** --- 52,60 ---- /* Version of client */ int version; + /* deny client write operations */ + int readonly = 0; + /* portable attibutes, etc. */ typedef struct Stat Stat; *************** *** 390,395 **** --- 393,404 ---- pflags = get_int(); /* portable flags */ a = get_attrib(); flags = flags_from_portable(pflags); + if (((flags & O_ACCMODE) == O_RDWR) || + ((flags & O_ACCMODE) == O_WRONLY)) { + status = SSH2_FX_PERMISSION_DENIED; + send_status(id, status); + return; + } mode = (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) ? a->perm : 0666; TRACE("open id %u name %s flags %d mode 0%o", id, name, pflags, mode); fd = open(name, flags, mode); *************** *** 587,592 **** --- 596,606 ---- id = get_int(); name = get_string(NULL); a = get_attrib(); + if (readonly) { + status = SSH2_FX_PERMISSION_DENIED; + send_status(id, status); + return; + } TRACE("setstat id %u name %s", id, name); if (a->flags & SSH2_FILEXFER_ATTR_SIZE) { ret = truncate(name, a->size); *************** *** 802,807 **** --- 816,826 ---- id = get_int(); name = get_string(NULL); + if (readonly) { + status = SSH2_FX_PERMISSION_DENIED; + send_status(id, status); + return; + } TRACE("remove id %u name %s", id, name); ret = unlink(name); status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; *************** *** 820,825 **** --- 839,849 ---- id = get_int(); name = get_string(NULL); a = get_attrib(); + if (readonly) { + status = SSH2_FX_PERMISSION_DENIED; + send_status(id, status); + return; + } mode = (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) ? a->perm & 0777 : 0777; TRACE("mkdir id %u name %s mode 0%o", id, name, mode); *************** *** 838,843 **** --- 862,872 ---- id = get_int(); name = get_string(NULL); + if (readonly) { + status = SSH2_FX_PERMISSION_DENIED; + send_status(id, status); + return; + } TRACE("rmdir id %u name %s", id, name); ret = rmdir(name); status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; *************** *** 881,886 **** --- 910,920 ---- id = get_int(); oldpath = get_string(NULL); newpath = get_string(NULL); + if (readonly) { + status = SSH2_FX_PERMISSION_DENIED; + send_status(id, status); + return; + } TRACE("rename id %u old %s new %s", id, oldpath, newpath); /* fail if 'newpath' exists */ if (stat(newpath, &st) == -1) { *************** *** 927,932 **** --- 970,980 ---- id = get_int(); oldpath = get_string(NULL); newpath = get_string(NULL); + if (readonly) { + status = SSH2_FX_PERMISSION_DENIED; + send_status(id, status); + return; + } TRACE("symlink id %u old %s new %s", id, oldpath, newpath); /* fail if 'newpath' exists */ if (stat(newpath, &st) == -1) { From GaryF at livevault.com Wed Nov 6 02:46:16 2002 From: GaryF at livevault.com (Gary Fernandez) Date: Tue, 5 Nov 2002 10:46:16 -0500 Subject: [PATCH] Add getlink command to sftp Message-ID: <66E3249CDB0D774DA1A0372C870DE9F101BE12F3@corp3.netint.com> One of the features missing in sftp is the ability to transfer a symlink. This patch adds a new command to sftp which performs this transfer. Note that it uses messages that already exist in the protocol between client and server. This diff is based on OpenSSH 3.4p1. *** sftp-client.c@@\main\1 Tue Oct 1 17:26:20 2002 --- sftp-client.c Wed Oct 23 15:57:34 2002 *************** *** 666,672 **** status = get_status(conn->fd_in, id); if (status != SSH2_FX_OK) ! error("Couldn't rename file \"%s\" to \"%s\": %s", oldpath, newpath, fx2txt(status)); return(status); --- 666,672 ---- status = get_status(conn->fd_in, id); if (status != SSH2_FX_OK) ! error("Couldn't symlink file \"%s\" to \"%s\": %s", oldpath, newpath, fx2txt(status)); return(status); *************** *** 673,679 **** } char * ! do_readlink(struct sftp_conn *conn, char *path) { Buffer msg; u_int type, expected_id, count, id; --- 673,679 ---- } char * ! do_readlink(struct sftp_conn *conn, char *path, Attrib *attrib) { Buffer msg; u_int type, expected_id, count, id; *************** *** 712,717 **** --- 712,720 ---- debug3("SSH_FXP_READLINK %s -> %s", path, filename); + if (attrib != NULL) + *attrib = *a; + xfree(longname); buffer_free(&msg); *************** *** 719,724 **** --- 722,774 ---- return(filename); } + int + do_getlink(struct sftp_conn *conn, char *path) + { + char *dest; + u_int status = 0; + int ret; + struct stat statb; + char *filename; + Attrib *a; + Attrib attrib; + + a = do_lstat(conn, path, 0); + if (a == NULL || !S_ISLNK(a->perm)) { + if (a != NULL) + error("%s is not a symlink", path); + return(-1); + } + + dest = do_readlink(conn, path, &attrib); + if (dest == NULL) + return(-1); + filename = strrchr(path, '/'); + if (filename == NULL) + filename = path; + else + filename += 1; + if (lstat(filename, &statb) == 0) { + error("Name \"%s\" already exists", filename); + return(-1); + } + else { + ret = symlink(dest, filename); + status = (ret == -1) ? errno : 0; + if (status != 0) + error("Couldn't create symlink \"%s\": %s", filename, + strerror(status)); + if (getuid() == 0 || geteuid() == 0) { + ret = lchown(filename, attrib.uid, attrib.gid); + status = (ret == -1) ? errno : 0; + if (status != 0) + error("Couldn't set ownership on symlink \"%s\": %s", filename, + strerror(status)); + } + } + return(status); + } + static void send_read_request(int fd_out, u_int id, u_int64_t offset, u_int len, char *handle, u_int handle_len) *** sftp.1@@\main\1 Tue Oct 1 17:26:04 2002 --- sftp.1 Wed Oct 2 07:59:00 2002 *************** *** 185,190 **** --- 185,199 ---- .Fl P flag is specified, then the file's full permission and access time are copied too. + .It Xo Ic getlink + .Ar remote-path + .Xc + Retrieve the + .Ar remote-path + and store it on the local machine. This is used to retrieve a symlink + rather than the target of the symlink. Since a local + path name is not specified, the symlink is given the same name it has on the + remote machine. .It Ic help Display help text. .It Ic lls Op Ar ls-options Op Ar path *** sftp-int.c@@\main\1 Tue Oct 1 17:27:02 2002 --- sftp-int.c Wed Oct 2 06:21:10 2002 *************** *** 74,79 **** --- 74,80 ---- #define I_SHELL 20 #define I_SYMLINK 21 #define I_VERSION 22 + #define I_GETLINK 23 struct CMD { const char *c; *************** *** 91,96 **** --- 92,98 ---- { "exit", I_QUIT }, { "get", I_GET }, { "mget", I_GET }, + { "getlink", I_GETLINK }, { "help", I_HELP }, { "lcd", I_LCHDIR }, { "lchdir", I_LCHDIR }, *************** *** 126,131 **** --- 128,134 ---- printf("chown own path Change owner of file 'path' to 'own'\n"); printf("help Display this help text\n"); printf("get remote-path [local-path] Download file\n"); + printf("getlink remote-path Download symlink\n"); printf("lls [ls-options [path]] Display local directory listing\n"); printf("ln oldpath newpath Symlink remote file\n"); printf("lmkdir path Create local directory\n"); *************** *** 582,587 **** --- 585,591 ---- case I_CHDIR: case I_LCHDIR: case I_LMKDIR: + case I_GETLINK: /* Get pathname (mandatory) */ if (get_pathname(&cp, path1)) return(-1); *************** *** 682,687 **** --- 686,695 ---- case I_SYMLINK: path2 = make_absolute(path2, *pwd); err = do_symlink(conn, path1, path2); + break; + case I_GETLINK: + path1 = make_absolute(path1, *pwd); + err = do_getlink(conn, path1); break; case I_RM: path1 = make_absolute(path1, *pwd); *** sftp-client.h@@\main\1 Tue Oct 1 17:26:26 2002 --- sftp-client.h Wed Oct 2 06:11:40 2002 *************** *** 90,97 **** /* Rename 'oldpath' to 'newpath' */ int do_symlink(struct sftp_conn *, char *, char *); /* Return target of symlink 'path' - caller must free result */ ! char *do_readlink(struct sftp_conn *, char *); /* XXX: add callbacks to do_download/do_upload so we can do progress meter */ --- 90,100 ---- /* Rename 'oldpath' to 'newpath' */ int do_symlink(struct sftp_conn *, char *, char *); + /* Download symlink 'path' */ + int do_getlink(struct sftp_conn *, char *); + /* Return target of symlink 'path' - caller must free result */ ! char *do_readlink(struct sftp_conn *, char *, Attrib *); /* XXX: add callbacks to do_download/do_upload so we can do progress meter */ *** sftp-server.c@@\main\1 Tue Oct 1 17:27:26 2002 --- sftp-server.c Tue Nov 5 10:07:54 2002 *************** *** 604,610 **** status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { ! ret = chown(name, a->uid, a->gid); if (ret == -1) status = errno_to_portable(errno); } --- 618,624 ---- status = errno_to_portable(errno); } if (a->flags & SSH2_FILEXFER_ATTR_UIDGID) { ! ret = lchown(name, a->uid, a->gid); if (ret == -1) status = errno_to_portable(errno); } *************** *** 907,915 **** send_status(id, errno_to_portable(errno)); else { Stat s; ! link[len] = '\0'; attrib_clear(&s.attrib); s.name = s.long_name = link; send_names(id, 1, &s); } --- 941,958 ---- send_status(id, errno_to_portable(errno)); else { Stat s; ! struct stat st; ! int status; link[len] = '\0'; attrib_clear(&s.attrib); + + status = lstat(path, &st); + if (status == 0) { + stat_to_attrib(&st, &s.attrib); + } + else { + send_status(id, errno_to_portable(errno)); + } s.name = s.long_name = link; send_names(id, 1, &s); } From GaryF at livevault.com Wed Nov 6 02:48:22 2002 From: GaryF at livevault.com (Gary Fernandez) Date: Tue, 5 Nov 2002 10:48:22 -0500 Subject: [PATCH] fix sftp to preserve permissions and uid/gid Message-ID: <66E3249CDB0D774DA1A0372C870DE9F101BE12F4@corp3.netint.com> Sftp fails to correctly preserve permissions when fetching a file. It adds write permission for the owner (presumably so it can write the file). Sftp also fails to preserve the uid/gid. Added code so that if is running as root, uid and gid are preserved. patch is based on Openssh 3.4p1. *** sftp-client.c@@\main\1 Tue Oct 1 17:26:20 2002 --- sftp-client.c Tue Nov 5 10:22:52 2002 *************** *** 666,672 **** status = get_status(conn->fd_in, id); if (status != SSH2_FX_OK) ! error("Couldn't rename file \"%s\" to \"%s\": %s", oldpath, newpath, fx2txt(status)); return(status); --- 666,672 ---- status = get_status(conn->fd_in, id); if (status != SSH2_FX_OK) ! error("Couldn't symlink file \"%s\" to \"%s\": %s", oldpath, newpath, fx2txt(status)); return(status); *************** *** 746,752 **** int local_fd, status, num_req, max_req, write_error; int read_error, write_errno; u_int64_t offset, size; ! u_int handle_len, mode, type, id, buflen; struct request { u_int id; u_int len; --- 796,802 ---- int local_fd, status, num_req, max_req, write_error; int read_error, write_errno; u_int64_t offset, size; ! u_int handle_len, mode, type, id, buflen, savemode; struct request { u_int id; u_int len; *************** *** 763,773 **** return(-1); /* XXX: should we preserve set[ug]id? */ ! if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) mode = S_IWRITE | (a->perm & 0777); ! else mode = 0666; ! if ((a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) && (a->perm & S_IFDIR)) { error("Cannot download a directory: %s", remote_path); --- 813,826 ---- return(-1); /* XXX: should we preserve set[ug]id? */ ! if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { mode = S_IWRITE | (a->perm & 0777); ! savemode = (a->perm & 0777); ! } ! else { mode = 0666; ! savemode = 0666; ! } if ((a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) && (a->perm & S_IFDIR)) { error("Cannot download a directory: %s", remote_path); *************** *** 931,939 **** /* Override umask and utimes if asked */ #ifdef HAVE_FCHMOD ! if (pflag && fchmod(local_fd, mode) == -1) #else ! if (pflag && chmod(local_path, mode) == -1) #endif /* HAVE_FCHMOD */ error("Couldn't set mode on \"%s\": %s", local_path, strerror(errno)); --- 984,992 ---- /* Override umask and utimes if asked */ #ifdef HAVE_FCHMOD ! if (pflag && fchmod(local_fd, savemode) == -1) #else ! if (pflag && chmod(local_path, savemode) == -1) #endif /* HAVE_FCHMOD */ error("Couldn't set mode on \"%s\": %s", local_path, strerror(errno)); *************** *** 945,950 **** --- 998,1008 ---- if (utimes(local_path, tv) == -1) error("Can't set times on \"%s\": %s", local_path, strerror(errno)); + } + if (getuid() == 0 || geteuid() == 0) { + if (chown(local_path, a->uid, a->gid) < 0) + error("could not set owner & group on \"%s\": %s", local_path, + strerror(errno)); } } close(local_fd); From GaryF at livevault.com Wed Nov 6 02:48:44 2002 From: GaryF at livevault.com (Gary Fernandez) Date: Tue, 5 Nov 2002 10:48:44 -0500 Subject: [PATCH] Add a chroot_users option to sshd Message-ID: <66E3249CDB0D774DA1A0372C870DE9F101BE12F5@corp3.netint.com> This patch adds a new option to sshd, chroot_users. It has the effect of chroot()ing incoming ssh users to their home directory. Note: this option does not work if UsePrivilegeSeparation is enabled. Patch is based on OpenSSH 3.4p1. *** servconf.h@@\main\1 Tue Oct 1 17:25:32 2002 --- servconf.h Wed Oct 2 06:17:48 2002 *************** *** 131,136 **** --- 131,137 ---- char *authorized_keys_file; /* File containing public keys */ char *authorized_keys_file2; int pam_authentication_via_kbd_int; + int chroot_users; } ServerOptions; void initialize_server_options(ServerOptions *); *** servconf.c@@\main\1 Tue Oct 1 17:25:26 2002 --- servconf.c Wed Oct 2 06:09:06 2002 *************** *** 122,127 **** --- 122,128 ---- options->client_alive_count_max = -1; options->authorized_keys_file = NULL; options->authorized_keys_file2 = NULL; + options->chroot_users = -1; /* Needs to be accessable in many places */ use_privsep = -1; *************** *** 253,258 **** --- 254,262 ---- if (options->authorized_keys_file == NULL) options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; + if (options->chroot_users == -1) + options->chroot_users = 0; + /* Turn privilege separation on by default */ if (use_privsep == -1) use_privsep = 1; *************** *** 298,304 **** sBanner, sVerifyReverseMapping, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, ! sUsePrivilegeSeparation, sDeprecated } ServerOpCodes; --- 302,308 ---- sBanner, sVerifyReverseMapping, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, ! sUsePrivilegeSeparation, sChrootUsers, sDeprecated } ServerOpCodes; *************** *** 375,380 **** --- 379,385 ---- { "clientalivecountmax", sClientAliveCountMax }, { "authorizedkeysfile", sAuthorizedKeysFile }, { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { "chrootusers", sChrootUsers }, { "useprivilegeseparation", sUsePrivilegeSeparation}, { NULL, sBadOption } }; *************** *** 900,905 **** --- 905,914 ---- case sClientAliveCountMax: intptr = &options->client_alive_count_max; goto parse_int; + + case sChrootUsers: + intptr = &options->chroot_users; + goto parse_flag; case sDeprecated: log("%s line %d: Deprecated option %s", *** session.c@@\main\1 Tue Oct 1 17:25:48 2002 --- session.c Tue Nov 5 09:59:14 2002 *************** *** 99,104 **** --- 99,111 ---- /* original command from peer. */ const char *original_command = NULL; + /* option to use filesystem snapshot */ + /* #define DO_SNAPSHOTS */ + #ifdef DO_SNAPSHOTS + /* snapshot name */ + char *snapshot = NULL; + #endif + /* data */ #define MAX_SESSIONS 10 Session sessions[MAX_SESSIONS]; *************** *** 1255,1260 **** --- 1262,1268 ---- const char *shell, *shell0, *hostname = NULL; struct passwd *pw = s->pw; u_int i; + char *idx = NULL; /* remove hostkey from the child's memory */ destroy_sensitive_data(); *************** *** 1274,1279 **** --- 1282,1330 ---- do_motd(); #else /* HAVE_OSF_SIA */ do_nologin(pw); + #ifdef DO_SNAPSHOTS + #define SNAPSHOT "snapshot!" + if ((snapshot == NULL || (snapshot != NULL && snapshot[0] == '\0')) && command != NULL && !strncmp(command, SNAPSHOT, strlen(SNAPSHOT))) { + idx = strchr(command, ','); + if (snapshot == NULL) + snapshot = xmalloc(128); + strncpy(snapshot, command+strlen(SNAPSHOT), idx - (command + strlen(SNAPSHOT))); + } + if (snapshot != NULL && snapshot[0] != '\0') { + char home[MAXPATHLEN]; + char *current; + current = strstr(pw->pw_dir, "current"); + if (current != NULL) { + strncpy(home, pw->pw_dir, current - pw->pw_dir); + home[current-pw->pw_dir] = '\0'; + strcat(home, snapshot); + strcat(home, current + strlen("current") ); + } + else + strcpy(home, pw->pw_dir); + if (chroot(home) < 0) { + fprintf(stderr, "Could not chroot to home directory %s: %s\n", + home, strerror(errno)); + strcpy(home, pw->pw_dir); + if (chroot(home) < 0) { + fprintf(stderr, "Could not chroot to home directory %s: %s\n", + home, strerror(errno)); + } + } + if (idx != NULL) + command = idx + 1; + } + else { + #endif /* DO_SNAPSHOTS */ + if (options.chroot_users) { + if (chroot(pw->pw_dir) < 0) { + fprintf(stderr, "Could not chroot to home directory %s: %s\n", + pw->pw_dir, strerror(errno)); + } + } + #ifdef DO_SNAPSHOTS + } + #endif do_setusercontext(pw); #endif /* HAVE_OSF_SIA */ } *************** *** 1347,1353 **** #endif /* AFS */ /* Change current directory to the user\'s home directory. */ ! if (chdir(pw->pw_dir) < 0) { fprintf(stderr, "Could not chdir to home directory %s: %s\n", pw->pw_dir, strerror(errno)); #ifdef HAVE_LOGIN_CAP --- 1398,1411 ---- #endif /* AFS */ /* Change current directory to the user\'s home directory. */ ! if (options.chroot_users) { ! if (chdir("/") < 0) { ! fprintf(stderr, "Could not chdir to home directory %s: %s\n", ! pw->pw_dir, strerror(errno)); ! } ! } ! else { ! if (chdir(pw->pw_dir) < 0) { fprintf(stderr, "Could not chdir to home directory %s: %s\n", pw->pw_dir, strerror(errno)); #ifdef HAVE_LOGIN_CAP *************** *** 1354,1359 **** --- 1412,1418 ---- if (login_getcapbool(lc, "requirehome", 0)) exit(1); #endif + } } if (!options.use_login) *************** *** 1613,1618 **** --- 1672,1678 ---- int success = 0; char *cmd, *subsys = packet_get_string(&len); int i; + char *idx; packet_check_eom(); log("subsystem request for %.100s", subsys); *************** *** 1620,1625 **** --- 1680,1697 ---- for (i = 0; i < options.num_subsystems; i++) { if (strcmp(subsys, options.subsystem_name[i]) == 0) { cmd = options.subsystem_command[i]; + #ifdef DO_SNAPSHOTS + if (snapshot == NULL) + snapshot = xmalloc(128); + snapshot[0] = '\0'; + if (!strncmp(cmd, SNAPSHOT, strlen(SNAPSHOT))) { + idx = strchr(cmd, ','); + strncpy(snapshot, cmd + strlen(SNAPSHOT), + idx - (cmd + strlen(SNAPSHOT))); + snapshot[idx - (cmd + strlen(SNAPSHOT))] = '\0'; + cmd = idx + 1; + } + #endif if (stat(cmd, &st) < 0) { error("subsystem: cannot stat %s: %s", cmd, strerror(errno)); From mouring at etoh.eviladmin.org Wed Nov 6 03:48:04 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 5 Nov 2002 10:48:04 -0600 (CST) Subject: [PATCH] fix sftp to preserve permissions and uid/gid In-Reply-To: <66E3249CDB0D774DA1A0372C870DE9F101BE12F4@corp3.netint.com> Message-ID: Don't know...I don't like that idea. Mainly because the remote side many not be UNIX and it may not be a sane thing to do. Plus I'm not sure this is really something that sftp should be doing to start with. - Ben On Tue, 5 Nov 2002, Gary Fernandez wrote: > Sftp fails to correctly preserve permissions when fetching a file. It adds > write permission for the owner (presumably so it can write the file). > > Sftp also fails to preserve the uid/gid. Added code so that if is running > as root, uid and gid are preserved. > > patch is based on Openssh 3.4p1. > > *** sftp-client.c@@\main\1 Tue Oct 1 17:26:20 2002 > --- sftp-client.c Tue Nov 5 10:22:52 2002 > *************** > *** 666,672 **** > > status = get_status(conn->fd_in, id); > if (status != SSH2_FX_OK) > ! error("Couldn't rename file \"%s\" to \"%s\": %s", oldpath, > newpath, fx2txt(status)); > > return(status); > --- 666,672 ---- > > status = get_status(conn->fd_in, id); > if (status != SSH2_FX_OK) > ! error("Couldn't symlink file \"%s\" to \"%s\": %s", oldpath, > newpath, fx2txt(status)); > > return(status); > *************** > *** 746,752 **** > int local_fd, status, num_req, max_req, write_error; > int read_error, write_errno; > u_int64_t offset, size; > ! u_int handle_len, mode, type, id, buflen; > struct request { > u_int id; > u_int len; > --- 796,802 ---- > int local_fd, status, num_req, max_req, write_error; > int read_error, write_errno; > u_int64_t offset, size; > ! u_int handle_len, mode, type, id, buflen, savemode; > struct request { > u_int id; > u_int len; > *************** > *** 763,773 **** > return(-1); > > /* XXX: should we preserve set[ug]id? */ > ! if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) > mode = S_IWRITE | (a->perm & 0777); > ! else > mode = 0666; > ! > if ((a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) && > (a->perm & S_IFDIR)) { > error("Cannot download a directory: %s", remote_path); > --- 813,826 ---- > return(-1); > > /* XXX: should we preserve set[ug]id? */ > ! if (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) { > mode = S_IWRITE | (a->perm & 0777); > ! savemode = (a->perm & 0777); > ! } > ! else { > mode = 0666; > ! savemode = 0666; > ! } > if ((a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) && > (a->perm & S_IFDIR)) { > error("Cannot download a directory: %s", remote_path); > *************** > *** 931,939 **** > > /* Override umask and utimes if asked */ > #ifdef HAVE_FCHMOD > ! if (pflag && fchmod(local_fd, mode) == -1) > #else > ! if (pflag && chmod(local_path, mode) == -1) > #endif /* HAVE_FCHMOD */ > error("Couldn't set mode on \"%s\": %s", local_path, > strerror(errno)); > --- 984,992 ---- > > /* Override umask and utimes if asked */ > #ifdef HAVE_FCHMOD > ! if (pflag && fchmod(local_fd, savemode) == -1) > #else > ! if (pflag && chmod(local_path, savemode) == -1) > #endif /* HAVE_FCHMOD */ > error("Couldn't set mode on \"%s\": %s", local_path, > strerror(errno)); > *************** > *** 945,950 **** > --- 998,1008 ---- > if (utimes(local_path, tv) == -1) > error("Can't set times on \"%s\": %s", > local_path, strerror(errno)); > + } > + if (getuid() == 0 || geteuid() == 0) { > + if (chown(local_path, a->uid, a->gid) < 0) > + error("could not set owner & group on > \"%s\": %s", local_path, > + strerror(errno)); > } > } > close(local_fd); > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From james at firstaidmusic.com Tue Nov 5 04:37:34 2002 From: james at firstaidmusic.com (James Dennis) Date: Mon, 4 Nov 2002 12:37:34 -0500 Subject: [PATCH] Add a chroot_users option to sshd In-Reply-To: <66E3249CDB0D774DA1A0372C870DE9F101BE12F5@corp3.netint.com> References: <66E3249CDB0D774DA1A0372C870DE9F101BE12F5@corp3.netint.com> Message-ID: <20021104123734.5eeb501d.james@firstaidmusic.com> http://chrootssh.sf.net -James On Tue, 5 Nov 2002 10:48:44 -0500 Gary Fernandez wrote: > This patch adds a new option to sshd, chroot_users. It has the effect of > chroot()ing incoming ssh users to their home directory. Note: this option > does not work if UsePrivilegeSeparation is enabled. > > Patch is based on OpenSSH 3.4p1. > > *** servconf.h@@\main\1 Tue Oct 1 17:25:32 2002 > --- servconf.h Wed Oct 2 06:17:48 2002 > *************** > *** 131,136 **** > --- 131,137 ---- > char *authorized_keys_file; /* File containing public keys */ > char *authorized_keys_file2; > int pam_authentication_via_kbd_int; > + int chroot_users; > } ServerOptions; > > void initialize_server_options(ServerOptions *); > > *** servconf.c@@\main\1 Tue Oct 1 17:25:26 2002 > --- servconf.c Wed Oct 2 06:09:06 2002 > *************** > *** 122,127 **** > --- 122,128 ---- > options->client_alive_count_max = -1; > options->authorized_keys_file = NULL; > options->authorized_keys_file2 = NULL; > + options->chroot_users = -1; > > /* Needs to be accessable in many places */ > use_privsep = -1; > *************** > *** 253,258 **** > --- 254,262 ---- > if (options->authorized_keys_file == NULL) > options->authorized_keys_file = > _PATH_SSH_USER_PERMITTED_KEYS; > > + if (options->chroot_users == -1) > + options->chroot_users = 0; > + > /* Turn privilege separation on by default */ > if (use_privsep == -1) > use_privsep = 1; > *************** > *** 298,304 **** > sBanner, sVerifyReverseMapping, sHostbasedAuthentication, > sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, > sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, > ! sUsePrivilegeSeparation, > sDeprecated > } ServerOpCodes; > > --- 302,308 ---- > sBanner, sVerifyReverseMapping, sHostbasedAuthentication, > sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, > sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, > ! sUsePrivilegeSeparation, sChrootUsers, > sDeprecated > } ServerOpCodes; > > *************** > *** 375,380 **** > --- 379,385 ---- > { "clientalivecountmax", sClientAliveCountMax }, > { "authorizedkeysfile", sAuthorizedKeysFile }, > { "authorizedkeysfile2", sAuthorizedKeysFile2 }, > + { "chrootusers", sChrootUsers }, > { "useprivilegeseparation", sUsePrivilegeSeparation}, > { NULL, sBadOption } > }; > *************** > *** 900,905 **** > --- 905,914 ---- > case sClientAliveCountMax: > intptr = &options->client_alive_count_max; > goto parse_int; > + > + case sChrootUsers: > + intptr = &options->chroot_users; > + goto parse_flag; > > case sDeprecated: > log("%s line %d: Deprecated option %s", > > *** session.c@@\main\1 Tue Oct 1 17:25:48 2002 > --- session.c Tue Nov 5 09:59:14 2002 > *************** > *** 99,104 **** > --- 99,111 ---- > /* original command from peer. */ > const char *original_command = NULL; > > + /* option to use filesystem snapshot */ > + /* #define DO_SNAPSHOTS */ > + #ifdef DO_SNAPSHOTS > + /* snapshot name */ > + char *snapshot = NULL; > + #endif > + > /* data */ > #define MAX_SESSIONS 10 > Session sessions[MAX_SESSIONS]; > *************** > *** 1255,1260 **** > --- 1262,1268 ---- > const char *shell, *shell0, *hostname = NULL; > struct passwd *pw = s->pw; > u_int i; > + char *idx = NULL; > > /* remove hostkey from the child's memory */ > destroy_sensitive_data(); > *************** > *** 1274,1279 **** > --- 1282,1330 ---- > do_motd(); > #else /* HAVE_OSF_SIA */ > do_nologin(pw); > + #ifdef DO_SNAPSHOTS > + #define SNAPSHOT "snapshot!" > + if ((snapshot == NULL || (snapshot != NULL && snapshot[0] == > '\0')) && command != NULL && !strncmp(command, SNAPSHOT, strlen(SNAPSHOT))) > { > + idx = strchr(command, ','); > + if (snapshot == NULL) > + snapshot = xmalloc(128); > + strncpy(snapshot, command+strlen(SNAPSHOT), idx - > (command + strlen(SNAPSHOT))); > + } > + if (snapshot != NULL && snapshot[0] != '\0') { > + char home[MAXPATHLEN]; > + char *current; > + current = strstr(pw->pw_dir, "current"); > + if (current != NULL) { > + strncpy(home, pw->pw_dir, current - > pw->pw_dir); > + home[current-pw->pw_dir] = '\0'; > + strcat(home, snapshot); > + strcat(home, current + strlen("current") ); > + } > + else > + strcpy(home, pw->pw_dir); > + if (chroot(home) < 0) { > + fprintf(stderr, "Could not chroot to home > directory %s: %s\n", > + home, strerror(errno)); > + strcpy(home, pw->pw_dir); > + if (chroot(home) < 0) { > + fprintf(stderr, "Could not chroot to > home directory %s: %s\n", > + home, strerror(errno)); > + } > + } > + if (idx != NULL) > + command = idx + 1; > + } > + else { > + #endif /* DO_SNAPSHOTS */ > + if (options.chroot_users) { > + if (chroot(pw->pw_dir) < 0) { > + fprintf(stderr, "Could not chroot to > home directory %s: %s\n", > + pw->pw_dir, > strerror(errno)); > + } > + } > + #ifdef DO_SNAPSHOTS > + } > + #endif > do_setusercontext(pw); > #endif /* HAVE_OSF_SIA */ > } > *************** > *** 1347,1353 **** > #endif /* AFS */ > > /* Change current directory to the user\'s home directory. */ > ! if (chdir(pw->pw_dir) < 0) { > fprintf(stderr, "Could not chdir to home directory %s: > %s\n", > pw->pw_dir, strerror(errno)); > #ifdef HAVE_LOGIN_CAP > --- 1398,1411 ---- > #endif /* AFS */ > > /* Change current directory to the user\'s home directory. */ > ! if (options.chroot_users) { > ! if (chdir("/") < 0) { > ! fprintf(stderr, "Could not chdir to home directory %s: %s\n", > ! pw->pw_dir, strerror(errno)); > ! } > ! } > ! else { > ! if (chdir(pw->pw_dir) < 0) { > fprintf(stderr, "Could not chdir to home directory %s: > %s\n", > pw->pw_dir, strerror(errno)); > #ifdef HAVE_LOGIN_CAP > *************** > *** 1354,1359 **** > --- 1412,1418 ---- > if (login_getcapbool(lc, "requirehome", 0)) > exit(1); > #endif > + } > } > > if (!options.use_login) > *************** > *** 1613,1618 **** > --- 1672,1678 ---- > int success = 0; > char *cmd, *subsys = packet_get_string(&len); > int i; > + char *idx; > > packet_check_eom(); > log("subsystem request for %.100s", subsys); > *************** > *** 1620,1625 **** > --- 1680,1697 ---- > for (i = 0; i < options.num_subsystems; i++) { > if (strcmp(subsys, options.subsystem_name[i]) == 0) { > cmd = options.subsystem_command[i]; > + #ifdef DO_SNAPSHOTS > + if (snapshot == NULL) > + snapshot = xmalloc(128); > + snapshot[0] = '\0'; > + if (!strncmp(cmd, SNAPSHOT, strlen(SNAPSHOT))) { > + idx = strchr(cmd, ','); > + strncpy(snapshot, cmd + strlen(SNAPSHOT), > + idx - (cmd + strlen(SNAPSHOT))); > + snapshot[idx - (cmd + strlen(SNAPSHOT))] = '\0'; > + cmd = idx + 1; > + } > + #endif > if (stat(cmd, &st) < 0) { > error("subsystem: cannot stat %s: %s", cmd, > strerror(errno)); > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -------------- 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/20021104/dc069008/attachment.bin From esp5 at rama.comp.pge.com Wed Nov 6 06:08:47 2002 From: esp5 at rama.comp.pge.com (Ed Peschko) Date: Tue, 5 Nov 2002 11:08:47 -0800 Subject: problems with -R Message-ID: <20021105110847.A13509@rama.comp.pge.com> hey all, I'm using openssh-3.5p1, was trying to set up a 'reverse telnet' session (sun solaris 2.6 on both machines). Anyways, I was doing: server% ssh -R 1111::2222 client% ssh -p 1111 where is behind a firewall and cannot reach Anyways the idea was to connect to the socket on and having the traffic forwarded over to the (hence avoiding a firewall). (right now, I'm testing it on 2 machines without firewalls to be simple). However, this doesn't work; I see an sshd program running on the client box that corresponds to the server request, I do a netstat -a, and see: localhost.1111 *.* 0 0 0 0 LISTEN on the client machine.. However, when I do 'ssh -p 1111 ', I get: ssh: connect to host port 1111: Connection refused. So.. any clues on what's going on? And how do I set it up so I can see what's going on on the client side via ssh -d... I can see debug messages for the parent process, *not* the process spawned listening on port 1111. Anyways, any help would be greatly appreciated, if you need any more info on configuration, let me know (perl has a -V option to show all compile options, sort of wondering what the equivalent would be for openssh.) Thanks much, Ed (ps - one more thing. When I do 'ssh -R 1111::2222 ', I actually *get a shell*. This isn't really the expected behaviour, I would have thought that it would just open up a port, and run in the background as a daemon...) From bugzilla-daemon at mindrot.org Wed Nov 6 06:43:53 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 6 Nov 2002 06:43:53 +1100 (EST) Subject: [Bug 425] Integer overflow in mm_zalloc Message-ID: <20021105194353.23C1D3D153@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=425 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-11-06 06:43 ------- thanks, applied ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Nov 6 07:01:55 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 6 Nov 2002 07:01:55 +1100 (EST) Subject: [Bug 414] sshd initially ignores -e (log_stderr) if -i (inetd_flag) is given Message-ID: <20021105200155.9EF263D16E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=414 ------- Additional Comments From markus at openbsd.org 2002-11-06 07:01 ------- Created an attachment (id=164) --> (http://bugzilla.mindrot.org/attachment.cgi?id=164&action=view) proposed patch what about this? (more in line with the rest of the code). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stuge-openssh-unix-dev at cdy.org Wed Nov 6 07:04:12 2002 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 5 Nov 2002 21:04:12 +0100 Subject: problems with -R In-Reply-To: <20021105110847.A13509@rama.comp.pge.com>; from esp5@rama.comp.pge.com on Tue, Nov 05, 2002 at 11:08:47AM -0800 References: <20021105110847.A13509@rama.comp.pge.com> Message-ID: <20021105210412.B7027@foo.birdnet.se> On Tue, Nov 05, 2002 at 11:08:47AM -0800, Ed Peschko wrote: > However, this doesn't work; I see an sshd program running on the client box > that corresponds to the server request, I do a netstat -a, and see: > localhost.1111 *.* 0 0 0 0 LISTEN > on the client machine.. > However, when I do 'ssh -p 1111 ', I get: > ssh: connect to host port 1111: Connection refused. See GatewayPorts in sshd_config(5) or try "ssh -p 1111 localhost" instead. //Peter From markus at openbsd.org Wed Nov 6 07:08:15 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 5 Nov 2002 21:08:15 +0100 Subject: [PATCH] Add a chroot_users option to sshd In-Reply-To: <66E3249CDB0D774DA1A0372C870DE9F101BE12F5@corp3.netint.com> References: <66E3249CDB0D774DA1A0372C870DE9F101BE12F5@corp3.netint.com> Message-ID: <20021105200815.GA30560@folly> On Tue, Nov 05, 2002 at 10:48:44AM -0500, Gary Fernandez wrote: > This patch adds a new option to sshd, chroot_users. It has the effect of > chroot()ing incoming ssh users to their home directory. Note: this option > does not work if UsePrivilegeSeparation is enabled. chrooting into a directory not owned by root is unsafe. From bugzilla-daemon at mindrot.org Wed Nov 6 07:10:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 6 Nov 2002 07:10:48 +1100 (EST) Subject: [Bug 412] AuthorizedKeysFile assumes home directory access upon authentication Message-ID: <20021105201048.34FC73D17A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=412 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-11-06 07:10 ------- fixed in -current ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Wed Nov 6 07:13:12 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 5 Nov 2002 21:13:12 +0100 Subject: problems with -R In-Reply-To: <20021105110847.A13509@rama.comp.pge.com> References: <20021105110847.A13509@rama.comp.pge.com> Message-ID: <20021105201312.GB30560@folly> On Tue, Nov 05, 2002 at 11:08:47AM -0800, Ed Peschko wrote: > localhost.1111 *.* 0 0 0 0 LISTEN sshd binds to localhost by default, see GatewayPorts in sshd_config. > (ps - one more thing. When I do 'ssh -R 1111::2222 ', I > actually *get a shell*. This isn't really the expected behaviour, I would have > thought that it would just open up a port, and run in the background as a > daemon...) use -N From bugzilla-daemon at mindrot.org Wed Nov 6 08:54:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 6 Nov 2002 08:54:12 +1100 (EST) Subject: [Bug 414] sshd initially ignores -e (log_stderr) if -i (inetd_flag) is given Message-ID: <20021105215412.680EC3D15E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=414 ------- Additional Comments From prj at po.cwru.edu 2002-11-06 08:54 ------- Your patch fails to preserve the current intended behavior of logging to stderr initially when debug_flag and inetd_flag are both false. It also fails to fix the problem in my case, since debug_flag is false for me, so log_stderr will not be set to true by that conditional, regardless of where you place it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From esp5 at rama.comp.pge.com Wed Nov 6 09:16:18 2002 From: esp5 at rama.comp.pge.com (Ed Peschko) Date: Tue, 5 Nov 2002 14:16:18 -0800 Subject: problems with -R In-Reply-To: <20021105201312.GB30560@folly> References: <20021105110847.A13509@rama.comp.pge.com> <20021105201312.GB30560@folly> Message-ID: <20021105141618.A14088@rama.comp.pge.com> On Tue, Nov 05, 2002 at 09:13:12PM +0100, Markus Friedl wrote: > On Tue, Nov 05, 2002 at 11:08:47AM -0800, Ed Peschko wrote: > > localhost.1111 *.* 0 0 0 0 LISTEN > > sshd binds to localhost by default, see GatewayPorts in sshd_config. ok, it sort-of-works.. ha. this is really cool. It should probably be in the FAQ. However, I'm getting 'permission denied' errors, when doing the 'ssh -p 1111 localhost' step. What is the password verified against? It sure isn't the unix password (at least in my case). Ed From dknodel at csc.com.au Wed Nov 6 10:07:13 2002 From: dknodel at csc.com.au (dknodel at csc.com.au) Date: Wed, 6 Nov 2002 07:07:13 +0800 Subject: [PATCH] fix sftp to preserve permissions and uid/gid Message-ID: > Don't know...I don't like that idea. Mainly because the remote side many > not be UNIX and it may not be a sane thing to do. > Plus I'm not sure this is really something that sftp should be doing to > start with. > > - Ben I can see that it may not be appropriate for sftp to always do this, but a command-line option and built-in sftp toggleable setting for this would be fantastic. > On Tue, 5 Nov 2002, Gary Fernandez wrote: > > Sftp fails to correctly preserve permissions when fetching a file. It adds > > write permission for the owner (presumably so it can write the file). > > > > Sftp also fails to preserve the uid/gid. Added code so that if is running > > as root, uid and gid are preserved. > > > patch is based on Openssh 3.4p1. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev - David Knodel From esp5 at rama.comp.pge.com Wed Nov 6 10:45:08 2002 From: esp5 at rama.comp.pge.com (Ed Peschko) Date: Tue, 5 Nov 2002 15:45:08 -0800 Subject: problems with -R In-Reply-To: <20021105201312.GB30560@folly> References: <20021105110847.A13509@rama.comp.pge.com> <20021105201312.GB30560@folly> Message-ID: <20021105154508.A14804@rama.comp.pge.com> ok, more about the password item... I'm still in the thick of it (looking at deja and trying various solutions), but is it messy. IMO, ssh should *not* be this difficult; users/passwords from /etc/passwd should be automatically enabled to connect without going through hoops like this. In short: a) if a system uses md5 passwords, configure should *auto-detect* it, b) if permissions are incorrect on a home directory, ssh should state that. c) If a 'permission denied' error is given, it should state *why* permission was denied. And so on.. this learning curve is not endearing me to openssh (although at the same time, I must admit that it is providing me an invaluable service). Anyways, if there is a troubleshooting FAQ to look at, I'd love to see it. Any advice on getting through this issue is greatly appreciated as well. Ed From ppp_ttt at hotmail.com Wed Nov 6 11:37:08 2002 From: ppp_ttt at hotmail.com (ppp ttt) Date: Wed, 06 Nov 2002 00:37:08 +0000 Subject: openssl version mismatch !! Message-ID: Hi Everybody, I am running openssh 3.4p1 on solaris 8 sparc machine. We recently upgraded our openssh,which is version 3.4p1. when I do "ssh -V" it shows "openssl version mismatch....." and even I try to generate keys with ssh-keygen it gives same error message. I would appreciate if somebody let me know what could be the reason for this error and How I can resolve it. Thanks _________________________________________________________________ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp From mouring at etoh.eviladmin.org Wed Nov 6 11:39:28 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 5 Nov 2002 18:39:28 -0600 (CST) Subject: openssl version mismatch !! In-Reply-To: Message-ID: It means the version of OpenSSL that OpenSSH was compiled against is not the version of OpenSSL that is installed. Either reinstall OpenSSH or install the correct OpenSSL package. - Ben On Wed, 6 Nov 2002, ppp ttt wrote: > > Hi Everybody, > > I am running openssh 3.4p1 on solaris 8 sparc machine. We recently > upgraded our openssh,which is version 3.4p1. when I do "ssh -V" > it shows "openssl version mismatch....." and even I try to generate > keys with ssh-keygen it gives same error message. > > I would appreciate if somebody let me know what could be the reason > for this error and How I can resolve it. > > Thanks > > > > > > > _________________________________________________________________ > Internet access plans that fit your lifestyle -- join MSN. > http://resourcecenter.msn.com/access/plans/default.asp > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From tim at multitalents.net Wed Nov 6 13:24:18 2002 From: tim at multitalents.net (Tim Rice) Date: Tue, 5 Nov 2002 18:24:18 -0800 (PST) Subject: problems with -R In-Reply-To: <20021105154508.A14804@rama.comp.pge.com> Message-ID: On Tue, 5 Nov 2002, Ed Peschko wrote: > ok, more about the password item... I'm still in the thick of it (looking at > deja and trying various solutions), but is it messy. > > IMO, ssh should *not* be this difficult; users/passwords from /etc/passwd > should be automatically enabled to connect without going through hoops like > this. In short: > > a) if a system uses md5 passwords, configure should *auto-detect* it, Care to provide a patch that does this without root permissions? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From esp5 at rama.comp.pge.com Wed Nov 6 13:32:49 2002 From: esp5 at rama.comp.pge.com (Ed Peschko) Date: Tue, 5 Nov 2002 18:32:49 -0800 Subject: problems with -R In-Reply-To: References: <20021105154508.A14804@rama.comp.pge.com> Message-ID: <20021105183249.A15581@rama.comp.pge.com> On Tue, Nov 05, 2002 at 06:24:18PM -0800, Tim Rice wrote: > On Tue, 5 Nov 2002, Ed Peschko wrote: > > > ok, more about the password item... I'm still in the thick of it (looking at > > deja and trying various solutions), but is it messy. > > > > IMO, ssh should *not* be this difficult; users/passwords from /etc/passwd > > should be automatically enabled to connect without going through hoops like > > this. In short: > > > > a) if a system uses md5 passwords, configure should *auto-detect* it, > > Care to provide a patch that does this without root permissions? yes, you could do this fairly straightforward - you know that x distribution/ unix-variant has md5 passwords enabled by default, so you make a list. If you see that os variant in that list, you enable the md5-password flag for the user. If not, you don't. Won't work about 1 time out of 100, but in that case, you give explicit flags. You also give a message in the configure that says you are doing this. Anyways, I gave up on the whole password authentication thing and made a passkey. I don't think I should have had to do that.. Ed > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > > From mouring at etoh.eviladmin.org Wed Nov 6 15:25:47 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 5 Nov 2002 22:25:47 -0600 (CST) Subject: problems with -R In-Reply-To: <20021105183249.A15581@rama.comp.pge.com> Message-ID: On Tue, 5 Nov 2002, Ed Peschko wrote: > On Tue, Nov 05, 2002 at 06:24:18PM -0800, Tim Rice wrote: > > On Tue, 5 Nov 2002, Ed Peschko wrote: > > > > > ok, more about the password item... I'm still in the thick of it (looking at > > > deja and trying various solutions), but is it messy. > > > > > > IMO, ssh should *not* be this difficult; users/passwords from /etc/passwd > > > should be automatically enabled to connect without going through hoops like > > > this. In short: > > > > > > a) if a system uses md5 passwords, configure should *auto-detect* it, > > > > Care to provide a patch that does this without root permissions? > > yes, you could do this fairly straightforward - you know that x distribution/ > unix-variant has md5 passwords enabled by default, so you make a list. If you > see that os variant in that list, you enable the md5-password flag for the user. > If not, you don't. Won't work about 1 time out of 100, but in that case, you > give explicit flags. You also give a message in the configure that says you are > doing this. > Until such time as that distro changes from MD5 to something else. Then you end up with having to say version 2.x and below are XX encryption, version 5.x and below is TT encryption, etc.. BAD for configuration scripts. BTW.. if your OS uses MD5. The changes you are running FreeBSD or Linux are high. And all but one Linux uses PAM. You should be compiling for pam so that system can handle it. > Anyways, I gave up on the whole password authentication thing and made a > passkey. I don't think I should have had to do that.. > I've never had a problem. I've stepped people through configuration their OS for the right password authentication method. And went on with life. Again, unless your doing something wierd. It is not that complex. - Ben From cjs2895 at hotmail.com Wed Nov 6 18:23:10 2002 From: cjs2895 at hotmail.com (cjs 2895) Date: Wed, 06 Nov 2002 02:23:10 -0500 Subject: Help with channels.c? Message-ID: Dear Sirs, I have recently discovered the remote port forwarding feature of ssh and see a lot of potential there to fill a unique need in a unique environment. I would like extend this feature minimally to enable remote hosts to connect to the remotely forwarded port or ideally to allow remote hosts to connect to a dynamically forwarded remote ports (ie a reverse socks4 tunnel). I've invested several hours into the cause and so far I'm having a little bit of trouble following how the "channels" are set up, and I was wondering if someone could post a summary of whats going on -- particularly in the case of remote ports being forwarded. Assistance is appreciated and I'll post a summary of any responses received at a later date. Please reply in private. Thanks, Christopher _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From dtucker at zip.com.au Wed Nov 6 23:24:47 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 06 Nov 2002 23:24:47 +1100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <20021104104708.912E03D14E@shitei.mindrot.org> Message-ID: <3DC90A0F.914B053@zip.com.au> This raises another possibility for changing passwords. As I see it the options now are: 1) Platform specific functions Pro: RFC compliant Con: extra code that runs as root 2) Spawn /bin/passwd in session Pro: Simple, portable Con: Not RFC compliant, possible timing attacks against proto 2? 3) Platform-specific setuid helpers Pro: Consistent v1 & v2 interface, delegate policy to user-written helpers, RFC compliant. Con: Potential attacks against setuid programs, repeated code (eg command line parsing). 4) Spawn /bin/passwd in tty (ala "expect") Pro: portable? RFC compliant. Con: lots of code, hard to get right, potentially flakey I know Markus doesn't like 1) and says that the only portable thing to do is 2). Isn't this similar the the case for UseLogin? After all the only portable way to do user authentication is /bin/login, but UseLogin defaults to no and is considered depreciated, right? I'm still in favour of 1). The platform-specific change functions that I've done so far[0] are ~40 lines (AIX) and ~100 lines (/etc/shadow). The shadow function handles 3 platforms (Solaris, Redhat, UnixWare). The rest of the patches are required to check whether or not a password is expired regardless of which method is used to change it. Regarding 3): if a consistent enough interface was specified you could use the same setuid helper for PASSWD_CHANGEREQ during proto 2 authentication as well as proto 1 sessions. Also, can someone who knows PAM please tell me if it's feasible to implement a function like: pam_change_password(char *user, char *oldpass, char *newpass)? Or is some odd PAM module likely to render that impossible? [0] See list archives or http://www.zip.com.au/~dtucker/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 bugzilla-daemon at mindrot.org Thu Nov 7 00:51:02 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 00:51:02 +1100 (EST) Subject: [Bug 426] New: sftp adds write permission when doing get -p Message-ID: <20021106135102.9B8B63D186@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=426 Summary: sftp adds write permission when doing get -p Product: Portable OpenSSH Version: 3.4p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: gfernandez at livevault.com sftp adds write permission when transferring a file. This is presumably so that it can have access to the file while writing it. However, when it later sets the permissions, it uses the permissions which included the added write access. As a result the access does not match the original mode. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 00:56:22 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 00:56:22 +1100 (EST) Subject: [Bug 426] sftp adds write permission when doing get -p Message-ID: <20021106135622.D87DC3D18A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=426 ------- Additional Comments From gfernandez at livevault.com 2002-11-07 00:56 ------- Created an attachment (id=165) --> (http://bugzilla.mindrot.org/attachment.cgi?id=165&action=view) Change for sftp to preserve permissions This is a possible solution to the problem ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 00:59:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 00:59:20 +1100 (EST) Subject: [Bug 426] sftp adds write permission when doing get -p Message-ID: <20021106135920.9580C3D18F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=426 gfernandez at livevault.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #165 is|0 |1 obsolete| | ------- Additional Comments From gfernandez at livevault.com 2002-11-07 00:59 ------- Created an attachment (id=166) --> (http://bugzilla.mindrot.org/attachment.cgi?id=166&action=view) Change for sftp to preserve permissions this is a possible fix for the problem ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:11:10 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:11:10 +1100 (EST) Subject: [Bug 427] New: sftp does not preserve uid/gid on fetch Message-ID: <20021106141110.94F3F3D18B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=427 Summary: sftp does not preserve uid/gid on fetch Product: Portable OpenSSH Version: 3.4p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: gfernandez at livevault.com currently sftp does not attempt to preserve uid/gid on fetch. If sftp is running as root, it could preserve uid/gid. Note: a possible objection to implementing this was raised. Namely, whether uid/gid will make sense when sftp is being used in a cross platform case. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:12:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:12:23 +1100 (EST) Subject: [Bug 427] sftp does not preserve uid/gid on fetch Message-ID: <20021106141223.3226E3D18B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=427 ------- Additional Comments From gfernandez at livevault.com 2002-11-07 01:12 ------- Created an attachment (id=167) --> (http://bugzilla.mindrot.org/attachment.cgi?id=167&action=view) changes to preserve uid/gid on fetch this is a possible change to preserve uid/gid on fetch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:33:47 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:33:47 +1100 (EST) Subject: [Bug 428] New: sftp could use a command to transfer symlinks Message-ID: <20021106143347.5AEE83D190@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=428 Summary: sftp could use a command to transfer symlinks Product: Portable OpenSSH Version: 3.4p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: gfernandez at livevault.com Currently there is no way using sftp to transfer a symlink. The attached patch adds a command "getlink" that allows a symlink to be transferred. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:36:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:36:20 +1100 (EST) Subject: [Bug 428] sftp could use a command to transfer symlinks Message-ID: <20021106143620.75E533D1A2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=428 ------- Additional Comments From gfernandez at livevault.com 2002-11-07 01:35 ------- Created an attachment (id=168) --> (http://bugzilla.mindrot.org/attachment.cgi?id=168&action=view) changes to implement getlink this patch includes changes to sftp-int.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:38:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:38:54 +1100 (EST) Subject: [Bug 428] sftp could use a command to transfer symlinks Message-ID: <20021106143854.CEC533D1A6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=428 ------- Additional Comments From gfernandez at livevault.com 2002-11-07 01:38 ------- Created an attachment (id=169) --> (http://bugzilla.mindrot.org/attachment.cgi?id=169&action=view) implement the getlink command this includes changes to sftp-client.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:41:02 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:41:02 +1100 (EST) Subject: [Bug 428] sftp could use a command to transfer symlinks Message-ID: <20021106144102.4B1E23D1AB@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=428 ------- Additional Comments From gfernandez at livevault.com 2002-11-07 01:40 ------- Created an attachment (id=170) --> (http://bugzilla.mindrot.org/attachment.cgi?id=170&action=view) implement the getlink command this includes changes to sftp.1 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:44:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:44:20 +1100 (EST) Subject: [Bug 428] sftp could use a command to transfer symlinks Message-ID: <20021106144420.DA8323D1B1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=428 ------- Additional Comments From gfernandez at livevault.com 2002-11-07 01:43 ------- Created an attachment (id=171) --> (http://bugzilla.mindrot.org/attachment.cgi?id=171&action=view) implement the getlink command this includes changes to sft-client.h ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Thu Nov 7 01:46:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 01:46:34 +1100 (EST) Subject: [Bug 428] sftp could use a command to transfer symlinks Message-ID: <20021106144634.E14203D1B5@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=428 ------- Additional Comments From gfernandez at livevault.com 2002-11-07 01:46 ------- Created an attachment (id=172) --> (http://bugzilla.mindrot.org/attachment.cgi?id=172&action=view) implement the getlink command include changes to sftp-server.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mmokrejs at natur.cuni.cz Thu Nov 7 02:05:30 2002 From: mmokrejs at natur.cuni.cz (=?iso-8859-2?Q?Martin_MOKREJ=A9?=) Date: Wed, 6 Nov 2002 16:05:30 +0100 (CET) Subject: ssh-3.5p1 core dumps on Solaris 2.6 In-Reply-To: <3DAD5F69.AE8435E@zip.com.au> Message-ID: On Wed, 16 Oct 2002, Darren Tucker wrote: > Martin MOKREJ? wrote: > > I've reported this problem a month ago on this list, and probably no-one > > is interested? Binaries were configured with krb4 and afs enabled. > > However, only the second crash seems to be related to krb4. > > Any thoughts? Hi, I feel I should post a conclusion. Maybe someone wants to update docs for ssh+krb4 in the INSTALL document. I've faced couple of problems: 1. If you ever installed shared libraries libkrb.so and libkafs.so, make sure to rename them temporarily while linking openssh-3.5p1. If you don't, then sshd "somehow" disconnects the client when trying to initiate connection. 2. If you ever installed /usr/athena/lib/libdes.* from KTH-KRB4 distribution and you use versions above 1.1.1 (I think, where the OpenSSL support was added), be sure to remove this library. In such a case, you already have kerberos binaroes linked against DES algorithms from libcrypto, originating from openssl distributon. Configure script of openssh-3.5p1 is quite stupid and will happily put both "-ldes" and "-lcrypto" on the LDFLAGS line. The problem might be similar to one appearing on SGI Irix platforms, where native cc compiler follows truly POSIX and is single-pass linker, i.e. does not shuffle the order of libraries while linking as gcc does. Thus, you have to specify them in right order! The problem there was that crypt() from libdes returns something completely different then crypt() from libcrypto, which point to the function in libc. The proper order was: -lssh -lopenbsd-compat -lwrap -lkafs -lkrb -lz -lgen -lcrypto -ldes I believe the solution would be to ignore -ldes, as last two releases of KTH-KRB4 do no provide anymore libdes. If user would have the old version, he would get unresolved symbols at link stage. When thinking of the case on Irix, I believe the RIGHT solution at time was to remove "-ldes". In my case, unknown function calls were resolved from libdes instead of libcrypto would NOT happen, thus thus people won't face strange crashes which I've seen. For example, the "./ssh-keygen" not working is one nice example, see my previous posts. ;) 3. After configuring, be sure to add one line to includes.h. This is Solaris specific! #include #include #include +#include #include 4. Remember, that kerberos is not available under ssh protocol 2. You have to use "-1" ssh command line option. I've tested openssh-3.5p1 as follows: openssl-0.9.6-stable-SNAP-20021102$ ./Configure solaris-sparcv7-gcc --prefix=/software/@sys/usr/openssl --openssldir=/usr/local/openssl no-threads krb4-1.2.1$ ./configure --with-readline --with-x --with-openssl=/software/@sys/usr/openssl --with-afsws=/usr/afsws --enable-rxkad --disable-shared openssh-3.5p1$ ./configure --prefix=/usr/local --with-kerberos4=/usr/athena --with-afs=/usr/afsws --with-tcp-wrappers --with-ssl-dir=/software/@sys/usr/openssl --without-rsh --disable-suid-ssh --with-privsep --with-zlib --with-pam HtH -- Martin Mokrejs , PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs MIPS / Institute for Bioinformatics GSF - National Research Center for Environment and Health Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany tel.: +49-89-3187 3683 , fax:?+49-89-3187 3585 From Aaron.Lineberger at nets.nemais.navy.mil Thu Nov 7 02:50:50 2002 From: Aaron.Lineberger at nets.nemais.navy.mil (Lineberger, Aaron CONT (NETS)) Date: Wed, 6 Nov 2002 10:50:50 -0500 Subject: scp output redirection doesn't work... Message-ID: > OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f > AIX 4.3.3.0 Maintenance Level 10. > > I have run a test on my boxes and found the following: > > > scp test :~/test > test 100% |*****************************| 16000 > 00:00 > > > > scp works fine, but when I tried to redirect stdio/stderr to files they > are empty! :( > > scp test :~/test 1>stdio.out 2>stderr.out > > ls -l std* > -rw-r----- 1 linaar staff 0 Nov 06 10:35 stderr.out > -rw-r----- 1 linaar staff 0 Nov 06 10:35 stdio.out > > I don't have an issue with ssh IO redirection. (yeah I realize they are > separate programs. ;) > Is there some other way to handle the output from scp or is this a bug? > > Here is the verbose output: > > scp -v test :~/test > Executing: program /usr/local/bin/ssh host , user > (unspecified), command scp -v -t ~/test > OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f > debug1: Reading configuration data /usr/local/etc/ssh_config > debug1: Applying options for * > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: ssh_connect: needpriv 0 > debug1: Connecting to sapdev [10.10.112.21] port 22. > debug1: Connection established. > debug1: identity file /home/linaar/.ssh/identity type 1 > debug1: identity file /home/linaar/.ssh/id_rsa type -1 > debug1: identity file /home/linaar/.ssh/id_dsa type -1 > debug1: Remote protocol version 1.99, remote software version > OpenSSH_3.4p1 > debug1: match: OpenSSH_3.4p1 pat OpenSSH* > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.4p1 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: dh_gen_key: priv key bits set: 125/256 > debug1: bits set: 1613/3191 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host '' is known and matches the RSA host key. > debug1: Found key in /home/linaar/.ssh/known_hosts:2 > debug1: bits set: 1574/3191 > debug1: ssh_rsa_verify: signature correct > debug1: kex_derive_keys > debug1: newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: waiting for SSH2_MSG_NEWKEYS > debug1: newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: done: ssh_kex2. > debug1: send SSH2_MSG_SERVICE_REQUEST > debug1: service_accept: ssh-userauth > debug1: got SSH2_MSG_SERVICE_ACCEPT > debug1: authentications that can continue: > publickey,password,keyboard-interactive > debug1: next auth method to try is publickey > debug1: userauth_pubkey_agent: testing agent key rsa-key-20020913 > debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 20043ab8 hint > -1 > debug1: ssh-userauth2 successful: method publickey > debug1: fd 4 setting O_NONBLOCK > debug1: fd 5 setting O_NONBLOCK > debug1: channel 0: new [client-session] > debug1: send channel open 0 > debug1: Entering interactive session. > debug1: ssh_session2_setup: id 0 > debug1: Sending command: scp -v -t ~/test > debug1: channel request 0: exec > debug1: channel 0: open confirm rwindow 0 rmax 32768 > Sending file modes: C0640 16000 test > test 100% |*****************************| 16000 > 00:00 > debug1: channel 0: read<=0 rfd 4 len 0 > debug1: channel 0: read failed > debug1: channel 0: close_read > debug1: channel 0: input open -> drain > debug1: channel 0: ibuf empty > debug1: channel 0: send eof > debug1: channel 0: input drain -> closed > debug1: channel 0: rcvd eof > debug1: channel 0: output open -> drain > debug1: channel 0: obuf empty > debug1: channel 0: close_write > debug1: channel 0: output drain -> closed > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug1: channel 0: rcvd close > debug1: channel 0: almost dead > debug1: channel 0: gc: notify user > debug1: channel 0: gc: user detached > debug1: channel 0: send close > debug1: channel 0: is dead > debug1: channel 0: garbage collecting > debug1: channel_free: channel 0: client-session, nchannels 1 > debug1: fd 0 clearing O_NONBLOCK > debug1: fd 1 clearing O_NONBLOCK > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug1: Exit status 0 > > > > > Thanks! > Aaron Lineberger From Eric.Ladner at ChevronTexaco.com Thu Nov 7 06:44:18 2002 From: Eric.Ladner at ChevronTexaco.com (Ladner, Eric (Eric.Ladner)) Date: Wed, 6 Nov 2002 13:44:18 -0600 Subject: scp output redirection doesn't work... Message-ID: <53D65D67C6AA694284F7584E25ADD3543336EA@nor935nte2k1.nor935.chevrontexaco.net> That is known behavior if stdin/stdout is not a terminal, I believe. You get the same behavior if you run scp in the background. No output. Eric -----Original Message----- From: Lineberger, Aaron CONT (NETS) [mailto:Aaron.Lineberger at nets.nemais.navy.mil] Sent: Wednesday, November 06, 2002 9:51 AM To: 'openssh-unix-dev at mindrot.org' Subject: scp output redirection doesn't work... > OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f > AIX 4.3.3.0 Maintenance Level 10. > > I have run a test on my boxes and found the following: > > > scp test :~/test > test 100% |*****************************| 16000 > 00:00 > > > > scp works fine, but when I tried to redirect stdio/stderr to files > they are empty! :( > > scp test :~/test 1>stdio.out 2>stderr.out ls -l std* > -rw-r----- 1 linaar staff 0 Nov 06 10:35 stderr.out > -rw-r----- 1 linaar staff 0 Nov 06 10:35 stdio.out > > I don't have an issue with ssh IO redirection. (yeah I realize they > are separate programs. ;) Is there some other way to handle the output > from scp or is this a bug? > > Here is the verbose output: > > scp -v test :~/test > Executing: program /usr/local/bin/ssh host , user > (unspecified), command scp -v -t ~/test OpenSSH_3.4p1, SSH protocols > 1.5/2.0, OpenSSL 0x0090607f > debug1: Reading configuration data /usr/local/etc/ssh_config > debug1: Applying options for * > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: ssh_connect: needpriv 0 > debug1: Connecting to sapdev [10.10.112.21] port 22. > debug1: Connection established. > debug1: identity file /home/linaar/.ssh/identity type 1 > debug1: identity file /home/linaar/.ssh/id_rsa type -1 > debug1: identity file /home/linaar/.ssh/id_dsa type -1 > debug1: Remote protocol version 1.99, remote software version > OpenSSH_3.4p1 > debug1: match: OpenSSH_3.4p1 pat OpenSSH* > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.4p1 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: dh_gen_key: priv key bits set: 125/256 > debug1: bits set: 1613/3191 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host '' is known and matches the RSA host key. > debug1: Found key in /home/linaar/.ssh/known_hosts:2 > debug1: bits set: 1574/3191 > debug1: ssh_rsa_verify: signature correct > debug1: kex_derive_keys > debug1: newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: waiting for SSH2_MSG_NEWKEYS > debug1: newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: done: ssh_kex2. > debug1: send SSH2_MSG_SERVICE_REQUEST > debug1: service_accept: ssh-userauth > debug1: got SSH2_MSG_SERVICE_ACCEPT > debug1: authentications that can continue: > publickey,password,keyboard-interactive > debug1: next auth method to try is publickey > debug1: userauth_pubkey_agent: testing agent key rsa-key-20020913 > debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 20043ab8 > hint -1 > debug1: ssh-userauth2 successful: method publickey > debug1: fd 4 setting O_NONBLOCK > debug1: fd 5 setting O_NONBLOCK > debug1: channel 0: new [client-session] > debug1: send channel open 0 > debug1: Entering interactive session. > debug1: ssh_session2_setup: id 0 > debug1: Sending command: scp -v -t ~/test > debug1: channel request 0: exec > debug1: channel 0: open confirm rwindow 0 rmax 32768 > Sending file modes: C0640 16000 test > test 100% |*****************************| 16000 > 00:00 > debug1: channel 0: read<=0 rfd 4 len 0 > debug1: channel 0: read failed > debug1: channel 0: close_read > debug1: channel 0: input open -> drain > debug1: channel 0: ibuf empty > debug1: channel 0: send eof > debug1: channel 0: input drain -> closed > debug1: channel 0: rcvd eof > debug1: channel 0: output open -> drain > debug1: channel 0: obuf empty > debug1: channel 0: close_write > debug1: channel 0: output drain -> closed > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug1: channel 0: rcvd close > debug1: channel 0: almost dead > debug1: channel 0: gc: notify user > debug1: channel 0: gc: user detached > debug1: channel 0: send close > debug1: channel 0: is dead > debug1: channel 0: garbage collecting > debug1: channel_free: channel 0: client-session, nchannels 1 > debug1: fd 0 clearing O_NONBLOCK > debug1: fd 1 clearing O_NONBLOCK > debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 > debug1: Exit status 0 > > > > > Thanks! > Aaron Lineberger _______________________________________________ openssh-unix-dev at mindrot.org mailing list http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From jmknoble at pobox.com Thu Nov 7 06:56:35 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 6 Nov 2002 14:56:35 -0500 Subject: scp output redirection doesn't work... In-Reply-To: ; from Aaron.Lineberger@nets.nemais.navy.mil on Wed, Nov 06, 2002 at 10:50:50AM -0500 References: Message-ID: <20021106145635.A27386@zax.half.pint-stowp.cx> Circa 2002-11-06 10:50:50 -0500 dixit Lineberger, Aaron CONT (NETS): : > OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f : > AIX 4.3.3.0 Maintenance Level 10. : > : > I have run a test on my boxes and found the following: [...] : > scp works fine, but when I tried to redirect stdio/stderr to files they : > are empty! :( [...] : > I don't have an issue with ssh IO redirection. (yeah I realize they are : > separate programs. ;) : > Is there some other way to handle the output from scp or is this a bug? It's not a bug. The progress output goes to stderr, but only if stderr is a terminal. If stderr is not a terminal, scp acts as if you gave the '-q' flag. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "I am non-refutable." --Enik the Altrusian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021106/09a92af9/attachment.bin From bugzilla-daemon at mindrot.org Thu Nov 7 08:38:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 7 Nov 2002 08:38:16 +1100 (EST) Subject: [Bug 429] New: SSH 3.4p1 problems on Tru64 V4.0D & Tru64 V4.0F Message-ID: <20021106213816.449D13D186@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=429 Summary: SSH 3.4p1 problems on Tru64 V4.0D & Tru64 V4.0F Product: Portable OpenSSH Version: 3.4p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: avi.koski at comverse.com We worked with no problems, with the following versions: openssh-3.0.2p1 , openssl-0.9.6b , zlib-1.1.3 We try to upgrade SSH to the new version openssh-3.4p1 (with the previous openssl and zlib versions, or with openssl-0.9.6g and same zlib version). Problem description: ssh works for root and no one else. If we try to ssh from another machine or from the Tru64 machine itself to any user, the connection is closed, after we enter the password. Example (ssh from another of from the same machine - no debug) $ssh -l avi168 10.119.50.168 avi168 at 10.119.50.168's password:xxxxxxxxxx Connection to 10.119.50.168 closed by remote host. Connection to 10.119.50.168 closed. and in the /var/adm/syslog.dated/05-Nov-16:53/auth.log file I get the following messages: Nov 6 11:29:30 trm61 sshd[24723]: Could not reverse map address 10.119.55.210. Nov 6 11:29:30 trm61 sshd[24723]: Accepted password for avi168 from 10.119.55.210 port 34450 ssh2 Nov 6 11:29:30 trm61 sshd[24733]: audgen(LOGIN): Permission denied Nov 6 11:29:30 trm61 sshd[24733]: fatal: Couldn't establish session for avi168 from 10.119.55.210 Example (with debug) $ ssh -vvv -l avi168 10.119.50.168 OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to 10.119.50.168 [10.119.50.168] port 22. debug1: Connection established. debug1: identity file /rlu/users/rluc/.ssh/identity type 0 debug1: identity file /rlu/users/rluc/.ssh/id_rsa type -1 debug1: identity file /rlu/users/rluc/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 debug1: match: OpenSSH_3.4p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman- group1-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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none 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- group1-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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blM-^?%M-&towfish-cbc,cast128- cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.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 sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 140/256 debug1: bits set: 1622/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /rlu/usM-^?%M- &ters/rluc/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host '10.119.50.168' is known and matches the RSA host key. debug1: Found key in /rlu/users/rluc/.ssh/known_hosts:2 debug1: bits set: 1596/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard- interactive debug3: start over, passed a different list publickey,password,keyboard- interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey M-^?%M-&tdebug1: try privkey: /rlu/users/rluc/.ssh/id_rsa debug3: no such identity: /rlu/users/rluc/.ssh/id_rsa debug1: try privkey: /rlu/users/rluc/.ssh/id_dsa debug3: no such identity: /rlu/users/rluc/.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 auth method to try is keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: authentications that can continue: publickey,password,keyboard- interactive 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 auth method to try is password avi168 at 10.119.50.168's password: debug3: packet_send2: adding 48 (len 61 padlen 19 extra_pad 64) debug2: we sent a passwM-^?%M-&tord packet, wait for reply debug1: ssh-userauth2 successful: method password debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 0 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 16 0 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 1 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 1 debug3: tty_make_mM-^?%M-&todes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug1: channel request 0: shell debug1: fd 4 setting TCP_NODELAY debug2: callback done debug1: channel 0: opM-^?%M-&t^Ben confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 5/6) debug3: channel_close_fds: channel 0: r 5 w 6 e 7 Connection to 10.119.50.168 closed by remote host. Connection to 10.119.50.168 closed. debug1: Transferred: stdin 0, stdout 0, stderr 89 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3187.2 debug1: Exit status -1 $ exit Additional info: User sshd have been added an it belongs to group sshd (SSH 3.4 request). /etc/passwd entry : sshd:*:27:27:sshd privsep:/var/empty:/bin/false /etc/group entry : sshd:*:27: The configuration file /usr/etc/ssh_config have not been modified and we use the default file (that includes only commented lines). Questions: Do you know if this version of SSH 3.4p1 have been installed with no such problems on Tru64 V4.0D / V4.0F ? If yes, what is wrong with our usage? Thanks and regards, Avi Koski ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Thu Nov 7 14:54:53 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 6 Nov 2002 19:54:53 -0800 Subject: TCP_NODELAY in Cygwin port In-Reply-To: References: Message-ID: <20021107035453.GA3577@jenny.crlsca.adelphia.net> On Thu, Oct 31, 2002 at 11:28:11AM -0500, Brian Genisio wrote: > I am sorry if this is not really a bug, and I am missing something, but I am running into an issue with port forwarding in SSH. I am using 3.4p1 of SSH on both sides. > > I am running the ssh daemon on a Slackware Linux 8.0 machine, and the ssh client is running in Cywgin version 1.3.13. The ssh client is creating about 7 port forwards in a mix of local and remote forwarding > types. Everything with this setup works great. > > I have an application that runs on the linux side that port forwards to the Cygwin side, and sends a small control packet (4-8 bytes) at a rate of 30 times per second to an application on the Cygwin side. Because > of this, the control application uses TCP_NODELAY in order to send it out as soon as it can. > > If I do not use SSH port forwarding, the control packets are sent at a steady rate. If I use the SSH port forwarding, the data is buffered, and sent in bursts. With this, the packets build up, so nothing is sent for 6 > to 10 frames, and then all are sent at once. This makes for jerky control. > > I have looked into the OpenSSH release notes, and noticed that you added TCP_NODELAY on your endpoints for TCP port forwarding, though it does not seem like it is working properly. > > Unfortunately, I have been unable to tell weather the burst is happening between the sshd and the ssh, or the ssh and the application. As I mentioned, if my control program connects directly to the application, > no buffering is used. > > Do you have any idea to why this is happening? Is there something wrong with the port forwarding implementation of SSH and TCP_NODELAY in Cygwin possibly? I ran both sides in debug mode, and it stated > that TCP_NODELAY was indeed set. i don't know. as you can see, we call set_nodelay() for all ends of port/x11 forwards. i'm not really clear on where source/sink sockets are from the above. can you replace the cygwin piece with non-cygwin and hence eliminate cygwin+MS TCP stack from the picture and see if behaviour changes? otherwise, you need to trace (tcpdump) on all ends and determine where delays originate from. From michael_steffens at hp.com Thu Nov 7 20:52:02 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Thu, 07 Nov 2002 10:52:02 +0100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) Message-ID: <3DCA37C2.3050008@hp.com> Darren Tucker wrote in http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103658633821391 > This raises another possibility for changing passwords. > > As I see it the options now are: > > 1) Platform specific functions > Pro: RFC compliant > Con: extra code that runs as root That's what I would consider the clean solution. And for PAM it would even be only moderately platform specific. But I found it complicated, thus wrote ssh-chauthtok-helper and called it a workaround. > > 2) Spawn /bin/passwd in session > Pro: Simple, portable > Con: Not RFC compliant, possible timing attacks against proto 2? Agreed for non-PAM, but with PAM there arises an issue. (See below) One could consider ssh-chauthtok-helper the PAM-variant of this approach. > 3) Platform-specific setuid helpers > Pro: Consistent v1 & v2 interface, delegate policy to user-written > helpers, RFC compliant. > Con: Potential attacks against setuid programs, repeated code (eg > command line parsing). I think only two of them are required. The system native passwd program is already the suid helper for non-PAM, and for PAM one sshd specific helper can do the job. > > 4) Spawn /bin/passwd in tty (ala "expect") > Pro: portable? RFC compliant. > Con: lots of code, hard to get right, potentially flakey > > I know Markus doesn't like 1) and says that the only portable thing to > do is 2). Isn't this similar the the case for UseLogin? After all the > only portable way to do user authentication is /bin/login, but UseLogin > defaults to no and is considered depreciated, right? > > I'm still in favour of 1). The platform-specific change functions that > I've done so far[0] are ~40 lines (AIX) and ~100 lines (/etc/shadow). > The shadow function handles 3 platforms (Solaris, Redhat, UnixWare). This is only true for Solaris and Redhat (don't know about UnixWare) if sshd is not configured to use PAM for authentication! Otherwise it's calling for mismatches. In the view of PAM "passwd" and "sshd" are different services. The PAM modules configured for them do not need to be the same, and they do not need to be configured with the same parameters. A user could authenticate using one (set of) module(s), but then change password(s) with a different one, using passwd. > The > rest of the patches are required to check whether or not a password is > expired regardless of which method is used to change it. > > Regarding 3): if a consistent enough interface was specified you could > use the same setuid helper for PASSWD_CHANGEREQ during proto 2 > authentication as well as proto 1 sessions. > > Also, can someone who knows PAM please tell me if it's feasible to > implement a function like: > pam_change_password(char *user, char *oldpass, char *newpass)? > Or is some odd PAM module likely to render that impossible? It doesn't even need to be that odd :) Two things do make it impossible in general: - PAM allows to configure multiple modules (and passwords) to be required for a specific service. The pam_chauthtok() function will check them all, according to configuration. But how should that work with only these three arguments for pam_change_password() being given? - PAM is being given a conversation callback function on pam_start(), used for user interaction. How exactly dialogs are being performed is up to the modules then. As an example for an "odd" pw change dialog you may look at the HP-UX default when running in trusted mode: Changing password for dummy Old password: Last successful password change for dummy: NEVER Last unsuccessful password change for dummy: Wed Oct 23 08:35:45 2002 Do you want (choose one letter only): pronounceable passwords generated for you (g) a string of letters generated (l) ? to pick your passwords (p) ? Enter choice here: g Generating random pronounceable password for dummy The password, along with a hyphenated version, is shown. Hit or until you like the choice. When you have chosen the password you want, type it in. Note: type your interrupt character or `quit' to abort at any time. Password: kretavikuj Hyphenation: kret-av-ik-uj Enter password: Password: ruhizacnat Hyphenation: ru-hiz-ac-nat Enter password: Re-enter new password: Passwd successfully changed I would say it's impossible to encapsulate such dialogs using a function like you are suggesting, unless you restrict to option (p), and prepare for being presented the choice, of course. This is also the reason why I found it too complicated to implement the clean solution 1) for the moment. It would require to tunnel the entire conversation between session daemon and monitor, rather than just doing a request/response between these. Cheers! Michael From fcusack at fcusack.com Thu Nov 7 21:42:56 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 7 Nov 2002 02:42:56 -0800 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) In-Reply-To: <3DCA37C2.3050008@hp.com>; from michael_steffens@hp.com on Thu, Nov 07, 2002 at 10:52:02AM +0100 References: <3DCA37C2.3050008@hp.com> Message-ID: <20021107024256.B3161@google.com> On Thu, Nov 07, 2002 at 10:52:02AM +0100, Michael Steffens wrote: > > I would say it's impossible to encapsulate such dialogs using > a function like you are suggesting, unless you restrict > to option (p), and prepare for being presented the choice, > of course. > > This is also the reason why I found it too complicated to > implement the clean solution 1) for the moment. It would > require to tunnel the entire conversation between session > daemon and monitor, rather than just doing a request/response > between these. The keyboard-interactive authentication method does this (and was designed with PAM in mind). It won't work correctly with privsep on (AFAIK). /fc From michael_steffens at hp.com Thu Nov 7 22:40:37 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Thu, 07 Nov 2002 12:40:37 +0100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <3DCA37C2.3050008@hp.com> <20021107024256.B3161@google.com> Message-ID: <3DCA5135.8090209@hp.com> Frank Cusack wrote: > On Thu, Nov 07, 2002 at 10:52:02AM +0100, Michael Steffens wrote: > >> This is also the reason why I found it too complicated to >> implement the clean solution 1) for the moment. It would >> require to tunnel the entire conversation between session >> daemon and monitor, rather than just doing a request/response >> between these. > > > The keyboard-interactive authentication method does this (and was designed > with PAM in mind). It won't work correctly with privsep on (AFAIK). Ooops, not familiar with that part. But if it does only work with privsep off I would assume it doesn't do conversation tunneling between session daemon and monitor, because there is no monitor? Or do I have an oversimplified view of the world here? :) Cheers! Michael From dtucker at zip.com.au Fri Nov 8 00:08:17 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Nov 2002 00:08:17 +1100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <3DCA37C2.3050008@hp.com> Message-ID: <3DCA65C1.B00210E0@zip.com.au> Michael Steffens wrote (in 2 separate messages): > > The platform-specific change functions that > > I've done so far[0] are ~40 lines (AIX) and ~100 lines (/etc/shadow). > > The shadow function handles 3 platforms (Solaris, Redhat, UnixWare). > > This is only true for Solaris and Redhat (don't know about UnixWare) > if sshd is not configured to use PAM for authentication! Otherwise it's > calling for mismatches. Good point. It should include "#if !defined(WITH_PAM)". UnixWare apparently has shadow but no PAM. > > Also, can someone who knows PAM please tell me if it's feasible to > > implement a function like: > > pam_change_password(char *user, char *oldpass, char *newpass)? [snip] > I would say it's impossible to encapsulate such dialogs using > a function like you are suggesting, unless you restrict > to option (p), and prepare for being presented the choice, > of course. That pretty much makes the general case for PAM incompatible with the password change part of the SSH2 userauth-password protocol. The client sends a USERAUTH_REQUEST with the change password flag set, followed by old and new passwords. (This may or may not be after a USERAUTH_CHANGEREQ from the server.) Frank Cusack mentioned keyboard-interactive.. it looks like it's time to RTFRFC again. > But if it does only work with privsep off I would assume it > doesn't do conversation tunneling between session daemon > and monitor, because there is no monitor? I'm still coming to grips with both PAM and privsep so correct me if I'm wrong here, but... PAM uses a callback hook (ie the "conversation" function), right? This conversation function will get called several times, each time with one or more messages to handle? PAM needs root, so the authenticating part has to be in the privileged monitor along with its callback. But the bits that drive the conversation with the user are in the unprivileged child. And privsep allows unpriv->priv calls but not vice versa? So you need to break the conversation function into two pieces with some kind of polling? Ugh, this makes my head hurt. -- 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 bugzilla-daemon at mindrot.org Fri Nov 8 00:31:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 00:31:30 +1100 (EST) Subject: [Bug 430] New: Could add option to sftp-server to disable write access Message-ID: <20021107133130.BC3C63D0E6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=430 Summary: Could add option to sftp-server to disable write access Product: Portable OpenSSH Version: 3.4p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: sftp-server AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: gfernandez at livevault.com This considers adding a flag to the sftp-server which would disable all write operations on the server, effectively making the server readonly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 8 00:32:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 00:32:42 +1100 (EST) Subject: [Bug 430] Could add option to sftp-server to disable write access Message-ID: <20021107133242.6F77C3D1BA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=430 ------- Additional Comments From gfernandez at livevault.com 2002-11-08 00:32 ------- Created an attachment (id=173) --> (http://bugzilla.mindrot.org/attachment.cgi?id=173&action=view) adds readonly flag to sftp-server this applies to sftp-server.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 8 00:35:41 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 00:35:41 +1100 (EST) Subject: [Bug 431] New: scp could prevent write access to server Message-ID: <20021107133541.2E10C3D149@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=431 Summary: scp could prevent write access to server Product: Portable OpenSSH Version: 3.4p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: scp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: gfernandez at livevault.com This provides a compile time mode where scp would refuse write operations. As a result, scp would treat the server as readonly. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 8 00:36:46 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 00:36:46 +1100 (EST) Subject: [Bug 431] scp could prevent write access to server Message-ID: <20021107133646.811483D1C4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=431 ------- Additional Comments From gfernandez at livevault.com 2002-11-08 00:36 ------- Created an attachment (id=174) --> (http://bugzilla.mindrot.org/attachment.cgi?id=174&action=view) adds readonly flag to scp this change applies to scp.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From michael_steffens at hp.com Fri Nov 8 01:16:01 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Thu, 07 Nov 2002 15:16:01 +0100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> Message-ID: <3DCA75A1.7090808@hp.com> Darren Tucker wrote: > I'm still coming to grips with both PAM and privsep so correct me if I'm > wrong here, but... > > PAM uses a callback hook (ie the "conversation" function), right? > This conversation function will get called several times, each time with > one or more messages to handle? > > PAM needs root, so the authenticating part has to be in the privileged > monitor along with its callback. But the bits that drive the > conversation with the user are in the unprivileged child. And privsep > allows unpriv->priv calls but not vice versa? That's how I do understand it (may be wrong). With privsep turned on auth_pam_password(Authctxt *authctxt, const char *password) is called by the monitor. Arguments (in particular the password) have been passed from the unprivileged daemon in the authentication request, before. The function above calls do_pam_authenticate() after setting pamstate = INITIAL_LOGIN which makes the conversation function do_pam_conversation() act "blindly", i.e. reply to PAM using the given passord on every PAM_PROMPT_ECHO_OFF style message, and obviously assuming that there will be only one. Or, more precisely, only one password, that PAM may prompt for arbitrarily often. The unprivileged daemon just gets success or failure returned. The user doesn't see any messages generated by PAM on authentication. Even the prompt, like dummy at localhost's password: is generated by sshd, rather than PAM. And, if the PAM stack for sshd is really configured to prompt for multiple different passwords, authentication will always fail... Ooops! Hadn't thought about the last point yet. But at least the password *change* helper would already be prepared to handle such a setup afterwards, if it had a chance to get called :) And even if it's only about a single passwords, it does add value by handling arbitralily "odd" dialogs. > So you need to break the conversation function into two pieces with some > kind of polling? Ugh, this makes my head hurt. So it did with mine... From bugzilla-daemon at mindrot.org Fri Nov 8 02:14:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 02:14:33 +1100 (EST) Subject: [Bug 427] sftp does not preserve uid/gid on fetch Message-ID: <20021107151433.A16453D1CA@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=427 gfernandez at livevault.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167 is|0 |1 obsolete| | ------- Additional Comments From gfernandez at livevault.com 2002-11-08 02:14 ------- Created an attachment (id=175) --> (http://bugzilla.mindrot.org/attachment.cgi?id=175&action=view) changes to preserve uid/gid on fetch changes to sftp-client.c ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 8 03:32:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 03:32:12 +1100 (EST) Subject: [Bug 414] sshd initially ignores -e (log_stderr) if -i (inetd_flag) is given Message-ID: <20021107163212.8D1713D19D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=414 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-11-08 03:32 ------- applied ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Daniel.D.Olsson at telia.se Fri Nov 8 03:40:14 2002 From: Daniel.D.Olsson at telia.se (Daniel.D.Olsson at telia.se) Date: Thu, 7 Nov 2002 17:40:14 +0100 Subject: Cant run SSHD daemon Message-ID: <03AD0B0B2573644A86F2C1F890691D8F013D3752@TMS011MB.tcad.telia.se> I have compiled openssh for sun solaris 2.6, no errors When I try to run SSHD daemon it says the following error. This platform does not support both privilege separation and compression Compression disabled Privilege separation user sshd does not exist Any one that have answer to this problem mail me on daniel.d.olsson at telia.se //Daniel From mouring at etoh.eviladmin.org Fri Nov 8 04:01:46 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 7 Nov 2002 11:01:46 -0600 (CST) Subject: Cant run SSHD daemon In-Reply-To: <03AD0B0B2573644A86F2C1F890691D8F013D3752@TMS011MB.tcad.telia.se> Message-ID: Install OpenSSH 3.5 - Ben On Thu, 7 Nov 2002 Daniel.D.Olsson at telia.se wrote: > I have compiled openssh for sun solaris 2.6, no errors > When I try to run SSHD daemon it says the following error. > This platform does not support both privilege separation and compression > Compression disabled > Privilege separation user sshd does not exist > Any one that have answer to this problem mail me on daniel.d.olsson at telia.se > > //Daniel > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From jmknoble at pobox.com Fri Nov 8 06:55:37 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 7 Nov 2002 14:55:37 -0500 Subject: Cant run SSHD daemon In-Reply-To: <03AD0B0B2573644A86F2C1F890691D8F013D3752@TMS011MB.tcad.telia.se>; from Daniel.D.Olsson@telia.se on Thu, Nov 07, 2002 at 05:40:14PM +0100 References: <03AD0B0B2573644A86F2C1F890691D8F013D3752@TMS011MB.tcad.telia.se> Message-ID: <20021107145537.E27386@zax.half.pint-stowp.cx> Circa 2002-11-07 17:40:14 +0100 dixit Daniel.D.Olsson at telia.se: : I have compiled openssh for sun solaris 2.6, no errors : When I try to run SSHD daemon it says the following error. : This platform does not support both privilege separation and compression : Compression disabled : Privilege separation user sshd does not exist ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Read the installation instructions that come with OpenSSH. They explain about the 'sshd' user. : Any one that have answer to this problem mail me on : daniel.d.olsson at telia.se -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "I am non-refutable." --Enik the Altrusian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021107/73ab173d/attachment.bin From hannu.liljemark at laurea.fi Fri Nov 8 07:22:34 2002 From: hannu.liljemark at laurea.fi (Hannu Liljemark) Date: Thu, 7 Nov 2002 22:22:34 +0200 Subject: OpenSSH and hostname resolution issues on Solaris Message-ID: <20021107202234.GB14674@charisma.myip.org> Is it a feature or a configuration error with OpenSSH when sshd refuses to answer, if you have DNS configured via /etc/resolv.conf and /etc/nsswitch.conf but the nameservers are not available (due to temporary firewalling glitch, for example)? Worst case the machine never gets past starting sshd during boot, but usually you "just" can't reach the machine with ssh. The OpenSSH in question is anything from ~2.9 to 3.5p1, compiled with tcp_wrappers and sshd: ALL in hosts.allow (if that matters). OS is Solaris 8, but I think we've had it in Sol7 as well. Some answers that turn up when browsing list archives seem to discuss misconfigured reverse-dns combined with all: PARANOID in hosts.deny but we haven't used the paranoid stuff. Sometimes the DNS is just out of reach and that's when things start going wrong. Some simple solution for the problem we've haven't noticed? From dtucker at zip.com.au Fri Nov 8 07:50:25 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Nov 2002 07:50:25 +1100 Subject: OpenSSH and hostname resolution issues on Solaris References: <20021107202234.GB14674@charisma.myip.org> Message-ID: <3DCAD211.76700C94@zip.com.au> Hannu Liljemark wrote: [DNS problems] > Worst case the machine never gets past starting sshd during > boot, but usually you "just" can't reach the machine with ssh. > The OpenSSH in question is anything from ~2.9 to 3.5p1, > compiled with tcp_wrappers and sshd: ALL in hosts.allow (if > that matters). OS is Solaris 8, but I think we've had it in > Sol7 as well. Some of the commands in ssh_prng_cmds might rely on DNS (the arp command is a common offender) and thus hang. This will cause ssh-rand-helper to hang. It's supposed to time out but didn't always. See http://bugzilla.mindrot.org/show_bug.cgi?id=400 > Some simple solution for the problem we've haven't > noticed? Try http://bugzilla.mindrot.org/attachment.cgi?id=156&action=view -- 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 Fri Nov 8 08:26:03 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Nov 2002 08:26:03 +1100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> Message-ID: <3DCADA6B.445A8B6A@zip.com.au> Michael Steffens wrote: > And, if the PAM stack for sshd is really configured to prompt for > multiple different passwords, authentication will always fail... So by rights, PAM authentication should always be done via keyboard-interactive? If you do that, you can throw the pam_chauthok stuff in there 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 dtucker at zip.com.au Fri Nov 8 09:34:59 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Nov 2002 09:34:59 +1100 Subject: From RISKS: secret scrubbing code removed by optimizers Message-ID: <3DCAEA93.CB8D71E4@zip.com.au> This showed up in RISKS and no one has mentioned it here yet, so.. OpenSSH contains lots of code like: char *password = read_passphrase(prompt, 0); [do stuff] memset(password, 0, strlen(password)); From bugzilla-daemon at mindrot.org Fri Nov 8 09:38:27 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 09:38:27 +1100 (EST) Subject: [Bug 369] Inconsistant exiit status from scp Message-ID: <20021107223827.AB20E3D1C3@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=369 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From markus at openbsd.org 2002-11-08 09:38 ------- patch applied. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Fri Nov 8 09:41:56 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 7 Nov 2002 16:41:56 -0600 (CST) Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <3DCAEA93.CB8D71E4@zip.com.au> Message-ID: I know there has been a lot of talk on private OpenBSD lists and it is being ensured that gcc never removes memset() entries on OpenBSD. Personally I think if gcc is optimizing it away it is incorrect. I believe 3.2+ GCC series supports a flag to leave memsets, but I'm not sure how usaged 3.2 is. - Ben On Fri, 8 Nov 2002, Darren Tucker wrote: > This showed up in RISKS and no one has mentioned it here yet, so.. > > OpenSSH contains lots of code like: > > char *password = read_passphrase(prompt, 0); > [do stuff] > memset(password, 0, strlen(password)); > > >From http://online.securityfocus.com/archive/82/297827 > > "clearing sensitive information such as encryption keys from memory may > not work as expected because an optimising compiler removes the memset() > if it decides it's redundant." > > "When compiled with any level of optimisation using gcc, the key > clearing call goes away because of dead code elimination." > > -- > Darren Tucker (dtucker at zip.com.au) > GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From gert at greenie.muc.de Fri Nov 8 10:08:24 2002 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 8 Nov 2002 00:08:24 +0100 Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <3DCAEA93.CB8D71E4@zip.com.au>; from dtucker@zip.com.au on Fri, Nov 08, 2002 at 09:34:59AM +1100 References: <3DCAEA93.CB8D71E4@zip.com.au> Message-ID: <20021108000824.A6252@greenie.muc.de> Hi, On Fri, Nov 08, 2002 at 09:34:59AM +1100, Darren Tucker wrote: > This showed up in RISKS and no one has mentioned it here yet, so.. > > OpenSSH contains lots of code like: > > char *password = read_passphrase(prompt, 0); > [do stuff] > memset(password, 0, strlen(password)); > > >From http://online.securityfocus.com/archive/82/297827 > > "clearing sensitive information such as encryption keys from memory may > not work as expected because an optimising compiler removes the memset() > if it decides it's redundant." > > "When compiled with any level of optimisation using gcc, the key > clearing call goes away because of dead code elimination." I don't think this applies here. The compiler can't know that the memory area isn't used by other functions. What you are referring to is: int foo() { char password[100] = "secret!"; memset(password, 0, sizeof(password); return; } in that case, "password" is a local variable to the function, and the compiler can rightfully assume that it will never be accessed after function return (because it's on the stack and its scope doesn't exist anymore). 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.doering at physik.tu-muenchen.de From gem at rellim.com Fri Nov 8 10:51:44 2002 From: gem at rellim.com (Gary E. Miller) Date: Thu, 7 Nov 2002 15:51:44 -0800 (PST) Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <20021108000824.A6252@greenie.muc.de> Message-ID: Yo Gert! On Fri, 8 Nov 2002, Gert Doering wrote: > in that case, "password" is a local variable to the function, and the > compiler can rightfully assume that it will never be accessed after > function return (because it's on the stack and its scope doesn't exist > anymore). In a non-paranoid world you are correct. In a paranoid world further analysis is required. If the memset() is eliminated as "dead code", then the password stays on the stack. Then anyone looking at /dev/kmem can see it in the clear. Worse yet, the stack could be swapped out to disk and now the password in on the disk in the clear. We can hope that another subroutine is soon called, and that part of the stack is overwritten, but there is a much longer window of exposure than if the memset() was executed. Maybe password could be declared with the "volatile" attribute to prevent this optimization. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 From bugzilla-daemon at mindrot.org Fri Nov 8 11:48:52 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 11:48:52 +1100 (EST) Subject: [Bug 432] New: AIX does not log login attempts for unknown users Message-ID: <20021108004852.F09CD3D1CE@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=432 Summary: AIX does not log login attempts for unknown users Product: Portable OpenSSH Version: -current Platform: PPC OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dtucker at zip.com.au A login attempt by an unknown user (eg via telnet) normally gets logged as: syslog: pts/4: failed login attempt for UNKNOWN_USER from my.host.com This is generated by a call to loginfailed(), which substitutes UNKNOWN_HOST for the username if it doesn't exist. AIX never finds out about it because getpwnamallow returns as soon as it finds no passwd entry. Following patch calls loginfailed before returning. It generates: syslog: ssh: failed login attempt for UNKNOWN_USER from my.host.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 8 11:50:48 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 11:50:48 +1100 (EST) Subject: [Bug 432] AIX does not log login attempts for unknown users Message-ID: <20021108005048.527C03D1D4@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=432 ------- Additional Comments From dtucker at zip.com.au 2002-11-08 11:50 ------- Created an attachment (id=176) --> (http://bugzilla.mindrot.org/attachment.cgi?id=176&action=view) Call loginfailed() on AIX for unknown usernames ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From carson at taltos.org Fri Nov 8 12:13:30 2002 From: carson at taltos.org (Carson Gaspar) Date: Thu, 07 Nov 2002 20:13:30 -0500 Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: References: Message-ID: <669222625.1036700010@[192.168.20.2]> --On Thursday, November 07, 2002 4:41 PM -0600 Ben Lindstrom wrote: > > I know there has been a lot of talk on private OpenBSD lists and it is > being ensured that gcc never removes memset() entries on OpenBSD. > > Personally I think if gcc is optimizing it away it is incorrect. I > believe 3.2+ GCC series supports a flag to leave memsets, but I'm not sure > how usaged 3.2 is. If you don't want the memset() optimized away, you should declare the variable volatile. -- Carson From bob at proulx.com Fri Nov 8 12:50:35 2002 From: bob at proulx.com (Bob Proulx) Date: Thu, 7 Nov 2002 18:50:35 -0700 Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: References: <20021108000824.A6252@greenie.muc.de> Message-ID: <20021108015035.GA4596@misery.proulx.com> Gary E. Miller [2002-11-07 15:51:44 -0800]: > On Fri, 8 Nov 2002, Gert Doering wrote: > > > in that case, "password" is a local variable to the function, and the > > compiler can rightfully assume that it will never be accessed after > > function return (because it's on the stack and its scope doesn't exist > > anymore). > > In a non-paranoid world you are correct. In a paranoid world further > analysis is required. > > If the memset() is eliminated as "dead code", then the password stays on > the stack. Then anyone looking at /dev/kmem can see it in the clear. > Worse yet, the stack could be swapped out to disk and now the password > in on the disk in the clear. Right and Gert I believe agrees with you if I read that right. But he was saying that was not the case and therefore that was why gcc would not be optimizing it away. I think you both are in agreement. Bob From dan at doxpara.com Fri Nov 8 13:07:39 2002 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 07 Nov 2002 18:07:39 -0800 Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: References: Message-ID: <3DCB1C6B.50707@doxpara.com> Ben Lindstrom wrote: >I know there has been a lot of talk on private OpenBSD lists and it is >being ensured that gcc never removes memset() entries on OpenBSD. > >Personally I think if gcc is optimizing it away it is incorrect. I >believe 3.2+ GCC series supports a flag to leave memsets, but I'm not sure >how usaged 3.2 is. > > Just to be a bit paranoid, Has somebody actually verified this optimizing behavior in any build of GCC? Does voliatile actually stop it? --Dan From mouring at etoh.eviladmin.org Fri Nov 8 13:00:27 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 7 Nov 2002 20:00:27 -0600 (CST) Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <669222625.1036700010@[192.168.20.2]> Message-ID: On Thu, 7 Nov 2002, Carson Gaspar wrote: > > > --On Thursday, November 07, 2002 4:41 PM -0600 Ben Lindstrom > wrote: > > > > > I know there has been a lot of talk on private OpenBSD lists and it is > > being ensured that gcc never removes memset() entries on OpenBSD. > > > > Personally I think if gcc is optimizing it away it is incorrect. I > > believe 3.2+ GCC series supports a flag to leave memsets, but I'm not sure > > how usaged 3.2 is. > > If you don't want the memset() optimized away, you should declare the > variable volatile. > There has been talked that this my not solve the problem. The correct thing is to set a gcc flag telling gcc to leave memset() the heck alone =-) - Ben From mouring at etoh.eviladmin.org Fri Nov 8 15:14:50 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 7 Nov 2002 22:14:50 -0600 (CST) Subject: memset suggestion. Message-ID: Since 3.x is rolling out with -fno-builtin- support maybe we should test for 3.x and set -fno-builtin-memset which should stop gcc from optimizing it away. And maybe everyone should look for the same feature in their favorite compiler. There is not much OpenSSH can do about bad compilers optimization, but that is the only reasonable way to stop it starting in the 3.x series of gcc. - Ben From dtucker at zip.com.au Fri Nov 8 15:59:23 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Nov 2002 15:59:23 +1100 Subject: From RISKS: secret scrubbing code removed by optimizers References: <3DCB1C6B.50707@doxpara.com> Message-ID: <3DCB44AB.9F37993@zip.com.au> Dan Kaminsky wrote: > Has somebody actually verified this optimizing behavior in any build > of GCC? Does voliatile actually stop it? Yes (gcc-3.2 on a SPARC). Yes. -Daz. Test function: void myfunc1() { char p[100]; scanf("%s\n", &p); memset(p, 0, 100); } gcc -s testfunc.c gives: myfunc1: !#PROLOGUE# 0 save %sp, -216, %sp !#PROLOGUE# 1 add %fp, -120, %o1 sethi %hi(.LLC0), %o0 or %o0, %lo(.LLC0), %o0 call scanf, 0 nop add %fp, -120, %o0 mov 0, %o1 mov 100, %o2 call memset, 0 nop nop ret restore gcc -s -O3 testfunc.c myfunc1: !#PROLOGUE# 0 save %sp, -216, %sp !#PROLOGUE# 1 sethi %hi(.LLC0), %g1 or %g1, %lo(.LLC0), %o0 call scanf, 0 add %fp, -120, %o1 nop ret restore Add "volatile" and inlines and unrolls memset: myfunc1: !#PROLOGUE# 0 save %sp, -216, %sp !#PROLOGUE# 1 sethi %hi(.LLC0), %g1 or %g1, %lo(.LLC0), %o0 call scanf, 0 add %fp, -120, %o1 mov 0, %o2 mov 0, %o3 std %o2, [%fp-120] std %o2, [%fp-112] std %o2, [%fp-104] std %o2, [%fp-96] std %o2, [%fp-88] std %o2, [%fp-80] std %o2, [%fp-72] std %o2, [%fp-64] std %o2, [%fp-56] std %o2, [%fp-48] std %o2, [%fp-40] std %o2, [%fp-32] st %g0, [%fp-24] nop ret restore -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From gem at rellim.com Fri Nov 8 17:08:24 2002 From: gem at rellim.com (Gary E. Miller) Date: Thu, 7 Nov 2002 22:08:24 -0800 (PST) Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <3DCB44AB.9F37993@zip.com.au> Message-ID: Yo All! On Fri, 8 Nov 2002, Darren Tucker wrote: > Dan Kaminsky wrote: > > Has somebody actually verified this optimizing behavior in any build > > of GCC? Does voliatile actually stop it? > > Yes (gcc-3.2 on a SPARC). Yes. Same test on gcc 3.2 and gcc 2.95.2 with i686-linux. I can not get memset() to optimize away. Maybe with other switches it will. Normal compile, gcc 3.2: gcc -S testfunc.c myfunc1: pushl %ebp movl %esp, %ebp subl $136, %esp movl $.LC0, (%esp) leal -120(%ebp), %eax movl %eax, 4(%esp) call scanf leal -120(%ebp), %eax movl %eax, (%esp) movl $0, 4(%esp) movl $100, 8(%esp) call memset leave ret gcc -S -O1 testfunc.c myfunc1: pushl %ebp movl %esp, %ebp subl $136, %esp movl %edi, -4(%ebp) movl $.LC0, (%esp) leal -120(%ebp), %edi movl %edi, 4(%esp) call scanf cld movl $25, %ecx movl $0, %eax rep stosl movl -4(%ebp), %edi movl %ebp, %esp popl %ebp ret gcc -S -O2 testfunc.c and gcc -S -O3 testfunc.c myfunc1: pushl %ebp movl %esp, %ebp subl $136, %esp movl %edi, -4(%ebp) leal -120(%ebp), %edi movl %edi, 4(%esp) movl $.LC0, (%esp) call scanf xorl %eax, %eax movl $25, %ecx cld rep stosl movl -4(%ebp), %edi movl %ebp, %esp popl %ebp ret Similar results w/ gcc 2.95.3 RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 From markus at openbsd.org Fri Nov 8 19:51:45 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 8 Nov 2002 09:51:45 +0100 Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <3DCAEA93.CB8D71E4@zip.com.au> References: <3DCAEA93.CB8D71E4@zip.com.au> Message-ID: <20021108085145.GB10554@folly> On Fri, Nov 08, 2002 at 09:34:59AM +1100, Darren Tucker wrote: > This showed up in RISKS and no one has mentioned it here yet, so.. > > OpenSSH contains lots of code like: > > char *password = read_passphrase(prompt, 0); > [do stuff] > memset(password, 0, strlen(password)); this is not a problem, because 'password' is not on the stack. however, there are other cases when memset() is called for automatic variables. -m From vinschen at redhat.com Fri Nov 8 19:57:41 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 8 Nov 2002 09:57:41 +0100 Subject: memset suggestion. In-Reply-To: References: Message-ID: <20021108095741.M24497@cygbert.vinschen.de> On Thu, Nov 07, 2002 at 10:14:50PM -0600, Ben Lindstrom wrote: > > Since 3.x is rolling out with -fno-builtin- support maybe we > should test for 3.x and set -fno-builtin-memset which should stop gcc from > optimizing it away. And maybe everyone should look for the same feature > in their favorite compiler. > > There is not much OpenSSH can do about bad compilers optimization, but > that is the only reasonable way to stop it starting in the 3.x series of > gcc. Can you enlighten us why it is bad? I'm not a compiler guru... Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From michael_steffens at hp.com Fri Nov 8 21:00:05 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Fri, 08 Nov 2002 11:00:05 +0100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> Message-ID: <3DCB8B25.6020207@hp.com> Darren Tucker wrote: > Michael Steffens wrote: > >>And, if the PAM stack for sshd is really configured to prompt for >>multiple different passwords, authentication will always fail... > > > So by rights, PAM authentication should always be done via > keyboard-interactive? If you do that, you can throw the pam_chauthok > stuff in there too? > Yes and no :) If keyboard-interactive would work in privsep mode (it doesn't, at least for me) and if it would be also available for protocol 1, which it isn't, it could be the general PAM authentication channel. But it's main purpose (may be wrong there) seems to be providing a full PAM conversation to the client without a local TTY, analogously to the INITIAL_LOGIN mode with do_pam_conversation(). For pam_chauthok() this is not relevant, because it is to be called after successful authentication with session and TTY established. So I doubt that keyboard-interactive is the appropriate place to throw pam_chauthok in. From bugzilla-daemon at mindrot.org Fri Nov 8 21:19:23 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 8 Nov 2002 21:19:23 +1100 (EST) Subject: [Bug 431] scp could prevent write access to server Message-ID: <20021108101923.E0D743D1F0@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=431 rumen at skalasoft.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From rumen at skalasoft.com 2002-11-08 21:19 ------- What about command: $ ssh user at host '( cat > FILE_NAME_ON_REMOTE_HOST )' < FILE_NAME_ON_LOCAL_HOST this is same as: $ scp FILE_NAME_ON_LOCAL_HOST user at host:FILE_NAME_ON_REMOTE_HOST ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From fcusack at fcusack.com Fri Nov 8 22:50:13 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Fri, 8 Nov 2002 03:50:13 -0800 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) In-Reply-To: <3DCB8B25.6020207@hp.com>; from michael_steffens@hp.com on Fri, Nov 08, 2002 at 11:00:05AM +0100 References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> Message-ID: <20021108035013.B6799@google.com> On Fri, Nov 08, 2002 at 11:00:05AM +0100, Michael Steffens wrote: > Darren Tucker wrote: > > Michael Steffens wrote: > > > >>And, if the PAM stack for sshd is really configured to prompt for > >>multiple different passwords, authentication will always fail... > > > > > > So by rights, PAM authentication should always be done via > > keyboard-interactive? If you do that, you can throw the pam_chauthok > > stuff in there too? > > > > Yes and no :) Just yes, really. The PAM framework demands the type of exchange that only keyboard-interactive offers. The way the "password" authentication method interacts with PAM is a kludge. > If keyboard-interactive would work in privsep mode (it doesn't, at > least for me) It does not because PAM in general requires root privs and in privsep mode the PAM code runs in the unpriv part. The correct fix IMHO is to move the PAM code into the priv part. I don't know if this is feasible, but from a security standpoint should be pretty good. The PAM code is a small part to look at and any bugs are going to be in the PAM libs, not openssh. > and if it would be also available for protocol 1, which it isn't, Not so fast there. :-) Look in the bugs db for a TISviaPAM patch. This uses the ssh1 TIS auth method to do the same thing that kbdint does. > it could be the general PAM authentication channel. > > But it's main purpose (may be wrong there) seems to be providing a > full PAM conversation to the client without a local TTY, analogously > to the INITIAL_LOGIN mode with do_pam_conversation(). > > For pam_chauthok() this is not relevant, because it is to be called > after successful authentication with session and TTY established. Not necessarily. PAM has two ways to make you change your password (during authentication). 1) in the call to pam_authenticate(), the module can determine that your password is expired and force a password change. 2) in the call to pam_acct_mgmt(), the module can determine that your password is expired and return PAM_AUTHTOK_EXPIRED. Then the application must drive the password change. In ssh, all of this would (could) happen during the "single" kbdint exchange. I don't think (1) is likely. During (2), it's up to the app to call pam_chauthtok(). In openssh, this would happen while still in the authentication exchange. > So I doubt that keyboard-interactive is the appropriate place to > throw pam_chauthok in. It is the correct place. But it still won't work with privsep on. The PAM code needs to run privileged. /fc From bugzilla-daemon at mindrot.org Sat Nov 9 00:05:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 9 Nov 2002 00:05:54 +1100 (EST) Subject: [Bug 431] scp could prevent write access to server Message-ID: <20021108130554.18EB43D1F1@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=431 ------- Additional Comments From gfernandez at livevault.com 2002-11-09 00:05 ------- like most security issues, this change would not be sufficient by itself. In my setup I've made other changes that make cat unavailable (i.e. by using chroot ()). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Sat Nov 9 00:55:25 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 8 Nov 2002 07:55:25 -0600 (CST) Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: <3DCB44AB.9F37993@zip.com.au> Message-ID: On Fri, 8 Nov 2002, Darren Tucker wrote: > Dan Kaminsky wrote: > > Has somebody actually verified this optimizing behavior in any build > > of GCC? Does voliatile actually stop it? > > Yes (gcc-3.2 on a SPARC). Yes. > does setting -fno-builtin-memset at compile time stop gcc from miscompiling? - Ben > -Daz. > > Test function: > void myfunc1() > { > char p[100]; > > scanf("%s\n", &p); > memset(p, 0, 100); > } > > gcc -s testfunc.c gives: > myfunc1: > !#PROLOGUE# 0 > save %sp, -216, %sp > !#PROLOGUE# 1 > add %fp, -120, %o1 > sethi %hi(.LLC0), %o0 > or %o0, %lo(.LLC0), %o0 > call scanf, 0 > nop > add %fp, -120, %o0 > mov 0, %o1 > mov 100, %o2 > call memset, 0 > nop > nop > ret > restore > > gcc -s -O3 testfunc.c > myfunc1: > !#PROLOGUE# 0 > save %sp, -216, %sp > !#PROLOGUE# 1 > sethi %hi(.LLC0), %g1 > or %g1, %lo(.LLC0), %o0 > call scanf, 0 > add %fp, -120, %o1 > nop > ret > restore > > Add "volatile" and inlines and unrolls memset: > myfunc1: > !#PROLOGUE# 0 > save %sp, -216, %sp > !#PROLOGUE# 1 > sethi %hi(.LLC0), %g1 > or %g1, %lo(.LLC0), %o0 > call scanf, 0 > add %fp, -120, %o1 > mov 0, %o2 > mov 0, %o3 > std %o2, [%fp-120] > std %o2, [%fp-112] > std %o2, [%fp-104] > std %o2, [%fp-96] > std %o2, [%fp-88] > std %o2, [%fp-80] > std %o2, [%fp-72] > std %o2, [%fp-64] > std %o2, [%fp-56] > std %o2, [%fp-48] > std %o2, [%fp-40] > std %o2, [%fp-32] > st %g0, [%fp-24] > nop > ret > restore > > -- > Darren Tucker (dtucker at zip.com.au) > GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From mouring at etoh.eviladmin.org Sat Nov 9 01:05:44 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 8 Nov 2002 08:05:44 -0600 (CST) Subject: memset suggestion. In-Reply-To: <20021108095741.M24497@cygbert.vinschen.de> Message-ID: On Fri, 8 Nov 2002, Corinna Vinschen wrote: > On Thu, Nov 07, 2002 at 10:14:50PM -0600, Ben Lindstrom wrote: > > > > Since 3.x is rolling out with -fno-builtin- support maybe we > > should test for 3.x and set -fno-builtin-memset which should stop gcc from > > optimizing it away. And maybe everyone should look for the same feature > > in their favorite compiler. > > > > There is not much OpenSSH can do about bad compilers optimization, but > > that is the only reasonable way to stop it starting in the 3.x series of > > gcc. > > Can you enlighten us why it is bad? I'm not a compiler guru... > Everyone uses memset() to clear inmemory passwords so people can't go digging around in /dev/kmem. If memset() is optimizated out then the password still stick around in memory until it is reallocated and reused. But this is only half of the issue. It could still be in registers or in the stack. Which memset() does not solve. I saw a post on OpenBSD mailinglist that gave an example of a function that may work for clearing all three and that should not be optimized out. I'll dig around for it and repost it here. I don't know how much action should be taken on this. Hacking around one gcc bug always leads to another version of gcc horking up a furball or some other compiler whining and moaning about it. Personally everyone I see that compiles software at greater than -O2 I tend to LART them over the head with either the bat book or 'hack proofing your network'. That seems to get their attention to explain why higher levels of -O may not be what the want (mainly when they come whining about their code not working..). - Ben From eddygeez at yahoo.com Sat Nov 9 02:04:49 2002 From: eddygeez at yahoo.com (Eddy) Date: Fri, 8 Nov 2002 07:04:49 -0800 (PST) Subject: Will OpenSSH fallback to internal PRNG? Message-ID: <20021108150449.61965.qmail@web9602.mail.yahoo.com> Greetings. I'm wondering if OpenSSH automatically falls back to the internal PRNG (such as used on Solaris) when it can't use a better alternative. The reason I ask is this: the machine I am compiling OpenSSH on has the /dev/random patch for Solaris 8. I'd like OpenSSH to use /dev/random whenever possible, if it exists. However, I'd prefer NOT to have to compile a separate version that doesn't use /dev/random for the Sol8 boxes which do NOT have the /dev/random patch. If OpenSSH falls back to the internal PRNG, then great, problem solved! If not, how hard would it be to implement such a feature? I'm hoping OpenSSH automatically "falls back" to its internal PRNG if it can't use/find a "better" one that it was compiled with. (Similar thing would be when using something like 'prngd'; what happens if the daemon isn't running? Will OpenSSH fall back to internal PRNG, or are you SOL?) Thanks for any insight! Eddy __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From vinschen at redhat.com Sat Nov 9 02:15:08 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 8 Nov 2002 16:15:08 +0100 Subject: memset suggestion. In-Reply-To: References: <20021108095741.M24497@cygbert.vinschen.de> Message-ID: <20021108161508.L21920@cygbert.vinschen.de> On Fri, Nov 08, 2002 at 08:05:44AM -0600, Ben Lindstrom wrote: > Everyone uses memset() to clear inmemory passwords so people can't go > digging around in /dev/kmem. If memset() is optimizated out then the > password still stick around in memory until it is reallocated and reused. > [...] Thanks for the description. However, I just saw that I didn't read a ML thread carefully enough :-( Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From mouring at etoh.eviladmin.org Sat Nov 9 02:12:14 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 8 Nov 2002 09:12:14 -0600 (CST) Subject: Will OpenSSH fallback to internal PRNG? In-Reply-To: <20021108150449.61965.qmail@web9602.mail.yahoo.com> Message-ID: ./configure --with-rand-helper will ensure the entropy code is always installed. OpenSSH will check with OpenSSL to see if it can seed itself. If it can not it will then fall back to it's internal entropy code. - Ben On Fri, 8 Nov 2002, Eddy wrote: > Greetings. > > I'm wondering if OpenSSH automatically falls back to the internal > PRNG (such as used on Solaris) when it can't use a better alternative. > > The reason I ask is this: the machine I am compiling OpenSSH on has > the /dev/random patch for Solaris 8. I'd like OpenSSH to use > /dev/random > whenever possible, if it exists. However, I'd prefer NOT to have to > compile a separate version that doesn't use /dev/random for the Sol8 > boxes which do NOT have the /dev/random patch. If OpenSSH falls back > to the internal PRNG, then great, problem solved! If not, how hard > would it be to implement such a feature? > > I'm hoping OpenSSH automatically "falls back" to its internal PRNG > if it can't use/find a "better" one that it was compiled with. > > (Similar thing would be when using something like 'prngd'; what happens > if the daemon isn't running? Will OpenSSH fall back to internal PRNG, > or are you SOL?) > > Thanks for any insight! > > Eddy > > > > > __________________________________________________ > Do you Yahoo!? > U2 on LAUNCH - Exclusive greatest hits videos > http://launch.yahoo.com/u2 > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From mouring at etoh.eviladmin.org Sat Nov 9 02:14:10 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 8 Nov 2002 09:14:10 -0600 (CST) Subject: ALERT - GroupShield ticket number OB5734_1036765092_SBAYECEX005_ 3 was generated (fwd) Message-ID: Who ever owns this server can you please correct this issue. Filtering 'spam' based on subject like is extremely stupid, and I'm getting tired of getting this email every other message. - Ben ---------- Forwarded message ---------- Date: Fri, 8 Nov 2002 14:18:13 -0000 From: NAIBTX002SBAYECEX005 at btx002.bt.com To: mouring at etoh.eviladmin.org Subject: ALERT - GroupShield ticket number OB5734_1036765092_SBAYECEX005_ 3 was generated Action Taken: The message was blocked because of its subject. To: Darren TuckerOpenSSH Devel List From: Ben Lindstrom Sent: -1417909760,29525809 Subject: From marco.ortisi at flashcom.it Sat Nov 9 03:19:28 2002 From: marco.ortisi at flashcom.it (marco.ortisi at flashcom.it) Date: Fri, 08 Nov 2002 16:19:28 GMT Subject: bug on openssh 3.5p1 Message-ID: <20021108161928.24366.qmail@mail.flashcom.it> Excuse me in advance for my poor english I have noted a small bug on OpenSSH 3.5p1. When user root is not permitted to log in a system (PermitRoot no) and a correct password is submitted for it to server, a RST packet is issued from server to client: [root at xxx root]# ssh victim root at victim's password: Permission denied, please try again. root at victim's password: Permission denied, please try again. ......... root at victim's password: Read from remote host 10.12.7.110: Connection reset by peer Connection to victim closed. tcpdump session: 12:17:32.650039 attacker.32804 > victim.22: S 1378959426:1378959426(0) win 5840 12:17:32.650538 victim.22 > attacker.32804: S 671772074:671772074(0) ack 1378959427 win 5792 12:17:32.650627 attacker.32804 > victim.22: . ack 1 win 5840 12:17:32.651741 victim.22 > attacker.32804: P 1:24(23) ack 1 win 5792 12:17:32.652078 attacker.32804 > victim.22: . ack 24 win 5840 12:17:32.652552 attacker.32804 > victim.22: P 1:23(22) ack 24 win 5840 12:17:32.652665 victim.22 > attacker.32804: . ack 23 win 5792 12:17:32.653418 attacker.32804 > victim.22: P 23:567(544) ack 24 win 5840 12:17:32.653684 victim.22 > attacker.32804: . ack 567 win 6528 12:17:32.654515 victim.22 > attacker.32804: P 24:568(544) ack 567 win 6528 12:17:32.654976 attacker.32804 > victim.22: P 567:591(24) ack 568 win 6528 12:17:32.660227 victim.22 > attacker.32804: P 568:992(424) ack 591 win 6528 12:17:32.696527 attacker.32804 > victim.22: P 591:1007(416) ack 992 win 7616 12:17:32.729500 victim.22 > attacker.32804: . ack 1007 win 7616 12:17:32.731171 victim.22 > attacker.32804: P 992:1728(736) ack 1007 win 7616 12:17:32.769467 attacker.32804 > victim.22: . ack 1728 win 8832 12:17:32.776527 attacker.32804 > victim.22: P 1007:1023(16) ack 1728 win 8832 12:17:32.776642 victim.22 > attacker.32804: . ack 1023 win 7616 12:17:32.777104 attacker.32804 > victim.22: P 1023:1071(48) ack 1728 win 8832 12:17:32.777226 victim.22 > attacker.32804: . ack 1071 win 7616 12:17:32.777326 victim.22 > attacker.32804: P 1728:1776(48) ack 1071 win 7616 12:17:32.777711 attacker.32804 > victim.22: . ack 1776 win 8832 12:17:32.778119 attacker.32804 > victim.22: P 1071:1135(64) ack 1776 win 8832 12:17:32.782956 victim.22 > attacker.32804: P 1776:1856(80) ack 1135 win 7616 12:17:32.783357 attacker.32804 > victim.22: P 1135:1231(96) ack 1856 win 8832 12:17:32.783594 victim.22 > attacker.32804: P 1856:1936(80) ack 1231 win 7616 12:17:32.822179 attacker.32804 > victim.22: . ack 1936 win 8832 12:17:44.779338 attacker.32804 > victim.22: P 1231:1375(144) ack 1936 win 8832 12:17:44.782988 victim.22 > attacker.32804: P 1936:1968(32) ack 1375 win 7616 12:17:44.783015 attacker.32804 > victim.22: . ack 1968 win 8832 12:17:44.783402 attacker.32804 > victim.22: P 1375:1439(64) ack 1968 win 8832 12:17:44.784724 victim.22 > attacker.32804: R 1968:1968(0) ack 1439 win 7616 This behavior can be used for root's password brute force attack. In OpenSSH 3.4 and low version the correct behavior was this: [root at xxx root]# ssh victim root at victim's password: Permission denied, please try again. root at victim's password: Permission denied, please try again. root at victim's password: Permission denied (publickey,password,keyboard-interactive). [root at ghetuetto root]# 12:18:36.066006 attacker.32805 > victim.22: S 1441357334:1441357334(0) win 5840 12:18:36.066132 victim.22 > attacker.32805: S 733426253:733426253(0) ack 1441357335 win 5792 12:18:36.066187 attacker.32805 > victim.22: . ack 1 win 5840 12:18:36.067281 victim.22 > attacker.32805: P 1:24(23) ack 1 win 5792 12:18:36.067344 attacker.32805 > victim.22: . ack 24 win 5840 12:18:36.068190 attacker.32805 > victim.22: P 1:23(22) ack 24 win 5840 12:18:36.068309 victim.22 > attacker.32805: . ack 23 win 5792 12:18:36.069017 attacker.32805 > victim.22: P 23:567(544) ack 24 win 5840 12:18:36.069287 victim.22 > attacker.32805: . ack 567 win 6528 12:18:36.070158 victim.22 > attacker.32805: P 24:568(544) ack 567 win 6528 12:18:36.070640 attacker.32805 > victim.22: P 567:591(24) ack 568 win 6528 12:18:36.075567 victim.22 > attacker.32805: P 568:992(424) ack 591 win 6528 12:18:36.111904 attacker.32805 > victim.22: P 591:1007(416) ack 992 win 7616 12:18:36.146240 victim.22 > attacker.32805: P 992:1728(736) ack 1007 win 7616 12:18:36.183531 attacker.32805 > victim.22: . ack 1728 win 8832 12:18:36.191387 attacker.32805 > victim.22: P 1007:1023(16) ack 1728 win 8832 12:18:36.226436 victim.22 > attacker.32805: . ack 1023 win 7616 12:18:36.226489 attacker.32805 > victim.22: P 1023:1071(48) ack 1728 win 8832 12:18:36.226602 victim.22 > attacker.32805: . ack 1071 win 7616 12:18:36.226709 victim.22 > attacker.32805: P 1728:1776(48) ack 1071 win 7616 12:18:36.227105 attacker.32805 > victim.22: . ack 1776 win 8832 12:18:36.227506 attacker.32805 > victim.22: P 1071:1135(64) ack 1776 win 8832 12:18:36.232244 victim.22 > attacker.32805: P 1776:1856(80) ack 1135 win 7616 12:18:36.232646 attacker.32805 > victim.22: P 1135:1231(96) ack 1856 win 8832 12:18:36.232877 victim.22 > attacker.32805: P 1856:1936(80) ack 1231 win 7616 12:18:36.271398 attacker.32805 > victim.22: . ack 1936 win 8832 12:18:40.784165 attacker.32805 > victim.22: P 1231:1375(144) ack 1936 win 8832 12:18:40.817684 victim.22 > attacker.32805: . ack 1375 win 7616 12:18:43.138984 victim.22 > attacker.32805: P 1936:2016(80) ack 1375 win 7616 12:18:43.139018 attacker.32805 > victim.22: . ack 2016 win 8832 12:19:00.035910 attacker.32805 > victim.22: P 1375:1519(144) ack 2016 win 8832 12:19:00.036060 victim.22 > attacker.32805: . ack 1519 win 7616 12:19:02.383905 victim.22 > attacker.32805: P 2016:2096(80) ack 1519 win 7616 12:19:02.383954 attacker.32805 > victim.22: . ack 2096 win 8832 12:19:22.108082 attacker.32805 > victim.22: P 1519:1663(144) ack 2096 win 8832 12:19:22.108250 victim.22 > attacker.32805: . ack 1663 win 7616 12:19:24.459964 victim.22 > attacker.32805: P 2096:2176(80) ack 1663 win 7616 12:19:24.460016 attacker.32805 > victim.22: . ack 2176 win 8832 12:19:24.460332 attacker.32805 > victim.22: F 1663:1663(0) ack 2176 win 8832 12:19:24.460536 victim.22 > attacker.32805: F 2176:2176(0) ack 1664 win 7616 12:19:24.460591 attacker.32805 > victim.22: . ack 2177 win 8832 Regards, Marco Ortisi From binder at arago.de Sat Nov 9 03:41:55 2002 From: binder at arago.de (Thomas Binder) Date: Fri, 8 Nov 2002 17:41:55 +0100 Subject: From RISKS: secret scrubbing code removed by optimizers In-Reply-To: ; from gem@rellim.com on Thu, Nov 07, 2002 at 03:51:44PM -0800 References: <20021108000824.A6252@greenie.muc.de> Message-ID: <20021108174155.A27131977@ohm.arago.de> Hi! On Thu, Nov 07, 2002 at 03:51:44PM -0800, Gary E. Miller wrote: > If the memset() is eliminated as "dead code", then the password > stays on the stack. Then anyone looking at /dev/kmem can see it > in the clear. The question is, though, why someone having access rights to read /dev/kmem or swap space wouldn't rather install a trojaned or otherwise modified sshd instead to snoop credentials. Ciao Thomas From appro at fy.chalmers.se Sat Nov 9 04:13:54 2002 From: appro at fy.chalmers.se (Andy Polyakov) Date: Fri, 08 Nov 2002 18:13:54 +0100 Subject: memset suggestion. References: Message-ID: <3DCBF0D2.AFC3D901@fy.chalmers.se> > > > Since 3.x is rolling out with -fno-builtin- support maybe we > > > should test for 3.x and set -fno-builtin-memset which should stop gcc from > > > optimizing it away. And maybe everyone should look for the same feature > > > in their favorite compiler. Why not pick and stick to a workaround that works with all compilers, is independent on compiler flags and is safe at any optimization level? As pointed out in my (sorry for quoting myself:-) submission to Bugtraq http://online.securityfocus.com/archive/1/298835/2002-11-05/2002-11-11/0 that is. In case you wonder "a variety of tested compilers" includes various versions of GCC (2.9x-3.1) on various platforms, Sun Forte for SPARC Solaris, Intel C for x86 Linux, DEC C for Alpha Linux, MIPSpro C for IRIX, HP C for PA-RISC HPUX and Microsoft compilers. > Everyone uses memset() to clear inmemory passwords so people can't go > digging around in /dev/kmem. If memset() is optimizated out then the > password still stick around in memory until it is reallocated and reused. Well, those who can go digging around in /dev/kmem most likely can debug anybody else's process as well, and it would be hard to hide secrets from them in either case. So that this is hardly the biggest issue. The prime reason for memset-ting is to avoid unintentional exposure of secret as part of reallocated buffer in the *same* process context. E.g. when it gets used as padding data in an I/O buffer. Or you have some other reason to mistrust the rest of the code, e.g. you read a secret as root, do whatever that needs to be done and drop privileges making it possible for user to attach to process and inject code that would recover root secret. > But this is only half of the issue. It could still be in registers or in > the stack. Which memset() does not solve. I saw a post on OpenBSD > mailinglist that gave an example of a function that may work for clearing > all three and that should not be optimized out. And you still have another potential leak you can't address even with this. Swap partition to be specific. I mean system swaps out page with secret, then you run memset and exit. The secret can be recovered by anybody who has physical access to the machine. So that you have lock in memory not only secret buffers, but relevant portion of stack as well... > I don't know how much action should be taken on this. Hacking around one > gcc bug always leads to another version of gcc horking up a furball or > some other compiler whining and moaning about it. I fail to understand why are you people trying to address it as if it was a gcc-specific problem? It's a generic problem and we should look for more common solution. Well, it can't be completely system independent, but at least I see no reason why it has to be dependant on any particular compiler implementation. A. From mouring at etoh.eviladmin.org Sat Nov 9 04:20:47 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 8 Nov 2002 11:20:47 -0600 (CST) Subject: memset suggestion. In-Reply-To: <3DCBF0D2.AFC3D901@fy.chalmers.se> Message-ID: On Fri, 8 Nov 2002, Andy Polyakov wrote: > > > > Since 3.x is rolling out with -fno-builtin- support maybe we > > > > should test for 3.x and set -fno-builtin-memset which should stop gcc from > > > > optimizing it away. And maybe everyone should look for the same feature > > > > in their favorite compiler. > > Why not pick and stick to a workaround that works with all compilers, is > independent on compiler flags and is safe at any optimization level? As > pointed out in my (sorry for quoting myself:-) submission to Bugtraq > http://online.securityfocus.com/archive/1/298835/2002-11-05/2002-11-11/0 > that is. In case you wonder "a variety of tested compilers" includes > various versions of GCC (2.9x-3.1) on various platforms, Sun Forte for > SPARC Solaris, Intel C for x86 Linux, DEC C for Alpha Linux, MIPSpro C > for IRIX, HP C for PA-RISC HPUX and Microsoft compilers. > Until the next round of optimizators come out that are smart enough to optimize that functional call out of existance. Again we are left with a hack that may or may not stand the test of time. > > Everyone uses memset() to clear inmemory passwords so people can't go > > digging around in /dev/kmem. If memset() is optimizated out then the > > password still stick around in memory until it is reallocated and reused. > > Well, those who can go digging around in /dev/kmem most likely can debug > anybody else's process as well, and it would be hard to hide secrets > from them in either case. So that this is hardly the biggest issue. The > prime reason for memset-ting is to avoid unintentional exposure of > secret as part of reallocated buffer in the *same* process context. E.g. > when it gets used as padding data in an I/O buffer. Or you have some > other reason to mistrust the rest of the code, e.g. you read a secret as > root, do whatever that needs to be done and drop privileges making it > possible for user to attach to process and inject code that would > recover root secret. > I'm aware of that also. However, a lot of newer system allocation code allows for either clearing memory before passing to the application or writing over it with new random junk. So that would affect older systems which may or may not be fixable. > > But this is only half of the issue. It could still be in registers or in > > the stack. Which memset() does not solve. I saw a post on OpenBSD > > mailinglist that gave an example of a function that may work for clearing > > all three and that should not be optimized out. > > And you still have another potential leak you can't address even with > this. Swap partition to be specific. I mean system swaps out page with > secret, then you run memset and exit. The secret can be recovered by > anybody who has physical access to the machine. So that you have lock in > memory not only secret buffers, but relevant portion of stack as well... > You tell me everyone does not have encrypted swap?! I thought it was the norm these days.. > > I don't know how much action should be taken on this. Hacking around one > > gcc bug always leads to another version of gcc horking up a furball or > > some other compiler whining and moaning about it. > > I fail to understand why are you people trying to address it as if it > was a gcc-specific problem? It's a generic problem and we should look > for more common solution. Well, it can't be completely system > independent, but at least I see no reason why it has to be dependant on > any particular compiler implementation. > The reason being is if for some insane reason code like this: void *guaranteed_memset(void *v,int c,size_t n) { volatile char *p=v; while (n--) *p++=c; return v; } takes off.. It may become part of libc.. And down the road you'll end up with it being optimized out again. The only CORRECT way of handling it is to tell the compiler to keep it's grubby hands off memset(). There is no other correct solution. Everything else is just a hack waiting to fail down the road.. If not a polution of C namespace which is horrific enough as it. The burn_stack() example I was looking for was posted by markus@ and it was brough up as soon as compilers were smart enough to know about tail end recursion it would be optimized away yet again. Every time I see a solution based on a C hack.. I see at least one or two people peg what compilers may be able to do in the future to optimize code. Thus I think this really boils down to flaws in the compiler's optimization and there is not much hope for us to hack around it for any long term solution. Broken compilers *NEED* to be fixed. If GCC, Microsoft, Sun, etc don't understand this then we as a community need to drill it into their heads. - Ben From raj at tardy.cup.hp.com Sat Nov 9 06:02:37 2002 From: raj at tardy.cup.hp.com (Rick Jones) Date: Fri, 8 Nov 2002 11:02:37 -0800 (PST) Subject: memset suggestion. In-Reply-To: from Ben Lindstrom at Nov "8," 2002 "08:05:44" am Message-ID: <200211081902.LAA24640@tardy.cup.hp.com> > > Can you enlighten us why it is bad? I'm not a compiler guru... > > Everyone uses memset() to clear inmemory passwords so people can't go > digging around in /dev/kmem. If memset() is optimizated out then the > password still stick around in memory until it is reallocated and reused. > > But this is only half of the issue. It could still be in registers or in > the stack. Which memset() does not solve. Which is why the optimization is not "bad" but perhaps "unfortunate" instead. Within the context of the output of the program, optimizing the memset away is fine. It seems that the real problem here (?) is an operating environment that allows access to others to the stack/heap/registers/whatever. > Personally everyone I see that compiles software at greater than -O2 > I tend to LART them over the head with either the bat book or 'hack > proofing your network'. That seems to get their attention to > explain why higher levels of -O may not be what the want (mainly > when they come whining about their code not working..). Of course, then when the do compile at only O2, they start to complain about the performance of the application... Now where or not the app not working at higher optimization levels is a bug in the app or a bug in the optimizer is another discussion... rick jones quixotic booster of provile-based optimization and higher levels :) From mouring at etoh.eviladmin.org Sat Nov 9 06:46:20 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 8 Nov 2002 13:46:20 -0600 (CST) Subject: memset suggestion. In-Reply-To: <200211081902.LAA24640@tardy.cup.hp.com> Message-ID: On Fri, 8 Nov 2002, Rick Jones wrote: > > > Can you enlighten us why it is bad? I'm not a compiler guru... > > > > Everyone uses memset() to clear inmemory passwords so people can't go > > digging around in /dev/kmem. If memset() is optimizated out then the > > password still stick around in memory until it is reallocated and reused. > > > > But this is only half of the issue. It could still be in registers or in > > the stack. Which memset() does not solve. > > Which is why the optimization is not "bad" but perhaps "unfortunate" > instead. Within the context of the output of the program, optimizing > the memset away is fine. > Don't know.. I guess I expect too much from compilers. I expect: 1. Code I write stays written. if I put a memset() in.. I put it in for a damn good reason.=) I hate when computers second guess me. 2. I expect the compiler to produce reasonable and predictable optimization. GCC fails at both of these at higher optimizations. 3. If a compiler decides to yank stuff I wrote out.. I expect it to tell me. "warning: xxx() removed as dead code" that way I at least know what the compiler is removing of my code so I can either report it as a bug/misfeature or correct my code so it does not remove it. Maybe I am asking too much.=) > It seems that the real problem here (?) is an operating environment > that allows access to others to the stack/heap/registers/whatever. > > > Personally everyone I see that compiles software at greater than -O2 > > I tend to LART them over the head with either the bat book or 'hack > > proofing your network'. That seems to get their attention to > > explain why higher levels of -O may not be what the want (mainly > > when they come whining about their code not working..). > > Of course, then when the do compile at only O2, they start to complain > about the performance of the application... Now where or not the app > not working at higher optimization levels is a bug in the app or a bug > in the optimizer is another discussion... > if your still having 'preformance' issues at -O2. I'd seriously look at why. Most fall into: 1. Lack of OS support of critical features (Ala /dev/random) 2. Lack of clean well written (programmer optimized) critical functions 3. Lack of processor support for critical features (Ala D/H key generation on SS20) 4. Bad/overcomplex design 5. Not enough ram, too slow of processor, bad hardware design, etc. The last thing you want is to crank up -O. Entrusting your code to a random compiler is asking for trouble. If the compiler is finding dead code. It really should be telling the programmer so they can decide why and to ensure if it is a valid code branch that it is not optimized away. As I said.. maybe I expect too much from the compiler. - Ben > rick jones > quixotic booster of provile-based optimization and higher levels :) > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From rick_jones2 at hp.com Sat Nov 9 07:20:15 2002 From: rick_jones2 at hp.com (Rick Jones) Date: Fri, 08 Nov 2002 12:20:15 -0800 Subject: memset suggestion. References: Message-ID: <3DCC1C7F.BE8D24C0@hp.com> > > Which is why the optimization is not "bad" but perhaps "unfortunate" > > instead. Within the context of the output of the program, optimizing > > the memset away is fine. > > > > Don't know.. I guess I expect too much from compilers. I expect: > > 1. Code I write stays written. if I put a memset() in.. I put it in for a > damn good reason.=) I hate when computers second guess me. I guess that precludes a compiler ever trying to do dead code elimination :) It also goes against the decades long trend of trying to make "programming" something that can be done by a room full of briefly trained primates. I suspect that the only sure way to have code one writes stay written is to write in assembly :) > 2. I expect the compiler to produce reasonable and predictable > optimization. GCC fails at both of these at higher optimizations. > > 3. If a compiler decides to yank stuff I wrote out.. I expect it to tell > me. "warning: xxx() removed as dead code" Of course, if it did that by default, the other 99.99% of the programmers out there would start to complain about too many messages comeing from the compiler. > that way I at least know what the compiler is removing of my code so I can > either report it as a bug/misfeature or correct my code so it does not > remove it. > > Maybe I am asking too much.=) Entirely possible :) > if your still having 'preformance' issues at -O2. I'd seriously look at > why. Most fall into: > 1. Lack of OS support of critical features (Ala /dev/random) > 2. Lack of clean well written (programmer optimized) critical functions > 3. Lack of processor support for critical features (Ala D/H key > generation on SS20) > 4. Bad/overcomplex design > 5. Not enough ram, too slow of processor, bad hardware design, etc. I was thinking more "in general" than ssh specific, but yes, those are all good points. I think it would be goodness for PBO to become more widely used - it allows the compiler to know more about how your program will run and so it can make more informed deicisons about branches and all that sort of stuff... > The last thing you want is to crank up -O. Entrusting your code to a > random compiler is asking for trouble. I must be a very troubled soul :) rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From appro at fy.chalmers.se Sat Nov 9 07:47:44 2002 From: appro at fy.chalmers.se (Andy Polyakov) Date: Fri, 08 Nov 2002 21:47:44 +0100 Subject: memset suggestion. References: Message-ID: <3DCC22F0.CB7E6796@fy.chalmers.se> > > > > > Since 3.x is rolling out with -fno-builtin- support maybe we > > > > > should test for 3.x and set -fno-builtin-memset which should stop gcc from > > > > > optimizing it away. And maybe everyone should look for the same feature > > > > > in their favorite compiler. > > > > Why not pick and stick to a workaround that works with all compilers, is > > independent on compiler flags and is safe at any optimization level? As > > pointed out in my (sorry for quoting myself:-) submission to Bugtraq > > http://online.securityfocus.com/archive/1/298835/2002-11-05/2002-11-11/0 > > that is. > > Until the next round of optimizators come out that are smart enough to > optimize that functional call out of existance. Note that it's not functional call that is optimized away, but it's inlined instantiation. It first gets inlined, *then* optimized away. Inlining is the keyword! Real function call will never ever be optimized away. > Again we are left with a > hack that may or may not stand the test of time. Well, you might have hard time proving that such memset optimization is actually a bug. But if you find guaranteed_memset optimized away, you won't have *no* problem whatsoever proving that it's wrong and *demand* the bug to be fixed. Even if guaranteed_memset gets inlined! A. From dtucker at zip.com.au Sat Nov 9 09:54:01 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 09 Nov 2002 09:54:01 +1100 Subject: From RISKS: secret scrubbing code removed by optimizers References: Message-ID: <3DCC4089.7F6D0279@zip.com.au> Ben Lindstrom wrote: > On Fri, 8 Nov 2002, Darren Tucker wrote: > > Dan Kaminsky wrote: > > > Has somebody actually verified this optimizing behavior in any build > > > of GCC? Does voliatile actually stop it? > > > > Yes (gcc-3.2 on a SPARC). Yes. > > does setting -fno-builtin-memset at compile time stop gcc from > miscompiling? Yes. Incidentally, the dead code elimination happens with -O so sticking to -O2 or less won't help in this case. gcc -S -O3 -fno-builtin-memset myfunc1.c myfunc1: !#PROLOGUE# 0 save %sp, -216, %sp !#PROLOGUE# 1 add %fp, -120, %l0 sethi %hi(.LLC0), %g1 mov %l0, %o1 call scanf, 0 or %g1, %lo(.LLC0), %o0 mov %l0, %o0 mov 0, %o1 call memset, 0 mov 100, %o2 nop ret restore -- 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 Sat Nov 9 11:21:28 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 09 Nov 2002 11:21:28 +1100 Subject: From RISKS: secret scrubbing code removed by optimizers References: <20021108000824.A6252@greenie.muc.de> <20021108174155.A27131977@ohm.arago.de> Message-ID: <3DCC5508.AB5EF6D5@zip.com.au> Thomas Binder wrote: > The question is, though, why someone having access rights to read > /dev/kmem or swap space wouldn't rather install a trojaned or > otherwise modified sshd instead to snoop credentials. A couple of reasons: 1) Malloc doesn't clear memory. Some platforms clear the memory before malloc gets it, but some don't. On the ones that don't an unprivileged user can just keep malloc'ing memory and looking for something interesting. 2) If I break into your box today, I could scan /dev/kmem and potentially find a password you typed in last week. I might have to wait weeks or months before you get bitten by a trojaned sshd. 3) In the worst case the memory containing the password could get swapped out and remain on disk for *forever*. If I broke into your box today I might find a password you entered last year. These are long shots, but are you willing to bet your password on it? Every time you enter it? -- 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 vinschen at redhat.com Sat Nov 9 20:32:16 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 9 Nov 2002 10:32:16 +0100 Subject: [PATCH] Two Cygwin related patches Message-ID: <20021109103216.V21920@cygbert.vinschen.de> Hi, the attached patch file contains two patches in one: - contrib/cygwin/ssh-host-config: Create sshd_config according to latest changes. - openbsd-compat/bsd-cygwin_util.c: Rewrite a bit to allow easier retrieval of Cygwin capabilities from version number (uname). For Cygwin versions beginning with API minor version 56 assume ntsec being on by default. Thanks in advance for applying this patch, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com -------------- next part -------------- Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-host-config,v retrieving revision 1.9 diff -u -p -r1.9 ssh-host-config --- contrib/cygwin/ssh-host-config 10 Jul 2002 14:40:12 -0000 1.9 +++ contrib/cygwin/ssh-host-config 9 Nov 2002 09:25:09 -0000 @@ -378,6 +378,8 @@ then # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. +# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin + # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a @@ -394,7 +396,7 @@ Port $port_number #HostKey ${SYSCONFDIR}/ssh_host_rsa_key #HostKey ${SYSCONFDIR}/ssh_host_dsa_key -# Lifetime and size of ephemeral version 1 server ke +# Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 3600 #ServerKeyBits 768 @@ -405,7 +407,7 @@ Port $port_number # Authentication: -#LoginGraceTime 600 +#LoginGraceTime 120 #PermitRootLogin yes # The following setting overrides permission checks on host key files # and directories. For security reasons set this to "yes" when running @@ -414,11 +416,11 @@ StrictModes no #RSAAuthentication yes #PubkeyAuthentication yes -#AuthorizedKeysFile %h/.ssh/authorized_keys +#AuthorizedKeysFile .ssh/authorized_keys # rhosts authentication should not be used #RhostsAuthentication no -# Don't read ~/.rhosts and ~/.shosts files +# Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # For this to work you will also need host keys in ${SYSCONFDIR}/ssh_known_hosts #RhostsRSAAuthentication no @@ -443,6 +445,7 @@ StrictModes no #KeepAlive yes #UseLogin no UsePrivilegeSeparation $privsep_used +#PermitUserEnvironment no #Compression yes #MaxStartups 10 Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.8 diff -u -p -r1.8 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 15 Apr 2002 22:00:52 -0000 1.8 +++ openbsd-compat/bsd-cygwin_util.c 9 Nov 2002 09:25:09 -0000 @@ -43,6 +43,7 @@ RCSID("$Id: bsd-cygwin_util.c,v 1.8 2002 #define is_winnt (GetVersion() < 0x80000000) #define ntsec_on(c) ((c) && strstr((c),"ntsec") && !strstr((c),"nontsec")) +#define ntsec_off(c) ((c) && strstr((c),"nontsec")) #define ntea_on(c) ((c) && strstr((c),"ntea") && !strstr((c),"nontea")) #if defined(open) && open == binary_open @@ -74,6 +75,56 @@ int binary_pipe(int fd[2]) return ret; } +#define HAS_CREATE_TOKEN 1 +#define HAS_NTSEC_BY_DEFAULT 2 + +static int has_capability(int what) +{ + /* has_capability() basically calls uname() and checks if + specific capabilities of Cygwin can be evaluated from that. + This simplifies the calling functions which only have to ask + for a capability using has_capability() instead of having + to figure that out by themselves. */ + static int inited; + static int has_create_token; + static int has_ntsec_by_default; + + if (!inited) { + struct utsname uts; + char *c; + + if (!uname(&uts)) { + int major_high = 0; + int major_low = 0; + int minor = 0; + int api_major_version = 0; + int api_minor_version = 0; + char *c; + + sscanf(uts.release, "%d.%d.%d", &major_high, + &major_low, &minor); + c = strchr(uts.release, '('); + if (c) + sscanf(c + 1, "%d.%d", &api_major_version, + &api_minor_version); + if (major_high > 1 || + (major_high == 1 && (major_low > 3 || + (major_low == 3 && minor >= 2)))) + has_create_token = 1; + if (api_major_version > 0 || api_minor_version >= 56) + has_ntsec_by_default = 1; + inited = 1; + } + } + switch (what) { + case HAS_CREATE_TOKEN: + return has_create_token; + case HAS_NTSEC_BY_DEFAULT: + return has_ntsec_by_default; + } + return 0; +} + int check_nt_auth(int pwd_authenticated, struct passwd *pw) { /* @@ -93,19 +144,14 @@ int check_nt_auth(int pwd_authenticated, return 0; if (is_winnt) { if (has_create_token < 0) { - struct utsname uts; - int major_high = 0, major_low = 0, minor = 0; char *cygwin = getenv("CYGWIN"); has_create_token = 0; - if (ntsec_on(cygwin) && !uname(&uts)) { - sscanf(uts.release, "%d.%d.%d", - &major_high, &major_low, &minor); - if (major_high > 1 || - (major_high == 1 && (major_low > 3 || - (major_low == 3 && minor >= 2)))) - has_create_token = 1; - } + if (has_capability(HAS_CREATE_TOKEN) && + (ntsec_on(cygwin) || + (has_capability(HAS_NTSEC_BY_DEFAULT) && + !ntsec_off(cygwin)))) + has_create_token = 1; } if (has_create_token < 1 && !pwd_authenticated && geteuid() != pw->pw_uid) @@ -128,7 +174,9 @@ int check_ntsec(const char *filename) /* Evaluate current CYGWIN settings. */ cygwin = getenv("CYGWIN"); allow_ntea = ntea_on(cygwin); - allow_ntsec = ntsec_on(cygwin); + allow_ntsec = ntsec_on(cygwin) || + (has_capability(HAS_NTSEC_BY_DEFAULT) && + !ntsec_off(cygwin)); /* * `ntea' is an emulation of POSIX attributes. It doesn't support From marco.ortisi at flashcom.it Sat Nov 9 21:25:47 2002 From: marco.ortisi at flashcom.it (marco.ortisi at flashcom.it) Date: Sat, 09 Nov 2002 10:25:47 GMT Subject: ScanMail Message: To Sender, sensitive content found and action t aken. In-Reply-To: <2705705BE153D511BD780008C786704C08160484@xs01ricgefage.gefa.capital.ge.com> References: <2705705BE153D511BD780008C786704C08160484@xs01ricgefage.gefa.capital.ge.com> Message-ID: <20021109102547.30501.qmail@mail.flashcom.it> > Trend SMEX Content Filter has detected sensitive content. > > Place = openssh-unix-dev at mindrot.org; ; > Sender = marco.ortisi at flashcom.it > Subject = bug on openssh 3.5p1 > Delivery Time = November 08, 2002 (Friday) 11:46:17 > Policy = Dirty Words > Action on this mail = Quarantine message > > Warning message from administrator: > Notice: A message you sent appears to have violated GE Financial Assurance > email policies for inappropriate language or content and may not have been > received by the recipient. My email was clear and there wasn't dirty words on it! I have only signaled a possible implementation bug on OpenSSH package. Regards, Marco Ortisi From dtucker at zip.com.au Sat Nov 9 23:58:59 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 09 Nov 2002 23:58:59 +1100 Subject: ScanMail Message: To Sender, sensitive content found and action t aken. References: <2705705BE153D511BD780008C786704C08160484@xs01ricgefage.gefa.capital.ge.com> <20021109102547.30501.qmail@mail.flashcom.it> Message-ID: <3DCD0693.58A7F00B@zip.com.au> marco.ortisi at flashcom.it wrote: [content filter bounce snipped] > My email was clear and there wasn't dirty words on it! > I have only signaled a possible implementation bug on OpenSSH > package. Ignore it and please don't take it personally. The message was not from the openssh list server. It was from an individual subscriber's dumb mail filter. My guess is that the content if didn't like is "root at xxx" (I'll let you know privately if it bounces this message too!). I'm getting similar objections from someone else's filter because it doesn't like the subject of one of the threads I've posted to. -- 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 Sun Nov 10 02:45:45 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 9 Nov 2002 09:45:45 -0600 (CST) Subject: [PATCH] Two Cygwin related patches In-Reply-To: <20021109103216.V21920@cygbert.vinschen.de> Message-ID: applied, thanks. - Ben On Sat, 9 Nov 2002, Corinna Vinschen wrote: > Hi, > > the attached patch file contains two patches in one: > > - contrib/cygwin/ssh-host-config: Create sshd_config according to latest > changes. > > - openbsd-compat/bsd-cygwin_util.c: Rewrite a bit to allow easier retrieval > of Cygwin capabilities from version number (uname). For Cygwin versions > beginning with API minor version 56 assume ntsec being on by default. > > Thanks in advance for applying this patch, > Corinna > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com > From bugzilla-daemon at mindrot.org Sun Nov 10 03:12:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 03:12:20 +1100 (EST) Subject: [Bug 432] AIX does not log login attempts for unknown users Message-ID: <20021109161220.1A4E33D16F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=432 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From mouring at eviladmin.org 2002-11-10 03:12 ------- Applied, Thanks to --current ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 03:34:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 03:34:37 +1100 (EST) Subject: [Bug 367] patches for Cray port Message-ID: <20021109163437.32C9C3D159@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=367 ------- Additional Comments From mouring at eviladmin.org 2002-11-10 03:34 ------- Everything was applied to 3.5 but deattack.c. Changes talked about on the list will be accepted if they are submitted in patch form. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 03:50:53 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 03:50:53 +1100 (EST) Subject: [Bug 168] "Could not find working OpenSSL library" Message-ID: <20021109165053.BFC073D16D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=168 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From mouring at eviladmin.org 2002-11-10 03:50 ------- this patch was applied to 3.5. If this issue still exists in 3.5 and above. Please reopen with new information. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 09:11:17 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 09:11:17 +1100 (EST) Subject: [Bug 318] Install failure creating ssh_prng_cmds Message-ID: <20021109221117.8EFEA3D16D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=318 ------- Additional Comments From dtucker at zip.com.au 2002-11-10 09:11 ------- errno 13 == EACCES. Did you do the "make install" as root? If so did you do it on an NFS filesystem that maps root -> nobody? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 09:29:35 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 09:29:35 +1100 (EST) Subject: [Bug 269] OpenSSH doesn't compile with dynamic OpenSSL libraries Message-ID: <20021109222935.039BA3D17B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=269 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From dtucker at zip.com.au 2002-11-10 09:29 ------- 5 months no reply == closed bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 09:37:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 09:37:12 +1100 (EST) Subject: [Bug 375] sshd core dumping with msg "Cannot delete credentials" Message-ID: <20021109223712.4B7B23D17A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=375 ------- Additional Comments From dtucker at zip.com.au 2002-11-10 09:37 ------- "Cannot delete credentials" is a red herring, it happens all the time on Solaris (no, I don't know why). Which function is sshd dumping in? To find out do something like: # gdb ./sshd (gdb) set args -ddd -p 2022 [wait for coredump] (gdb) backtrace ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 09:49:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 09:49:54 +1100 (EST) Subject: [Bug 406] Build openssh-3.4p1 fails, Mac OS X v1.2 Message-ID: <20021109224954.AD10A3D184@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=406 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From dtucker at zip.com.au 2002-11-10 09:49 ------- 20021003 [snip] - (djm) Bug #406: s/msg_send/ssh_msg_send/ for Mac OS X 1.2 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 12:02:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 12:02:59 +1100 (EST) Subject: [Bug 429] SSH 3.4p1 problems on Tru64 V4.0D & Tru64 V4.0F Message-ID: <20021110010259.03FD83D17D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=429 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE Summary|SSH 3.4p1 problems on Tru64 |SSH 3.4p1 problems on Tru64 |V4.0D & Tru64 V4.0F |V4.0D & Tru64 V4.0F ------- Additional Comments From mouring at eviladmin.org 2002-11-10 12:02 ------- *** This bug has been marked as a duplicate of 296 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 10 12:03:11 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 10 Nov 2002 12:03:11 +1100 (EST) Subject: [Bug 296] Priv separation does not work on OSF/1 Message-ID: <20021110010311.DC4FF3D17D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=296 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avi.koski at comverse.com ------- Additional Comments From mouring at eviladmin.org 2002-11-10 12:03 ------- *** Bug 429 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Sun Nov 10 17:01:08 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 10 Nov 2002 17:01:08 +1100 Subject: Password expiry patch plans References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> Message-ID: <3DCDF624.4251C133@zip.com.au> [was Re: [Bug 423] Workaround for pw change in privsep mode (3.5.p1)] Frank Cusack wrote: > The PAM framework demands the type of exchange that > only keyboard-interactive offers. The way the "password" authentication > method interacts with PAM is a kludge. After following this thread and thinking about this for a while, this is the current plan for my experimental expiry patch[0]: 1) Add "int password_changereq" and "char *postauth_message" to struct Authctxt. This will allow elimination of a bunch of global variables (eg password_change_required, loginmsg) and some #defines, and allow the merge of some of the AIX & PAM specific code (eg in session.c). It will require the parameters of getpwnamallow and friends to be changed to authctxt and another monitor wrapper for is_password_change_required and maybe get_login_messages. Would anyone object to that? 2) Write a pam_change_password function that uses do_pam_conversation in INITIAL_LOGIN (ie "blind") mode and plug it into auth_change_password. This should cover the majority of simple cases (ie basically the same cases that the existing auth_pam_password function covers for "password" authentication) and work with privsep. 3) Hack pam_chauthtok into keyboard-interactive for proto 2 to handle the tricky PAM cases the Right Way. It won't work with privsep (see 6) but apparently it doesn't now anyway. People requiring deep PAM magic can use that ("PAMAuthenticationViaKbdInt yes"). 4) Make the general case for proto 1 call /bin/passwd (including for PAM). Maybe look at the following later: > Not so fast there. :-) Look in the bugs db for a TISviaPAM patch. This > uses the ssh1 TIS auth method to do the same thing that kbdint does. 5) Add something like the following to the unpriv child: if (PRIVSEP(is_password_change_required())) disable port forwarding disable agent etc 6) Make keyboard-interactive work with PAM & privsep. This one is a bit hazy but might involve a privsep-specific pam conversation function and some explicit to-and-fro between priv and unpriv (ie not just via the wrapper). Not sure. Comments? [0] See http://www.zip.com.au/~dtucker/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 michael_steffens at hp.com Mon Nov 11 01:13:53 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Sun, 10 Nov 2002 15:13:53 +0100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> Message-ID: <3DCE69A1.5090205@hp.com> Frank Cusack wrote: > On Fri, Nov 08, 2002 at 11:00:05AM +0100, Michael Steffens wrote: > >>Darren Tucker wrote: >> >>>Michael Steffens wrote: >>> >>> >>>>And, if the PAM stack for sshd is really configured to prompt for >>>>multiple different passwords, authentication will always fail... >>> >>> >>>So by rights, PAM authentication should always be done via >>>keyboard-interactive? If you do that, you can throw the pam_chauthok >>>stuff in there too? >>> >> >>Yes and no :) > > > Just yes, really. The PAM framework demands the type of exchange that > only keyboard-interactive offers. The way the "password" authentication > method interacts with PAM is a kludge. > > >>If keyboard-interactive would work in privsep mode (it doesn't, at >>least for me) > > > It does not because PAM in general requires root privs I remember vaguely that PAM itself doesn't require root privileges, despite in real life it actually often does, for a subset of functions, where the modules are implemented to access secret information directly. Like pam_authenticate() reading in a shadow database. So for being sure that it actually works you are right. :) > and in privsep > mode the PAM code runs in the unpriv part. The correct fix IMHO is > to move the PAM code into the priv part. I don't know if this is > feasible, but from a security standpoint should be pretty good. The > PAM code is a small part to look at and any bugs are going to be in > the PAM libs, not openssh. > >>and if it would be also available for protocol 1, which it isn't, > > > Not so fast there. :-) Look in the bugs db for a TISviaPAM patch. This > uses the ssh1 TIS auth method to do the same thing that kbdint does. Here I'm confused. Assuming that you mean http://bugzilla.mindrot.org/show_bug.cgi?id=118 and that it does challenge/response authentication, can it replace the password authentication part? From michael_steffens at hp.com Mon Nov 11 01:50:18 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Sun, 10 Nov 2002 15:50:18 +0100 Subject: Password expiry patch plans References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCDF624.4251C133@zip.com.au> Message-ID: <3DCE722A.9080100@hp.com> Darren Tucker wrote: > [was Re: [Bug 423] Workaround for pw change in privsep mode (3.5.p1)] > > Frank Cusack wrote: > >>The PAM framework demands the type of exchange that >>only keyboard-interactive offers. The way the "password" authentication >>method interacts with PAM is a kludge. > > > After following this thread and thinking about this for a while, this is > the current plan for my experimental expiry patch[0]: > > 1) Add "int password_changereq" and "char *postauth_message" to struct > Authctxt. This will allow elimination of a bunch of global variables (eg > password_change_required, loginmsg) and some #defines, and allow the > merge of some of the AIX & PAM specific code (eg in session.c). It will > require the parameters of getpwnamallow and friends to be changed to > authctxt and another monitor wrapper for is_password_change_required and > maybe get_login_messages. Would anyone object to that? > > 2) Write a pam_change_password function that uses do_pam_conversation in > INITIAL_LOGIN (ie "blind") mode and plug it into auth_change_password. > This should cover the majority of simple cases (ie basically the same > cases that the existing auth_pam_password function covers for "password" > authentication) and work with privsep. Isn't that adding just another kludge, where we already do have an expample where it won't work in default configuration? HP-UX in trusted mode is one thing. Another one will be whether you are being prompted for the old password at all, depending on real and effective UID, and possibly on PAM_RUSER and PAM_RHOST. When I did last testings Solaris behaved differently there than HP-UX and Linux did, if the real UID was zero, which will always happen if the user logging in is root himself. I doubt this was the only opportunity you might get trapped by unexpected conversation behaviour of password change dialogs. > 3) Hack pam_chauthtok into keyboard-interactive for proto 2 to handle > the tricky PAM cases the Right Way. It won't work with privsep (see 6) > but apparently it doesn't now anyway. People requiring deep PAM magic > can use that ("PAMAuthenticationViaKbdInt yes"). > > 4) Make the general case for proto 1 call /bin/passwd (including for > PAM). Maybe look at the following later: Why /bin/passwd also for PAM? What's wrong with the helper dedicated to "sshd" service? Would consider that at least a little bit cleaner. As far as privsep is concerned I'm getting the feeling that Frank is right that all calls of PAM functions should be moved to the privileged monitor. Possibly this could also solve the auditing corruptions reported for Solaris? But in any way it requieres tunnneling PAM conversation between monitor and unprivileged child, and this seems to be far from being an easy task. Already tried to wrap my had around it only for the keyboard interactive case... From mouring at etoh.eviladmin.org Mon Nov 11 02:31:55 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 10 Nov 2002 09:31:55 -0600 (CST) Subject: Password expiry patch plans In-Reply-To: <3DCE722A.9080100@hp.com> Message-ID: On Sun, 10 Nov 2002, Michael Steffens wrote: [..] > > 4) Make the general case for proto 1 call /bin/passwd (including for > > PAM). Maybe look at the following later: > > Why /bin/passwd also for PAM? What's wrong with the helper > dedicated to "sshd" service? Would consider that at least a > little bit cleaner. > Two reasons. 1. It is yet another setuid binary (well maybe not in OpenBSD's case), but I'm not really not sure I want to even go near the topic with Theo/Markus. 2. Anytime you write such things you MUST ensure all your p's and q's are right. That there is *NO* way for someone to abuse it from user space. Which brings me back to #1. I agree it would be nice to this password change all through a helper program. It would allow local admins to implement the level of strictness based on their needs (same with how we do entropy collection now), but again it comes back to the ability to abuse a setuid binary. I don't want to be the next person to introduce the next misfeature into OpenSSH that allows the local machine to be comprised. And skimming through your example code does not make me want to rush out and implement it. - Ben From stevesk at pobox.com Mon Nov 11 04:56:31 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 10 Nov 2002 09:56:31 -0800 Subject: bug on openssh 3.5p1 In-Reply-To: <20021108161928.24366.qmail@mail.flashcom.it> References: <20021108161928.24366.qmail@mail.flashcom.it> Message-ID: <20021110175631.GB1357@jenny.crlsca.adelphia.net> On Fri, Nov 08, 2002 at 04:19:28PM +0000, marco.ortisi at flashcom.it wrote: > Excuse me in advance for my poor english > > I have noted a small bug on OpenSSH 3.5p1. When user root is not > permitted to log in a system (PermitRoot no) and a correct password > is submitted for it to server, a RST packet is issued from server to > client: > [root at xxx root]# ssh victim > root at victim's password: > Permission denied, please try again. > root at victim's password: > Permission denied, please try again. > ......... > root at victim's password: > Read from remote host 10.12.7.110: Connection reset by peer > Connection to victim closed. i don't see that. what platform and configuration? sshd -ddd? From fcusack at fcusack.com Mon Nov 11 10:51:46 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 10 Nov 2002 15:51:46 -0800 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) In-Reply-To: <3DCE69A1.5090205@hp.com>; from michael_steffens@hp.com on Sun, Nov 10, 2002 at 03:13:53PM +0100 References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCE69A1.5090205@hp.com> Message-ID: <20021110155146.A14544@google.com> On Sun, Nov 10, 2002 at 03:13:53PM +0100, Michael Steffens wrote: > Frank Cusack wrote: > > Not so fast there. :-) Look in the bugs db for a TISviaPAM patch. This > > uses the ssh1 TIS auth method to do the same thing that kbdint does. > > Here I'm confused. Assuming that you mean > > http://bugzilla.mindrot.org/show_bug.cgi?id=118 That is what I meant. > and that it does challenge/response authentication, can it > replace the password authentication part? No. Sorry to have indicated that. On further review, that patch isn't quite an "ssh1 kbdint equivalent", and wouldn't be safe to modify into a password authentication mechanism. I can go into length on the details if desired. The only thing that patch is useful for is challenge/response type auths, eg S/Key. This is a limitation of protocol 1. There's no reason a new auth type couldn't be added to protocol 1, however. It wouldn't be portable though. I think it's unlikely that any new ssh1 auth would be picked up by any implementation, even openssh. /fc From samuel at bcgreen.com Mon Nov 11 17:41:53 2002 From: samuel at bcgreen.com (Stephen Samuel) Date: Sun, 10 Nov 2002 22:41:53 -0800 Subject: changes to allow chroot'ed sftp Message-ID: <3DCF5131.7010208@bcgreen.com> I have a use for sftp to run in a chroot jail. Since sftp doesn't quite work properly for that, I did the work to make it function like that. This required two different changes: sftpsh is a replacement for nologin. It works like nologin except under certain circumstances -- where it will start up sftp-server. The other part was to add an option to sftp-server. the '-c' option causes sftp-server to chroot(".");chdir("/"); (the latter being to avoid chroot hole problems). It's been a while since I've done anything security-critical, so PLEASE feel free to audit/critique my code. The changes for sftp-server.c and sftp-server.8 are as follows: =================================================================== RCS file: RCS/sftp-server.c,v retrieving revision 1.38 diff -u -r1.38 sftp-server.c --- sftp-server.c 2002/11/10 22:56:08 1.38 +++ sftp-server.c 2002/11/11 04:01:02 @@ -1058,6 +1058,11 @@ ssize_t len, olen, set_size; /* XXX should use getopt */ + if(ac == 2 && strcmp(av[1],"-c") == 0 ){ + chroot("."); + chdir("/"); /* get rid of '.' chroot hole */ + setuid(getuid()); + }; __progname = get_progname(av[0]); handle_init(); =================================================================== =================================================================== RCS file: RCS/sftp-server.8,v retrieving revision 1.1 diff -u -r1.1 sftp-server.8 --- sftp-server.8 2002/11/10 23:17:06 1.1 +++ sftp-server.8 2002/11/10 23:35:44 @@ -43,6 +43,10 @@ See .Xr sshd 8 for more information. +.Sh OPTIONS +.Bl -tag -width CC +.It Fl c +chroot jail: (do a chroot and setuid(getuid()) when starting) .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , =================================================================== sftpsh.c is attached (83 lines including copyright) Notes: sftpsh needs to be installed setuid. I don't have install scripts for it. The location of sftp-server is hardwired into sftpsh.c . sftpsh.c uses /proc/ppid/cmdline to check the name and pid of it's parent No docs for sftpsh.c Conditions for sftpsh calling sftp-server: Parent process is sshd, and is uid-root. parameters are: "-c /usr/libexec/sshd/sshd-server" If sftp-server doesn't cooperate, you end up with a (potential) remote root exploit. Perhaps instead of checking for a parameter of '-c' I should just check for euid==0? -- Stephen Samuel +1(604)876-0426 samuel at bcgreen.com http://www.bcgreen.com/~samuel/ Powerful committed communication, reaching through fear, uncertainty and doubt to touch the jewel within each person and bring it to life. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sftpsh.c Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021110/882386af/attachment.c From michael_steffens at hp.com Mon Nov 11 20:22:36 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Mon, 11 Nov 2002 10:22:36 +0100 Subject: [Bug 423] Workaround for pw change in privsep mode (3.5.p1) References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCE69A1.5090205@hp.com> <20021110155146.A14544@google.com> Message-ID: <3DCF76DC.9090000@hp.com> Frank Cusack wrote: >>and that it does challenge/response authentication, can it >>replace the password authentication part? > > > No. Sorry to have indicated that. > > On further review, that patch isn't quite an "ssh1 kbdint equivalent", and > wouldn't be safe to modify into a password authentication mechanism. I can > go into length on the details if desired. Yes, I would like to know the details! :) > The only thing that patch is > useful for is challenge/response type auths, eg S/Key. This is a limitation > of protocol 1. > > There's no reason a new auth type couldn't be added to protocol 1, however. > It wouldn't be portable though. I think it's unlikely that any new ssh1 > auth would be picked up by any implementation, even openssh. Unlikely. But if the bottom line is that with protocol 1 PAM authentication dialogs can only be handled when demanding exectly one password, while protocol 2 can handle arbitrary ones via keyboard interactive, that's quite fair IMO. From fcusack at fcusack.com Mon Nov 11 20:52:24 2002 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 11 Nov 2002 01:52:24 -0800 Subject: Password expiry patch plans In-Reply-To: <3DCDF624.4251C133@zip.com.au>; from dtucker@zip.com.au on Sun, Nov 10, 2002 at 05:01:08PM +1100 References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCDF624.4251C133@zip.com.au> Message-ID: <20021111015224.A15807@google.com> On Sun, Nov 10, 2002 at 05:01:08PM +1100, Darren Tucker wrote: > After following this thread and thinking about this for a while, this is > the current plan for my experimental expiry patch[0]: > > 1) Add "int password_changereq" and "char *postauth_message" to struct > Authctxt. [...] > > 2) Write a pam_change_password function that uses do_pam_conversation in > INITIAL_LOGIN (ie "blind") mode and plug it into auth_change_password. [...] > > 3) Hack pam_chauthtok into keyboard-interactive for proto 2 to handle > the tricky PAM cases the Right Way. [...] > > 4) Make the general case for proto 1 call /bin/passwd (including for > PAM). [...] > > 5) Add something like the following to the unpriv child: > if (PRIVSEP(is_password_change_required())) > disable port forwarding > disable agent > etc > > 6) Make keyboard-interactive work with PAM & privsep. [...] > > Comments? Well, I'm certainly a fan of (3). I couldn't care about (6). I can't speak to the other ones. I'm confused about (5). Are you saying you would re-enable those after the password change? /fc From dtucker at zip.com.au Mon Nov 11 21:07:26 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Nov 2002 21:07:26 +1100 Subject: Password expiry patch plans References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCDF624.4251C133@zip.com.au> <3DCE722A.9080100@hp.com> Message-ID: <3DCF815E.4617B0D6@zip.com.au> The patches I've been working on are an experiment. I don't expect it to be merged as-is. Some parts might work out OK and get merged, some probably won't. I don't decide which, if any, do but I hope that password expiry ends up working on most supported platforms that have the capability. There's several things being traded off here: code size, complexity, portability and (expired draft) RFC compliance. Michael Steffens wrote: > Isn't that adding just another kludge, where we already do have > an expample where it won't work in default configuration? Yep. We'll also have many (the majority?) of configurations where it will and where it works it'll be RFC-compliant for PASSWD_CHANGEREQ. Many people just want expiry to work and don't want to do anything tricky with PAM. [snip] > I doubt this was the only > opportunity you might get trapped by unexpected conversation > behaviour of password change dialogs. Those cases could use something else (keyboard-interactive, /bin/passwd or the setuid helper in the session). > Why /bin/passwd also for PAM? What's wrong with the helper > dedicated to "sshd" service? Because I've already copped flak about the size of the patch and it's not needed for the experiment. It does roughly the same thing as /bin/passwd and can be considered independantly. > As far as privsep is concerned I'm getting the feeling that > Frank is right that all calls of PAM functions should be > moved to the privileged monitor. Agreed. -- 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 michael_steffens at hp.com Mon Nov 11 21:19:41 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Mon, 11 Nov 2002 11:19:41 +0100 Subject: Password expiry patch plans References: Message-ID: <3DCF843D.2050105@hp.com> Ben Lindstrom wrote: > Two reasons. > > 1. It is yet another setuid binary (well maybe not in OpenBSD's case), but > I'm not really not sure I want to even go near the topic with Theo/Markus. It is a workaround. As soon as there is a possibility to have the monitor talk to PAM and the unpriv child talk to the user for PAM conversation, it would be obsolete. > > 2. Anytime you write such things you MUST ensure all your p's and q's are > right. That there is *NO* way for someone to abuse it from user space. > Which brings me back to #1. The ways I tried to ensure this were: - Make it small and simple - Don't allow anything a userspace caller couldn't also do with /bin/passwd, if it were the same PAM stack. - Don't use user (command line) data which can't be verified. This was the reason to exclude PAM_RUSER and PAM_RHOST, which I had in an intermediate version. Requesting entities are not even the local ones, they are just unknown and left undefined. It's up to the modules to reject a change if they require these. This would be the point where the workaround's capabilities are exhausted. The only user supplied data preceding the dialog is the user name, which is required and used for redundancy (checked against real UID). - Restrict functionaly to base purpose, i.e. do only allow change of expired authentication tokens. Change of non-expired ones is rejected (and unnecessary for sshd's use, as it won't call it then). - Don't spawn any further children (despite what PAM modules might spawn themself, and would also do when called from inside sshd). Exclude ssh-askpass from conversation. > > I agree it would be nice to this password change all through a helper > program. It would allow local admins to implement the level of strictness > based on their needs (same with how we do entropy collection now), but > again it comes back to the ability to abuse a setuid binary. This is not what I had in mind. A general password change helper would be considerably larger and much harder to review. > > I don't want to be the next person to introduce the next misfeature into > OpenSSH that allows the local machine to be comprised. And skimming > through your example code does not make me want to rush out and implement > it. I'm aware it's not perfect. But what do you mean specifically? From dtucker at zip.com.au Mon Nov 11 21:50:45 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Nov 2002 21:50:45 +1100 Subject: Password expiry patch plans References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCDF624.4251C133@zip.com.au> <20021111015224.A15807@google.com> Message-ID: <3DCF8B85.1901D5D7@zip.com.au> Frank Cusack wrote: > On Sun, Nov 10, 2002 at 05:01:08PM +1100, Darren Tucker wrote: [snip] > > Comments? > > Well, I'm certainly a fan of (3). > I couldn't care about (6). I can't speak to the other ones. > I'm confused about (5). Are you saying you > would re-enable those after the password change? Yes but I'm now not sure I understand how it works. I thought I did and now I don't... -- 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 vinschen at redhat.com Mon Nov 11 21:56:52 2002 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 11 Nov 2002 11:56:52 +0100 Subject: Password expiry patch plans In-Reply-To: <3DCDF624.4251C133@zip.com.au> References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCDF624.4251C133@zip.com.au> Message-ID: <20021111115652.J10395@cygbert.vinschen.de> On Sun, Nov 10, 2002 at 05:01:08PM +1100, Darren Tucker wrote: > 4) Make the general case for proto 1 call /bin/passwd (including for > PAM). Maybe look at the following later: > [...] > Comments? Looking from a Cygwin perspective: Since Windows based systems also have the expiry problem, it would be helpful to have a generalized way to solve that regardless of the protocol in use and especially independant of AIX or PAM specific stuff. Calling /bin/passwd seems a very good way, IMHO. Unfortunately, the current cygwin_logon_user() call used in auth-passwd.c doesn't return whether the authentication failed due to a expired password or any other problem. But that's easily solved by changing Cygwin... Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From dtucker at zip.com.au Mon Nov 11 23:22:52 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Nov 2002 23:22:52 +1100 Subject: Password expiry patch plans References: <3DCA37C2.3050008@hp.com> <3DCA65C1.B00210E0@zip.com.au> <3DCA75A1.7090808@hp.com> <3DCADA6B.445A8B6A@zip.com.au> <3DCB8B25.6020207@hp.com> <20021108035013.B6799@google.com> <3DCDF624.4251C133@zip.com.au> <20021111115652.J10395@cygbert.vinschen.de> Message-ID: <3DCFA11C.45764042@zip.com.au> Corinna Vinschen wrote: > Since Windows based systems also have the expiry problem, it would > be helpful to have a generalized way to solve that regardless of the > protocol in use and especially independant of AIX or PAM specific > stuff. Calling /bin/passwd seems a very good way, IMHO. The issue with that is for protocol 2 execing /bin/passwd can't be done on many platforms until you have a tty, but according to the RFC you "MUST NOT allow an expired password to be used for authentication" and you don't normally get a tty until after you're authenticated. Goto 1. > Unfortunately, the current cygwin_logon_user() call used in auth-passwd.c > doesn't return whether the authentication failed due to a expired > password or any other problem. But that's easily solved by changing > Cygwin... Must be nice to have the option of changing your platform to suit :-) Someone mentioned to me in private email that some third-party products (the example was CA's eTrust) replace /bin/passwd with their own binary, and suggested a "UsePasswd yes|no" option for those cases. How about using /bin/passwd as a last resort? ie if the change flag isn't cleared by the time the session starts, then do it. If it gets handled earlier, clear the flag. You could put that in first, then if/when any of the other options go in they have auth_password return a "change password now" value and clear the change flag if the password is changed successfully. Another question: what's OpenBSD going to do about password expiry via ssh? -- 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 bugzilla-daemon at mindrot.org Tue Nov 12 02:31:33 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Nov 2002 02:31:33 +1100 (EST) Subject: [Bug 433] New: Allow "ProxyCommand none" in ssh_config Message-ID: <20021111153133.5F4943D184@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=433 Summary: Allow "ProxyCommand none" in ssh_config Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: binder at arago.de Currently, you can't have a ProxyCommand for "Host *" and none for some exceptions, as there's no way to unset ProxyCommand once it's been set. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Nov 12 02:35:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Nov 2002 02:35:31 +1100 (EST) Subject: [Bug 433] Allow "ProxyCommand none" in ssh_config Message-ID: <20021111153531.2F9073D19B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=433 ------- Additional Comments From binder at arago.de 2002-11-12 02:35 ------- Created an attachment (id=177) --> (http://bugzilla.mindrot.org/attachment.cgi?id=177&action=view) Patch as discussed in openssh-unix-dev's thread 'Allow "ProxyCommand none" in ssh_config' ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Nov 12 04:41:26 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 12 Nov 2002 04:41:26 +1100 (EST) Subject: [Bug 434] New: ssh-add doesn't always add all identities to ssh-agent Message-ID: <20021111174126.550F83D0E6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=434 Summary: ssh-add doesn't always add all identities to ssh-agent Product: Portable OpenSSH Version: older versions Platform: ix86 OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: ssh-add AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: worley at theworld.com RedHat package: openssh-clients-3.1p1-5 OpenSSH version (as reported by ssh -v): OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f Symptom: When using ssh-add to add identities to the ssh-agent, and when using it as an X windows application, ssh-add acts incorrectly when a bad passphrase is entered initially: ssh-add correctly reports that the passphrase is bad and then correctly prompts for the passphrase again. But when I then enter the correct password, only one of my two identities is added to the ssh-agent, as is attested by ssh-add -l afterward. My configuration: My two identies are stored in ~/.ssh/id_rsa and ~/.ssh/id_dsa, and both use the same passphrase. When I initially enter a bad passphrase, only id_dsa is added to the ssh-agent. When I enter the correct passphrase the first time, both ~/.ssh/id_dsa and ~/.ssh/id_rsa are added (in that order, if that makes any difference). Workaround: In many cases the user can work around this problem by aborting ssh-add, then restarting it and entering the correct password the first time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From eddygeez at yahoo.com Tue Nov 12 10:18:51 2002 From: eddygeez at yahoo.com (Eddy) Date: Mon, 11 Nov 2002 15:18:51 -0800 (PST) Subject: Why is 'moduli' installed where it is? Message-ID: <20021111231851.33934.qmail@web9607.mail.yahoo.com> [ OS: Solaris 2.8 ] Curious why 'moduli' is installed in the "--sysconfdir' directory? Isn't this machine-independent and therefore should go in the "--datadir" directory? Also, it seems to me that the datadir/sysconfdir/sharedstatedir/ localstatedir would be more useful if they were set up (or further expanded) to better support packaging of OpenSSH. For example, the binaries, man pages, 'moduli' and 'ssh_prng_cmd' files are "machine independent" (for a given architecture) and should be installable under their own, site-wide distributable package. (i.e., under something like /usr/local/pkg/openssh-3.5p1/bin /sbin /etc ) The machine-specific files, such as 'sshd_config' and 'ssh_host_key', etc. should be able to be separated into a machine-specific package As it stands now, the host keys, moduli and ssh_prng_cmd files all live in the same directory, requiring that non-machine-specific data be stored in the machine-specific location that contains the host keys. I can't find any easy way to make this split (machine independent vs. machine specific) given the current build system without modifying pathnames.h and Makefile.in. Comments or suggestions? __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From harbaugh at nciaxp.ncifcrf.gov Tue Nov 12 20:24:03 2002 From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford) Date: Tue, 12 Nov 2002 04:24:03 -0500 (EST) Subject: also needed for Tru64 SIA to work in privsep. WAS: Password expiry patch plans In-Reply-To: <3DCE722A.9080100@hp.com> Message-ID: On Sun, 10 Nov 2002, Michael Steffens wrote: > Darren Tucker wrote: > > [was Re: [Bug 423] Workaround for pw change in privsep mode (3.5.p1)] > > > > Frank Cusack wrote: > > > >>The PAM framework demands the type of exchange that > >>only keyboard-interactive offers. The way the "password" authentication > >>method interacts with PAM is a kludge. > > > > > > After following this thread and thinking about this for a while, this is > > the current plan for my experimental expiry patch[0]: > > <... text deleted ...> > > As far as privsep is concerned I'm getting the feeling that > Frank is right that all calls of PAM functions should be > moved to the privileged monitor. Possibly this could also > solve the auditing corruptions reported for Solaris? > > But in any way it requieres tunnneling PAM conversation between > monitor and unprivileged child, and this seems to be far from being > an easy task. Already tried to wrap my had around it only > for the keyboard interactive case... > This is exactly the problem with getting Tru64 SIA to work in privsep mode. SIA wants to 'talk' to the user directly over the tty that is passed to the auth routines. It insists on having this tty as it's own controlling terminal, which is not the case in privsep mode since the unpriviledged child has the tty. The way around this would be to have two separate tty's, one owned by the privledged process and passed to the SIA routines, and tunnel the conversation between the SIA routines and the unprivileged child. I don't know enough about tty programming and the internals of the ssh code to do this. If someone else figures it out though, it would be great if the code could be used for Tru64 also. :) Toni ----------------------------------------------------------------------- Toni Harbaugh-Blackford harbaugh at nciaxp.ncifcrf.gov AlphaServer System Administrator SAIC/NCI Frederick Advanced Biomedical Computing Center From Osmo.Paananen at sonera.inet.fi Wed Nov 13 02:33:44 2002 From: Osmo.Paananen at sonera.inet.fi (Osmo Paananen) Date: Tue, 12 Nov 2002 17:33:44 +0200 Subject: Locked account and logging in with public key Message-ID: <3DD11F58.5070009@sonera.inet.fi> Hi! I'm using Openssh v3.5p1 with Solaris 8 compiled with pam support enabled. It seems that if I use public key authentication I can log in to an account that is locked (/etc/shadow has *LK* as password). Login is also allowed even if the user does not have a valid shell. Is this a bug or am I missing something? -- Osmo Paananen From Robert.Dahlem at siemens.com Wed Nov 13 05:47:17 2002 From: Robert.Dahlem at siemens.com (Robert Dahlem) Date: Tue, 12 Nov 2002 19:47:17 +0100 Subject: Forcing privileged ports with ssh -R Message-ID: <200211121847.gACIlIB14691@mail1.siemens.de> Hi, I have a daemon process which is changings things in the system only the superuser should be allowed to change. Lets call it "riskyd". Users use a frontend on the same machine (lets call it "risky"). risky is a SUID program which talks to riskyd by binding to a privileged port, then connecting to riskyd on localhost. riskyd cheks that the connection is coming from localhost and from a privileged port to make sure the partner is privileged. Now - as an addition - I need connections from the network to riskyd too. These connections must be tunneled through a secure connection. The idea was to start something like my_host: # ssh -R riskyd_port:localhost:riskyd_port -N other_host This way the spawned sshd on other_host would listen() on riskyd's port, incoming connections are tunneled to my_host (the host riskyd is running on) and ssh makes a connection to the real riskyd on localhost (my_host). Some lousy ascii art: my_host other_host riskyd ^ | secure tunnel through network ssh ===================================== spawned sshd ^ | risky Now from the users point of view it looks like riskyd is running on other_host too: they can use risky, risky can connect to localhost:riskyd_port. But in this case the real action is done on my_host. riskyd still sees connections from localhost. So far, so good. But: sshd on other_host will happily accept connections from non- privileged ports, ssh will connect from a non-privileged port to localhost. No way to check if the originating connection was from a privileged port. How could this be forced? I did not find any parameters ... A stroll through the sources did not reveal something relevant (well, at least not to me :-) so it seems not to be implemented yet. Actually, remote forwarding is negotiated within some protocol between ssh and sshd. No problem to change this slightly with a private patch. If it only wouldn't incompatibly change the protocol. So my idea is to implement it in a way that client_request_forwarded_tcpip() in clientloop.c checks originator_port for being in the priveleged range and - if yes - uses a privileged port to connect. Any comments? Regards, Robert -- Robert.Dahlem at siemens.com Siemens Business Services - SBS D ORS FS BO DEZ KORDOBA-Outsourcing Tel: +49-69-797-6530 Fax: +49-69-797-6599 ---------------------------------------------------------------------- Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email software; far better than Outlook. Try it sometime. From markus at openbsd.org Wed Nov 13 06:20:29 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Nov 2002 20:20:29 +0100 Subject: Forcing privileged ports with ssh -R In-Reply-To: <200211121847.gACIlIB14691@mail1.siemens.de> References: <200211121847.gACIlIB14691@mail1.siemens.de> Message-ID: <20021112192029.GA5965@folly> On Tue, Nov 12, 2002 at 07:47:17PM +0100, Robert Dahlem wrote: > So my idea is to implement it in a way that > client_request_forwarded_tcpip() in clientloop.c checks originator_port > for being in the priveleged range and - if yes - uses a privileged port > to connect. yes, that would make sense, but only if privileged ports make sense. however, client_request_forwarded_tcpip is only for -R style and only for protocol version 2. (but i think you should use real authentication instead of privileged ports....) From Darren.Moffat at Sun.COM Wed Nov 13 07:41:45 2002 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 12 Nov 2002 12:41:45 -0800 (PST) Subject: Locked account and logging in with public key In-Reply-To: <3DD11F58.5070009@sonera.inet.fi> Message-ID: On Tue, 12 Nov 2002, Osmo Paananen wrote: > I'm using Openssh v3.5p1 with Solaris 8 compiled with pam support enabled. > > It seems that if I use public key authentication I can log in to an > account that is locked (/etc/shadow has *LK* as password). > Login is also allowed even if the user does not have a valid shell. > > Is this a bug or am I missing something? It is a Solaris 8 bug that was fixed in Solaris 9 (Sun BugId: 4506972) when pam_unix was broken into smaller modules. If tthe password field had *LK* in it the pam_authenticate call would have failed. However when using public key pam_authenticate() is not called only pam_acct_mgmt. In Solaris 9 the pam_sm_acct_mgmt() in pam_unix_account.so.1 call checks for *LK* explictly so that even if pam_authenticate() hadn't been called the account will still be reported as locked if pam_unix_account is in the PAM stack (which it is by default). The fix could be backported to Solaris 8 and I believe it will be done as part of a pending Solaris 8 feature patch - though I can't confirm this at the moment. -- Darren J Moffat From enigma at turingstudio.com Wed Nov 13 18:37:40 2002 From: enigma at turingstudio.com (Alex Black) Date: Tue, 12 Nov 2002 23:37:40 -0800 Subject: sftp file locking Message-ID: hi all, does sftp do file locking? I'm writing an app which will process incoming files uploaded files via sftp and it would be great if I could assume a file lock :) please respond directly as I am not subscribed. tia, sorry if this is the wrong list. _a From markus at openbsd.org Wed Nov 13 21:10:16 2002 From: markus at openbsd.org (Markus Friedl) Date: Wed, 13 Nov 2002 11:10:16 +0100 Subject: sftp file locking In-Reply-To: References: Message-ID: <20021113101016.GD10474@folly> On Tue, Nov 12, 2002 at 11:37:40PM -0800, Alex Black wrote: > does sftp do file locking? no, but it supports rename. From osmo.paananen at sonera.inet.fi Thu Nov 14 00:46:16 2002 From: osmo.paananen at sonera.inet.fi (Osmo Paananen) Date: Wed, 13 Nov 2002 15:46:16 +0200 Subject: Locked account and logging in with public key References: Message-ID: <3DD257A8.2020504@sonera.inet.fi> Darren J Moffat wrote: >On Tue, 12 Nov 2002, Osmo Paananen wrote: > >>I'm using Openssh v3.5p1 with Solaris 8 compiled with pam support enabled. >>It seems that if I use public key authentication I can log in to an >>account that is locked (/etc/shadow has *LK* as password). >>Login is also allowed even if the user does not have a valid shell. >>Is this a bug or am I missing something >> > >It is a Solaris 8 bug that was fixed in Solaris 9 (Sun BugId: 4506972) >when pam_unix was broken into smaller modules. > I don't believe that this is a Solaris 8 issue. The behavior seems to be identical in Solaris 2.6. If account has *LK* as password login is allowed when using public key authentication. Could this be a configuration issue? snippet from my (Sol 2.6) pam.conf: other auth required /usr/lib/security/pam_unix.so.1 other account required /usr/lib/security/pam_unix.so.1 other session required /usr/lib/security/pam_unix.so.1 other password required /usr/lib/security/pam_unix.so.1 From Darren.Moffat at Sun.COM Thu Nov 14 03:28:51 2002 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Wed, 13 Nov 2002 08:28:51 -0800 (PST) Subject: Locked account and logging in with public key In-Reply-To: <3DD257A8.2020504@sonera.inet.fi> Message-ID: On Wed, 13 Nov 2002, Osmo Paananen wrote: > Darren J Moffat wrote: > > >On Tue, 12 Nov 2002, Osmo Paananen wrote: > > > >>I'm using Openssh v3.5p1 with Solaris 8 compiled with pam support enabled. > >>It seems that if I use public key authentication I can log in to an > >>account that is locked (/etc/shadow has *LK* as password). > >>Login is also allowed even if the user does not have a valid shell. > >>Is this a bug or am I missing something > >> > > > >It is a Solaris 8 bug that was fixed in Solaris 9 (Sun BugId: 4506972) > >when pam_unix was broken into smaller modules. > > > I don't believe that this is a Solaris 8 issue. The behavior seems to > be identical in Solaris 2.6. You mentioned Solaris 8 as what you were running it is a bug in Solaris 8. That bug is present in Solaris 2.6 through Solaris 8. > Could this be a configuration issue? No it is an issue with how OpenSSH uses PAM and the assumptions that the pam_unix module had made. It isn't an OpenSSH bug or a configuration bug. It is a bug in pam_unix that can only show up if applications do not call pam_authenticate but still expect that pam_acct_mgmt will tell them if the account it locked. You can create a simple PAM module that implements pam_sm_acct_mgmt() and checks for the exact string *LK*. However if the account is locked by some other means (other than running passwd -l ) then that isn't going to work either. *LK* is the correct lock string for Solaris, it may not be correct for other systems that have PAM and a pam_unix or pam_unix like module. -- Darren J Moffat From weed at thebucket.org Thu Nov 14 09:12:59 2002 From: weed at thebucket.org (Ford Prefect) Date: Wed, 13 Nov 2002 16:12:59 -0600 (CST) Subject: askpass replacement which uses pam module to get password? Message-ID: greetings all, i'm not a member of this list, but i'm wondering if anyone has ever tried this before. i'm deploying some linux clients which authenticate against a yp server. at login time, if the user has never logged into the machine before, a script automatically creates their home directory. next, a pam module named pam_authtoken opens a unix socket which makes the plaintext password available to a script which then runs rsync -e ssh to sync their new home directory with the one on the server. at logout time, the process is reversed. the end result is intended to be similar to the "roaming profiles" system of a certain other operating system. unfortunately, i can't find a way to pipe the password into ssh that doesn't expose it one way or another. has anyone done any work on a way to get ssh (not sshd) to get it's password from a pam module (or heck, even from an environment variable)? i saw the work done on the fd patch and i guess that's a possibility, but i was hoping for something cleaner. like i said, i'm not subscribed to this list, so please cc me on any responses. thanks for your time, chris From ajith at noida.hcltech.com Thu Nov 14 20:43:34 2002 From: ajith at noida.hcltech.com (Ajit Yashwant Vaishampayan, Noida) Date: Thu, 14 Nov 2002 15:13:34 +0530 Subject: OpenSSL in OpenSSH Message-ID: Hi, Can somebody provide me information of what portion from OpenSSL is used in OpenSSH ? I am just trying to figure if some portion of OpenSSL is not working then still can I use it for OpenSSH. thanks, Ajit From markus at openbsd.org Thu Nov 14 21:28:06 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 14 Nov 2002 11:28:06 +0100 Subject: OpenSSL in OpenSSH In-Reply-To: References: Message-ID: <20021114102805.GB24439@folly> openssl basically consists of libcrypto and libssl. libcrypto is the larger part and openssh uses libcrypto only. On Thu, Nov 14, 2002 at 03:13:34PM +0530, Ajit Yashwant Vaishampayan, Noida wrote: > Hi, > > Can somebody provide me information of what portion from OpenSSL is used in > OpenSSH ? I am just trying to figure if some portion of OpenSSL is not > working then still can I use it for OpenSSH. > > thanks, > Ajit > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From bugzilla-daemon at mindrot.org Thu Nov 14 22:40:03 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 14 Nov 2002 22:40:03 +1100 (EST) Subject: [Bug 435] New: internal entropy gatherer Message-ID: <20021114114003.29E7D3D159@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=435 Summary: internal entropy gatherer Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: udo_guenthner at de.ibm.com Gathering entropy from programs does not work. Using multiple -v in ssh shows 'timed out' and returned 0.00 bytes for all commands in ssh_prng_cmds. Looking at the source code of ssh-rand-helper.c I found in line 309 and 310: dup2(p[1], STDOUT_FILENO); dup2(p[1], STDERR_FILENO); I guess the first should be p[0] (because in line 362 we have bytes_read = read(p[0], buf, sizeof(buf)); p[0] is not set and in 365ff if (bytes_read == -1) { error_abort = 1; later (starting 399) error_abort causes the 'timed out' message. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 15 00:21:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Nov 2002 00:21:25 +1100 (EST) Subject: [Bug 435] internal entropy gatherer Message-ID: <20021114132125.393EF3D166@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=435 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|internal entropy gatherer |internal entropy gatherer ------- Additional Comments From dtucker at zip.com.au 2002-11-15 00:21 ------- Which platform did you observe this on? Assuming it's AIX, it works ok for me on 4.3.3. What's in ssh_prng_cmds? Non-existant commands will produces zero entropy. $ /usr/local/libexec/ssh-rand-helper -vvv debug1: loading PRNG seed from file /home/dtucker/.ssh/prng_seed debug1: Seeded RNG with 3 bytes from system calls debug1: Loaded 25 entropy commands from /usr/local/etc/ssh_prng_cmds debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 38 msec debug3: Got 4.12 bytes of entropy from 'ls -alni /var/log' [snip] ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 15 01:33:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Nov 2002 01:33:34 +1100 (EST) Subject: [Bug 436] New: SSH client API Message-ID: <20021114143334.7EC013D0E6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=436 Summary: SSH client API Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jensus at linux.nu I would be usefull to have an API for the SSH client, so it could be used from other programs. Java-stype pseudo code: // create connections and forward ports SSHClient ssh = new SSHClient(); ssh.setUserAuthenticationHandler(new PasswordDialog()); ssh.setHostAuthenticationHandler(this); SSHSocket con = ssh.connect("127.0.0.1"); con.getOutputStream().write("hello".getBytes()); ssh.localForward(80, "www.google.com", 80); ssh.remoteForward(80, "www.google.com", 80); // access configuration SSHConfiguration sshConfig = ssh.getConfiguration(); SSHHostConfiguration hc = sshConfig.getHostConfiguration("*.ssh.box"); hc.setForwardX11(true); sshConfig.write(); // manage keys SSHKey key = SSHKeymanager.createKey(SSHKey.DSA, "apan-ola at foo.bar"); key.write("key1"); // creates ~/.ssh/key1 and ~/.ssh/key1.pub SSHKeymanager.removeKey("key1"); Collection keys = SSHKeymanager.listKeys(); ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 15 02:49:16 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Nov 2002 02:49:16 +1100 (EST) Subject: [Bug 435] internal entropy gatherer Message-ID: <20021114154916.D28823D16F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=435 ------- Additional Comments From udo_guenthner at de.ibm.com 2002-11-15 02:49 ------- I experienced it under IBM z/OS 1.3 Unix System Services (ufff :-( ) but looking at the source code I wonder how it ever works on any platform ... debug output: debug3: Reading output from 'ls -alni /tmp' debug3: Time elapsed: 40 msec debug2: Command 'ls -alni /tmp' timed out debug3: Got 0.00 bytes of entropy from 'ls -alni /tmp' debug3: Reading output from 'ls -alni /usr/lpp' debug3: Time elapsed: 33 msec debug2: Command 'ls -alni /usr/lpp' timed out debug3: Got 0.00 bytes of entropy from 'ls -alni /usr/lpp' debug3: Reading output from 'ls -alni /etc' debug3: Time elapsed: 35 msec debug2: Command 'ls -alni /etc' timed out debug3: Got 0.00 bytes of entropy from 'ls -alni /etc' debug3: Reading output from 'ls -alni /bin' debug3: Time elapsed: 39 msec debug2: Command 'ls -alni /bin' timed out debug3: Got 0.00 bytes of entropy from 'ls -alni /bin' ..... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 15 04:58:12 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 15 Nov 2002 04:58:12 +1100 (EST) Subject: [Bug 435] internal entropy gatherer Message-ID: <20021114175812.9EDF33D15D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=435 ------- Additional Comments From mouring at eviladmin.org 2002-11-15 04:58 ------- does this change actually fix it? the code pretty much clsoes all STDIN/STDOUT/STDERR of the parent so that the child can overwrite it. Some platforms may handle it without the close(p[..]) part correctly. If it does solve it and does not cause problems then I have no problems submitting such a patch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From godot at ulyssis.org Fri Nov 15 09:36:36 2002 From: godot at ulyssis.org (Danny De Cock) Date: Thu, 14 Nov 2002 23:36:36 +0100 (CET) Subject: playing with smartcard: rsa key upload? In-Reply-To: <20021104092849.GA17474@folly> Message-ID: hi, this is me again on smartcard authentication using openssh with opensc support ];-) I finally managed to get openssh do the job without spectacular crashes using a combination of: openssh-3.5p1, openssl-0.9.7-stable-SNAP-20021112, zlib-1.1.4, and the cvs-source for opensc fetched on november 12th. the changes I had to apply to scard.h, scard-opensc.c, sshconnect2.c, ssh-rsa.c and the Makefile (which was produced by `./configure --with-opensc=/usr/local --with-ssl-dir=/usr/local/ssl`) are included in the attachment. without these changes, the ssh binary dies due to a combination of fatal misuderstandings ];->> with these changes, a gemsafe gpk 16000 smartcard, holding a private key and a corresponding certificate, completes the rsa digital signature generation (using the first private key it finds) during the ssh authentication process (e.g. with `ssh -I 0 wherever.org`). I do not claim that the changes I applied are clean (cfr. sshconnect2.c), but they do what I expect them to do. in order not to interfere with the original openssh-3.5p1, all my changes follow this structure: #if defined(SMARTCARD) && defined(USE_OPENSC) my code #else original code #endif feel free to produce comments, danny. ps: is there a special reason why scp does not have smartcard support similar to ssh? I am currently `copying' the way ssh.c deals with smartcard support in general to scp.c, as for my application, I need both programs to behave similarly... On Mon, 4 Nov 2002, Markus Friedl wrote: > On Sun, Nov 03, 2002 at 06:14:57PM +0100, Danny De Cock wrote: > > the attachment contains a source file which solves the segmentation > > faults: a few type conflicts caused fatal misunderstandings between > > several routines of openssl and openssh. > > no, 'fatal misunderstandings' is wrong. OpenSSL has 2 different > interfaces for overloading the RSA routines (engine and non-engine). > check scard.c for a way to work around this problem (->USE_ENGINE). > > (btw, please send diffs instead of complete files). > > -m -------------- next part -------------- ===================== scard.h ===================== 40,43d39 < #if defined(SMARTCARD) && defined(USE_OPENSC) < int sc_sign(int type, u_char *m, unsigned int m_len, unsigned char *sigret, unsigned int *siglen, RSA *rsa); < #endif < ===================== scard-opensc.c ===================== 188,210c188 < #if defined(SMARTCARD) && defined(USE_OPENSC) < char * < get_pin (struct sc_pkcs15_object *obj) < { < char buf[80]; < char *pincode; < struct sc_pkcs15_pin_info *pinfo = (struct sc_pkcs15_pin_info *) obj->data; < < sprintf (buf, "Enter PIN [%s]: ", obj->label); < while (1) < { < pincode = getpass (buf); < if (strlen (pincode) == 0) < return NULL; < if (strlen (pincode) < pinfo->min_length || < strlen (pincode) > pinfo->stored_length) < continue; < return pincode; < } < } < #endif < < int --- > static int 214,274d191 < #if defined(SMARTCARD) && defined(USE_OPENSC) < struct sc_pkcs15_object *key_obj; < int r; < struct sc_pkcs15_id id; < struct sc_pkcs15_object *objs[32]; < struct sc_pkcs15_object *key; < unsigned long flags = 0; < char *pincode; < struct sc_pkcs15_object *pin; < < r = sc_lock (card); < if (r) < { < error ("Unable to lock smartcard: %s", sc_strerror (r)); < goto err; < } < r = sc_pkcs15_get_objects (p15card, SC_PKCS15_TYPE_PRKEY, objs, 32); < key = objs[0]; < if (key->auth_id.len) < { < r = sc_pkcs15_find_pin_by_auth_id (p15card, &key->auth_id, &pin); < if (r) < { < debug (stderr, "Unable to find PIN code for private key: %s\n", < sc_strerror (r)); < return -1; < } < pincode = get_pin (pin); < if (pincode == NULL) < { < return -1; < } < r = < sc_pkcs15_verify_pin (p15card, < (struct sc_pkcs15_pin_info *) pin->data, < (const u8 *) pincode, strlen (pincode)); < if (r) < { < debug (stderr, "PIN code verification failed: %s\n", < sc_strerror (r)); < return -1; < } < free (pincode); < debug ("PIN code correct.\n"); < } < // /* FIXME: check 'type' and modify flags accordingly */ < flags = SC_ALGORITHM_RSA_PAD_PKCS1 | SC_ALGORITHM_RSA_HASH_SHA1; < r = sc_pkcs15_compute_signature (p15card, key, flags, < m, m_len, sigret, RSA_size (rsa)); < if (r < 0) < { < error ("sc_pkcs15_compute_signature() failed: %s", sc_strerror (r)); < goto err; < } < sc_unlock (card); < *siglen = r; < return 1; < err: < sc_close (); < return 0; < #else 298d214 < #endif ===================== sshconnect2.c ===================== 170,175d169 < #if defined(SMARTCARD) && defined(USE_OPENSC) < static int < key_sign_cb(Authctxt *authctxt, Key *key, u_char **sigp, u_int *lenp, < u_char *data, u_int datalen); < #endif < 605,607d598 < #if defined(SMARTCARD) && defined(USE_OPENSC) < ret = (key_sign_cb)(authctxt, k, &signature, &slen, < #else 609d599 < #endif ===================== ssh-rsa.c ===================== 40,43d39 < #if defined(SMARTCARD) && defined(USE_OPENSC) < #include "scard.h" < #endif < 74,76d69 < #if defined(SMARTCARD) && defined(USE_OPENSC) < ok = sc_sign(nid, digest, dlen, sig, &len, key->rsa); < #else 78d70 < #endif ===================== Makefile ===================== 65,66c65 < #SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o < SSHOBJS= scard-opensc.o ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o --- > SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o From markus at openbsd.org Fri Nov 15 09:56:14 2002 From: markus at openbsd.org (Markus Friedl) Date: Thu, 14 Nov 2002 23:56:14 +0100 Subject: playing with smartcard: rsa key upload? In-Reply-To: References: <20021104092849.GA17474@folly> Message-ID: <20021114225614.GA19481@folly> On Thu, Nov 14, 2002 at 11:36:36PM +0100, Danny De Cock wrote: > ps: is there a special reason why scp does not have smartcard support > similar to ssh? I am currently `copying' the way ssh.c deals with > smartcard support in general to scp.c, as for my application, I need both > programs to behave similarly... you could use -o SmartcardDevice for scp From markus at openbsd.org Fri Nov 15 10:17:23 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 15 Nov 2002 00:17:23 +0100 Subject: playing with smartcard: rsa key upload? In-Reply-To: References: <20021104092849.GA17474@folly> Message-ID: <20021114231723.GA26565@folly> there should be no need to do this, you can overwrite the RSA_sign method with the OpenSSL API. On Thu, Nov 14, 2002 at 11:36:36PM +0100, Danny De Cock wrote: > ===================== ssh-rsa.c ===================== > 40,43d39 > < #if defined(SMARTCARD) && defined(USE_OPENSC) > < #include "scard.h" > < #endif > < > 74,76d69 > < #if defined(SMARTCARD) && defined(USE_OPENSC) > < ok = sc_sign(nid, digest, dlen, sig, &len, key->rsa); > < #else > 78d70 > < #endif From yusufg at outblaze.com Sat Nov 16 01:15:47 2002 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Fri, 15 Nov 2002 22:15:47 +0800 Subject: workaround for 'hang on exit' bug does not seem to work Message-ID: <20021115141547.GA16118@outblaze.com> Hi, I am using Redhat 7.3 which comes with openssh 3.1p1. I am running an antivirus software called vexira on this server. It starts of 2 daemon processes in the background. Whenever I stop/start these daemons in an ssh session, it hangs. I added "shopt -s huponexit" (without the quotes) in /etc/bashrc, but the hangs still occur. Any advice on this would be appreciated Regards, Yusuf -- Yusuf Goolamabbas yusufg at outblaze.com From Daniel.D.Olsson at telia.se Sat Nov 16 01:19:35 2002 From: Daniel.D.Olsson at telia.se (Daniel.D.Olsson at telia.se) Date: Fri, 15 Nov 2002 15:19:35 +0100 Subject: Error 255 Openssh-3.5 Message-ID: <03AD0B0B2573644A86F2C1F890691D8F013D376E@TMS011MB.tcad.telia.se> Hello I try to compile openssh-3.5 on Solaris 2.6 with gcc-3.2. configure and make is no problem but when i do make install following error comes out mkdir /opt/openssh/etc ssh-rand-helper: Cannot find ELF ssh-rand-helper child produced insufficient data ssh-rand-helper: Cannot find ELF ssh-rand-helper child produced insufficient data ssh-rand-helper: Cannot find ELF ssh-rand-helper child produced insufficient data make: *** [host-key] Error 255 o Anyone that no what to do mail me on daniel.d.olsson at telia.se From Daniel.D.Olsson at telia.se Sat Nov 16 01:58:53 2002 From: Daniel.D.Olsson at telia.se (Daniel.D.Olsson at telia.se) Date: Fri, 15 Nov 2002 15:58:53 +0100 Subject: Error openssh Message-ID: <03AD0B0B2573644A86F2C1F890691D8F013D3770@TMS011MB.tcad.telia.se> Hello Following error when compiling openssh-3.5 on solaris 2.6 gcc-3.2 Have installed /dev/random /dev/urandom for another error (255) but no I get this. /opt/openssh/sbin/sshd -t -f /opt/openssh/etc/sshd_config sshd: Cannot find ELF make: *** [check-config] Killed Anyone that no what to do mail me on daniel.d.olsson at telia.se From mouring at etoh.eviladmin.org Sat Nov 16 02:37:34 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 15 Nov 2002 09:37:34 -0600 (CST) Subject: Error 255 Openssh-3.5 In-Reply-To: <03AD0B0B2573644A86F2C1F890691D8F013D376E@TMS011MB.tcad.telia.se> Message-ID: Do you have GNU binutil loaded? If so I suggest you update them. Older versions were buggy and created bad code. - Ben On Fri, 15 Nov 2002 Daniel.D.Olsson at telia.se wrote: > Hello > > I try to compile openssh-3.5 on Solaris 2.6 with gcc-3.2. > > configure and make is no problem but when i do make install following error comes out > > mkdir /opt/openssh/etc > ssh-rand-helper: Cannot find ELF > ssh-rand-helper child produced insufficient data > ssh-rand-helper: Cannot find ELF > ssh-rand-helper child produced insufficient data > ssh-rand-helper: Cannot find ELF > ssh-rand-helper child produced insufficient data > make: *** [host-key] Error 255 > o > > Anyone that no what to do mail me on daniel.d.olsson at telia.se > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From binder at arago.de Sat Nov 16 03:20:10 2002 From: binder at arago.de (Thomas Binder) Date: Fri, 15 Nov 2002 17:20:10 +0100 Subject: workaround for 'hang on exit' bug does not seem to work In-Reply-To: <20021115141547.GA16118@outblaze.com>; from yusufg@outblaze.com on Fri, Nov 15, 2002 at 10:15:47PM +0800 References: <20021115141547.GA16118@outblaze.com> Message-ID: <20021115172010.A28287464@ohm.arago.de> Hi! On Fri, Nov 15, 2002 at 10:15:47PM +0800, Yusuf Goolamabbas wrote: > Hi, I am using Redhat 7.3 which comes with openssh 3.1p1. I am > running an antivirus software called vexira on this server. It > starts of 2 daemon processes in the background. Whenever I > stop/start these daemons in an ssh session, it hangs. > > I added "shopt -s huponexit" (without the quotes) in > /etc/bashrc, but the hangs still occur. Any advice on this would > be appreciated Try starting your daemons with stdin, stdout and stderr redirected to /dev/null. E.g. when you're using an sh-compatible shell and your daemons have a single startup script '/etc/init.d/vexira' (this is only an assumption), you'd have to type /etc/init.d/vexira < /dev/null > /dev/null 2>&1 Ciao Thomas From bugzilla-daemon at mindrot.org Sat Nov 16 03:21:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 16 Nov 2002 03:21:20 +1100 (EST) Subject: [Bug 435] internal entropy gatherer Message-ID: <20021115162120.364493D185@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=435 udo_guenthner at de.ibm.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From udo_guenthner at de.ibm.com 2002-11-16 03:21 ------- seems that the select() does not work properly on my system. Sometimes it times out even when the elapsed time of the command is less than the specified timeout. maybe a timer resolution issue on my platform .... when I specify for instance a timeout of 300 ms, somm commands that used 250 ms are ok, but others with 30 ms are not ... When I set the timeout to 500 ms or more, I have a good chance to get entropy (although I cannot be sure :-( ). Guess I have to find a fix for the select() problem. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From P.Brown at mmu.ac.uk Sat Nov 16 03:59:24 2002 From: P.Brown at mmu.ac.uk (Phillip Brown) Date: Fri, 15 Nov 2002 16:59:24 GMT Subject: apparent ssh_config fascism Message-ID: <200211151659.gAFGxO620145@doughnut.doc.stu.mmu.ac.uk> It appears that /etc/ssh/ssh_config enforces policy on local users in addition to its documented role as provider of defaults. $ ssh -V OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f $ cat .ssh/config Host localhost HostbasedAuthentication yes PreferredAuthentications hostbased $ ssh localhost Hostbased authentication not enabled in /etc/ssh/ssh_config ssh_keysign: no reply key_sign failed Permission denied (publickey,password,keyboard-interactive,hostbased). The situation is rectified by enabling Hostbased authentication in /etc/ssh/ssh_config (as the error message suggests), but this must be done by the systems administrator. Why is the setting in .ssh/config not sufficient? Is this behaviour a bug or a feature? BTW these experiences are with the RPM for Red Hat 7.3 From markus at openbsd.org Sat Nov 16 04:26:56 2002 From: markus at openbsd.org (Markus Friedl) Date: Fri, 15 Nov 2002 18:26:56 +0100 Subject: apparent ssh_config fascism In-Reply-To: <200211151659.gAFGxO620145@doughnut.doc.stu.mmu.ac.uk> References: <200211151659.gAFGxO620145@doughnut.doc.stu.mmu.ac.uk> Message-ID: <20021115172656.GA28187@folly> On Fri, Nov 15, 2002 at 04:59:24PM +0000, Phillip Brown wrote: > $ ssh localhost > Hostbased authentication not enabled in /etc/ssh/ssh_config > ssh_keysign: no reply > key_sign failed > Permission denied (publickey,password,keyboard-interactive,hostbased). > > The situation is rectified by enabling Hostbased authentication in > /etc/ssh/ssh_config (as the error message suggests), but this must be > done by the systems administrator. Why is the setting in .ssh/config not > sufficient? Is this behaviour a bug or a feature? the systems administrator has to allow the use of the private hostkey for authentication. From mouring at etoh.eviladmin.org Sat Nov 16 06:03:42 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 15 Nov 2002 13:03:42 -0600 (CST) Subject: apparent ssh_config fascism In-Reply-To: <200211151659.gAFGxO620145@doughnut.doc.stu.mmu.ac.uk> Message-ID: Because man 'ssh-keysign' says: [..] Since they are readable only by root, ssh-keysign must be set-uid root if hostbased authentication is used. So it does the user no good to enabled it if ssh-keysign is not setuid. So yes. There is a reason for it. - Ben On Fri, 15 Nov 2002, Phillip Brown wrote: > > It appears that /etc/ssh/ssh_config enforces policy on local users in > addition to its documented role as provider of defaults. > > $ ssh -V > OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f > > $ cat .ssh/config > Host localhost > HostbasedAuthentication yes > PreferredAuthentications hostbased > > $ ssh localhost > Hostbased authentication not enabled in /etc/ssh/ssh_config > ssh_keysign: no reply > key_sign failed > Permission denied (publickey,password,keyboard-interactive,hostbased). > > The situation is rectified by enabling Hostbased authentication in > /etc/ssh/ssh_config (as the error message suggests), but this must be > done by the systems administrator. Why is the setting in .ssh/config not > sufficient? Is this behaviour a bug or a feature? > > BTW these experiences are with the RPM for Red Hat 7.3 > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Sat Nov 16 07:20:54 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 16 Nov 2002 07:20:54 +1100 (EST) Subject: [Bug 125] with BSM auditing, cron editing thru ssh session causes cron jobs to fail Message-ID: <20021115202054.A3E743D152@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=125 ------- Additional Comments From Brian.King at xwave.com 2002-11-16 07:20 ------- One of the suggested work-a-rounds was to set "UseLogin yes" in sshd_config. This does not work 100% of the time. SSH clients used in non-interactive modes still exhibit the problem. e.g.: ssh {hostname} "crontab -l >crontmp ; crontab crontmp" Will corrupt your cron audit file just the same as if "UseLogin no" was set. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dtucker at zip.com.au Sat Nov 16 09:19:59 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 16 Nov 2002 09:19:59 +1100 Subject: Error 255 Openssh-3.5 References: Message-ID: <3DD5730F.BDDAF427@zip.com.au> Ben Lindstrom wrote: On Fri, 15 Nov 2002 Daniel.D.Olsson at telia.se wrote: > > make install following error comes out > > > > mkdir /opt/openssh/etc > > ssh-rand-helper: Cannot find ELF > Do you have GNU binutil loaded? If so I suggest you update them. Older > versions were buggy and created bad code. You can also set your path so /usr/ccs/bin/strip is used instead of /usr/local/bin/strip. The error occurs when binaries linked by /usr/ccs/bin/ld are stripped by GNU strip from binutils 2.12.1 or lower. As Ben said, upgrading binutils is probably your best bet. -- 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 bugzilla-daemon at mindrot.org Sat Nov 16 11:26:49 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 16 Nov 2002 11:26:49 +1100 (EST) Subject: [Bug 437] New: Expiry from the moment of last use Message-ID: <20021116002649.431AE3D18D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=437 Summary: Expiry from the moment of last use Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: ssh-agent AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bugzilla.mindrot.org at future.shiny.co.il ssh-add / ssh-agent should have an option to start counting private key expiry time from the moment it was last time used. That way, one would only need to re-enter the private key's password if he actually left the desk for a prolonged time rather than once in constant period of time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From DPIERROT at unedic.fr Mon Nov 18 21:02:00 2002 From: DPIERROT at unedic.fr (PIERROT David) Date: Mon, 18 Nov 2002 11:02:00 +0100 Subject: (no subject) Message-ID: <4F711A956E6FD311AA2100508B5C5AD5042B8703@SA10900301.moe.ups-b.unedic.fr> Good morning, I am david pierrot ingeener for it company. We nned to install a ssh client and ssh server (linux and win 2000) we have have problem , could you tell me please if this thing is possible. we want that users on ssh can only use sftp or scp but we do not want thath they can be use roo command or something elese. with sshd command it is possible to use telnet by port 22, do you think that is it possible to forbiden this kind of thing and to have only ftp command. many thanks in advance. best regards > DAVID PIERROT > UNEDIC Ma?trise d'Oeuvre > * 5, avenue Jean Jaures - BP2 - 69551 FEYZIN Cedex msg : dpierrott at unedic.fr Tel. : 04-72-89-23-62 +----------------------------------------------------------------+ | Ce courrier ainsi que les fichiers joints sont confidentiels. | | Si vous avez recu ce courrier par erreur, veuillez en informer | | l'administrateur du systeme : exp-iris at unedic.fr | | --------- | | Ce message confirme que le courrier a passe le controle | | antivirus du relais de messagerie Internet avec succes. | +----------------------------------------------------------------+ From markus at openbsd.org Mon Nov 18 21:12:01 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Nov 2002 11:12:01 +0100 Subject: apparent ssh_config fascism In-Reply-To: References: <200211151659.gAFGxO620145@doughnut.doc.stu.mmu.ac.uk> Message-ID: <20021118101201.GE29727@folly> On Fri, Nov 15, 2002 at 01:03:42PM -0600, Ben Lindstrom wrote: > > Because man 'ssh-keysign' says: > > [..] Since they > are readable only by root, ssh-keysign must be set-uid root if > hostbased authentication is used. > > So it does the user no good to enabled it if ssh-keysign is not setuid. but that's not the reason. the sysadmin might now want you to use the hostkey, so she has to decide if ssh-keysign should be enabled. having the sysadmin remove the sbit is not an option, so it's controlled by the config file. From markus at openbsd.org Mon Nov 18 22:35:30 2002 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Nov 2002 12:35:30 +0100 Subject: signals and ssh Message-ID: <20021118113530.GA32303@folly> hi, please test this. if ssh is called with SIGINT ignored (e.g. from a backup system, with rmt) then ssh should not overwrite set it's own handler. Index: clientloop.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/clientloop.c,v retrieving revision 1.104 diff -u -r1.104 clientloop.c --- clientloop.c 22 Aug 2002 19:38:42 -0000 1.104 +++ clientloop.c 18 Nov 2002 11:33:45 -0000 @@ -888,10 +888,16 @@ client_init_dispatch(); - /* Set signal handlers to restore non-blocking mode. */ - signal(SIGINT, signal_handler); - signal(SIGQUIT, signal_handler); - signal(SIGTERM, signal_handler); + /* + * Set signal handlers, (e.g. to restore non-blocking mode) + * but don't overwrite SIG_IGN, matches behaviour from rsh(1) + */ + if (signal(SIGINT, SIG_IGN) != SIG_IGN) + signal(SIGINT, signal_handler); + if (signal(SIGQUIT, SIG_IGN) != SIG_IGN) + signal(SIGQUIT, signal_handler); + if (signal(SIGTERM, SIG_IGN) != SIG_IGN) + signal(SIGTERM, signal_handler); if (have_pty) signal(SIGWINCH, window_change_handler); From dtucker at zip.com.au Mon Nov 18 23:07:31 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 18 Nov 2002 23:07:31 +1100 Subject: also needed for Tru64 SIA to work in privsep. WAS: Password expirypatch plans References: Message-ID: <3DD8D803.14A3E6AB@zip.com.au> "Toni L. Harbaugh-Blackford" wrote: > On Sun, 10 Nov 2002, Michael Steffens wrote: > > But in any way it requieres tunnneling PAM conversation between > > monitor and unprivileged child > > This is exactly the problem with getting Tru64 SIA to work in privsep > mode. SIA wants to 'talk' to the user directly over the tty that is passed > to the auth routines. How about allocating a pty and passing the fd's back to the slave, then calling chauthtok or whatever in the monitor? ie: 1) Slave calls wrapped chauthtok, request passed to monitor 2) Monitor allocs pty, opens, makes controlling tty 3) Monitor passes descriptors back to slave 4) Monitor calls chauthtok / SIA / whatever 5) Slave spins copying to and from stdio and the passed fd's 6) In monitor, chauthtok returns and returns status to slave 7) Slave reads return status from monitor No, I haven't tried this so I don't know if it will work. I don't know if you want the monitor to have a controlling tty either. -- 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 P.Brown at mmu.ac.uk Mon Nov 18 23:39:05 2002 From: P.Brown at mmu.ac.uk (Phillip Brown) Date: Mon, 18 Nov 2002 12:39:05 GMT Subject: apparent ssh_config fascism Message-ID: <200211181239.gAICd5l27910@doughnut.doc.stu.mmu.ac.uk> After reading the man page for ssh-keysign, some admins might be unaware that root can use Hostbased authentication by only having a setting in .ssh/config without having to think about the ramifications of going down the /etc/ssh/ssh_config route. Maybe man ssh-keysign should be fleshed out a little to make the exception absolutely clear. The fact that Hostbased authentication needs to be enabled in /etc/ssh/ssh_config to make the method available to users other than root, even when ssh-keysign is suid root, suggests that it should be a decision the administrator should not take lightly - and hence that such ramifications do exist. Perhaps there are scenarios of abuse or am I reading to much into this? From michael_steffens at hp.com Mon Nov 18 23:59:42 2002 From: michael_steffens at hp.com (Michael Steffens) Date: Mon, 18 Nov 2002 13:59:42 +0100 Subject: also needed for Tru64 SIA to work in privsep. WAS: Password expirypatch plans References: <3DD8D803.14A3E6AB@zip.com.au> Message-ID: <3DD8E43E.7020306@hp.com> Darren Tucker wrote: > "Toni L. Harbaugh-Blackford" wrote: >>This is exactly the problem with getting Tru64 SIA to work in privsep >>mode. SIA wants to 'talk' to the user directly over the tty that is passed >>to the auth routines. > > > How about allocating a pty and passing the fd's back to the slave, then > calling chauthtok or whatever in the monitor? ie: > > 1) Slave calls wrapped chauthtok, request passed to monitor > 2) Monitor allocs pty, opens, makes controlling tty > 3) Monitor passes descriptors back to slave > 4) Monitor calls chauthtok / SIA / whatever > 5) Slave spins copying to and from stdio and the passed fd's > 6) In monitor, chauthtok returns and returns status to slave > 7) Slave reads return status from monitor Sounds very good to me. But 5) seems to be the tough point (where actually my brain got spinning :) How to avoid communication monitor <-> slave and slave <-> network socket blocking each other? The latter one will need to be served for the remote client to see the communication in any case. The PAM conversation funtion of keyboard-interactive seems to avoid a similar problem by taking over network communication itself, using SSH2_MSG_USERAUTH_INFO_REQUEST packets. Besides being protocol 2 only, would this method be usable for our purpose? Or does it need to be integrated in sshd's server loop? From dtucker at zip.com.au Tue Nov 19 00:29:27 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 19 Nov 2002 00:29:27 +1100 Subject: also needed for Tru64 SIA to work in privsep. WAS: Passwordexpirypatch plans References: <3DD8D803.14A3E6AB@zip.com.au> <3DD8E43E.7020306@hp.com> Message-ID: <3DD8EB37.C0DDBC91@zip.com.au> Michael Steffens wrote: > > 1) Slave calls wrapped chauthtok, request passed to monitor > > 2) Monitor allocs pty, opens, makes controlling tty > > 3) Monitor passes descriptors back to slave > > 4) Monitor calls chauthtok / SIA / whatever > > 5) Slave spins copying to and from stdio and the passed fd's > > 6) In monitor, chauthtok returns and returns status to slave > > 7) Slave reads return status from monitor > > Sounds very good to me. But 5) seems to be the tough point > (where actually my brain got spinning :) > > How to avoid communication monitor <-> slave and > slave <-> network socket blocking each other? The > latter one will need to be served for the remote client > to see the communication in any case. I was thinking of during the session (ie where chauthtok is now) and SIA (about which I know nothing except the contents of the previous message). You could select() on the 2 readable fds? Given the challenge-response nature of PAM, it's likely to be half-duplex anyway. It doesn't (easily) handle the keyboard-interactive + privsep case. You could wrap a simple protocol around it (eg ^D = end of message or something) for that but that might be ugly. -- 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 Tue Nov 19 01:06:22 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 18 Nov 2002 08:06:22 -0600 (CST) Subject: apparent ssh_config fascism In-Reply-To: <20021118101201.GE29727@folly> Message-ID: Just stated that it may have the setuid bit removed if the admin is locking down a box and decided the feature was not required and he's rather not have yet another setuid binary running around. So it is not just a simple 'switch' you throw and it magicly works. Which is what the original poster was trying to imply. - Ben On Mon, 18 Nov 2002, Markus Friedl wrote: > On Fri, Nov 15, 2002 at 01:03:42PM -0600, Ben Lindstrom wrote: > > > > Because man 'ssh-keysign' says: > > > > [..] Since they > > are readable only by root, ssh-keysign must be set-uid root if > > hostbased authentication is used. > > > > So it does the user no good to enabled it if ssh-keysign is not setuid. > > but that's not the reason. the sysadmin might now want you to use > the hostkey, so she has to decide if ssh-keysign should be > enabled. > > having the sysadmin remove the sbit is not an option, so it's > controlled by the config file. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Tue Nov 19 04:38:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Nov 2002 04:38:32 +1100 (EST) Subject: [Bug 438] New: SFTP does not work for users with RSH shells Message-ID: <20021118173832.5C71D3D157@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=438 Summary: SFTP does not work for users with RSH shells Product: Portable OpenSSH Version: older versions Platform: Sparc OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bmzoueit at hewitt.com Users with rsh (ristricted) shells on our Solaris 8 servers are unable to use SFTP. rsh is included in the /etc/shells file, so that's not the issue. The rsh shell users can SSH to the servers just fine, but they can't use SFTP. Any idea why this is happening? here are the errors we're getting: linuddb3# ./sftp -v -oPort=##### temp at localhost Connecting to localhost... OpenSSH_3.2.3p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f debug1: Reading configuration data /apps/openssh/3.2.3p1/etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 1 debug1: Connecting to localhost [127.0.0.1] port #####. debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 0/1 (e=0) debug1: restore_uid 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.2.3p1 debug1: match: OpenSSH_3.2.3p1 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.2.3p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 130/256 debug1: bits set: 1589/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'localhost' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:31 debug1: bits set: 1619/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password debug1: next auth method to try is publickey debug1: try privkey: /.ssh/id_rsa debug1: try privkey: /.ssh/id_dsa debug1: next auth method to try is password temp at localhost's password: debug1: ssh-userauth2 successful: method password debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: ssh_session2_setup: id 0 debug1: Sending subsystem: sftp debug1: channel request 0: subsystem debug1: channel 0: open confirm rwindow 0 rmax 32768 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd close debug1: channel 0: close_read debug1: channel 0: input open -> closed debug1: channel 0: almost dead debug1: channel 0: gc: notify user debug1: channel 0: gc: user detached debug1: channel 0: send close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 1 Connection closed ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Tue Nov 19 05:46:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Nov 2002 05:46:37 +1100 (EST) Subject: [Bug 438] SFTP does not work for users with RSH shells Message-ID: <20021118184637.765183D14C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=438 ------- Additional Comments From mouring at eviladmin.org 2002-11-19 05:46 ------- if the user logs in and types /path/to/sftp-server does he/she get an error? If rsh is impeeding running the command then it is a rsh issue and not a sftp issue. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From samuel at bcgreen.com Tue Nov 19 05:55:29 2002 From: samuel at bcgreen.com (Stephen Samuel) Date: Mon, 18 Nov 2002 10:55:29 -0800 Subject: allowing sftp only users In-Reply-To: <4F711A956E6FD311AA2100508B5C5AD5042B8703@SA10900301.moe.ups-b.unedic.fr> References: <4F711A956E6FD311AA2100508B5C5AD5042B8703@SA10900301.moe.ups-b.unedic.fr> Message-ID: <3DD937A1.1040209@bcgreen.com> I've attached an email that I wrote a couple of weeks ago -- including my solution to the problem. (an sftp chroot jail). It has two parts: an sftpsh replacement for nologin and a (very spall) patch for sftp While I'm at it. what's the protocol for submitting these changes for inclusion in the base release? PIERROT David wrote: > Good morning, > > I am david pierrot ingeener for it company. > > We nned to install a ssh client and ssh server (linux and win 2000) > > we have have problem , could you tell me please if this thing is possible. > > we want that users on ssh can only use sftp or scp but we do not want thath > they can be use roo command or something elese. > with sshd command it is possible to use telnet by port 22, do you think that > is it possible to forbiden this kind of thing and to have only ftp command. > > many thanks in advance. > > best regards > > >>DAVID PIERROT >>UNEDIC Ma?trise d'Oeuvre >>* 5, avenue Jean Jaures - BP2 - 69551 FEYZIN Cedex > > msg : dpierrott at unedic.fr > Tel. : 04-72-89-23-62 > > > > +----------------------------------------------------------------+ > | Ce courrier ainsi que les fichiers joints sont confidentiels. | > | Si vous avez recu ce courrier par erreur, veuillez en informer | > | l'administrateur du systeme : exp-iris at unedic.fr | > | --------- | > | Ce message confirme que le courrier a passe le controle | > | antivirus du relais de messagerie Internet avec succes. | > +----------------------------------------------------------------+ > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Stephen Samuel +1(604)876-0426 samuel at bcgreen.com http://www.bcgreen.com/~samuel/ Powerful committed communication, reaching through fear, uncertainty and doubt to touch the jewel within each person and bring it to life. -------------- next part -------------- An embedded message was scrubbed... From: Stephen Samuel Subject: changes to allow chroot'ed sftp Date: Sun, 10 Nov 2002 22:41:53 -0800 Size: 6720 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021118/78447be5/attachment.mht From alchemst at mysun.com Tue Nov 19 06:00:03 2002 From: alchemst at mysun.com (Jason Arnold) Date: Mon, 18 Nov 2002 13:00:03 -0600 Subject: [Bug 438] SFTP does not work for users with RSH shells Message-ID: <5acb05b97f.5b97f5acb0@mysun.com> rsh and friends (rksh, rcsh, etc) do not allow "/" in commands, hence the problem. The normal solution is to ln all of the appropriate commands into the user's path, but in this case, that probably means modifing sshd_config to not be fully pathed (assuming that doesn't break anything and all other users also have it in their compiled in paths). Jason Lacoss-Arnold St. Louis, MO USA ----- Original Message ----- From: bugzilla-daemon at mindrot.org Date: Monday, November 18, 2002 12:46 pm Subject: [Bug 438] SFTP does not work for users with RSH shells > http://bugzilla.mindrot.org/show_bug.cgi?id=438 > > > > > > ------- Additional Comments From mouring at eviladmin.org 2002-11-19 > 05:46 ------- > if the user logs in and types /path/to/sftp-server does he/she > get an error? > If rsh is impeeding running the command then it is a rsh issue and > not a sftp > issue. > > - Ben > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: "alchemst.vcf Type: text/x-vcard Size: 192 bytes Desc: Card for Jason Arnold Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021118/1eedae44/attachment.vcf From bugzilla-daemon at mindrot.org Tue Nov 19 07:25:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Nov 2002 07:25:24 +1100 (EST) Subject: [Bug 438] SFTP does not work for users with RSH shells Message-ID: <20021118202524.434733D0E6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=438 ------- Additional Comments From bmzoueit at hewitt.com 2002-11-19 07:25 ------- when running the sftp-server with the path specified, we get the "restricted" error... $ /apps/ssh/current/libexec/sftp-server rsh: /apps/ssh/current/libexec/sftp-server: restricted but when running it without specifying the path, it works.. $ sftp-server ^C $ sounds like its an rsh issue.. any ideas on top of your head? Thanks, Bassel. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Tue Nov 19 09:30:00 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 18 Nov 2002 16:30:00 -0600 (CST) Subject: NeXT Community wake up and smell the test cycle. Message-ID: If no one replies soon on if this solves NeXTStep's incomplete mmap() configuration then I will start ignoring all whining about that platform. From bugzilla-daemon at mindrot.org Tue Nov 19 09:53:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 19 Nov 2002 09:53:30 +1100 (EST) Subject: [Bug 438] SFTP does not work for users with RSH shells Message-ID: <20021118225330.15BA23D152@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=438 ------- Additional Comments From mouring at eviladmin.org 2002-11-19 09:53 ------- Only advice I can give you. Is make sure that sftp-server is in the core system path and change: sshd_config: # override default of no subsystems Subsystem sftp /path/to/sftp-server to: # override default of no subsystems Subsystem sftp sftp-server - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mouring at etoh.eviladmin.org Tue Nov 19 09:43:31 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 18 Nov 2002 16:43:31 -0600 (CST) Subject: allowing sftp only users In-Reply-To: <3DD937A1.1040209@bcgreen.com> Message-ID: Why do you need to modify sftp-server at all? Your sftpsh should be able to handle it all internally. - Ben On Mon, 18 Nov 2002, Stephen Samuel wrote: > I've attached an email that I wrote a couple of weeks ago -- including > my solution to the problem. (an sftp chroot jail). It has two parts: an > sftpsh replacement for nologin and a (very spall) patch for sftp > > While I'm at it. what's the protocol for submitting these changes > for inclusion in the base release? > > PIERROT David wrote: > > Good morning, > > > > I am david pierrot ingeener for it company. > > > > We nned to install a ssh client and ssh server (linux and win 2000) > > > > we have have problem , could you tell me please if this thing is possible. > > > > we want that users on ssh can only use sftp or scp but we do not want thath > > they can be use roo command or something elese. > > with sshd command it is possible to use telnet by port 22, do you think that > > is it possible to forbiden this kind of thing and to have only ftp command. > > > > many thanks in advance. > > > > best regards > > > > > >>DAVID PIERROT > >>UNEDIC Ma?trise d'Oeuvre > >>* 5, avenue Jean Jaures - BP2 - 69551 FEYZIN Cedex > > > > msg : dpierrott at unedic.fr > > Tel. : 04-72-89-23-62 > > > > > > > > +----------------------------------------------------------------+ > > | Ce courrier ainsi que les fichiers joints sont confidentiels. | > > | Si vous avez recu ce courrier par erreur, veuillez en informer | > > | l'administrateur du systeme : exp-iris at unedic.fr | > > | --------- | > > | Ce message confirme que le courrier a passe le controle | > > | antivirus du relais de messagerie Internet avec succes. | > > +----------------------------------------------------------------+ > > > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- > Stephen Samuel +1(604)876-0426 samuel at bcgreen.com > http://www.bcgreen.com/~samuel/ > Powerful committed communication, reaching through fear, uncertainty and > doubt to touch the jewel within each person and bring it to life. > From samuel at bcgreen.com Tue Nov 19 12:02:45 2002 From: samuel at bcgreen.com (Stephen Samuel) Date: Mon, 18 Nov 2002 17:02:45 -0800 Subject: allowing sftp only users In-Reply-To: References: Message-ID: <3DD98DB5.3060704@bcgreen.com> I only need to modify sftp-server if I want to creat arbitrary chroot jails. Once the chroot jail is created, there's no real way to find the sftp-server binary. As a result, the chroot call needs to be done by sftp-server. The 5-line change to sftp-server consists of checking for a -c flag, doing the chroot and then doing a chdir("/") call (to close off any possible chroot escape) Ben Lindstrom wrote: > > Why do you need to modify sftp-server at all? Your sftpsh should be able > to handle it all internally. > > - Ben > > On Mon, 18 Nov 2002, Stephen Samuel wrote: > > >>I've attached an email that I wrote a couple of weeks ago -- including >>my solution to the problem. (an sftp chroot jail). It has two parts: an >>sftpsh replacement for nologin and a (very spall) patch for sftp >> >>While I'm at it. what's the protocol for submitting these changes >>for inclusion in the base release? >> >>PIERROT David wrote: >> >>>Good morning, >>> >>>I am david pierrot ingeener for it company. >>> >>>We nned to install a ssh client and ssh server (linux and win 2000) >>> >>>we have have problem , could you tell me please if this thing is possible. >>> >>>we want that users on ssh can only use sftp or scp but we do not want thath >>>they can be use roo command or something elese. >>>with sshd command it is possible to use telnet by port 22, do you think that >>>is it possible to forbiden this kind of thing and to have only ftp command. >>> >>>many thanks in advance. >>> >>>best regards >>> >>> >>> >>>>DAVID PIERROT >>>>UNEDIC Ma?trise d'Oeuvre >>>>* 5, avenue Jean Jaures - BP2 - 69551 FEYZIN Cedex >>> >>>msg : dpierrott at unedic.fr >>>Tel. : 04-72-89-23-62 >>> >>> >>> >>>+----------------------------------------------------------------+ >>>| Ce courrier ainsi que les fichiers joints sont confidentiels. | >>>| Si vous avez recu ce courrier par erreur, veuillez en informer | >>>| l'administrateur du systeme : exp-iris at unedic.fr | >>>| --------- | >>>| Ce message confirme que le courrier a passe le controle | >>>| antivirus du relais de messagerie Internet avec succes. | >>>+----------------------------------------------------------------+ >>> >>>_______________________________________________ >>>openssh-unix-dev at mindrot.org mailing list >>>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> >>-- >>Stephen Samuel +1(604)876-0426 samuel at bcgreen.com >> http://www.bcgreen.com/~samuel/ >>Powerful committed communication, reaching through fear, uncertainty and >>doubt to touch the jewel within each person and bring it to life. >> > > -- Stephen Samuel +1(604)876-0426 samuel at bcgreen.com http://www.bcgreen.com/~samuel/ Powerful committed communication, reaching through fear, uncertainty and doubt to touch the jewel within each person and bring it to life. From bugzilla-daemon at mindrot.org Wed Nov 20 00:35:31 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Nov 2002 00:35:31 +1100 (EST) Subject: [Bug 439] New: key_try_load_public() always sets pathname as the keyfile's comment Message-ID: <20021119133531.8F1D03D0E6@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=439 Summary: key_try_load_public() always sets pathname as the keyfile's comment Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: binder at arago.de The function key_try_load_public() in authfile.c always uses the key's pathname as the comment, ignoring any comment actually given in the public key file. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Nov 20 00:37:37 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 20 Nov 2002 00:37:37 +1100 (EST) Subject: [Bug 439] key_try_load_public() always sets pathname as the keyfile's comment Message-ID: <20021119133737.872673D171@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=439 ------- Additional Comments From binder at arago.de 2002-11-20 00:37 ------- Created an attachment (id=178) --> (http://bugzilla.mindrot.org/attachment.cgi?id=178&action=view) Proposed patch This patch returns the keyfile's comment if there is one, the keyfile's path otherwise. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From J.S.Peatfield at damtp.cam.ac.uk Wed Nov 20 04:37:34 2002 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Tue, 19 Nov 2002 17:37:34 +0000 Subject: forwarding features Message-ID: <200211191737.gAJHbY424106.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> While messing with various tunnels it occured to me that there may be cases where some extra tunneling functionality would come in handy. I thought I better run it past the list before trying to implement a patch since the last 2 times I did this there was another way to get the effect I wanted with no code changes... Forwarding should not just be of AF_INET but (where available) AF_UNIX (ie forwarding unix-domain sockets). The syntax might be a little messy though. The ability to set up forwardings at any point, e.g. ssh to a host which runs some code to determine which ports need forwarding and it asks the sshd to negotiate with the client, or a user might want to add a new forwarded connection by typing some ~ stuff from the client end... The reason I've been thinking about this is that I need to be able to set up a -R tunnel, but I don't know the port to listen on since someone else may already be using that port (well I can select the port at random, but that isn't safe either -- perhaps port 0 should ask sshd to select any free port). If I could port-forward unix-domain sockets then the name could be guarenteed unique, similarly if the forwarding could be added after running code we would be ok too. [ Well I could do it with external code at both ends I suppose, but that just makes it harder to run on some platforms ... ] -- Jon Peatfield, DAMTP, Computer Officer, University of Cambridge Telephone: +44 1223 3 37852 Mail: J.S.Peatfield at damtp.cam.ac.uk From tim at mcgarry.ch Wed Nov 20 08:39:05 2002 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 19 Nov 2002 22:39:05 +0100 Subject: forwarding features References: <200211191737.gAJHbY424106.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Message-ID: <000b01c29014$1716a1a0$ca02a8c0@opf.swissbank.com> This is what agent-forwarding does, it could be handy if it was available for other uses too Tim ----- Original Message ----- From: "Jon Peatfield" To: Sent: Tuesday, November 19, 2002 6:37 PM Subject: forwarding features > While messing with various tunnels it occured to me that there may be > cases where some extra tunneling functionality would come in handy. I > thought I better run it past the list before trying to implement a > patch since the last 2 times I did this there was another way to > get the effect I wanted with no code changes... > > Forwarding should not just be of AF_INET but (where available) > AF_UNIX (ie forwarding unix-domain sockets). The syntax might be a > little messy though. > > The ability to set up forwardings at any point, e.g. ssh to a host > which runs some code to determine which ports need forwarding and it > asks the sshd to negotiate with the client, or a user might want to > add a new forwarded connection by typing some ~ stuff from the > client end... > > The reason I've been thinking about this is that I need to be able to > set up a -R tunnel, but I don't know the port to listen on since > someone else may already be using that port (well I can select the > port at random, but that isn't safe either -- perhaps port 0 should > ask sshd to select any free port). If I could port-forward > unix-domain sockets then the name could be guarenteed unique, > similarly if the forwarding could be added after running code we would > be ok too. > > [ Well I could do it with external code at both ends I suppose, but > that just makes it harder to run on some platforms ... ] > > -- > Jon Peatfield, DAMTP, Computer Officer, University of Cambridge > Telephone: +44 1223 3 37852 Mail: J.S.Peatfield at damtp.cam.ac.uk > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From rao3 at leicester.ac.uk Wed Nov 20 22:03:12 2002 From: rao3 at leicester.ac.uk (R.A.Owen) Date: Wed, 20 Nov 2002 11:03:12 +0000 (GMT) Subject: Key comment to syslog on login Message-ID: Hello, Firstly thankyou for developing openssh - it is a great tool. Secondly I'm not subscribed to this list - sorry! It would be helpful to log the key comment to syslog when logging in using private key authentication. At the moment I get. Nov xx xx:xx:xx hostname sshd[pid]: Accepted publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2 If this could be changed to log the key comment as stored in ~/.ssh/authorized_keys... something like Nov xx xx:xx:xx hostname sshd[pid]: Accepted publickey "key_comment_here" for root from xxx.xxx.xxx.xxx port xxxxx ssh2 then I could let other admins log in as root using public key authentication and still have an audit trail of who logged in due to the key comments. Perhaps the syslog message should include the key fingerprint too/instead of the key_comment. ie: Nov xx xx:xx:xx hostname sshd[pid]: Accepted publickey "key_comment_here" fingerprint=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx for root from xxx.xxx.xxx.xxx port xxxxx ssh2 or Nov xx xx:xx:xx hostname sshd[pid]: Accepted publickey fingerprint=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx for root from xxx.xxx.xxx.xxx port xxxxx ssh2 I'm sure I would not be the only one to benifit from a better audit trail. I have looked briefly at the code but I'm not up to the job so no patch is attached! I hope that you find this idea a usefull one and that it get's added to the "ToDo" list. Thanks for your time... Alex Owen ---------------------------------------------------------------- Dr Richard Alexander Owen Unix System Administrator ---------------------------------------------------------------- From dtucker at zip.com.au Thu Nov 21 01:00:39 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 21 Nov 2002 01:00:39 +1100 Subject: [PATCH #9] Password expiration via /bin/passwd. Message-ID: <3DDB9587.88EE6E74@zip.com.au> This is an attempt to simplify the AIX expiry-via-passwd stuff and make it more generic. (There's actually a net reduction in #ifdefs). Patch against CVS: 1) configure finds passwd. 2) sshd uses passwd during session if required. 3) sshd uses passwd for PAM change if privsep disabled. 4) sshd uses Buffers for expire and post-login messages (no longer AIX specific). 5) password_change_required generalized (no longer PAM specific). Tested on the following configurations: Redhat 8 (without PAM) AIX 4.3.3 Solaris 8 (without PAM) HP-UX 11.0 (trusted configuration, with PAM) I'm confused about this from auth-pam.c: /* XXX: This would need to be done in the parent process, * but there's currently no way to pass such request. */ no_port_forwarding_flag &= ~2; no_agent_forwarding_flag &= ~2; no_x11_forwarding_flag &= ~2; if (!no_port_forwarding_flag && options.allow_tcp_forwarding) channel_permit_all_opens(); Isn't this all in the post-auth privsep slave? Or am I overlooking something? -- 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 -------------- Index: acconfig.h =================================================================== RCS file: /cvs/openssh/acconfig.h,v retrieving revision 1.145 diff -u -r1.145 acconfig.h --- acconfig.h 26 Sep 2002 00:38:48 -0000 1.145 +++ acconfig.h 20 Nov 2002 13:12:12 -0000 @@ -25,6 +25,9 @@ /* from environment and PATH */ #undef LOGIN_PROGRAM_FALLBACK +/* Path to passwd program */ +#undef PASSWD_PROGRAM_PATH + /* Define if your password has a pw_class field */ #undef HAVE_PW_CLASS_IN_PASSWD Index: auth-pam.c =================================================================== RCS file: /cvs/openssh/auth-pam.c,v retrieving revision 1.54 diff -u -r1.54 auth-pam.c --- auth-pam.c 28 Jul 2002 20:24:08 -0000 1.54 +++ auth-pam.c 20 Nov 2002 13:12:12 -0000 @@ -60,7 +60,7 @@ /* states for do_pam_conversation() */ enum { INITIAL_LOGIN, OTHER } pamstate = INITIAL_LOGIN; /* remember whether pam_acct_mgmt() returned PAM_NEW_AUTHTOK_REQD */ -static int password_change_required = 0; +extern int password_change_required; /* remember whether the last pam_authenticate() succeeded or not */ static int was_authenticated = 0; @@ -256,7 +256,6 @@ case PAM_SUCCESS: /* This is what we want */ break; -#if 0 case PAM_NEW_AUTHTOK_REQD: message_cat(&__pam_msg, use_privsep ? NEW_AUTHTOK_MSG_PRIVSEP : NEW_AUTHTOK_MSG); @@ -267,7 +266,6 @@ no_agent_forwarding_flag |= 2; no_x11_forwarding_flag |= 2; break; -#endif default: log("PAM rejected by account configuration[%d]: " "%.200s", pam_retval, PAM_STRERROR(__pamh, @@ -352,6 +350,8 @@ if (pam_retval != PAM_SUCCESS) fatal("PAM pam_chauthtok failed[%d]: %.200s", pam_retval, PAM_STRERROR(__pamh, pam_retval)); + else + password_change_required = 0; #if 0 /* XXX: This would need to be done in the parent process, * but there's currently no way to pass such request. */ Index: auth-passwd.c =================================================================== RCS file: /cvs/openssh/auth-passwd.c,v retrieving revision 1.48 diff -u -r1.48 auth-passwd.c --- auth-passwd.c 25 Sep 2002 23:14:16 -0000 1.48 +++ auth-passwd.c 20 Nov 2002 13:12:13 -0000 @@ -42,6 +42,8 @@ #include "log.h" #include "servconf.h" #include "auth.h" +#include "buffer.h" +#include "misc.h" #if !defined(USE_PAM) && !defined(HAVE_OSF_SIA) /* Don't need any of these headers for the PAM or SIA cases */ @@ -81,8 +83,10 @@ #endif /* !USE_PAM && !HAVE_OSF_SIA */ extern ServerOptions options; +extern Buffer login_message; +extern int password_change_required; #ifdef WITH_AIXAUTHENTICATE -extern char *aixloginmsg; +void aix_remove_embedded_newlines(char *); #endif /* @@ -149,13 +153,23 @@ #endif #ifdef WITH_AIXAUTHENTICATE authsuccess = (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0); + aix_remove_embedded_newlines(authmsg); - if (authsuccess) + if (authsuccess) { + char *msg; + + debug("authenticate() succeeded for user %s: %.100s", pw->pw_name, authmsg); /* We don't have a pty yet, so just label the line as "ssh" */ if (loginsuccess(authctxt->user, - get_canonical_hostname(options.verify_reverse_mapping), - "ssh", &aixloginmsg) < 0) - aixloginmsg = NULL; + get_canonical_hostname(options.verify_reverse_mapping), + "ssh", &msg) < 0) + msg = NULL; + buffer_append(&login_message, msg, strlen(msg)); + } else { + debug("authenticate() failed for user %s: %.100s", pw->pw_name, authmsg); + } + if (authmsg) + xfree(authmsg); return(authsuccess); #endif @@ -232,4 +246,43 @@ /* Authentication is accepted if the encrypted passwords are identical. */ return (strcmp(encrypted_password, pw_password) == 0); #endif /* !USE_PAM && !HAVE_OSF_SIA */ +} + +/* + * Perform generic password change via tty + * Like do_pam_chauthtok(), it throws a fatal error if the password can't be changed. + */ +void +do_tty_change_password(struct passwd *pw) +{ + pid_t pid; + int status; + mysig_t old_signal; + + old_signal = mysignal(SIGCHLD, SIG_DFL); + + if ((pid = fork()) == -1) + fatal("Couldn't fork: %s", strerror(errno)); + + if (pid == 0) { + setuid(pw->pw_uid); + if (geteuid() == 0) + execl(PASSWD_PROGRAM_PATH, "passwd", pw->pw_name, + (char *)NULL); + else + execl(PASSWD_PROGRAM_PATH, "passwd", (char *)NULL); + + /* execl shouldn't return */ + fatal("Couldn't exec %s", PASSWD_PROGRAM_PATH); + exit(1); + } + + if (waitpid(pid, &status, 0) == -1) + fatal("Couldn't wait for child: %s", strerror(errno)); + + if (WEXITSTATUS(status)) /* Passwd exited abnormally */ + fatal("Failed to change password for %s, passwd returned %d", pw->pw_name, status); + + mysignal(SIGCHLD, old_signal); + password_change_required = 0; } Index: auth.c =================================================================== RCS file: /cvs/openssh/auth.c,v retrieving revision 1.61 diff -u -r1.61 auth.c --- auth.c 9 Nov 2002 16:11:12 -0000 1.61 +++ auth.c 20 Nov 2002 13:12:13 -0000 @@ -58,6 +58,12 @@ /* Debugging messages */ Buffer auth_debug; int auth_debug_init; +extern int password_change_required; +extern Buffer expire_message; + +#ifdef WITH_AIXAUTHENTICATE +void aix_remove_embedded_newlines(char *); +#endif /* * Check if the user is allowed to log in via ssh. If user is listed @@ -75,21 +81,22 @@ const char *hostname = NULL, *ipaddr = NULL; char *shell; int i; -#ifdef WITH_AIXAUTHENTICATE - char *loginmsg; -#endif /* WITH_AIXAUTHENTICATE */ #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) struct spwd *spw; +#endif /* Shouldn't be called if pw is NULL, but better safe than sorry... */ if (!pw || !pw->pw_name) return 0; + buffer_init(&expire_message); +#if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ + !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) #define DAY (24L * 60 * 60) /* 1 day in seconds */ spw = getspnam(pw->pw_name); if (spw != NULL) { - time_t today = time(NULL) / DAY; + time_t expiredate, today = time(NULL) / DAY; debug3("allowed_user: today %d sp_expire %d sp_lstchg %d" " sp_max %d", (int)today, (int)spw->sp_expire, (int)spw->sp_lstchg, (int)spw->sp_max); @@ -106,20 +113,28 @@ if (spw->sp_lstchg == 0) { log("User %.100s password has expired (root forced)", pw->pw_name); - return 0; + password_change_required = 1; + buffer_append(&expire_message, + "You must change your password now.\n", 35); } - if (spw->sp_max != -1 && - today > spw->sp_lstchg + spw->sp_max) { + expiredate = spw->sp_lstchg + spw->sp_max; + if (spw->sp_max != -1 && today > expiredate) { log("User %.100s password has expired (password aged)", pw->pw_name); - return 0; + password_change_required = 1; + buffer_append(&expire_message, + "Your password has expired, you must change it now.\n", + 51); + } else if (spw->sp_max != -1 && expiredate - today < 14) { + char msg[100]; + + snprintf(msg, 100, + "Your password will expire in %d days.\n", + (int)(expiredate - today)); + buffer_append(&expire_message, msg, strlen(msg)); } } -#else - /* Shouldn't be called if pw is NULL, but better safe than sorry... */ - if (!pw || !pw->pw_name) - return 0; #endif /* @@ -203,25 +218,46 @@ #ifdef WITH_AIXAUTHENTICATE /* - * Don't check loginrestrictions() for root account (use + * Don't check loginrestrictions or expiry for root account (use * PermitRootLogin to control logins via ssh), or if running as * non-root user (since loginrestrictions will always fail). */ - if ( (pw->pw_uid != 0) && (geteuid() == 0) && - loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) { - if (loginmsg && *loginmsg) { - /* Remove embedded newlines (if any) */ - char *p; - for (p = loginmsg; *p; p++) { - if (*p == '\n') - *p = ' '; + if ( (pw->pw_uid != 0) && (geteuid() == 0) ) { + char *msg; + int passexpcode; + + /* check for AIX account restrictions */ + if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &msg) != 0) { + if (msg && *msg) { + aix_remove_embedded_newlines(msg); + log("Login restricted for %s: %.100s", pw->pw_name, msg); + xfree(msg); } - /* Remove trailing newline */ - *--p = '\0'; - log("Login restricted for %s: %.100s", pw->pw_name, loginmsg); + return 0; } - return 0; - } + + /* check for AIX expired account */ + passexpcode = passwdexpired(pw->pw_name, &msg); + buffer_append(&expire_message, msg, strlen(msg)); + + switch (passexpcode) { + case 0: /* success, password not expired */ + break; + case 1: /* expired, password change required */ + password_change_required = 1; + break; + default: /* expired too long (2) or other error (-1) */ + if (msg && *msg) + aix_remove_embedded_newlines(msg); + debug3("AIX passwdexpired returned %d, msg %.100s", + passexpcode, msg); + log("Password expired too long or system failure for user %s: %.100s", + pw->pw_name, msg); + if (msg) + xfree(msg); + return 0; + } + } #endif /* WITH_AIXAUTHENTICATE */ /* We found no reason not to let this user try to log on... */ Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.92 diff -u -r1.92 configure.ac --- configure.ac 13 Nov 2002 23:55:57 -0000 1.92 +++ configure.ac 20 Nov 2002 13:12:14 -0000 @@ -40,6 +40,13 @@ fi fi +AC_PATH_PROG(PASSWD_PROGRAM_PATH, passwd) +if test ! -z "$PASSWD_PROGRAM_PATH" ; then + AC_DEFINE_UNQUOTED(PASSWD_PROGRAM_PATH, "$PASSWD_PROGRAM_PATH") +else + AC_MSG_ERROR([*** passwd command not found - check config.log ***]) +fi + if test -z "$LD" ; then LD=$CC fi Index: session.c =================================================================== RCS file: /cvs/openssh/session.c,v retrieving revision 1.222 diff -u -r1.222 session.c --- session.c 26 Sep 2002 00:38:50 -0000 1.222 +++ session.c 20 Nov 2002 13:12:16 -0000 @@ -102,10 +102,11 @@ /* data */ #define MAX_SESSIONS 10 Session sessions[MAX_SESSIONS]; +Buffer expire_message; /* "password will expire/has expired" messages */ +Buffer login_message; /* message to be displayed after login */ +int password_change_required = 0; -#ifdef WITH_AIXAUTHENTICATE -char *aixloginmsg; -#endif /* WITH_AIXAUTHENTICATE */ +void do_tty_change_password(struct passwd *); #ifdef HAVE_LOGIN_CAP login_cap_t *lc; @@ -456,10 +457,11 @@ #if defined(USE_PAM) do_pam_session(s->pw->pw_name, NULL); do_pam_setcred(1); - if (is_pam_password_change_required()) +#endif /* USE_PAM */ + + if (password_change_required) packet_disconnect("Password change required but no " "TTY available"); -#endif /* USE_PAM */ /* Fork the child. */ if ((pid = fork()) == 0) { @@ -723,6 +725,7 @@ socklen_t fromlen; struct sockaddr_storage from; struct passwd * pw = s->pw; + int password_changed = 0; pid_t pid = getpid(); /* @@ -746,16 +749,23 @@ options.verify_reverse_mapping), (struct sockaddr *)&from, fromlen); -#ifdef USE_PAM /* * If password change is needed, do it now. * This needs to occur before the ~/.hushlogin check. */ +#ifdef USE_PAM if (is_pam_password_change_required()) { print_pam_messages(); - do_pam_chauthtok(); + if (!use_privsep) + do_pam_chauthtok(); } #endif + buffer_append(&expire_message, "\0", 1); + if (password_change_required) { + printf("%s", (char *)buffer_ptr(&expire_message)); + do_tty_change_password(pw); + password_changed = 1; + } if (check_quietlogin(s, command)) return; @@ -764,10 +774,11 @@ if (!is_pam_password_change_required()) print_pam_messages(); #endif /* USE_PAM */ -#ifdef WITH_AIXAUTHENTICATE - if (aixloginmsg && *aixloginmsg) - printf("%s\n", aixloginmsg); -#endif /* WITH_AIXAUTHENTICATE */ + if (!password_changed) + printf("%s", (char *)buffer_ptr(&expire_message)); + + buffer_append(&login_message, "\0", 1); + printf("%s", (char *)buffer_ptr(&login_message)); #ifndef NO_SSH_LASTLOG if (options.print_lastlog && s->last_login_time != 0) { Index: openbsd-compat/port-aix.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/port-aix.c,v retrieving revision 1.6 diff -u -r1.6 port-aix.c --- openbsd-compat/port-aix.c 7 Jul 2002 02:17:36 -0000 1.6 +++ openbsd-compat/port-aix.c 20 Nov 2002 13:12:16 -0000 @@ -52,5 +52,25 @@ xfree(cp); } -#endif /* _AIX */ +#ifdef WITH_AIXAUTHENTICATE +/* + * Remove embedded newlines in string (if any). + * Used before logging messages returned by AIX authentication functions + * so the message is logged on one line. + */ +void +aix_remove_embedded_newlines(char *p) +{ + if (p == NULL) + return; + + for (; *p; p++) { + if (*p == '\n') + *p = ' '; + } + /* Remove trailing newline */ + *--p = '\0'; +} +#endif /* WITH_AIXAUTHENTICATE */ +#endif /* _AIX */ From Robert.Dahlem at siemens.com Thu Nov 21 04:58:48 2002 From: Robert.Dahlem at siemens.com (Robert Dahlem) Date: Wed, 20 Nov 2002 18:58:48 +0100 Subject: Forcing privileged ports with ssh -R Message-ID: <200211201758.gAKHwnx22515@mail2.siemens.de> On Tue, 12 Nov 2002 19:47:17 +0100, Robert Dahlem wrote: [abstract: in need of knowing wether remote side incoming connection for ssh -R came from a privileged port and - if yes - connect on the local side from a privileged port too] >So my idea is to implement it in a way that >client_request_forwarded_tcpip() in clientloop.c checks originator_port >for being in the priveleged range and - if yes - uses a privileged port >to connect. I implemented this, please see attached patch file. I made it an option (-Q), because it implies some trust into the remote sshd. Any chance this will make it into the "official" code? Regards, Robert -- Robert.Dahlem at siemens.com Siemens Business Services - SBS D ORS FS BO DEZ KORDOBA-Outsourcing Tel: +49-69-797-6530 Fax: +49-69-797-6599 ---------------------------------------------------------------------- Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email software; far better than Outlook. Try it sometime. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 11042 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021120/e3b3644a/attachment.obj From stevesk at pobox.com Thu Nov 21 06:35:13 2002 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 20 Nov 2002 11:35:13 -0800 Subject: [marco.ortisi@flashcom.it: Re: bug on openssh 3.5p1] Message-ID: <20021120193513.GA1443@jenny.crlsca.adelphia.net> related to RST-based close in one case? can someone investigate or dup? ----- Forwarded message from marco.ortisi at flashcom.it ----- Date: Tue, 19 Nov 2002 11:49:30 GMT From: marco.ortisi at flashcom.it To: Kevin Steves Subject: Re: bug on openssh 3.5p1 Excuse me for delay...i have much work in this time...then >can you post to the list? i don't have linux. I can't....smtp filter's list refuse my messages with label "dirty words" and my messages go in quarantene. >also, include sshd -ddd output. I include sshd -ddd output session as txt attachment file. ssh's Configuration file that i use is standard sshd_config installed after compiling the package. In this case i have modified only the listen port (not 22 but 6699). Now i go... Regards, Marco Ortisi [root at FlashComa xabino]# /usr/local/sbin/sshd -ddd debug1: sshd version OpenSSH_3.5p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA socket: Address family not supported by protocol debug1: Bind to port 6699 on 0.0.0.0. Server listening on 0.0.0.0 port 6699. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 192.168.0.66 port 32982 debug1: Client protocol version 2.0; client software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.5p1 debug2: Network child is on pid 14179 debug3: preauth child monitor started debug3: mm_request_receive entering debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.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-group1-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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.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: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_send entering: type 1 debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 130/256 debug1: bits set: 1619/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1655/3191 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_answer_sign: signature 0x809efa8(143) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for root debug3: mm_start_pam entering debug3: mm_request_send entering: type 41 debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 41 debug1: Starting up PAM with username "root" debug3: Trying to reverse map address 192.168.0.66. debug1: PAM setting rhost to "192.168.0.66" debug2: monitor_read: 41 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 Failed none for root from 192.168.0.66 port 32982 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user not authenticated Failed none for root from 192.168.0.66 port 32982 ssh2 debug1: userauth-request for user root service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=root devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for root from 192.168.0.66 port 32982 ssh2 debug1: userauth-request for user root service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug1: PAM Password authentication accepted for user "root" debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 11 ROOT LOGIN REFUSED FROM 192.168.0.66 debug2: pam_acct_mgmt() = 0 Failed password for root from 192.168.0.66 port 32982 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user authenticated Accepted password for root from 192.168.0.66 port 32982 ssh2 debug3: mm_send_keystate: Sending new keys: 0x8098d98 0x80993e0 debug3: mm_newkeys_to_blob: converting 0x8098d98 debug3: mm_newkeys_to_blob: converting 0x80993e0 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state debug3: monitor_read: checking request 24 monitor_read: unsupported request: 24 debug1: Calling cleanup 0x8052fa0(0x0) [root at FlashComa xabino]# /usr/local/sbin/sshd -ddd debug1: sshd version OpenSSH_3.5p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA socket: Address family not supported by protocol debug1: Bind to port 6699 on 0.0.0.0. Server listening on 0.0.0.0 port 6699. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 192.168.0.66 port 32982 debug1: Client protocol version 2.0; client software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_3.5p1 debug2: Network child is on pid 14179 debug3: preauth child monitor started debug3: mm_request_receive entering debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.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-group1-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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.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: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_send entering: type 1 debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 130/256 debug1: bits set: 1619/3191 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1655/3191 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_answer_sign: signature 0x809efa8(143) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for root debug3: mm_start_pam entering debug3: mm_request_send entering: type 41 debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 41 debug1: Starting up PAM with username "root" debug3: Trying to reverse map address 192.168.0.66. debug1: PAM setting rhost to "192.168.0.66" debug2: monitor_read: 41 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 Failed none for root from 192.168.0.66 port 32982 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user not authenticated Failed none for root from 192.168.0.66 port 32982 ssh2 debug1: userauth-request for user root service ssh-connection method keyboard-interactive debug1: attempt 1 failures 1 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=root devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for root from 192.168.0.66 port 32982 ssh2 debug1: userauth-request for user root service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug1: PAM Password authentication accepted for user "root" debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 11 ROOT LOGIN REFUSED FROM 192.168.0.66 debug2: pam_acct_mgmt() = 0 Failed password for root from 192.168.0.66 port 32982 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user authenticated Accepted password for root from 192.168.0.66 port 32982 ssh2 debug3: mm_send_keystate: Sending new keys: 0x8098d98 0x80993e0 debug3: mm_newkeys_to_blob: converting 0x8098d98 debug3: mm_newkeys_to_blob: converting 0x80993e0 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state debug3: monitor_read: checking request 24 monitor_read: unsupported request: 24 debug1: Calling cleanup 0x8052fa0(0x0) ----- End forwarded message ----- From bugzilla-daemon at mindrot.org Thu Nov 21 06:47:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 21 Nov 2002 06:47:15 +1100 (EST) Subject: [Bug 440] New: Protocol 1 server key generated at start up even when P1 not used Message-ID: <20021120194715.259F93D182@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=440 Summary: Protocol 1 server key generated at start up even when P1 not used Product: Portable OpenSSH Version: older versions Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: bruno at wolff.to A protocol 1 server key is generated when sshd starts up even if only protocol 2 is allowed and hence that key will never be used. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jmknoble at pobox.com Thu Nov 21 06:54:19 2002 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 20 Nov 2002 14:54:19 -0500 Subject: Key comment to syslog on login In-Reply-To: ; from rao3@leicester.ac.uk on Wed, Nov 20, 2002 at 11:03:12AM +0000 References: Message-ID: <20021120145419.B30056@zax.half.pint-stowp.cx> Circa 2002-11-20 11:03:12 +0000 dixit R.A.Owen: : Hello, : Firstly thankyou for developing openssh - it is a great tool. : Secondly I'm not subscribed to this list - sorry! : : It would be helpful to log the key comment to syslog when logging in using : private key authentication. Key comments can be manipulated by the user who has the key. Putting them in the log would produce a false sense that you know what's going on. The fingerprints, however, are not able to be changed. : Perhaps the syslog message should include the key fingerprint too/instead : of the key_comment. ie: [...] The key fingerprint is logged if you set LogLevel to VERBOSE in sshd_config. : I'm sure I would not be the only one to benifit from a better audit trail. : I have looked briefly at the code but I'm not up to the job so no patch is : attached! : : I hope that you find this idea a usefull one and that it get's added to : the "ToDo" list. Actually, it's added to the "Done" list. ;) -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "I am non-refutable." --Enik the Altrusian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021120/6bda3f99/attachment.bin From bugzilla-daemon at mindrot.org Thu Nov 21 20:22:00 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 21 Nov 2002 20:22:00 +1100 (EST) Subject: [Bug 440] Protocol 1 server key generated at start up even when P1 not used Message-ID: <20021121092200.E37783D181@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=440 ------- Additional Comments From markus at openbsd.org 2002-11-21 20:21 ------- when does this happen? i don't see this with version 3.5 (or 2.5.1) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 22 01:01:57 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Nov 2002 01:01:57 +1100 (EST) Subject: [Bug 441] New: should ssh BindAddress apply to LocalForward ports Message-ID: <20021121140157.C0AAB3D138@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=441 Summary: should ssh BindAddress apply to LocalForward ports Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: sjc at makalumedia.com when i use -b and port forward together, the forwarded port is not bound to the same local address (should it ?). (ive patch my local ssh to do this). This brings me to the basic idea that -L/-R could optionally accept quads ie -L [local_bind_addr:]port:host:port -R [remote_bind_addr:]port:host:port this is actually what i would like as always binding to the -b option is not flexible. .... Simon ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From c234 at www.com Thu Nov 21 15:53:36 2002 From: c234 at www.com (john cisse) Date: Thu, 21 Nov 2002 15:53:36 Subject: c234@www.com Message-ID: <20021121145621.5A28B3D155@shitei.mindrot.org> -------------------------------------------------------------------------------- Request for urgent business Reletionship ATTN Sir, first i must solicit your co-operetion in this transaction, give the fact that we have not known before i therefore seekyour permission in this regard.I get your contact from a member of goverment delegation who visited overesas on trade mission .I am MR JOHN CISSE, the head of accounts departtment in ECOWAS INTERNATIONAL BANK ,Republic of benin , cutonu.we have in the records in ouraccount department an investment account belonging to Engneer KELVIN MICHEAL An oil merchant totaling us$35.725.00Unfortunately Engneer KELVIN MICHEAL died during the sept11th 2001 on terrorist attact on world trade center (wtc)usa.Ashead of the accountdepartment i have the mandate of the account which stpalates that in the event of the death of the account hulder the next of kin to lateEngneer KELVIN MICHEAL should make claims for the fund .It is now over one year this incedent happend and we have not heard from anybody as nest of kin to the account holder and all efforts to contact the family of late Engneer KELVIN MICHEAL from the bank have not yeedled no resuld ,it is assumed that they are not aware of the deposlt.Based on the policy of the bank any account that is inactive for overone year the will dealare it domant and close the account in thir favour.in view of the policy and bin order to sefganrd this fund, iam my colleagueshave decided to contact you to front as Engneer KELVIN MICHEALnext of kin and make claim for the relcase of the fund to you .We wist to assure you that this businss is risk fee as we will perfect all arrangement for the smorth release of the fund . you will be adequalelyrewarded at the successful and of thetransation . If you are interested in this proposal , kindly contact meon this email.r234 at mail.com.comso that i will forward to you detail and modalities on how to condude the transation including the name fo you will bear as the next of kin .Thank you in intcipation of you favourably reply. Regards, john cisse From Roumen.Petrov at skalasoft.com Fri Nov 22 03:06:24 2002 From: Roumen.Petrov at skalasoft.com (Roumen.Petrov at skalasoft.com) Date: Thu, 21 Nov 2002 18:06:24 +0200 Subject: [marco.ortisi@flashcom.it: Re: bug on openssh 3.5p1] Message-ID: <200211211806.24059.Roumen.Petrov@skalasoft.com> When sshd is not running as root on linux with pam we recieve error like this fatal: monitor_read: unsupported request: 24 From Roumen.Petrov at skalasoft.com Fri Nov 22 04:18:32 2002 From: Roumen.Petrov at skalasoft.com (Roumen.Petrov at skalasoft.com) Date: Thu, 21 Nov 2002 19:18:32 +0200 Subject: x509v3 certificates in OpenSSH Message-ID: <200211211918.32418.Roumen.Petrov@skalasoft.com> New version "x509e" is out on http://satva.skalasoft.com/~rumen/openssh/ . Now OpenSSH (client and server) can use x509 certificates for hostkeys too. Try it and give to forum (prefered) feedbacks, comments, suggestions, etc. From sluggo at unknown.nu Fri Nov 22 04:18:51 2002 From: sluggo at unknown.nu (Kim Scarborough) Date: Thu, 21 Nov 2002 11:18:51 -0600 Subject: Building without perl Message-ID: <3DDD157B.7050705@unknown.nu> I can't seem to compile 3.5p1 on a Solaris 9 box with gcc and GNU make. The box does not have perl installed on it. When I run configure, it correctly detects the absence of perl on the system, but make dies immediately trying to run "fixpaths", which is a perl script. PERL is set to nothing in the Makefile. Is perl required? The docs don't say it is... if not, how do I get around this? -- ---------------------------------------------------------------------------- Kim Scarborough http://www.unknown.nu/kim/ ---------------------------------------------------------------------------- "Every day I beat my own previous record for the number of consecutive days I've stayed alive." - George Carlin ---------------------------------------------------------------------------- From v_t_m at seznam.cz Fri Nov 22 04:40:15 2002 From: v_t_m at seznam.cz (=?iso-8859-2?Q?V=E1clav=20Tomec?=) Date: Thu, 21 Nov 2002 18:40:15 +0100 (CET) Subject: =?iso-8859-2?Q?SecurID=20authentication?= Message-ID: <6443.13771-25798-725290294-1037900415@seznam.cz> Hello, on this page (http://sweb.cz/v_t_m/)you can find SecurID authentication for OpenSSH-3.5p1. Vaclav ______________________________________________________________________ Reklama: http://audioexpert.cz / http://videoexpert.cz / http://fotoexpert.cz ...experti nejenom prodavaji :-) From bugzilla-daemon at mindrot.org Fri Nov 22 09:48:42 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Nov 2002 09:48:42 +1100 (EST) Subject: [Bug 441] should ssh BindAddress apply to LocalForward ports Message-ID: <20021121224842.280493D149@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=441 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From markus at openbsd.org 2002-11-22 09:48 ------- duplicate *** This bug has been marked as a duplicate of 413 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 22 09:48:51 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Nov 2002 09:48:51 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20021121224851.DE75E3D149@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sjc at makalumedia.com ------- Additional Comments From markus at openbsd.org 2002-11-22 09:48 ------- *** Bug 441 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Fri Nov 22 10:26:59 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Fri, 22 Nov 2002 10:26:59 +1100 (EST) Subject: [Bug 440] Protocol 1 server key generated at start up even when P1 not used Message-ID: <20021121232659.D458A3D156@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=440 ------- Additional Comments From bruno at wolff.to 2002-11-22 10:26 ------- I have tested this on 3.1p1 and was able to apply the diff to 3.5p1 without an error but wasn't able to test it yet. Just for clarification I am starting an instance of sshd for each connection. (Using inetd on one set of systems and tcpserver on another.) So that the extra key generation is once per connection, not server startup. It isn't that big of a slowdown, but it is an unnecessary one. I have a copy of the diffs I used to fix the problem at: http://wolff.to/bruno/sshd.c.diff This should illustrate what I am complaining about. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From spaceacademy at hotmail.com Sat Nov 23 04:11:31 2002 From: spaceacademy at hotmail.com (s c o t t) Date: Fri, 22 Nov 2002 09:11:31 -0800 Subject: forwarding to a wider audience - KbdInteractiveDevices??? Message-ID: Could someone provide a description of the config setting KbdInteractiveDevices And how it would be used. There is no mention of this here: http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current And a quick glance of the source doesn't seem to reveal much. Thanks in advance, scott _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From herb at sgi.com Sat Nov 23 05:50:54 2002 From: herb at sgi.com (Herb Lewis) Date: Fri, 22 Nov 2002 10:50:54 -0800 Subject: proposed change to configure Message-ID: <3DDE7C8E.94A9CBC0@sgi.com> configure currently checks the paths.h file for the definition of _PATH_STDPATH On IRIX the define is named _PATH_USERPATH The following patch to configure allows the correct value to be obtained --- configure.orig Wed Jun 26 07:08:18 2002 +++ configure Fri Nov 22 10:38:57 2002 @@ -15705,8 +15713,12 @@ #ifdef HAVE_PATHS_H # include #endif +#ifdef _PATH_USERPATH +# define _PATH_STDPATH _PATH_USERPATH +#else #ifndef _PATH_STDPATH # define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" +#endif #endif #include #include -- ====================================================================== Herb Lewis Silicon Graphics Networking Engineer 1600 Amphitheatre Pkwy MS-510 Strategic Software Organization Mountain View, CA 94043-1351 herb at sgi.com Tel: 650-933-2177 http://www.sgi.com Fax: 650-932-2177 PGP Key: 0x8408D65D ====================================================================== From tim at multitalents.net Sat Nov 23 08:08:55 2002 From: tim at multitalents.net (Tim Rice) Date: Fri, 22 Nov 2002 13:08:55 -0800 (PST) Subject: proposed change to configure In-Reply-To: <3DDE7C8E.94A9CBC0@sgi.com> Message-ID: On Fri, 22 Nov 2002, Herb Lewis wrote: > configure currently checks the paths.h file for the definition of > _PATH_STDPATH > > On IRIX the define is named _PATH_USERPATH Finally someone on IRIX has verified this will work. I've been holding onto a similar patch since July. I'll commit it now. BTW. changes go in configure.ac as configure is a generated file. > > The following patch to configure allows the correct value to be obtained > > --- configure.orig Wed Jun 26 07:08:18 2002 > +++ configure Fri Nov 22 10:38:57 2002 > @@ -15705,8 +15713,12 @@ > #ifdef HAVE_PATHS_H > # include > #endif > +#ifdef _PATH_USERPATH > +# define _PATH_STDPATH _PATH_USERPATH > +#else > #ifndef _PATH_STDPATH > # define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" > +#endif > #endif > #include > #include > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From lv8pv at lv8pv.com Sat Nov 23 09:03:43 2002 From: lv8pv at lv8pv.com (=?iso-8859-1?Q?B=F8rge?= Amundsen) Date: Fri, 22 Nov 2002 23:03:43 +0100 Subject: (no subject) Message-ID: <20021122220342.GF1540@smokebuff.lv8pv.com> From bugzilla-daemon at mindrot.org Sat Nov 23 11:24:50 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 23 Nov 2002 11:24:50 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20021123002450.A11173D162@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 ------- Additional Comments From dtucker at zip.com.au 2002-11-23 11:24 ------- Created an attachment (id=179) --> (http://bugzilla.mindrot.org/attachment.cgi?id=179&action=view) Original patch by Dan Astoorian ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sat Nov 23 11:31:34 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 23 Nov 2002 11:31:34 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20021123003134.CCA653D16A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2002-11-23 11:31 ------- Created an attachment (id=180) --> (http://bugzilla.mindrot.org/attachment.cgi?id=180&action=view) Ported Dan's patch to current tree Ported to current. Moved option parsing code into parse_forward(). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 24 14:23:29 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 24 Nov 2002 14:23:29 +1100 (EST) Subject: [Bug 442] New: sshd allows login via public-key when account locked Message-ID: <20021124032329.63FBC3D138@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 Summary: sshd allows login via public-key when account locked Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: security Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dtucker at zip.com.au Observed on Redhat and Solaris. When openssh is configured without PAM, an account that is locked (via passwd -l) can still be logged into via public-key authentication. Although the password field is modified (to "*LK*" on Solaris or with a leading "!" on Redhat), allowed_user() does not test for those so if password authentication isn't used, the login still succeeds. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 24 14:25:20 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 24 Nov 2002 14:25:20 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20021124032520.898763D16B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 ------- Additional Comments From dtucker at zip.com.au 2002-11-24 14:25 ------- Created an attachment (id=181) --> (http://bugzilla.mindrot.org/attachment.cgi?id=181&action=view) Test for locked account in allowed_user() Tested on Redhat 8 and Solaris 8. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 24 17:13:15 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 24 Nov 2002 17:13:15 +1100 (EST) Subject: [Bug 413] Port forwarding: [localhost:]localport:remotehost:remoteport Message-ID: <20021124061315.195183D16A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=413 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #180 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2002-11-24 17:13 ------- Created an attachment (id=182) --> (http://bugzilla.mindrot.org/attachment.cgi?id=182&action=view) Implement optional address binding for port forwards Re-added test for number of arguments to parse_forward. Updated man page for ssh's -D option missed earlier. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Sun Nov 24 17:53:30 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 24 Nov 2002 17:53:30 +1100 (EST) Subject: [Bug 442] sshd allows login via public-key when account locked Message-ID: <20021124065330.72CA23D174@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=442 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #181 is|0 |1 obsolete| | ------- Additional Comments From dtucker at zip.com.au 2002-11-24 17:53 ------- Created an attachment (id=183) --> (http://bugzilla.mindrot.org/attachment.cgi?id=183&action=view) Make check for locked pw not depend on HAS_SHADOW_EXPIRE ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From flavien at lebarbe.net Mon Nov 25 06:12:23 2002 From: flavien at lebarbe.net (Flavien Lebarbe) Date: Sun, 24 Nov 2002 20:12:23 +0100 Subject: [PATCH] PamServiceNameAppend Message-ID: <20021124191223.GA19025@diplo.flavsfarm> Hello, Here's the situation I'm facing : I'm running OpenSSH on a server. On a gateway, I forward TCP:22 to the server TCP:22. So far, so good. I can log in from inside the lan by connecting using standard SSH port, or from the other network through the gateway. Now, I'd like a different configuration for connections from the outside. I start another SSHd on the server with another config file, listening on another port, and instead of forwarding incoming connections on the gateway to TCP:22, I forward them to TCP:theotherport and it's fine. Now, one step further : I use pam on the server, and would like to use /etc/pam.d/ssh_remote as the pam config-file for the second instance of sshd and continue to use /etc/pam.d/ssh for the first one. It comes down to change the "service_name" parameter of pam_start() for the second daemon. I had a look in the source and SSHD_PAM_SERVICE is a constant. I could of course recompile with -DSSHD_PAM_SERVICE= "ssh_remote" but I would have to have two sets of binaries : One sshd and another sshd_remote. Not really easy. :-( Attached is a patch that allows me to do this in the config file by appending a string to SSHD_PAM_SERVICE at runtime (yes, I'd have liked to do it at fill_default_server_options time). It just adds another option : PamServiceNameAppend. This is my first attempt at patching ssh (hacked it this afternoon, only basic and very primitive testing), so it sure needs hints from "the guys who know it better". :o) Feedback welcome ! Flavien. -------------- next part -------------- Index: auth-pam.c =================================================================== RCS file: /cvs/openssh/auth-pam.c,v retrieving revision 1.54 diff -u -w -u -w -b -p -r1.54 auth-pam.c --- auth-pam.c 28 Jul 2002 20:24:08 -0000 1.54 +++ auth-pam.c 24 Nov 2002 18:43:41 -0000 @@ -378,10 +378,13 @@ void start_pam(const char *user) extern ServerOptions options; extern u_int utmp_len; const char *rhost; + char buf[1024]; debug("Starting up PAM with username \"%.200s\"", user); - pam_retval = pam_start(SSHD_PAM_SERVICE, user, &conv, &__pamh); + strlcpy(buf, SSHD_PAM_SERVICE, sizeof(buf)); + strlcat(buf, options.pam_service_name_append, sizeof(buf)); + pam_retval = pam_start(buf, user, &conv, &__pamh); if (pam_retval != PAM_SUCCESS) fatal("PAM initialisation failed[%d]: %.200s", Index: servconf.c =================================================================== RCS file: /cvs/openssh/servconf.c,v retrieving revision 1.97 diff -u -w -u -w -b -p -r1.97 servconf.c --- servconf.c 5 Sep 2002 04:35:15 -0000 1.97 +++ servconf.c 24 Nov 2002 18:43:41 -0000 @@ -57,6 +57,9 @@ initialize_server_options(ServerOptions /* Portable-specific options */ options->pam_authentication_via_kbd_int = -1; +#ifdef USE_PAM + options->pam_service_name_append = NULL; +#endif /* Standard Options */ options->num_ports = 0; @@ -134,6 +137,10 @@ fill_default_server_options(ServerOption /* Portable-specific options */ if (options->pam_authentication_via_kbd_int == -1) options->pam_authentication_via_kbd_int = 0; +#ifdef USE_PAM + if (options->pam_service_name_append == NULL) + options->pam_service_name_append = ""; +#endif /* Standard Options */ if (options->protocol == SSH_PROTO_UNKNOWN) @@ -275,7 +282,7 @@ fill_default_server_options(ServerOption typedef enum { sBadOption, /* == unknown option */ /* Portable-specific options */ - sPAMAuthenticationViaKbdInt, + sPAMAuthenticationViaKbdInt, sPAMServiceNameAppend, /* Standard Options */ sPort, sHostKeyFile, sServerKeyBits, sLoginGraceTime, sKeyRegenerationTime, sPermitRootLogin, sLogFacility, sLogLevel, @@ -312,6 +319,7 @@ static struct { } keywords[] = { /* Portable-specific options */ { "PAMAuthenticationViaKbdInt", sPAMAuthenticationViaKbdInt }, + { "PAMServiceNameAppend", sPAMServiceNameAppend }, /* Standard Options */ { "port", sPort }, { "hostkey", sHostKeyFile }, @@ -461,6 +469,15 @@ process_server_config_line(ServerOptions case sPAMAuthenticationViaKbdInt: intptr = &options->pam_authentication_via_kbd_int; goto parse_flag; +#ifdef USE_PAM + case sPAMServiceNameAppend: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing argument.", filename, linenum); + if (options->pam_service_name_append == NULL) + options->pam_service_name_append = xstrdup(arg); + break; +#endif /* Standard Options */ case sBadOption: Index: servconf.h =================================================================== RCS file: /cvs/openssh/servconf.h,v retrieving revision 1.50 diff -u -w -u -w -b -p -r1.50 servconf.h --- servconf.h 1 Aug 2002 01:28:39 -0000 1.50 +++ servconf.h 24 Nov 2002 18:43:42 -0000 @@ -132,6 +132,7 @@ typedef struct { char *authorized_keys_file; /* File containing public keys */ char *authorized_keys_file2; int pam_authentication_via_kbd_int; + char *pam_service_name_append; } ServerOptions; void initialize_server_options(ServerOptions *); From stevesk at pobox.com Mon Nov 25 07:54:57 2002 From: stevesk at pobox.com (Kevin Steves) Date: Sun, 24 Nov 2002 12:54:57 -0800 Subject: [PATCH] PamServiceNameAppend In-Reply-To: <20021124191223.GA19025@diplo.flavsfarm> References: <20021124191223.GA19025@diplo.flavsfarm> Message-ID: <20021124205457.GC1356@jenny.crlsca.adelphia.net> On Sun, Nov 24, 2002 at 08:12:23PM +0100, Flavien Lebarbe wrote: > Now, one step further : I use pam on the server, and would like to use > /etc/pam.d/ssh_remote as the pam config-file for the second instance of > sshd and continue to use /etc/pam.d/ssh for the first one. > > It comes down to change the "service_name" parameter of pam_start() for > the second daemon. I had a look in the source and SSHD_PAM_SERVICE is a > constant. I could of course recompile with -DSSHD_PAM_SERVICE= > "ssh_remote" but I would have to have two sets of binaries : One sshd > and another sshd_remote. Not really easy. :-( no need to recompile, SSHD_PAM_SERVICE is set to basename argv[0]. yes, you need to link sshd to the other service name. why is this not easy? From bugzilla-daemon at mindrot.org Mon Nov 25 13:48:04 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 25 Nov 2002 13:48:04 +1100 (EST) Subject: [Bug 443] New: Ability to set KeepAlive time Message-ID: <20021125024804.A38DE3D14B@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=443 Summary: Ability to set KeepAlive time Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: danfuzz at milk.com I currently have to deal with a (arguably broken) firewall which likes to drop connections that have been idle for more than a couple minutes. Unfortunately, while ssh gives me the option of using keepalives, it doesn't give me a way to set the keepalive time, and, since the default is 3 hours, it doesn't do me much good. What I'd love to see is either a KeepAliveTime option indicating a number of seconds between keepalives if KeepAlive is "on", or make KeepAlive itself take a number of seconds as an option. Thanks! -dan danfuzz at milk.com ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Nov 25 14:38:03 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 25 Nov 2002 14:38:03 +1100 (EST) Subject: [Bug 443] Ability to set KeepAlive time Message-ID: <20021125033803.5C48E3D14C@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=443 ------- Additional Comments From dtucker at zip.com.au 2002-11-25 14:37 ------- The "KeepAlive" option enables TCP_KEEPALIVE on the socket which uses a system-wide setting (normally 2 hours according to Stevens.) There is a "Heartbeat" patch for openssh which does what you want, see http://www.sc.isc.tohoku.ac.jp/~hgot/sources/openssh-watchdog.html ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Mon Nov 25 14:54:45 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 25 Nov 2002 14:54:45 +1100 (EST) Subject: [Bug 443] Ability to set KeepAlive time Message-ID: <20021125035445.503AD3D176@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=443 ------- Additional Comments From danfuzz at milk.com 2002-11-25 14:54 ------- Thanks for the reference to the heartbeat patch; I'll probably be installing it shortly. However, I should note that at least on some systems (on mine at least), there *is* a TCP option to change the keepalive time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From maf at appgate.com Mon Nov 25 18:34:10 2002 From: maf at appgate.com (maf at appgate.com) Date: Mon, 25 Nov 2002 08:34:10 +0100 (CET) Subject: forwarding to a wider audience - KbdInteractiveDevices??? Message-ID: <20021125073424.2B929317CE@pelee.firedoor.se> On 22 Nov, s c o t t wrote: > Could someone provide a description of the config setting > KbdInteractiveDevices > > And how it would be used. You probably do not need to set it at all. See http://ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-04.txt for details. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From jean-louis.ly at eads-telecom.com Tue Nov 26 02:40:56 2002 From: jean-louis.ly at eads-telecom.com (Jean-Louis LY) Date: Mon, 25 Nov 2002 16:40:56 +0100 Subject: weird behaviour of commands option : bug or not ? Message-ID: <200211251545.QAA10355@trantor.eads-dsn.com> Hello I think I've found a bug but since no one replied to me on comp.security.ssh, I'll try my luck here. On my client, PreferredAuthentications is set to publickey,password. When using the commands option in authorized_keys file like command="ls" ssh-dss ... it is supposed to connect using the private key associated with , perform ls and then quits. Until here everything is fine. Then I tried to delete the private key file associated to on my client. Then if I connect, it asks for my password and once I'm logged in, it performs ls and quits again. So why does it still read the authorized_keys file since I deleted the key ? I looked into it a bit further and I found that the public key file on my client is the one messing up. If I rename it (by default, it is id_dsa.pub) then everything works fine (password authentication and then I'm logged in with a shell). It seems somehow that the public key file is read no matter what and compares it to the keys found in authorized_keys. So bug or not ? Thanks for your answers. ########################################### This message has been scanned by Anti-Virus for Microsoft Exchange. From jean-louis.ly at eads-telecom.com Tue Nov 26 03:40:46 2002 From: jean-louis.ly at eads-telecom.com (Jean-Louis LY) Date: Mon, 25 Nov 2002 17:40:46 +0100 Subject: sorry for my last post Message-ID: <200211251645.RAA19197@trantor.eads-dsn.com> I completely screwed up I'm really sorry. Hoping that now it would be fine, here is my original message. --- Hello I think I've found a bug but since no one replied to me on comp.security.ssh, I'll try my luck here. On my client, PreferredAuthentications is set to publickey,password. When using the commands option in authorized_keys file like command="ls" ssh-dss ... it is supposed to connect using the private key associated with , perform ls and then quits. Until here everything is fine. Then I tried to delete the private key file associated to on my client. Then if I connect, it asks for my password and once I'm logged in, it performs ls and quits again. So why does it still read the authorized_keys file since I deleted the key ? I looked into it a bit further and I found that the public key file on my client is the one messing up. If I rename it (by default, it is id_dsa.pub) then everything works fine (password authentication and then I'm logged in with a shell). It seems somehow that the public key file is read no matter what and compares it to the keys found in authorized_keys. So bug or not ? Thanks for your answers. ########################################### This message has been scanned by Anti-Virus for Microsoft Exchange. From mouring at etoh.eviladmin.org Tue Nov 26 03:43:24 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 25 Nov 2002 10:43:24 -0600 (CST) Subject: weird behaviour of commands option : bug or not ? In-Reply-To: <200211251545.QAA10355@trantor.eads-dsn.com> Message-ID: I can't mimic this. You have id_dsa.pub which is your public key and you have id_dsa which is your private key. if I do: keygen -t dsa echo -n "command=\"ls\""; cat id_dsa.pub >> authorized_keys ssh localhost works as it should, runs the command="" rm id_dsa ssh localhost prompts for password and then drops me to a login prompt like it should. - Ben On Mon, 25 Nov 2002, Jean-Louis LY wrote: > Hello > > I think I've found a bug but since no one replied to me on comp.security.ssh, > I'll try my luck here. > On my client, PreferredAuthentications is set to publickey,password. > When using the commands option in authorized_keys file like > command="ls" ssh-dss ... it is supposed to connect using the private key > associated with , perform ls and then quits. > Until here everything is fine. > Then I tried to delete the private key file associated to on my client. > Then if I connect, it asks for my password and once I'm logged in, it performs > ls and quits again. > So why does it still read the authorized_keys file since I deleted the key ? > I looked into it a bit further and I found that the public key file on my > client is the one messing up. If I rename it (by default, it is id_dsa.pub) > then everything works fine (password authentication and then I'm logged in > with a shell). It seems somehow that the public key file is read no matter > what and compares it to the keys found in authorized_keys. > So bug or not ? > > Thanks for your answers. > ########################################### > > This message has been scanned by Anti-Virus for Microsoft Exchange. > ??????????????????????????????????????????,?u???)??????&j)b? b??m???? 0?h?v?-????f??f??X??)???)z{,????? > From david.r.steiner at Dartmouth.EDU Tue Nov 26 08:25:24 2002 From: david.r.steiner at Dartmouth.EDU (David Steiner) Date: Mon, 25 Nov 2002 16:25:24 -0500 Subject: AIX 4.3.3/OpenSSH 3.5p1 compile problem Message-ID: My apologies if this is not the appropriate forum for this but I have posted twice to the ssh security list and have not received any replies. I would appreciated any help that anyone can offer. TIA ------- Ok, this is a repost from awhile back to which I received no replies. Originally, I was dealing with 3.4p1 but I am running into the same problem now with 3.5p1. I would greatly appreciate it if someone could point me to what I may be missing. I am having a problem building OpenSSH on my AIX 4.3.3 box. It fails during the make with the following error: xlc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/ssl/lib -L/usr/local/lib -L/usr/local/lib -L/usr/athena/lib -L/usr/afsws/lib -blibpath:/usr/lib:/lib:/usr/local/lib:/usr/athena/lib -lssh -lopenbsd-compat -lkafs -ldes -lkrb -lz -lcrypto -lld -ldes ld: 0711-317 ERROR: Undefined symbol: .issuid ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: 1254-004 The error code from the last command is 8 Building against the following: zlib 1.1.4 openssl 0.9.6g (compiled with xlc) krb4-1.2 (compiled with xlc) tcpwrappers 7.6 This is the output from configure: OpenSSH has been configured with the following options: User binaries: /usr/ssh/bin System binaries: /usr/ssh/sbin Configuration files: /etc/ssh Askpass program: /usr/ssh/libexec/ssh-askpass Manual pages: /usr/ssh/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/afsws/bin:/usr/ssh/bin:/usr/local/bin Manpage format: man PAM support: no KerberosIV support: yes KerberosV support: no Smartcard support: no AFS support: yes S/KEY support: no TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: yes Translate v4 in v6 hack: no BSD Auth support: no Random number source: ssh-rand-helper ssh-rand-helper collects from: Command hashing (timeout 200) Host: powerpc-ibm-aix4.3.3.0 Compiler: xlc Compiler flags: -g Preprocessor flags: -I/usr/local/ssl/include -I/usr/local/include -I/usr/local/include -I/usr/athena/include -I/usr/afsws/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/lib -L/usr/local/lib -L/usr/athena/lib -L/usr/afsws/lib -blibpath:/usr/lib:/lib:/usr/local/lib:/usr/athena/lib Libraries: -lwrap -lkafs -ldes -lkrb -lz -lcrypto -lld -ldes I did get one warning from configure but not sure if it is related: checking if your system defines WTMPX_FILE... no configure: WARNING: Please check and edit -blibpath in LDFLAGS in Makefile configure: creating ./config.status -bloadmap produced the following error: ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source-File(Object-File) OR Import-File {Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------------------------------- --------------- .issuid [238] ER PR afssys.c(/usr/athena/lib/libkafs.a[afss ys.o]) 000000a0 .text R_RBR [109] <.try_aix> ER: The return code is 8. TIA -David- -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From dtucker at zip.com.au Tue Nov 26 09:23:08 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Nov 2002 09:23:08 +1100 Subject: AIX 4.3.3/OpenSSH 3.5p1 compile problem References: Message-ID: <3DE2A2CC.2A9911D1@zip.com.au> David Steiner wrote: > My apologies if this is not the appropriate forum for this but I have > posted twice to the ssh security list and have not received any > replies. I would appreciated any help that anyone can offer. TIA What options did you give to configure for krb4 and openssh? One guess based on previous kerberos problems: do you have a libdes or librcrypto in /usr/athena/lib from a previous (older) installation of kerberos? > checking if your system defines WTMPX_FILE... no > configure: WARNING: Please check and edit -blibpath in LDFLAGS in Makefile > configure: creating ./config.status That's normal. -- Darren Tucker (dtucker at zip.com.au) GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Elisabeth.Porteneuve at cetp.ipsl.fr Tue Nov 26 22:19:45 2002 From: Elisabeth.Porteneuve at cetp.ipsl.fr (Elisabeth Porteneuve) Date: Tue, 26 Nov 2002 12:19:45 +0100 (MET) Subject: Solaris 8, Can't find recent OpenSSL libcrypto Message-ID: <200211261119.MAA24458@balsa.cetp.ipsl.fr> I have probably trivial problem in OpenSSH installation, but do not see it - could you help, please ? The libcrypto has been installed. caroubier% ls -l /usr/local/ssl/lib/libcrypto.a -rw-r--r-- 1 root other 2778744 Nov 19 17:53 /usr/local/ssl/lib/libcrypto.a But the openssh stops with Can't find recent OpenSSL libcrypto. Thank you very much in advance, Elisabeth Porteneuve -- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.53. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## uname -m = sun4u uname -r = 5.8 uname -s = SunOS uname -v = Generic_108528-07 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = caroubier Release = 5.8 KernelID = Generic_108528-07 Machine = sun4u BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 2 /bin/arch = sun4 /usr/bin/arch -k = sun4u /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown [snip] -- configure:8530: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** -- From godot at ulyssis.org Tue Nov 26 22:27:42 2002 From: godot at ulyssis.org (Danny De Cock) Date: Tue, 26 Nov 2002 12:27:42 +0100 (CET) Subject: Solaris 8, Can't find recent OpenSSL libcrypto In-Reply-To: <200211261119.MAA24458@balsa.cetp.ipsl.fr> Message-ID: try with ./configure --with-ssl-dir=/usr/local/ssl cu, danny. On Tue, 26 Nov 2002, Elisabeth Porteneuve wrote: > > > I have probably trivial problem in OpenSSH installation, > but do not see it - could you help, please ? > The libcrypto has been installed. > > caroubier% ls -l /usr/local/ssl/lib/libcrypto.a > -rw-r--r-- 1 root other 2778744 Nov 19 17:53 /usr/local/ssl/lib/libcrypto.a > > But the openssh stops with Can't find recent OpenSSL libcrypto. > > > Thank you very much in advance, > Elisabeth Porteneuve > -- > > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by configure, which was > generated by GNU Autoconf 2.53. Invocation command line was > > $ ./configure > > ## --------- ## > ## Platform. ## > ## --------- ## > > uname -m = sun4u > uname -r = 5.8 > uname -s = SunOS > uname -v = Generic_108528-07 > > /usr/bin/uname -p = sparc > /bin/uname -X = System = SunOS > Node = caroubier > Release = 5.8 > KernelID = Generic_108528-07 > Machine = sun4u > BusType = > Serial = > Users = > OEM# = 0 > Origin# = 1 > NumCPU = 2 > > /bin/arch = sun4 > /usr/bin/arch -k = sun4u > /usr/convex/getsysinfo = unknown > hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > [snip] > -- > configure:8530: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** From jean-louis.ly at eads-telecom.com Tue Nov 26 22:43:19 2002 From: jean-louis.ly at eads-telecom.com (Jean-Louis LY) Date: Tue, 26 Nov 2002 12:43:19 +0100 Subject: weird behaviour of commands option : bug or not ? Message-ID: <200211261147.MAA02883@trantor.eads-dsn.com> That's weird. It's more or less what I did. I'm running a BSD/OS 4.3 with OpenSSH 3.4p1. Client is also an OpenSSH 3.4p1. If I try like you (connecting to localhost) it leads to the same result. Here is the debug log with id_dsa and id_dsa.pub. [...] debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,password debug3: authmethod_lookup publickey debug3: remaining preferred: password debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try privkey: /usr/home/jl/.ssh/id_rsa debug3: no such identity: /usr/home/jl/.ssh/id_rsa debug1: try pubkey: /usr/home/jl/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Remote: Forced command: ls debug1: Remote: Pty allocation disabled. debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x100b4560 hint 1 debug2: input_userauth_pk_ok: fp [some key] debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: Remote: Forced command: ls debug1: Remote: Pty allocation disabled. debug1: ssh-userauth2 successful: method publickey [executes ls and quits] Here is the same log after having deleted id_dsa. [...] debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,password debug3: authmethod_lookup publickey debug3: remaining preferred: password debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: try privkey: /usr/home/jl/.ssh/id_rsa debug3: no such identity: /usr/home/jl/.ssh/id_rsa debug1: try pubkey: /usr/home/jl/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Remote: Forced command: ls debug1: Remote: Pty allocation disabled. debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x100b4560 hint 1 debug2: input_userauth_pk_ok: fp [same key as above] debug3: sign_and_send_pubkey debug3: no such identity: /usr/home/jl/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: next auth method to try is password jl at marvin's password: [entered password] debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: ssh-userauth2 successful: method password [executes ls and quits] The weird part is when the client is using send_pubkey_test since there is no key file. Since the client received the "remote: forced command" part, then the server executes it but it seems it is done before the authentication is successful. I used a password so I get the remote command to work with password authentication. The same happens when I try to connect to localhost. If I'm mistaken somewhere please tell me. Thanks. > I can't mimic this. > > You have id_dsa.pub which is your public key and you have id_dsa which is > your private key. > > if I do: > > keygen -t dsa > echo -n "command=\"ls\""; cat id_dsa.pub >> authorized_keys > ssh localhost > > works as it should, runs the command="" > > rm id_dsa > ssh localhost > > prompts for password and then drops me to a login prompt like it should. > > - Ben > > On Mon, 25 Nov 2002, Jean-Louis LY wrote: > > > Hello > > > > I think I've found a bug but since no one replied to me on comp.security.ssh, > > I'll try my luck here. > > On my client, PreferredAuthentications is set to publickey,password. > > When using the commands option in authorized_keys file like > > command="ls" ssh-dss ... it is supposed to connect using the private key > > associated with , perform ls and then quits. > > Until here everything is fine. > > Then I tried to delete the private key file associated to on my cl ient. > > Then if I connect, it asks for my password and once I'm logged in, it performs > > ls and quits again. > > So why does it still read the authorized_keys file since I deleted the key ? > > I looked into it a bit further and I found that the public key file on my > > client is the one messing up. If I rename it (by default, it is id_dsa.pub) > > then everything works fine (password authentication and then I'm logged in > > with a shell). It seems somehow that the public key file is read no matter > > what and compares it to the keys found in authorized_keys. > > So bug or not ? > > > > Thanks for your answers. ########################################### This message has been scanned by Anti-Virus for Microsoft Exchange. From dtucker at zip.com.au Tue Nov 26 22:59:34 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Nov 2002 22:59:34 +1100 Subject: Solaris 8, Can't find recent OpenSSL libcrypto References: <200211261119.MAA24458@balsa.cetp.ipsl.fr> Message-ID: <3DE36226.B13FA8AF@zip.com.au> Elisabeth Porteneuve wrote > I have probably trivial problem in OpenSSH installation, > but do not see it - could you help, please ? > The libcrypto has been installed. > > caroubier% ls -l /usr/local/ssl/lib/libcrypto.a > -rw-r--r-- 1 root other 2778744 Nov 19 17:53 /usr/local/ssl/lib/libcrypto.a > > But the openssh stops with Can't find recent OpenSSL libcrypto. [snip] > configure:8530: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** Well, what did the end of config.log say? You'll need to find the last instance of something that looks like the following: int main () { RAND_add (); ; return 0; } configure:8517: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/ssl/include -I/usr/local/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib conftest.c -lz -lsocket -lnsl -lcrypto >&5 [** compile error here **] If this doesn't help you you'll need to supply more details (compiler type and version, openssl version) and possibly a copy of config.log. -- 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 bugzilla-daemon at mindrot.org Tue Nov 26 23:09:32 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 26 Nov 2002 23:09:32 +1100 (EST) Subject: [Bug 444] New: Wrong path to ssh in scp after re-configure Message-ID: <20021126120932.617DE3D176@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=444 Summary: Wrong path to ssh in scp after re-configure Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: Heinrich.Mislik at univie.ac.at Doing the following: ./configure --prefix=/tmp/ssh make install ./configure make install The second make will not compile scp.o and leave /tmp/ssh/bin/ssh as path to ssh in the binary. This will work fine until the testing directory /tmp/ssh is removed. The reason is that scp.o is missing from SSHOBJS in the Makefile: SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o should be: SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o scp.o ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From jean-bernard.santabodia at laposte.fr Wed Nov 27 02:47:51 2002 From: jean-bernard.santabodia at laposte.fr (Jean-Bernard SANTABODIA) Date: Tue, 26 Nov 2002 15:47:51 +0000 Subject: script-shell sftp Message-ID: <3DE397A7.7312DE87@laposte.fr> hello, how use sftp2 in a shell-script ( under unix : OS ) with the passphrase ?? my apologyse for my english thanks for yours reponses -------------- next part -------------- A non-text attachment was scrubbed... Name: jean-bernard.santabodia.vcf Type: text/x-vcard Size: 226 bytes Desc: Carte pour Jean-Bernard SANTABODIA Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20021126/2e7b17c0/attachment.vcf -------------- next part -------------- Post-scriptum La Poste Ce message est confidentiel. Sous r?serve de tout accord conclu par ?crit entre vous et La Poste, son contenu ne repr?sente en aucun cas un engagement de la part de La Poste. Toute publication, utilisation ou diffusion, m?me partielle, doit ?tre autoris?e pr?alablement. Si vous n'?tes pas destinataire de ce message, merci d'en avertir imm?diatement l'exp?diteur. From markus at openbsd.org Wed Nov 27 02:20:41 2002 From: markus at openbsd.org (Markus Friedl) Date: Tue, 26 Nov 2002 16:20:41 +0100 Subject: script-shell sftp In-Reply-To: <3DE397A7.7312DE87@laposte.fr> References: <3DE397A7.7312DE87@laposte.fr> Message-ID: <20021126152041.GA24541@folly> On Tue, Nov 26, 2002 at 03:47:51PM +0000, Jean-Bernard SANTABODIA wrote: > Ce message est confidentiel. Sous r?serve de tout accord conclu par > ?crit entre vous et La Poste, son contenu ne repr?sente en aucun cas un > engagement de la part de La Poste. Toute publication, utilisation ou > diffusion, m?me partielle, doit ?tre autoris?e pr?alablement. Si vous > n'?tes pas destinataire de ce message, merci d'en avertir imm?diatement > l'exp?diteur. am i allowed to reply to this mail on a public mailing list? From bugzilla-daemon at mindrot.org Wed Nov 27 03:09:36 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Nov 2002 03:09:36 +1100 (EST) Subject: [Bug 444] Wrong path to ssh in scp after re-configure Message-ID: <20021126160936.F18D03D182@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=444 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From mouring at eviladmin.org 2002-11-27 03:09 ------- No, that is the wrong way of handling it. The issue goes back to detecting dependancy changes. This will be an issue for ssh-add, sftp, sftp-server, scp, ssh-agent, ssh- keygen, ssh-keysign, ssh-keyscan and ssh-rand-helper. And it is deeper than just 'path has not changed'. it is 'Any changes in config.h are not propgated'. In the past we have stated if you do a 'make clean' before rebuilding. At this point I'm still convinced that is the correct thing to do. Handling dependancies is a nightmare. However, I will take another look at it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From Elisabeth.Porteneuve at cetp.ipsl.fr Wed Nov 27 03:11:46 2002 From: Elisabeth.Porteneuve at cetp.ipsl.fr (Elisabeth Porteneuve) Date: Tue, 26 Nov 2002 17:11:46 +0100 (MET) Subject: Solaris 8, Can't find recent OpenSSL libcrypto Message-ID: <200211261611.RAA04577@balsa.cetp.ipsl.fr> > Well, what did the end of config.log say? You'll need to find the last Darren, Below is the relevant section. Thank you ! Elisabeth Porteneuve -- int main () { RAND_add (); ; return 0; } configure:8511: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/ssl/include -I/usr/local/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib conftest.c -lz -lsocket -lnsl -lcrypto >&5 /usr/local/ssl/lib/libcrypto.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status configure:8514: $? = 1 configure: failed program was: #line 8485 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ #ifdef __cplusplus extern "C" #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char RAND_add (); #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { RAND_add (); ; return 0; } configure:8530: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** From mouring at etoh.eviladmin.org Wed Nov 27 03:35:54 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 26 Nov 2002 10:35:54 -0600 (CST) Subject: Solaris 8, Can't find recent OpenSSL libcrypto In-Reply-To: <200211261611.RAA04577@balsa.cetp.ipsl.fr> Message-ID: [..] configure:8511: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I/usr/local/ssl/include -I/usr/local/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib conftest.c -lz -lsocket -lnsl -lcrypto >&5 /usr/local/ssl/lib/libcrypto.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status [..] That seems to be a major clue. It does not like your libcrypto.a. I suggest you recompile it. - Ben On Tue, 26 Nov 2002, Elisabeth Porteneuve wrote: > > > > > Well, what did the end of config.log say? You'll need to find the last > > Darren, > > Below is the relevant section. Thank you ! > > Elisabeth Porteneuve > -- > > int > main () > { > RAND_add (); > ; > return 0; > } > configure:8511: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized > -I/usr/local/ssl/include -I/usr/local/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib conftest.c -lz -lsocket -lnsl -lcrypto >&5 > /usr/local/ssl/lib/libcrypto.a: could not read symbols: File format not recognized > collect2: ld returned 1 exit status > configure:8514: $? = 1 > configure: failed program was: > #line 8485 "configure" > #include "confdefs.h" > > /* Override any gcc2 internal prototype to avoid an error. */ > #ifdef __cplusplus > extern "C" > #endif > /* We use char because int might match the return type of a gcc2 > builtin and then its argument prototype would still apply. */ > char RAND_add (); > #ifdef F77_DUMMY_MAIN > # ifdef __cplusplus > extern "C" > # endif > int F77_DUMMY_MAIN() { return 1; } > #endif > int > main () > { > RAND_add (); > ; > return 0; > } > configure:8530: error: *** Can't find recent OpenSSL libcrypto (see config.log for details) *** > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From tim at multitalents.net Wed Nov 27 03:53:27 2002 From: tim at multitalents.net (Tim Rice) Date: Tue, 26 Nov 2002 08:53:27 -0800 (PST) Subject: Solaris 8, Can't find recent OpenSSL libcrypto In-Reply-To: <200211261611.RAA04577@balsa.cetp.ipsl.fr> Message-ID: On Tue, 26 Nov 2002, Elisabeth Porteneuve wrote: > > > Well, what did the end of config.log say? You'll need to find the last > > Darren, > > Below is the relevant section. Thank you ! > > Elisabeth Porteneuve > -- > > int > main () > { > RAND_add (); > ; > return 0; > } > configure:8511: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wno-uninitialized > -I/usr/local/ssl/include -I/usr/local/include -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib conftest.c -lz -lsocket -lnsl -lcrypto >&5 > /usr/local/ssl/lib/libcrypto.a: could not read symbols: File format not recognized > collect2: ld returned 1 exit status If ld can not read the symbols in libcrypto.a, something is wrong with your OpenSSL build. Did you build OpenSSL from source? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bugzilla-daemon at mindrot.org Wed Nov 27 06:41:56 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Nov 2002 06:41:56 +1100 (EST) Subject: [Bug 445] New: User DCE Credentials do not get forwarded to child session Message-ID: <20021126194156.750653D152@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=445 Summary: User DCE Credentials do not get forwarded to child session Product: Portable OpenSSH Version: 3.4p1 Platform: Alpha OS/Version: OSF/1 Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: kmy at ornl.gov Under OSF/1, DCE credentials are created in the SIA layer for the parent when the user log's in with a password. These credentials do not get forwarded to the child session. This can be done via passing an environmental variable from parent to child in session.c. The following fix accomplishes this functionality and is basically a NO-OP in the event that the required environmental variable is not present: [kmy at gazelle:/dfs/sys/packages/ssh/openssh-3.4p1/alpha_tru64_v510] diff session.c.orig session.c 940c940 < char **env; --- > char **env, *dcecreds; 954a955,958 > > /* Propagate DCE credentials to child .. kmy at ornl.gov */ > if( (dcecreds=getenv("KRB5CCNAME")) ) > child_set_env( &env, &envsize, "KRB5CCNAME", dcecreds ); [kmy at gazelle:/dfs/sys/packages/ssh/openssh-3.4p1/alpha_tru64_v510] With this fix installed, users may use native DFS without the complexity of having to perform a dce_login in addition to their normal login, because the child now has access to the file containing the credentials of the parent and accepts them as their credentials. are sent to the ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Nov 27 06:49:13 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Nov 2002 06:49:13 +1100 (EST) Subject: [Bug 446] New: $LOGIN not set by openssh under AIX Message-ID: <20021126194913.9CE703D185@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=446 Summary: $LOGIN not set by openssh under AIX Product: Portable OpenSSH Version: -current Platform: All OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: mii at ornl.gov I'd like to submit a request to get the following patch incorporated into openssh. AIX generates an environment variable called $LOGIN when using telnet/rsh. This appears to be generated by /bin/login. However, turning on UseLogin disables X11Forwarding, so that doesn't help us much. Some scripts (most notably netscape at the present) reference $LOGIN, so if users ssh into our machines, the script will blow up. This seems like a reasonable thing to do since the AIX native remote login facilities set this variable. The AIXtoolbox group which maintains the AIX version of openssh for IBM is incorporating this patch into their version. What are the chances of getting this incorporated into the openssh distribution? *** session.c.3.5p1 Wed Sep 25 20:38:50 2002 --- session.c Mon Nov 25 12:28:41 2002 *************** *** 969,974 **** --- 969,977 ---- /* Set basic environment. */ child_set_env(&env, &envsize, "USER", pw->pw_name); child_set_env(&env, &envsize, "LOGNAME", pw->pw_name); + #ifdef _AIX + child_set_env(&env, &envsize, "LOGIN", pw->pw_name); + #endif child_set_env(&env, &envsize, "HOME", pw->pw_dir); #ifdef HAVE_LOGIN_CAP if (setusercontext(lc, pw, pw->pw_uid, LOGIN_SETPATH) < 0) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Nov 27 09:51:25 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 27 Nov 2002 09:51:25 +1100 (EST) Subject: [Bug 447] New: Invalid parsing for user@hostname in scp.c and ssh.c Message-ID: <20021126225125.4F3F23D176@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=447 Summary: Invalid parsing for user at hostname in scp.c and ssh.c Product: Portable OpenSSH Version: 3.5p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: stephane_bailliez at hotmail.com I just changed my hosting provider that gives user at domain as ssh login to the domain.. so a scp command line gives: scp file.tocopy user at domain@domain: It fails to connect. I checked the source code and it uses strchr rather than strrchr to get the hostname and user.. thus it will end up with user 'user' and domain 'domain at domain'...which is unlikely to succeed. This bug exists at least in scp.c and ssh.c Workaround for ssh is to use ssh -l user at domain domain and for scp is to use another client. I use pscp on windows. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From hstoh at yahoo.com Wed Nov 27 22:04:39 2002 From: hstoh at yahoo.com (=?iso-8859-1?q?Hwee-Siong=20Toh?=) Date: Wed, 27 Nov 2002 19:04:39 +0800 (CST) Subject: OpenSSH 3.5p1 Chroot and Password Expiry Patch Message-ID: <20021127110439.96854.qmail@web11108.mail.yahoo.com> I have consolidated the OpenSSH patches for version 3.5p1 to incorporate the following : 1. Include Chroot ability 2. Fix the "change password upon expiry" problems for AIX and Solaris You can get the patches from http://wave.prohosting.com/~hstoh/ Regards, Hwee Siong. ******************************* ** Please support OpenSource ** ******************************* __________________________________________________ Do You Yahoo!? Play for a chance to win a trip to Sydney! http://sg.mobile.yahoo.com From j.schroeder at rockwelldatacorp.com Wed Nov 27 22:47:28 2002 From: j.schroeder at rockwelldatacorp.com (J Schroeder) Date: Wed, 27 Nov 2002 12:47:28 +0100 Subject: Urgent Unix Support Requirement for Frankfurt Message-ID: <20021127114814.6414A3D171@shitei.mindrot.org> Hi. If any of you guys are looking (or know of anyone looking) for a new position in Frankfurt, I have a colleague looking for several Unix Support people there. Please drop me a mail if interested and I will forward details The rquirement involves: Knowledge of UNIX, SQL or programming languages, Standard Microsoft software, Native German speaker (also good knowledge of English) Best regards, J. Schroeder From david.r.steiner at Dartmouth.EDU Thu Nov 28 03:30:52 2002 From: david.r.steiner at Dartmouth.EDU (David Steiner) Date: Wed, 27 Nov 2002 11:30:52 -0500 Subject: AIX 4.3.3/OpenSSH 3.5p1 compile problem In-Reply-To: <3DE2A2CC.2A9911D1@zip.com.au> References: <3DE2A2CC.2A9911D1@zip.com.au> Message-ID: At 9:23 +1100 11/26/02, Darren Tucker wrote: >David Steiner wrote: >> My apologies if this is not the appropriate forum for this but I have >> posted twice to the ssh security list and have not received any >> replies. I would appreciated any help that anyone can offer. TIA > >What options did you give to configure for krb4 and openssh? krb4: No special options except compiler: env CC=xlc ./configure make make install openssh: CC=xlc ./configure --prefix=/usr/ssh --with-afs=/usr/afsws --with-kerberos4=/usr/athena --with-tcp-wrappers=/usr/local --sysconfdir=/etc/ssh --with-pid-dir=/var/run --with-ipv4-default --with-default-path=/usr/bin:/bin:/usr/sbin:/sbin:/usr/afsws/bin:/usr/ssh/bin:/usr/local/bin >One guess based on previous kerberos problems: do you have a libdes or >librcrypto in /usr/athena/lib from a previous (older) installation of >kerberos? This is a newly set up machine. The only version of krb4 on it is the current one built as above. > > checking if your system defines WTMPX_FILE... no >> configure: WARNING: Please check and edit -blibpath in LDFLAGS in Makefile >> configure: creating ./config.status > >That's normal. ok. -David- -- David R. Steiner david.r.steiner at dartmouth.edu UNIX System Manager Phone: 603.646.3127 Dartmouth College Fax: 603.646.1041 From bugzilla-daemon at mindrot.org Thu Nov 28 04:16:24 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Nov 2002 04:16:24 +1100 (EST) Subject: [Bug 448] New: ssh ignores key specified with -i if agent is running Message-ID: <20021127171624.574813D177@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=448 Summary: ssh ignores key specified with -i if agent is running Product: Portable OpenSSH Version: older versions Platform: All OS/Version: Linux Status: NEW Severity: trivial Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dmarti at zgp.org ssh -i special_key host uses the key from ssh-agent, not the one specified with -i. ssh -i special_key host and env -u SSH_AUTH_SOCK ssh -i .ssh/special_key host do different things. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From elessar at numenor.org Thu Nov 28 11:37:37 2002 From: elessar at numenor.org (Kenneth Lareau) Date: Wed, 27 Nov 2002 16:37:37 -0800 Subject: contrib/solaris/buildpkg.sh - use within JumpStart as well? Message-ID: <200211280037.gAS0bbtD008710@minddrive.numenor.org> Hello, I don't know how off the wall this question will be, but first let me say that I've found your buildpkg.sh script very useful in creating an OpenSSH package for use on my Solaris systems. Currently I'm trying to set up a fully automated JumpStart system at my workplace, and I'm realizing that the 'postinstall' script (and possibly some of the other install scripts) won't work cleanly from within a JumpStart install. Do you know if anyone, perhaps yourself, have tried to make this work? I've given it a few tries myself, but with not much success. I'll be fully understanding if the response is, "I have no ****ing clue how to do what you ask", but I thought I should at least try. :) Thank you in advance for any help you can give. Kenneth Lareau elessar at numenor.org From mouring at etoh.eviladmin.org Thu Nov 28 11:49:47 2002 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Wed, 27 Nov 2002 18:49:47 -0600 (CST) Subject: contrib/solaris/buildpkg.sh - use within JumpStart as well? In-Reply-To: <200211280037.gAS0bbtD008710@minddrive.numenor.org> Message-ID: On Wed, 27 Nov 2002, Kenneth Lareau wrote: > Hello, > > I don't know how off the wall this question will be, but first let me > say that I've found your buildpkg.sh script very useful in creating > an OpenSSH package for use on my Solaris systems. Currently I'm trying > to set up a fully automated JumpStart system at my workplace, and I'm > realizing that the 'postinstall' script (and possibly some of the other > install scripts) won't work cleanly from within a JumpStart install. > Do you know if anyone, perhaps yourself, have tried to make this work? > I've given it a few tries myself, but with not much success. > Ermm.. It should.. I've tried to watch what patches have gone in to ensure it works with JumpStart. It was one of three reasons why I rewrote the package software. I'd need to have more information as to WHY it is failing. For all I know I may have missed commiting a patch from someone in the last few months. - Ben From elessar at numenor.org Thu Nov 28 12:12:28 2002 From: elessar at numenor.org (Kenneth Lareau) Date: Wed, 27 Nov 2002 17:12:28 -0800 Subject: contrib/solaris/buildpkg.sh - use within JumpStart as well? In-Reply-To: Message from Ben Lindstrom of "Wed, 27 Nov 2002 18:49:47 CST." Message-ID: <200211280112.gAS1CStC009127@minddrive.numenor.org> Crap. I just started looking at your script in 3.5p1, and there's a lot of changes I didn't know of (I was working off the one from 3.4p1, which didn't have the check/creation of the 'sshd' user). Let me build 3.5p1 (like I should have done several weeks ago *sigh*), and get back to you... Sorry about that. :-/ Ken elessar at numenor.org In message , Ben L indstrom writes: > > >On Wed, 27 Nov 2002, Kenneth Lareau wrote: > >> Hello, >> >> I don't know how off the wall this question will be, but first let me >> say that I've found your buildpkg.sh script very useful in creating >> an OpenSSH package for use on my Solaris systems. Currently I'm trying >> to set up a fully automated JumpStart system at my workplace, and I'm >> realizing that the 'postinstall' script (and possibly some of the other >> install scripts) won't work cleanly from within a JumpStart install. >> Do you know if anyone, perhaps yourself, have tried to make this work? >> I've given it a few tries myself, but with not much success. >> > >Ermm.. It should.. I've tried to watch what patches have gone in to ensure >it works with JumpStart. It was one of three reasons why I rewrote the >package software. > >I'd need to have more information as to WHY it is failing. > >For all I know I may have missed commiting a patch from someone in the >last few months. > >- Ben > From scott.burch at camberwind.com Thu Nov 28 14:29:17 2002 From: scott.burch at camberwind.com (Scott Burch) Date: 27 Nov 2002 21:29:17 -0600 Subject: contrib/solaris/buildpkg.sh - use within JumpStart as well? In-Reply-To: <200211280037.gAS0bbtD008710@minddrive.numenor.org> References: <200211280037.gAS0bbtD008710@minddrive.numenor.org> Message-ID: <1038454157.22381.18.camel@glacierjr> Kenneth, You might also consider using Jumpstart with Webstart Flash, in that case you will already have your package installed. Flashing new server installations is much faster than the traditional Jumpstart and sometimes you just don't have time to build unattended installations for complex packages when you have to deploy large amounts of machines quickly. Where I work I create a base image that contains Veritas Foundation Suite, DiskSuite, Openssh, and anything else that we need on most servers. Patches, any non-standard packages and package removals can be handled with finish (aka driver scripts). A Flash archive is basically a cpio archive and it can be used on any machine of the same architecture. All of our servers are ultra class machines; so if I create an image on an ultra10 it is usable on a 4810, E4500, 280R, etc. The difference in installation time is hours! A machine can be flashed easily in 30 minutes with the base image; if I did a standard Jump it would take several hours (assuming you install everything + OEM). -Scott On Wed, 2002-11-27 at 18:37, Kenneth Lareau wrote: > Hello, > > I don't know how off the wall this question will be, but first let me > say that I've found your buildpkg.sh script very useful in creating > an OpenSSH package for use on my Solaris systems. Currently I'm trying > to set up a fully automated JumpStart system at my workplace, and I'm > realizing that the 'postinstall' script (and possibly some of the other > install scripts) won't work cleanly from within a JumpStart install. > Do you know if anyone, perhaps yourself, have tried to make this work? > I've given it a few tries myself, but with not much success. > > I'll be fully understanding if the response is, "I have no ****ing clue > how to do what you ask", but I thought I should at least try. :) Thank > you in advance for any help you can give.s > > > Kenneth Lareau > elessar at numenor.org > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From bugzilla-daemon at mindrot.org Thu Nov 28 21:38:05 2002 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 28 Nov 2002 21:38:05 +1100 (EST) Subject: [Bug 448] ssh ignores key specified with -i if agent is running Message-ID: <20021128103805.1D2F03D13D@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=448 markus at openbsd.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|trivial |enhancement ------- Additional Comments From markus at openbsd.org 2002-11-28 21:37 ------- having -i automagically turning off the agent might break things. unsetting SSH_AUTH_SOCK works fine. so what should be done? new option for turning off the agent is a bad idea, too. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From setit2003 at voila.fr Thu Nov 28 22:19:24 2002 From: setit2003 at voila.fr (=?ISO-8859-1?Q?comit=E9?= setit) Date: Thu, 28 Nov 2002 12:19:24 +0100 Subject: rappel setit Message-ID: <200211281053.gASArFL19341@localhost.localdomain> Sorry in advance if you have received this email again. Please don't hesitate to forwart it for ones who can be interested. We are pleased to inform you that the deadline for submitting papers to the international conference SETIT is November 30, 2002. This conference is supportde by IEEE France.It will be from 17 to 21 March 2003 in Tunisia. The topics of the conference are about Sciences of electronic, Information technology and telecommunications. you can find more details in: or in your propositions are welcome (they can be made either in french or in english). The conference fees are: Registration fees: 150 euros Accommodation in hotel 5 stars: 50 euros per night (include breakfast, lunch and dinner) Accommodation in hotel 4 stars: 45 euros per night (include breakfast, lunch and dinner) Accommodation in hotel 3 stars: 40 euros per night (include breakfast, lunch and dinner) TUNIS AIR, the Official carrier for the Conference, accord to the participants and their accompaniers A Reduction of 50% to the plane tickets We are waiting for seeing you in Tunisia in SETIT 2003. thanks in advance Organzing comitee --------------------------------------------------------------------------------- --------------------- --------------------------------------------------------------------------------- --------------------- Pardon d'avance pour le multipostage. Mais n'hesitez pas a faire suivre. Nous avons le plaisir de vous rappeler que la date limite de soumission des propositions pour la conference SETIT 2003 est le 30 Novembre 2002. Cette conference se tiendra du 17 au 21 Mars 2003 en tunisie. Elle est supportee par la section IEEE France. Nous vous invitons a visiter notre site ci-dessous pour davantage de renseignements sur le cette conference: ou bien Nous souhaitons votre participation dans cette manifestation scientifique. Les frais de la conference sont : Frais de participation : 150 euros Frais d?hebergement dans un hotel 5 etoiles en Pension Complete : 50 euros par nuit. Frais d?hebergement dans un hotel 4 etoiles en Pension Complete : 45 euros par nuit. Frais d?hebergement dans un hotel 3 etoiles en Pension Complete : 40 euros par nuit. TUNIS AIR, Transporteur Officiel de la Conf?rence, accorde aux participants ainsi qu?a leurs accompagnateurs une r?duction de 50% sur les Billets d'Avion N'hesitez pas a diffuser l'appel aux communications aupres de vos collegues pouvant etre concernes. Dans l'attente de vous voir parmi nous dans SETIT 2003 en tunisie, nous vous prions, d'accepter nos salutations les plus distinguees. Par le Comite d'organisation From dtucker at zip.com.au Thu Nov 28 23:43:40 2002 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 28 Nov 2002 23:43:40 +1100 Subject: contrib/solaris/buildpkg.sh - use within JumpStart as well? References: <200211280112.gAS1CStC009127@minddrive.numenor.org> Message-ID: <3DE60F7C.8975BC3A@zip.com.au> Kenneth Lareau wrote: > I just started looking at your script in 3.5p1, and there's a lot of > changes I didn't know of (I was working off the one from 3.4p1, which > didn't have the check/creation of the 'sshd' user). Let me build > 3.5p1 (like I should have done several weeks ago *sigh*), and get > back to you... There's also a bug in pkgadd that is likely to bite you when installing openssh during a jumpstart: pkgadd: ERROR: freopen(/dev/tty, "a", stdout) failed, errno=6 pkgadd: ERROR: preinstall script did not complete successfully See http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102695739216190 for details and a workaround. FWIW, buildpkg.sh from 3.5p1 + this workaround works fine for me. -- 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 boliset at cse.iitk.ac.in Fri Nov 29 05:31:08 2002 From: boliset at cse.iitk.ac.in (Kapileswar Rao .B) Date: Fri, 29 Nov 2002 00:01:08 +0530 (IST) Subject: Documentation for SSLeay_add_all_algorithms Message-ID: Hello, I am looking into the ssh sources. I couldn't get docs for SSLeay_add_all_algorithms. I tried for this in openssl.org. Can someone give some pointers for documents, which can tell how to use the SSL functions used in the ssh sources and what they do?? thanks kapil From Lutz.Jaenicke at aet.TU-Cottbus.DE Fri Nov 29 06:04:01 2002 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 28 Nov 2002 20:04:01 +0100 Subject: Documentation for SSLeay_add_all_algorithms In-Reply-To: References: Message-ID: <20021128190401.GA8671@serv01.aet.tu-cottbus.de> On Fri, Nov 29, 2002 at 12:01:08AM +0530, Kapileswar Rao .B wrote: > I am looking into the ssh sources. I couldn't get docs for > SSLeay_add_all_algorithms. I tried for this in openssl.org. Can someone > give some pointers for documents, which can tell how to use the SSL > functions used in the ssh sources and what they do?? SSLeay_add_all_algorithms() is a synonym for OpenSSL_add_all_algorithms(), documentation is available for the latter name. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From elessar at numenor.org Fri Nov 29 11:29:38 2002 From: elessar at numenor.org (Kenneth Lareau) Date: Thu, 28 Nov 2002 16:29:38 -0800 Subject: contrib/solaris/buildpkg.sh - use within JumpStart as well? In-Reply-To: <3DE60F7C.8975BC3A@zip.com.au> References: <200211280112.gAS1CStC009127@minddrive.numenor.org> <3DE60F7C.8975BC3A@zip.com.au> Message-ID: <20021128162938.57992ef0.elessar@numenor.org> Thanks, Darren, I actually ran into that when I built my 3.4p1 package, and I seem to recall you were the person who pointed me to the workaround for that the last time... in fact, your URL is the one you sent to me then. :) The fix is already built into my JumpStart finish scripts... Ken On Thu, 28 Nov 2002 23:43:40 +1100 Darren Tucker wrote: > Kenneth Lareau wrote: > > I just started looking at your script in 3.5p1, and there's a lot of > > changes I didn't know of (I was working off the one from 3.4p1, which > > didn't have the check/creation of the 'sshd' user). Let me build > > 3.5p1 (like I should have done several weeks ago *sigh*), and get > > back to you... > > There's also a bug in pkgadd that is likely to bite you when installing > openssh during a jumpstart: > pkgadd: ERROR: freopen(/dev/tty, "a", stdout) failed, errno=6 > pkgadd: ERROR: preinstall script did not complete successfully > > See http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102695739216190 > for details and a workaround. > > FWIW, buildpkg.sh from 3.5p1 + this workaround works fine for me. > > -- > 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 elessar at numenor.org Fri Nov 29 11:34:59 2002 From: elessar at numenor.org (Kenneth Lareau) Date: Thu, 28 Nov 2002 16:34:59 -0800 Subject: contrib/solaris/buildpkg.sh - use within JumpStart as well? In-Reply-To: <1038454157.22381.18.camel@glacierjr> References: <200211280037.gAS0bbtD008710@minddrive.numenor.org> <1038454157.22381.18.camel@glacierjr> Message-ID: <20021128163459.62930e28.elessar@numenor.org> Actually, my JumpStart configuration already handles web flash images, but given the work environment at my job (software com- pany), they need a lot of flexibility to try different config- urations, and having a flash image for every possible one would simply be too much... the point of my whole setup is to allow a developer at my site to interact with a basic script (soon to be a web-based interface), select what they want, then go to the console on the machine they're jumping, type 'boot net - install', and walk away for a few hours... then to come back a fully built system, ready for immediate use. The time it takes isn't really as important, and for the times it is, there will be flash images available; however, I need to cover all bases. :) Thank you for the suggestion, however. Ken Lareau elessar at numenor.org On 27 Nov 2002 21:29:17 -0600 Scott Burch wrote: > Kenneth, > > You might also consider using Jumpstart with Webstart Flash, in that > case you will already have your package installed. Flashing new server > installations is much faster than the traditional Jumpstart and > sometimes you just don't have time to build unattended installations for > complex packages when you have to deploy large amounts of machines > quickly. Where I work I create a base image that contains Veritas > Foundation Suite, DiskSuite, Openssh, and anything else that we need on > most servers. Patches, any non-standard packages and package removals > can be handled with finish (aka driver scripts). A Flash archive is > basically a cpio archive and it can be used on any machine of the same > architecture. All of our servers are ultra class machines; so if I > create an image on an ultra10 it is usable on a 4810, E4500, 280R, etc. > The difference in installation time is hours! A machine can be flashed > easily in 30 minutes with the base image; if I did a standard Jump it > would take several hours (assuming you install everything + OEM). > > -Scott > > On Wed, 2002-11-27 at 18:37, Kenneth Lareau wrote: > > Hello, > > > > I don't know how off the wall this question will be, but first let me > > say that I've found your buildpkg.sh script very useful in creating > > an OpenSSH package for use on my Solaris systems. Currently I'm trying > > to set up a fully automated JumpStart system at my workplace, and I'm > > realizing that the 'postinstall' script (and possibly some of the other > > install scripts) won't work cleanly from within a JumpStart install. > > Do you know if anyone, perhaps yourself, have tried to make this work? > > I've given it a few tries myself, but with not much success. > > > > I'll be fully understanding if the response is, "I have no ****ing clue > > how to do what you ask", but I thought I should at least try. :) Thank > > you in advance for any help you can give.s > > > > > > Kenneth Lareau > > elessar at numenor.org > > _______________________________________________ > > openssh-unix-dev at mindrot.org mailing list > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > >