From ml at t-b-o-h.net Fri Feb 1 00:35:06 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 31 Jan 2008 08:35:06 -0500 (EST) Subject: [openssh] Re: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <20080131061812.GA3620@fermat.math.technion.ac.il> Message-ID: <200801311335.m0VDZ6Za064036@himinbjorg.tucs-beachin-obx-house.com> > > On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"": > > I ran what you said, and the first one ran for about > > 2 minutes and then : > > > > Connection to 10.0.0.6 closed by remote host. > > Connection to 10.0.0.6 closed. > > > > And the 2nd time about 20 seconds before the same. > > If I understood correctly, what you ran just opened a connection, but passed > no data for two minutes. Is it possible that your router simply disconnects > inactive TCP connections after two minutes, in the pretext of saving memory, > guard against DOS attacks, or who knows what? > > You can try setting ServerAliveInterval in your client to something less than > two minutes, and see if it helps. E.g., in your ~/.ssh/config put > > ServerAliveInterval 60 > Hi, I'm sorry if somehow you took away that I didn't do anything for the 2 minutes. Every time I'm testing I am either scurring to get something typed in before it disconnects, or I am running "ls" over and over and having it quit mid my typing or mid the response. Absolutely not a timeout issue. When I was asked to do the last test, it took me 7 logins just to get screen running, start tcpdump writing to a file listening on 2022, and in another window start ssh on 2022. So there was never a second I wasn't typing or there wasn't screen interaction, and it still dumped me 6 times. The only reason I was able to get that long seemed to be using the ProxyCommand. Without it, normal sessions lasted anywhere from 0 (Yes, it would disconnect before I could type the 8 character password I've been using for 29 year and could type in my sleep) to 15 or 20 seconds. I also get knocked off of SSH from the ROUTER ITSELF. So this can't be it. I set up where past the "router" and laptop, I wireless connected to a home router, and then out to the net. With this, if I ssh to a machine outside the site, I can stay connected for DAYS. laptop->router+ddwrt|====air===|router+ddwrt->laptop+NAT===air===router->cablemodem ....................SSH PROBLEMS HERE.SSH PROBLEMS H............................... I'm guessing if RSTs are generated, they aren't able to get to/past the cable modem. Thanks, Tuc From ml at t-b-o-h.net Fri Feb 1 00:44:52 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 31 Jan 2008 08:44:52 -0500 (EST) Subject: [openssh] Re: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <47A1ADD6.9010205@zip.com.au> Message-ID: <200801311344.m0VDiqXl064187@himinbjorg.tucs-beachin-obx-house.com> > > Nadav Har'El wrote: > > On Tue, Jan 29, 2008, Tuc at T-B-O-H.NET wrote about "Re: [openssh] Re: Frequent "Connection reset by peer"": > >> I ran what you said, and the first one ran for about > >> 2 minutes and then : > >> > >> Connection to 10.0.0.6 closed by remote host. > >> Connection to 10.0.0.6 closed. > >> > >> And the 2nd time about 20 seconds before the same. > > > > If I understood correctly, what you ran just opened a connection, but passed > > no data for two minutes. Is it possible that your router simply disconnects > > inactive TCP connections after two minutes, in the pretext of saving memory, > > guard against DOS attacks, or who knows what? > > Good point, and that reminds me: another thing to check for, > particularly if you have links with differing MTUs, is fragmentation > problems: > > http://www.snailbook.com/faq/mtu-mismatch.auto.html > > A dead giveaway for this problem is if you see a non-zero and increasing > number in the SendQ column in the "netstat" output for the SSH > connection (on either server or client end of the connection). > I wouldn't have time to even run a netstat. I went back to my original dump, and verified that no received packet had the fragment bit on. Not even towards the end that it was expecting a fragment but never received it. But would the device have sent a RST if it received a fragment it couldn't route? I'm getting an actual RST from the router on the other end of a WDS link towards the far end laptop. Thanks, Tuc From ml at t-b-o-h.net Fri Feb 1 02:08:07 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 31 Jan 2008 10:08:07 -0500 (EST) Subject: [openssh] Re: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <20080131143611.GM3278@greenie.muc.de> Message-ID: <200801311508.m0VF87Dk065574@himinbjorg.tucs-beachin-obx-house.com> > > Hi, > > On Thu, Jan 31, 2008 at 08:35:06AM -0500, Tuc at T-B-O-H.NET wrote: > > I also get knocked off of SSH from the ROUTER ITSELF. > > I have seen this happen when I had a duplicate IP address on the LAN - > every time the packet happened to hit the "other" box, it caused a RST > (because the other box didn't know anything about it). > > You can see this if you look into the ARP caches of other boxes on the > same network - if the server IP address is alternating between different > MAC addresses, you have a double IP address. > The entire network (prior to adding the outside link, which happened AFTER all the problems started) is 4 pieces of equipment. The arp table shows only all 4 of them. I'm using 10.0.0.0/24. When it was isolated to just those 4 pieces of equipment, and impossible for any other piece of equipment to be a part of the network, the problems existed. Adding the new part has not changed the original way the network acts at all. If there were any arp changes, the machines would be logging it. Tuc From gert at greenie.muc.de Fri Feb 1 01:36:12 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 31 Jan 2008 15:36:12 +0100 Subject: [openssh] Re: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <200801311335.m0VDZ6Za064036@himinbjorg.tucs-beachin-obx-house.com> References: <20080131061812.GA3620@fermat.math.technion.ac.il> <200801311335.m0VDZ6Za064036@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <20080131143611.GM3278@greenie.muc.de> Hi, On Thu, Jan 31, 2008 at 08:35:06AM -0500, Tuc at T-B-O-H.NET wrote: > I also get knocked off of SSH from the ROUTER ITSELF. I have seen this happen when I had a duplicate IP address on the LAN - every time the packet happened to hit the "other" box, it caused a RST (because the other box didn't know anything about it). You can see this if you look into the ARP caches of other boxes on the same network - if the server IP address is alternating between different MAC addresses, you have a double IP address. 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 Jefferson.Ogata at noaa.gov Fri Feb 1 01:34:23 2008 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 31 Jan 2008 14:34:23 +0000 Subject: [openssh] Re: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <200801311344.m0VDiqXl064187@himinbjorg.tucs-beachin-obx-house.com> References: <200801311344.m0VDiqXl064187@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <47A1DC6F.2040403@noaa.gov> On 2008-01-31 13:44, Tuc at T-B-O-H.NET wrote: > But would the device have sent a RST if it received a fragment > it couldn't route? I'm getting an actual RST from the router on the other > end of a WDS link towards the far end laptop. Some versions of Linux wrongly generate an RST in response to a bad TCP checksum. (Wrongly because the bad checksum is telling you you can't trust the TCP header and payload, so why generate an RST using values from the header?) I've had problems in the past with simply bad cabling exercising this bug. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From nicholas.dokos at hp.com Fri Feb 1 05:00:12 2008 From: nicholas.dokos at hp.com (Nick Dokos) Date: Thu, 31 Jan 2008 13:00:12 -0500 Subject: RFC: ssh-copy-id tweaks Message-ID: <30502.1201802412@alphaville.zko.hp.com> I'd like to propose a couple of tweaks to ssh-copy-id: o Change the default ID_FILE from identity.pub to id_dsa.pub or perhaps {id_dsa,id_rsa,identity}.pub to cover all the bases, although the patch below deals only with id_dsa.pub - it would need some more tweaking to deal with more than one (possibly non-existent) file. o If the destination authorized_keys file already contains the keys, they should not be duplicated. I use ssh-copy-id in a regression harness and I end up adding the same key tens or hundreds of times. I have not seen any problem but it is somewhat distasteful. The method proposed is frankly a hack, but it is simple and I think it is foolproof and portable. At least initially, it will mess up the order of the keys, but given that the file is mostly write-only by humans, that should not make any difference. Comments? Thanks, Nick --- ssh-copy-id.orig 2008-01-31 12:01:03.000000000 -0500 +++ ssh-copy-id 2008-01-31 12:05:16.000000000 -0500 @@ -1,11 +1,11 @@ #!/bin/sh -# Shell script to install your identity.pub on a remote machine +# Shell script to install your id_dsa.pub on a remote machine # Takes the remote machine name as an argument. # Obviously, the remote machine must accept password authentication, # or one of the other keys in your ssh-agent, for this to work. -ID_FILE="${HOME}/.ssh/identity.pub" +ID_FILE="${HOME}/.ssh/id_dsa.pub" if [ "-i" = "$1" ]; then shift @@ -38,7 +38,7 @@ exit 1 fi -{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1 +{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys && sort -u -o .ssh/authorized_keys .ssh/authorized_keys" || exit 1 cat < Message-ID: <200801311938.m0VJcmie070740@himinbjorg.tucs-beachin-obx-house.com> > > On 2008-01-31 13:44, Tuc at T-B-O-H.NET wrote: > > But would the device have sent a RST if it received a fragment > > it couldn't route? I'm getting an actual RST from the router on the other > > end of a WDS link towards the far end laptop. > > Some versions of Linux wrongly generate an RST in response to a bad TCP > checksum. (Wrongly because the bad checksum is telling you you can't > trust the TCP header and payload, so why generate an RST using values > from the header?) I've had problems in the past with simply bad cabling > exercising this bug. > But would it generate the RST *FORWARD* or *BACKWARD*? So generally if .1 sends a packet through .2 which is WDS'd to .5 for .6 ... If .1 or .2 forwarded/created a bad packet destined for .6, would .5 deliver the RST to .1/.2 or to .6? My situation is .1 sends, through .2 (Ethernet input, WDS/radio output) to .5 (radio/WDS input, ethernet output) for .6. .5 sends the RST to .6. I've checked the checksums I can capture off .6 for checksum issues, none were marked that way. I'll swap out the far side cable to see if it helps. Thanks, Tuc From jmknoble at pobox.com Fri Feb 1 10:28:37 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 31 Jan 2008 18:28:37 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <30502.1201802412@alphaville.zko.hp.com> References: <30502.1201802412@alphaville.zko.hp.com> Message-ID: <20080131232837.GE4832@crawfish.ais.com> Circa 2008-01-31 13:00 dixit Nick Dokos: : I'd like to propose a couple of tweaks to ssh-copy-id: : : o Change the default ID_FILE from identity.pub to id_dsa.pub or perhaps : {id_dsa,id_rsa,identity}.pub to cover all the bases, although the : patch below deals only with id_dsa.pub - it would need some more : tweaking to deal with more than one (possibly non-existent) file. If this is to be done, i would propose the default be id_rsa.pub, since the RSA patent has expired, but that it be changeable via the environment. See below. : o If the destination authorized_keys file already contains the keys, : they should not be duplicated. I use ssh-copy-id in a regression harness : and I end up adding the same key tens or hundreds of times. I have not : seen any problem but it is somewhat distasteful. : : The method proposed is frankly a hack, but it is simple and I think it : is foolproof and portable. At least initially, it will mess up the : order of the keys, but given that the file is mostly write-only by : humans, that should not make any difference. See below for comments. : --- ssh-copy-id.orig 2008-01-31 12:01:03.000000000 -0500 : +++ ssh-copy-id 2008-01-31 12:05:16.000000000 -0500 : @@ -1,11 +1,11 @@ : #!/bin/sh : : -# Shell script to install your identity.pub on a remote machine : +# Shell script to install your id_dsa.pub on a remote machine : # Takes the remote machine name as an argument. : # Obviously, the remote machine must accept password authentication, : # or one of the other keys in your ssh-agent, for this to work. : : -ID_FILE="${HOME}/.ssh/identity.pub" : +ID_FILE="${HOME}/.ssh/id_dsa.pub" I'd propose changing this to: SSH_IDENTITY_FILE="${SSH_IDENTITY_FILE:-${HOME}/.ssh/id_rsa.pub}" or, alternatively, if there's concern about ${...:-...} being non-portable: [ x"${SSH_IDENTITY_FILE}" = x"" ] && \ SSH_IDENTITY_FILE="${HOME}/.ssh/id_rsa.pub" This allows the default identity to be set in the environment. Even more interesting would be to make ssh-copy-id use the same approach as ssh-add, i.e., copying all of the available identities that exist (~/.ssh/id_rsa.pub, ~/.ssh/id_dsa.pub, and ~/.ssh/identity). (Alternatively, for more paranoai, ssh-copy-id could copy only the first found of the three). This would be more complex, but might do the right thing for more folks. : : if [ "-i" = "$1" ]; then : shift : @@ -38,7 +38,7 @@ : exit 1 : fi : : -{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1 : +{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys && sort -u -o .ssh/authorized_keys .ssh/authorized_keys" || exit 1 I would propose the following pipeline instead (on multiple lines for legibility): { eval "$GET_ID" ; } \ |ssh "$1" ' umask 077 test -d .ssh || mkdir .ssh cd .ssh \ && ( test -f authorized_keys || touch authorized_keys ) \ && ( cat authorized_keys; cat ) |sort |uniq >authorized_keys.$$ \ && mv -f authorized_keys.$$ authorized_keys ' || exit 1 This does the following: * ensures that the .ssh directory exists and is searchable after the test -d and mkdir * avoids writing to the authorized_keys file until it has been written completely and successfully * avoids depending on 'sort -u', which may not be available on all systems * remains (i believe) compatible with Bourne/ksh, and csh shells and their descendants on the remote host Alternatively, the following would keep the authorized_keys file from being reordered, using 'grep -F' to check whether the identity is already present: { eval "$GET_ID" ; } \ |ssh "$1" ' umask 077 test -d .ssh || mkdir .ssh cd .ssh || exit 1 SSH_IDENTITY="`cat`" test x"${SSH_IDENTITY}" = x"" && exit 1 ( test -f authorized_keys || touch authorized_keys ) \ grep -F "${SSH_IDENTITY}" authorized_keys >/dev/null 2>&1 \ || { ( cat authorized_keys; echo "${SSH_IDENTITY}" ) >authorized_keys.$$ \ && mv -f authorized_keys.$$ authorized_keys } ' || exit 1 Unfortunately, the use of the SSH_IDENTITY variable makes this only work With Bourne/ksh shells and their descendants. A shell-independent version of this may be able to be written with nawk or gawk, but that poses its own portability problems.... -- 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 ml at t-b-o-h.net Fri Feb 1 11:21:56 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 31 Jan 2008 19:21:56 -0500 (EST) Subject: [openssh] Re: [openssh] Re: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <47A1DC6F.2040403@noaa.gov> Message-ID: <200802010021.m110Lv7X076511@himinbjorg.tucs-beachin-obx-house.com> > > On 2008-01-31 13:44, Tuc at T-B-O-H.NET wrote: > > But would the device have sent a RST if it received a fragment > > it couldn't route? I'm getting an actual RST from the router on the other > > end of a WDS link towards the far end laptop. > > Some versions of Linux wrongly generate an RST in response to a bad TCP > checksum. (Wrongly because the bad checksum is telling you you can't > trust the TCP header and payload, so why generate an RST using values > from the header?) I've had problems in the past with simply bad cabling > exercising this bug. > New cables on one side, then the other, then both. Still happening. Tuc From tusker at tusker.org Fri Feb 1 12:24:03 2008 From: tusker at tusker.org (Damien Mascord) Date: Fri, 01 Feb 2008 09:24:03 +0800 Subject: [openssh] Re: [openssh] Re: [openssh] Re: Frequent "Connection reset by peer" In-Reply-To: <200802010021.m110Lv7X076511@himinbjorg.tucs-beachin-obx-house.com> References: <200802010021.m110Lv7X076511@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <47A274B3.9030903@tusker.org> Tuc at T-B-O-H.NET wrote: > New cables on one side, then the other, then both. Still > happening. > > Tuc > Hi Tuc, Sorry to come into this discussion late, I was wondering what DD-WRT version you are running in WDS ? What wireless security settings have you chosen (there are known issues with WDS and WPA2/PSK) ? With the "I also get knocked off of SSH from the ROUTER ITSELF." statement, do you mean when you are connected via wire to that router ? As a final thing to try, check out the latest v24RC6v2. Damien From asmith15 at littlesvr.ca Fri Feb 1 12:45:30 2008 From: asmith15 at littlesvr.ca (Andrew Smith) Date: Thu, 31 Jan 2008 20:45:30 -0500 Subject: ssh wrapper scripts Message-ID: <47A279BA.7040008@littlesvr.ca> Hello This is an idea someone had that I thought of implementing, but I don't know whether I have the time. Regardless, I would only do it if you would include it with the OpenSSH distribution, so I would need to know your opinion. OpenSSH is a very useful an very versatile tool. Not only a remote terminal - but also an FTP-like client/server, an app for copying files, an aid for port forwarding and tunneling. For two of those features there are helper applications, little if anything more than wrappers: sftp and scp; that hide the complexity of the respective ssh commands. They achieve this by limiting the range of stuff that can be done (e.g. can't do much more than copy files with scp). For port forwarding and tunneling there are no such helpers. I spent the saturday at an install fest where a 15-year (seriously) linux veteran was struggling to remember/find the ssh syntax for making a tunnel for more than 2 hours, giving up eventually. It should be very easy (perhaps trivial) to make a script that makes this ordeal unnecessary. Pardon my ignorance, but something like: `sshforward 10000:20000`. Do the OpenSSH developers have any interest in this? Cheers, Andrew From stuge-openssh-unix-dev at cdy.org Fri Feb 1 13:26:26 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 1 Feb 2008 03:26:26 +0100 Subject: ssh wrapper scripts In-Reply-To: <47A279BA.7040008@littlesvr.ca> References: <47A279BA.7040008@littlesvr.ca> Message-ID: <20080201022627.3274.qmail@cdy.org> On Thu, Jan 31, 2008 at 08:45:30PM -0500, Andrew Smith wrote: > For port forwarding and tunneling there are no such helpers. I > spent the saturday at an install fest where a 15-year (seriously) > linux veteran was struggling to remember/find the ssh syntax for > making a tunnel for more than 2 hours, giving up eventually. > > It should be very easy (perhaps trivial) to make a script that > makes this ordeal unnecessary. Pardon my ignorance, but something > like: > `sshforward 10000:20000`. > > Do the OpenSSH developers have any interest in this? I doubt it. Veterans will already have their own scripts and configurations set up. This can be done partly in .ssh/ssh_config using something like this: Host mytunnel HostName remote.host.com LocalForward 2525 127.0.0.1:25 ..and then: $ ssh -NT mytunnel to start it up. I would like being able to set -N and -T from ssh_config though. //Peter From gert at greenie.muc.de Fri Feb 1 19:33:20 2008 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 1 Feb 2008 09:33:20 +0100 Subject: ssh wrapper scripts In-Reply-To: <47A279BA.7040008@littlesvr.ca> References: <47A279BA.7040008@littlesvr.ca> Message-ID: <20080201083319.GO3278@greenie.muc.de> Hi, On Thu, Jan 31, 2008 at 08:45:30PM -0500, Andrew Smith wrote: > For port forwarding and tunneling there are no such helpers. I spent the > saturday at an install fest where a 15-year (seriously) linux veteran > was struggling to remember/find the ssh syntax for making a tunnel for > more than 2 hours, giving up eventually. A "linux veteran" that is not able to find "-L" in the ssh man page won't find a special extra command either. Especially as it would need to have very much the same arguments - $ ssh -L 1000:somehost:2000 someotherhost vs. $ sshforward 1000:somehost:2000 someotherhost not much gained here. 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 archer at eskimo.com Sat Feb 2 03:32:58 2008 From: archer at eskimo.com (Curt, WE7U) Date: Fri, 1 Feb 2008 08:32:58 -0800 (PST) Subject: ssh wrapper scripts In-Reply-To: <20080201083319.GO3278@greenie.muc.de> References: <47A279BA.7040008@littlesvr.ca> <20080201083319.GO3278@greenie.muc.de> Message-ID: On Fri, 1 Feb 2008, Gert Doering wrote: > A "linux veteran" that is not able to find "-L" in the ssh man page > won't find a special extra command either. A simpler solution would be to add more examples to the man page. When I needed to do this exact thing in a hurry a few weeks ago I ended up doing a Google search to find a usage example. I had started with a quick scan of the man page but didn't find the info. The examples in the man page didn't cover this topic either, which was my initial hope. It was quicker/easier just to do the Google search and then I had it all running a few seconds later. If I had plenty of time to read the entire man page I could have done it that way too, but why not make it easy on people and include that example as well? For what it's worth, I'm a "Linux veteran" too, plus BSD and Solaris and a few others thrown in. Deriving the proper command-line switches to any particular command is not hard, but it takes time to read all the docs and test things. Add examples to the man page for this operation and you'll save a lot of people some time. Same goes for any other extremely common uses that might not be shown in the examples. -- Curt, WE7U: XASTIR: "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U The world DOES revolve around me: I picked the coordinate system! From nicholas.dokos at hp.com Sat Feb 2 04:54:09 2008 From: nicholas.dokos at hp.com (Nick Dokos) Date: Fri, 01 Feb 2008 12:54:09 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: Message from Jim Knoble of "Thu, 31 Jan 2008 18:28:37 EST." <20080131232837.GE4832@crawfish.ais.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> Message-ID: <16206.1201888449@alphaville.zko.hp.com> Jim Knoble wrote: > Circa 2008-01-31 13:00 dixit Nick Dokos: > > : I'd like to propose a couple of tweaks to ssh-copy-id: > : > : o Change the default ID_FILE from identity.pub to id_dsa.pub or perhaps > : {id_dsa,id_rsa,identity}.pub to cover all the bases, although the > : patch below deals only with id_dsa.pub - it would need some more > : tweaking to deal with more than one (possibly non-existent) file. > > If this is to be done, i would propose the default be id_rsa.pub, since > the RSA patent has expired, but that it be changeable via the > environment. See below. IANAL but I thought DSA's patent has been thrown open by NIST for use by anybody (although I understand that Dr. Schnorr has some claims). In any case, dealing with more than one (or maybe the most recent as you mention below) would be preferable imho. I just thought that having the default being the case that nobody uses (perhaps I should say, that nobody should use) any more is a little strange. > > : o If the destination authorized_keys file already contains the keys, > : they should not be duplicated. I use ssh-copy-id in a regression harness > : and I end up adding the same key tens or hundreds of times. I have not > : seen any problem but it is somewhat distasteful. > : > : The method proposed is frankly a hack, but it is simple and I think it > : is foolproof and portable. At least initially, it will mess up the > : order of the keys, but given that the file is mostly write-only by > : humans, that should not make any difference. > > See below for comments. > [patch skipped] > > Even more interesting would be to make ssh-copy-id use the same > approach as ssh-add, i.e., copying all of the available identities > that exist (~/.ssh/id_rsa.pub, ~/.ssh/id_dsa.pub, and ~/.ssh/identity). > (Alternatively, for more paranoai, ssh-copy-id could copy only the first > found of the three). > > This would be more complex, but might do the right thing for more folks. I agree. Would you like to propose a patch along these lines? If not, I can take a whack at it. > : -{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys" || exit 1 > : +{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys && sort -u -o .ssh/authorized_keys .ssh/authorized_keys" || exit 1 > > I would propose the following pipeline instead (on multiple lines for > legibility): > > { eval "$GET_ID" ; } \ > |ssh "$1" ' > umask 077 > test -d .ssh || mkdir .ssh > cd .ssh \ > && ( test -f authorized_keys || touch authorized_keys ) \ > && ( cat authorized_keys; cat ) |sort |uniq >authorized_keys.$$ \ > && mv -f authorized_keys.$$ authorized_keys > ' || exit 1 > > This does the following: > > * ensures that the .ssh directory exists and is searchable after the > test -d and mkdir > > * avoids writing to the authorized_keys file until it has been > written completely and successfully > > * avoids depending on 'sort -u', which may not be available on all > systems > > * remains (i believe) compatible with Bourne/ksh, and csh > shells and their descendants on the remote host > Again, if this is deemed a better solution, I'm fine with it: I'd just like to see the duplication go away. On the other hand, I don't think it's much better than my suggestion: it does deal better (bullet #2) with corner cases than the original code (and my proposed mod) but I don't believe that `sort -u' is a portability problem (otoh, I might be wrong). > Alternatively, the following would keep the authorized_keys file from > being reordered, using 'grep -F' to check whether the identity is > already present: > > { eval "$GET_ID" ; } \ > |ssh "$1" ' > umask 077 > test -d .ssh || mkdir .ssh > cd .ssh || exit 1 > SSH_IDENTITY="`cat`" > test x"${SSH_IDENTITY}" = x"" && exit 1 > ( test -f authorized_keys || touch authorized_keys ) \ > grep -F "${SSH_IDENTITY}" authorized_keys >/dev/null 2>&1 \ > || { > ( cat authorized_keys; echo "${SSH_IDENTITY}" ) > >authorized_keys.$$ \ > && mv -f authorized_keys.$$ authorized_keys > } > ' || exit 1 > > Unfortunately, the use of the SSH_IDENTITY variable makes this only work > With Bourne/ksh shells and their descendants. A shell-independent > version of this may be able to be written with nawk or gawk, but that > poses its own portability problems.... > Not worth it imho. Thanks for the comments! Nick From bob at proulx.com Sat Feb 2 06:10:18 2008 From: bob at proulx.com (Bob Proulx) Date: Fri, 1 Feb 2008 12:10:18 -0700 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <16206.1201888449@alphaville.zko.hp.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> Message-ID: <20080201191018.GA16331@dementia.proulx.com> Nick Dokos wrote: > Jim Knoble wrote: > > If this is to be done, i would propose the default be id_rsa.pub, since > > the RSA patent has expired, but that it be changeable via the > > environment. See below. > > IANAL but I thought DSA's patent has been thrown open by NIST for use by > anybody (although I understand that Dr. Schnorr has some claims). I am not aware of any problem with using DSA. It is just that RSA is the more preferred solution by many. The purpose of DSA was to avoid the RSA patent. Since the RSA patent is now long expired there is no longer any reason to avoid using RSA. +1 on using id_rsa.pub by default, or other more generic solution. > I just thought that having the default being the case that nobody > uses (perhaps I should say, that nobody should use) any more is a > little strange. I am not quite understanding what you are saying here. Are you saying that people should not use DSA? This is not the case. DSA is perfectly fine to use. It is just not as efficient as using RSA. That is what makes use of RSA the preferred choice by many. Bob From nicholas.dokos at hp.com Sat Feb 2 06:31:34 2008 From: nicholas.dokos at hp.com (Nick Dokos) Date: Fri, 01 Feb 2008 14:31:34 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: Message from bob@proulx.com (Bob Proulx) of "Fri, 01 Feb 2008 12:10:18 MST." <20080201191018.GA16331@dementia.proulx.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> Message-ID: <28145.1201894294@alphaville.zko.hp.com> Bob Proulx wrote: > I am not aware of any problem with using DSA. It is just that RSA is > the more preferred solution by many. > > The purpose of DSA was to avoid the RSA patent. Since the RSA patent > is now long expired there is no longer any reason to avoid using RSA. > > +1 on using id_rsa.pub by default, or other more generic solution. OK. > > > I just thought that having the default being the case that nobody > > uses (perhaps I should say, that nobody should use) any more is a > > little strange. > > I am not quite understanding what you are saying here. Are you saying > that people should not use DSA? This is not the case. DSA is > perfectly fine to use. It is just not as efficient as using RSA. > That is what makes use of RSA the preferred choice by many. > ssh-copy-id is using the RSA1 identity.pub by default. My point was that nobody should use RSA1, so this should be changed: I went for id_dsa.pub but so far at least, the vote (by a margin of 2 to 1!-) seems to be going for id_rsa.pub (or a more inclusive solution). What do you think about the proposals to eliminate duplicate keys from .ssh/authorized_keys? Regards, Nick From mouring at eviladmin.org Sat Feb 2 08:02:03 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 1 Feb 2008 15:02:03 -0600 (CST) Subject: RFC: ssh-copy-id tweaks In-Reply-To: <28145.1201894294@alphaville.zko.hp.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> Message-ID: On Fri, 1 Feb 2008, Nick Dokos wrote: [..] > What do you think about the proposals to eliminate duplicate keys from > .ssh/authorized_keys? > I'm really not that much of a fan of either method. Both fail if the auhtorized_keys file has any customizations (e.g. from="" in front of the key. Something I tend to do out of habbit after moving a key up to a new server). If anything I'd rather see a solution where it it looks at the RSA/DSA/RSA1 key proper without any prefix logic and not insert a new entry if it finds one (with a nice message to that effect as well). The other two solutions are to me are no better than the existing behavior in this regards. - Ben From nicholas.dokos at hp.com Sat Feb 2 09:44:04 2008 From: nicholas.dokos at hp.com (Nick Dokos) Date: Fri, 01 Feb 2008 17:44:04 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: Message from Ben Lindstrom of "Fri, 01 Feb 2008 15:02:03 CST." References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> Message-ID: <20275.1201905844@alphaville.zko.hp.com> Ben Lindstrom wrote: > I'm really not that much of a fan of either method. Both fail if the > auhtorized_keys file has any customizations (e.g. from="" in front of the > key. Something I tend to do out of habbit after moving a key up to a new > server). That's a problem. > > If anything I'd rather see a solution where it it looks at the > RSA/DSA/RSA1 key proper without any prefix logic and not insert a new > entry if it finds one (with a nice message to that effect as well). > > The other two solutions are to me are no better than the existing behavior > in this regards. > I think the grep-using implementation of Jim Knoble *is* better in that respect both to the existing behavior and to either of the sort-using suggestions. It avoids entering the key if it is already in the authorized_keys file, key restrictions or no key restrictions (although it does not produce the nice message). If it is not present, it appends it. Thanks, Nick From asmith15 at littlesvr.ca Sat Feb 2 12:43:42 2008 From: asmith15 at littlesvr.ca (Andrew Smith) Date: Fri, 01 Feb 2008 20:43:42 -0500 Subject: ssh wrapper scripts In-Reply-To: References: <47A279BA.7040008@littlesvr.ca> <20080201083319.GO3278@greenie.muc.de> Message-ID: <47A3CACE.6040104@littlesvr.ca> Curt, WE7U a ?crit : > On Fri, 1 Feb 2008, Gert Doering wrote: > >> A "linux veteran" that is not able to find "-L" in the ssh man page >> won't find a special extra command either. > > A simpler solution would be to add more examples to the man page. > I think that would be just as good. Andrew From jmknoble at pobox.com Sat Feb 2 16:50:01 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Sat, 2 Feb 2008 00:50:01 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20275.1201905844@alphaville.zko.hp.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> Message-ID: <20080202055001.GG4832@crawfish.ais.com> Circa 2008-02-01 17:44 dixit Nick Dokos: : Ben Lindstrom wrote: : > If anything I'd rather see a solution where it it looks at the : > RSA/DSA/RSA1 key proper without any prefix logic and not insert a new : > entry if it finds one (with a nice message to that effect as well). : : I think the grep-using implementation of Jim Knoble *is* better in that : respect both to the existing behavior and to either of the sort-using : suggestions. It avoids entering the key if it is already in the : authorized_keys file, key restrictions or no key restrictions (although : it does not produce the nice message). If it is not present, it appends : it. It's got portability problems, however. Principally, it depends on Bourne shell syntax, when the remote account could well use csh or tcsh, due to either system defaults or user preference. I'm working on a rewrite of ssh-copy-id which adds the first identity available from the following: keys added to a currently running ssh-agent[*] ~/.ssh/id_rsa.pub ~/.ssh/id_dsa.pub ~/.ssh/identity [*] This functionality is present in the current ssh-copy-id. I'm not too happy with its implementation (copies whatever 'ssh-add -L' gives it, as long as it's not blank, which could be multiple public keys). I'm beginning to think it might be better for ssh-copy-id to find all available identities and prompt the user for which one(s) to "copy".... My rewrite will also work regardless of whether the user's shell is Bourne shell, ksh, bash, or csh/tcsh, by executing commands using /bin/sh. I'm considering sending an awk script (or a thin wrapper around one) to the remote ~/.ssh directory, then running it as part of the ssh-copy-id transaction. If done properly, this could leave a useful 'add-authorized-key' script behind.... --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 pgsery at swcp.com Sun Feb 3 08:21:29 2008 From: pgsery at swcp.com (paul) Date: Sat, 02 Feb 2008 14:21:29 -0700 Subject: [PATCH] Requiring multiple auth mechanisms (updated) Message-ID: <47A4DED9.1080606@swcp.com> Jefferson Ogata's patch http://marc.info/?l=openssh-unix-dev&m=108134938701018&w=2 adds a multiple authentication methods option to sshd. I updated the patch to 4.7p1 and added logic to allow it to work with privilege separation. https://bugzilla.mindrot.org/show_bug.cgi?id=1435 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.7p1-multiauth.patch Type: text/x-patch Size: 7098 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080202/c709151b/attachment.bin From Jefferson.Ogata at noaa.gov Sun Feb 3 23:18:56 2008 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 03 Feb 2008 12:18:56 +0000 Subject: [PATCH] Requiring multiple auth mechanisms (updated) In-Reply-To: <47A4DED9.1080606@swcp.com> References: <47A4DED9.1080606@swcp.com> Message-ID: <47A5B130.4070502@noaa.gov> On 2008-02-02 21:21, paul wrote: > Jefferson Ogata's patch > http://marc.info/?l=openssh-unix-dev&m=108134938701018&w=2 adds a > multiple authentication methods option to sshd. I updated the patch to > 4.7p1 and added logic to allow it to work with privilege separation. > > https://bugzilla.mindrot.org/show_bug.cgi?id=1435 Wow... thanks! -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From djm at mindrot.org Mon Feb 4 14:58:07 2008 From: djm at mindrot.org (Damien Miller) Date: Mon, 4 Feb 2008 14:58:07 +1100 (EST) Subject: [PATCH] Requiring multiple auth mechanisms (updated) In-Reply-To: <47A4DED9.1080606@swcp.com> References: <47A4DED9.1080606@swcp.com> Message-ID: See also https://bugzilla.mindrot.org/show_bug.cgi?id=983 On Sat, 2 Feb 2008, paul wrote: > Jefferson Ogata's patch > http://marc.info/?l=openssh-unix-dev&m=108134938701018&w=2 adds a multiple > authentication methods option to sshd. I updated the patch to 4.7p1 and added > logic to allow it to work with privilege separation. > > https://bugzilla.mindrot.org/show_bug.cgi?id=1435 > From apb at cequrux.com Tue Feb 5 06:30:15 2008 From: apb at cequrux.com (Alan Barrett) Date: Mon, 4 Feb 2008 21:30:15 +0200 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080131232837.GE4832@crawfish.ais.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> Message-ID: <20080204193015.GA1223@apb-laptoy.apb.alt.za> On Thu, 31 Jan 2008, Jim Knoble wrote: > Alternatively, the following would keep the authorized_keys file from > being reordered, using 'grep -F' to check whether the identity is > already present: [script deleted] This is much better than other attempts I have seen. Apart from trivial issues like one line with an unwanted backslash and another with a missing backslash, the only problem I see is that, if the key exists but has a different comment at the end of line, then a duplicate line will be added. > Unfortunately, the use of the SSH_IDENTITY variable makes this only work > With Bourne/ksh shells and their descendants. A client can force a remote command to be executed under 'sh', like this: ssh "${user_at_host}" sh -c \''blah blah'\' This assumes that the remote host has a working 'sh' command, assumes no nested single quotes inside the 'blah blah' part, and assumes that the remote user's preferred shell handles backslashes and single quotes in the same way as sh or csh. It would probably be a good idea to have an option to customise the 'sh' part of this (for example, it might need to be /bin/sh or /usr/xpg4/bin/sh instead of just plain sh). Digression: I think it's a bug that sshd runs commands with the user's shell instead of with /bin/sh. The bug is easy to fix, by using _PATH_BSHELL in appropriate places in do_child() in session.c. If this is deemed to be intended behaviour and not a bug, then I'd ask that the part of the ssh man page that says If command is specified, it is executed on the remote host instead of a login shell. should be changed to explain what actually happens, so that people don't think "command is executed" means "command is executed using the remote system's standard command processor (which is /bin/sh on Unix-like systems)". --apb (Alan Barrett) From apb at cequrux.com Tue Feb 5 06:38:34 2008 From: apb at cequrux.com (Alan Barrett) Date: Mon, 4 Feb 2008 21:38:34 +0200 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <16206.1201888449@alphaville.zko.hp.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> Message-ID: <20080204193834.GB1223@apb-laptoy.apb.alt.za> On Fri, 01 Feb 2008, Nick Dokos wrote: > I don't believe that `sort -u' is a portability problem Whether or not it's a portability problem (I think it's not), it's a huge usability problem. Sorting my authorized_keys file will do very bad things to the comment block at the top fo the file, as well as the other comments intermingled with the keys. --apb (Alan Barrett) From mouring at eviladmin.org Tue Feb 5 09:30:42 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 4 Feb 2008 16:30:42 -0600 (CST) Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080204193015.GA1223@apb-laptoy.apb.alt.za> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <20080204193015.GA1223@apb-laptoy.apb.alt.za> Message-ID: On Mon, 4 Feb 2008, Alan Barrett wrote: [..] > Digression: > > I think it's a bug that sshd runs commands with the user's shell instead > of with /bin/sh. The bug is easy to fix, by using _PATH_BSHELL in > appropriate places in do_child() in session.c. If this is deemed to be > intended behaviour and not a bug, then I'd ask that the part of the ssh > man page that says > > If command is specified, it is executed on the remote host instead > of a login shell. > > should be changed to explain what actually happens, so that people don't > think "command is executed" means "command is executed using the remote > system's standard command processor (which is /bin/sh on Unix-like > systems)". > I disagree.. This would be a massive change in behavior. And would break a lot of environment where they set the user's shell to some restricted shell (rksh or scponly or rssh). And there would be no way for the admin to allow scp but deny shell access. - Ben From ccase at tresys.com Tue Feb 5 09:52:03 2008 From: ccase at tresys.com (Caleb Case) Date: Mon, 4 Feb 2008 17:52:03 -0500 Subject: configure/makefile cleanup: remove LIBSELINUX, LIBWRAP and LIBPAM Message-ID: <150846cc0802041452r75132e89u381bb42d4f1b37eb@mail.gmail.com> > @@ -3157,19 +3155,18 @@ LIBSELINUX="" > AC_ARG_WITH(selinux, > [ --with-selinux Enable SELinux support], > [ if test "x$withval" != "xno" ; then > + save_LIBS="$LIBS" > AC_DEFINE(WITH_SELINUX,1,[Define if you want SELinux support.]) > SELINUX_MSG="yes" > AC_CHECK_HEADER([selinux/selinux.h], , > AC_MSG_ERROR(SELinux support requires selinux.h header)) > AC_CHECK_LIB(selinux, setexeccon, [ LIBSELINUX="-lselinux" ], > AC_MSG_ERROR(SELinux support requires libselinux library)) > - save_LIBS="$LIBS" > - LIBS="$LIBS $LIBSELINUX" > + SSHDLIBS="$SSHDLIBS $LIBSELINUX" > AC_CHECK_FUNCS(getseuserbyname get_default_context_with_level) This breaks AC_CHECK_FUNCS :( If LIBS doesn't have $LIBSELINUX it will always fail to find getseuserbyname get_default_context_with_level. > LIBS="$save_LIBS" > fi ] > ) > -AC_SUBST(LIBSELINUX) > > # Check whether user wants Kerberos 5 support > KRB5_MSG="no" This patch adds -lselinux to LIBS during the check for getseuserbyname get_default_context_with_level. Thanks, Caleb --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: openssh/configure.ac =================================================================== --- openssh.orig/configure.ac +++ openssh/configure.ac @@ -3223,7 +3223,7 @@ AC_ARG_WITH(selinux, SELINUX_MSG="yes" AC_CHECK_HEADER([selinux/selinux.h], , AC_MSG_ERROR(SELinux support requires selinux.h header)) - AC_CHECK_LIB(selinux, setexeccon, [ LIBSELINUX="-lselinux" ], + AC_CHECK_LIB(selinux, setexeccon, [ LIBSELINUX="-lselinux" LIBS="-lselinux $LIBS" ], AC_MSG_ERROR(SELinux support requires libselinux library)) SSHDLIBS="$SSHDLIBS $LIBSELINUX" AC_CHECK_FUNCS(getseuserbyname get_default_context_with_level) From tkiernan at gmail.com Tue Feb 5 04:32:45 2008 From: tkiernan at gmail.com (T Kiernan) Date: Mon, 4 Feb 2008 17:32:45 +0000 Subject: configuring openssh Message-ID: <705ae6ad0802040932q6c713150q6cd1b46707809d50@mail.gmail.com> Hi , I have moved to a new platform and I ma trying to build openssh on redhat5.1powerpc64 gcc version 4.1.2 but gettinag an issue with strlcpy and strlcat However these are openbsd-compat and i have the source code .. But when i build the programs that invoke them do not recognise the definitions. Do you know if I need to configure this for ppc64 and when i do i get the following ... /configure configure: error: cannot find sources (ssh.c) in . or .. Is there a way I can force it to use the openbsd-compat strlcpy strlcat etc .. Thanks From jmknoble at pobox.com Tue Feb 5 22:23:27 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 5 Feb 2008 06:23:27 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080202055001.GG4832@crawfish.ais.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> <20080202055001.GG4832@crawfish.ais.com> Message-ID: <20080205112327.GA29551@crawfish.ais.com> Circa 2008-02-02 00:50 dixit Jim Knoble: : I'm working on a rewrite of ssh-copy-id The (nearly complete) rewrite of ssh-copy-id is available: http://www.jmknoble.net/openssh/ssh-copy-id Differences from prior ssh-copy-id: (1) Searches for identities in the following order: [identities in ssh-agent] ~/.ssh/id_rsa.pub ~/.ssh/id_dsa.pub ~/.ssh/identity.pub Copies the first one available (more than one if ssh-agent has multiple identities loaded, see below). (2) Old ssh-copy-id overloaded two meanings onto the '-i' switch: (a) "Don't look for identities in ssh-agent" (b) "Use this identity file over here" [a] above has moved from '-i' (with no arguments) to '-A'. [b] above remains at '-i' (with an argument). See the help (available with 'ssh-copy-id --help'). (3) Allows one to use an alternate "dot-ssh" directory on the local host, by setting the SSH_DIR environment variable to the path to a directory. Equivalent functionality on the remote side is not yet available. (4) Most importantly (it's what initiated this whole thread), only adds an identity to ~/.ssh/authorized_keys on the remote host if the public key isn't already present in some form. (5) It's more complex. In order to be smart enough about how we do [4], we use awk, which may be present on the remote host as 'gawk', 'mawk', 'nawk', or 'awk'. We look for them, in that order, on the PATH. You can correct the limited search used by setting the REMOTE_AWK environment variable to the path to the remote system's awk ('env REMOTE_AWK=/usr/bin/awk ssh-copy-id'). (6) It executes commands on the remote host using 'sh'. I believe it to be portable to situations where the remote user's shell is csh or tcsh, but i could be mistaken. Please test that. I'm a little worried about command-line length; the 'ssh' command has gotten somewhat long. Feedback about that would be handy as well. -- 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 mouring at eviladmin.org Wed Feb 6 03:52:13 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 5 Feb 2008 10:52:13 -0600 (CST) Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080205112327.GA29551@crawfish.ais.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> <20080202055001.GG4832@crawfish.ais.com> <20080205112327.GA29551@crawfish.ais.com> Message-ID: Geesh, I knew a better solution would be more complex, but this is starting to be scary. =) In some respects it is sad that VanDyke's proposed key management RFC has stalled (or was stalled last I checked). I'd almost advocate looking at this from another direction and seeing if ssh-agent or some other tool leveraging the openssh base code for testing and validating these things. Just I doubt it would be cleaner any other way. - Ben On Tue, 5 Feb 2008, Jim Knoble wrote: > Circa 2008-02-02 00:50 dixit Jim Knoble: > > : I'm working on a rewrite of ssh-copy-id > > The (nearly complete) rewrite of ssh-copy-id is available: > > http://www.jmknoble.net/openssh/ssh-copy-id > > Differences from prior ssh-copy-id: > > (1) Searches for identities in the following order: > > [identities in ssh-agent] > ~/.ssh/id_rsa.pub > ~/.ssh/id_dsa.pub > ~/.ssh/identity.pub > > Copies the first one available (more than one if ssh-agent has > multiple identities loaded, see below). > > (2) Old ssh-copy-id overloaded two meanings onto the '-i' switch: > > (a) "Don't look for identities in ssh-agent" > (b) "Use this identity file over here" > > [a] above has moved from '-i' (with no arguments) to '-A'. > [b] above remains at '-i' (with an argument). See the help > (available with 'ssh-copy-id --help'). > > (3) Allows one to use an alternate "dot-ssh" directory on the local > host, by setting the SSH_DIR environment variable to the path to > a directory. Equivalent functionality on the remote side is not > yet available. > > (4) Most importantly (it's what initiated this whole thread), only > adds an identity to ~/.ssh/authorized_keys on the remote host if > the public key isn't already present in some form. > > (5) It's more complex. In order to be smart enough about how we do > [4], we use awk, which may be present on the remote host as > 'gawk', 'mawk', 'nawk', or 'awk'. We look for them, in that > order, on the PATH. You can correct the limited search used by > setting the REMOTE_AWK environment variable to the path to the > remote system's awk ('env REMOTE_AWK=/usr/bin/awk ssh-copy-id'). > > (6) It executes commands on the remote host using 'sh'. I believe > it to be portable to situations where the remote user's shell is > csh or tcsh, but i could be mistaken. Please test that. > > I'm a little worried about command-line length; the 'ssh' command has > gotten somewhat long. Feedback about that would be handy as well. > > -- > 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 stuge-openssh-unix-dev at cdy.org Wed Feb 6 04:16:00 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 5 Feb 2008 18:16:00 +0100 Subject: RFC: ssh-copy-id tweaks In-Reply-To: References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> <20080202055001.GG4832@crawfish.ais.com> <20080205112327.GA29551@crawfish.ais.com> Message-ID: <20080205171600.3991.qmail@cdy.org> On Tue, Feb 05, 2008 at 10:52:13AM -0600, Ben Lindstrom wrote: > On Tue, 5 Feb 2008, Jim Knoble wrote: > > The (nearly complete) rewrite of ssh-copy-id is available: > > > > http://www.jmknoble.net/openssh/ssh-copy-id Now that's what I call a script. I like the many layers of quotes in the scripts being sent over to the remote side. > Geesh, I knew a better solution would be more complex, but this is > starting to be scary. =) Agree. > I'd almost advocate looking at this from another direction and > seeing if ssh-agent or some other tool leveraging the openssh base > code for testing and validating these things. I too think that it would be good to reuse existing code rather than writing a new implemention using sh and awk. > Just I doubt it would be cleaner any other way. I don't doubt so much. The local part of the tool would be much cleaner. Question is how much the remote part can improve if there is to be zero dependencies. On one hand it's nice to be independent, on the other hand OpenSSH will already be installed on the remote host. We could ship a helper (or subsystem) for rewriting authorized_keys. Yes yes, I am re-inventing key management, but so what - it doesn't have to be very complicated and could easily be replaced with a standardized implementation if/when a standard is decided on. //Peter From bob at proulx.com Wed Feb 6 04:48:50 2008 From: bob at proulx.com (Bob Proulx) Date: Tue, 5 Feb 2008 10:48:50 -0700 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080205112327.GA29551@crawfish.ais.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> <20080202055001.GG4832@crawfish.ais.com> <20080205112327.GA29551@crawfish.ais.com> Message-ID: <20080205174850.GA2998@dementia.proulx.com> Jim Knoble wrote: > The (nearly complete) rewrite of ssh-copy-id is available: > http://www.jmknoble.net/openssh/ssh-copy-id Thanks for working on this. I looked at it briefly and have a few quick comments: echo "--> $*" Progress() { if [ x"${VERBOSE}" = x"yes" ]; then echo "--> $* ..."; fi; } Because of the leading '-' I worry that some echo implementations might confused this with an option syntax. As you know echo can be a troublesome command with many non-portable implementations. But perhaps I worry needlessly here. - agent_identity="`ssh-add -L |grep -v '^The agent has no identities\.$' 2>/dev/null`" + agent_identity="`ssh-add -L |sed '/^The agent has no identities\.$/d'`" The exit code of grep is dependent upon whether it matched or not. (Also I don't think the stderr should have been redirected.) But we don't care about knowing if there was a match here but simply want to remove the line. Therefore using sed is better because the exit status of sed indicates the success or failure of the operation. And if there is an error then we would want to see it. BTW... Thanks for adding that section. The previous command did not make that check and I would sometimes annoyingly find "The agent has no identities" in my authorized keys file. :-) Nice to see this check in place for the future. - if [ ${msgcount} -eq 1 ]; then + if [ ${msgcount} -eq 1 ]; then There is a trailing space on that line. It would be great if that were cleaned up. I hate to even suggest this after seeing your efforts but if I were doing this I would have piped the script into the remote shell on stdin and passed the keys to it through the argument list instead of the other way around. The keys are small by comparison and won't need fancy quoting. By sending the script in on stdin then all of the quoting problems disappear. I think it would make this more maintainable in the long run. Something to think about... It seems to work for me. Thanks again for working on this. Bob From jmknoble at pobox.com Wed Feb 6 05:53:44 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 5 Feb 2008 13:53:44 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080205171600.3991.qmail@cdy.org> References: <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> <20080202055001.GG4832@crawfish.ais.com> <20080205112327.GA29551@crawfish.ais.com> <20080205171600.3991.qmail@cdy.org> Message-ID: <20080205185344.GC29551@crawfish.ais.com> Circa 2008-02-05 12:16 dixit Peter Stuge: : On Tue, Feb 05, 2008 at 10:52:13AM -0600, Ben Lindstrom wrote: : > Geesh, I knew a better solution would be more complex, but this is : > starting to be scary. =) : : Agree. Seconded. :) : Question is how much the remote part can improve if there is to be : zero dependencies. On one hand it's nice to be independent, on the : other hand OpenSSH will already be installed on the remote host. Some implementation of SSH will already be installed on the remote host. Currently, we pretty much bluster on through as if it's OpenSSH. And there's no guarantee it will be a recent version of OpenSSH, either. We might be copying an ID to a {cough} Solaris 8 system running an old implementation of SunSSH.... -- 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 jmknoble at pobox.com Wed Feb 6 06:12:54 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 5 Feb 2008 14:12:54 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080205174850.GA2998@dementia.proulx.com> References: <30502.1201802412@alphaville.zko.hp.com> <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> <20080202055001.GG4832@crawfish.ais.com> <20080205112327.GA29551@crawfish.ais.com> <20080205174850.GA2998@dementia.proulx.com> Message-ID: <20080205191254.GD29551@crawfish.ais.com> Circa 2008-02-05 12:48 dixit Bob Proulx: : echo "--> $*" : : Because of the leading '-' I worry that some echo implementations : might confused this with an option syntax. [...] But perhaps I worry : needlessly here. Good point. Not necessarily needless worry. That's the sort of thing we always hope to leave in the past, but which inevitably arises when we've gotten comfortable about forgetting it. [use 'sed /.../d' instead of 'grep -v' with output of 'ssh-add -L'] : [...] using sed is better because the exit status of sed indicates the : success or failure of the operation. And if there is an error then we : would want to see it. Maybe. We might want ssh-copy-id to catch the error and emit a friendly warning message. : - if [ ${msgcount} -eq 1 ]; then : + if [ ${msgcount} -eq 1 ]; then : : There is a trailing space on that line. It would be great if that : were cleaned up. Agreed. : I hate to even suggest this after seeing your efforts but if I were : doing this I would have piped the script into the remote shell on : stdin and passed the keys to it through the argument list instead of : the other way around.[...] I thought about piping the script to stdin as well, but the script was somewhat smaller then and it didn't seem as necessary. It seems to have grown somewhat.... Thanks for your feedback. -- 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 jmknoble at pobox.com Wed Feb 6 06:50:19 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 5 Feb 2008 14:50:19 -0500 Subject: RFC: ssh-copy-id tweaks In-Reply-To: <20080205171600.3991.qmail@cdy.org> References: <20080131232837.GE4832@crawfish.ais.com> <16206.1201888449@alphaville.zko.hp.com> <20080201191018.GA16331@dementia.proulx.com> <28145.1201894294@alphaville.zko.hp.com> <20275.1201905844@alphaville.zko.hp.com> <20080202055001.GG4832@crawfish.ais.com> <20080205112327.GA29551@crawfish.ais.com> <20080205171600.3991.qmail@cdy.org> Message-ID: <20080205195019.GE29551@crawfish.ais.com> Circa 2008-02-05 12:16 dixit Peter Stuge: : I too think that it would be good to reuse existing code rather : than writing a new implemention using sh and awk. The biggest problem with a sh implementation is how (and how much) to validate the keys before adding them to authorized_keys. The OpenSSH codebase obviously already has stuff to do that. Another sizable part of the script is gracefully degrading when stuff we need isn't present ('awk' on both the local and remote ends being a prime example) and other user interaction. After thinking about this some more, we might be able to dispense with 'awk' if we felt sure we could rely on 'cut' being present remotely. It may even be better to fully parse the keys on the local side. This might even be able to help us avoid transmitting more than one key in the event the ssh-agent contains multiple identities (i'm still not completely satisfied with that area of ssh-copy-id---i'd rather we only copy one identity at a time as opposed to slopping them all in there, hoping for the best, and telling the user to go see if there are any "extra unexpected" keys in ~/.ssh/authorized_keys). : > Just I doubt it would be cleaner any other way. : : I don't doubt so much. The local part of the tool would be much : cleaner. Particularly in the area of parsing/validating the keys.... -- 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 pgsery at swcp.com Wed Feb 6 16:47:08 2008 From: pgsery at swcp.com (paul) Date: Tue, 05 Feb 2008 22:47:08 -0700 Subject: [PATCH] Out-of-band challenge (OBC) authentication method Message-ID: <47A949DC.8070701@swcp.com> This patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1438) creates a kbdint device that provides a server-based authentication mechanism. The server generates and emails you a random string when you attempt to login. You're authenticated if you can correctly answer the challenge. You can use a regular email account, a pager, cell phone or other email capable device to receive the challenge. However, by using a physical device you can receive a one-time authentication secret isolated from your workstation. OBC can be used in conjunction with the "Multiauth" patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1435), to create a two-factor authentication system; Multiauth allows you to require two or more authentications for a successful login. Combining OBC with Multiauth creates two physically separate authentication factors equivalent to a commercial two-factor token. For instance, requiring public key and OBC authentications creates physically separate factors. See README.obc for configuration and installation information -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.7p1-kbdint-obc.patch Type: text/x-patch Size: 32846 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080205/06b9d576/attachment-0001.bin From pgsery at swcp.com Wed Feb 6 16:56:18 2008 From: pgsery at swcp.com (paul) Date: Tue, 05 Feb 2008 22:56:18 -0700 Subject: [PATCH] Requiring multiple auth mechanisms (updated) In-Reply-To: References: <47A4DED9.1080606@swcp.com> Message-ID: <47A94C02.7000704@swcp.com> This patch looked interesting but Mr. Ogata's seemed better suited for use with the out-of-band (obc) authentication method (https://bugzilla.mindrot.org/show_bug.cgi?id=1438) I was working on. I'm a novice, so I could easily be wrong. Thanks for the heads-up! Damien Miller wrote: > See also https://bugzilla.mindrot.org/show_bug.cgi?id=983 > > On Sat, 2 Feb 2008, paul wrote: > > >> Jefferson Ogata's patch >> http://marc.info/?l=openssh-unix-dev&m=108134938701018&w=2 adds a multiple >> authentication methods option to sshd. I updated the patch to 4.7p1 and added >> logic to allow it to work with privilege separation. >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=1435 >> >> From dkg-openssh.com at fifthhorseman.net Wed Feb 6 18:15:34 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Feb 2008 02:15:34 -0500 Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: <47A949DC.8070701@swcp.com> (paul's message of "Tue\, 05 Feb 2008 22\:47\:08 -0700") References: <47A949DC.8070701@swcp.com> Message-ID: <877ihi7dyh.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/20080206/218564e1/attachment.bin From mouring at eviladmin.org Thu Feb 7 04:29:59 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 6 Feb 2008 11:29:59 -0600 (CST) Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: <877ihi7dyh.fsf@squeak.fifthhorseman.net> References: <47A949DC.8070701@swcp.com> <877ihi7dyh.fsf@squeak.fifthhorseman.net> Message-ID: To take this a step farther wouldn't it be better to build this more like the "ProxyCommand". I'm not thrilled with the idea that we start adding massive amount of authentication methods that are used by a dozen people. I'd rather see someone invest the time in a good external proxy method for adding in custom authentications (Even at that, I dislike it from a security view since it makes it easier to compermise the deamon). Also, email isn't very reliable and timely transmission of information. Even worse if you are sending it to an SMS gateway. - Ben On Wed, 6 Feb 2008, Daniel Kahn Gillmor wrote: > On Wed 2008-02-06 00:47:08 -0500, paul wrote: > >> This patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1438) creates >> a kbdint device that provides a server-based authentication >> mechanism. The server generates and emails you a random string when >> you attempt to login. You're authenticated if you can correctly answer >> the challenge. > > Thereby proving the old adage that every program expands until it can > send mail ;) > > This is a seriously neat idea, but i'm not sure why you'd want to > limit it to sending mail, or assuming that the particular type of SMTP > submission you've implemented here will work for everyone (port 25 > might be blocked, users might need TLS, SMTP authentication, etc). > > Wouldn't it make more sense to make this a spawnable, unprivileged > sub-process that accepts the challenge on stdin? For example, this > could be specified as: > > ChallengeMethod mail -s 'Challenge from %h' %u > ChallengeMethodUser nobody > > (meaning "for each challenge, as the user 'nobody', invoke > /usr/bin/mail with these arguments") > > This would be instead of having to specify ChallengeSMTPServer. > > If you'd like to remove the challenge-generating part from ssh as > well, you could also implement it as a spawnable unprivileged > subprocess which emits the challenge on stdout, which would probably > be better. This would allow an external system to do things like > buffer a single challenge for a limited duration (instead of issuing a > dozen different challenges for a single user at once), or select its > challenge from an alternate randomized string space. > > An administrator could also make use of the already-present Match > functionality to avoid needing ChallengeUsers in the config file. > > This would remove the mail-sending and user-mapping functionality from > ssh, which means it would be much more flexible for other users (who > might prefer the OBC to be delievered to an authenticated RSS feed, > posted to a bulletin board in steganographic form, etc). > > The patch would need to make sure that the spawned out-of-band > challenge drops as much privileges as possible, and admins would need > to make sure that their chosen ChallengeMethod is not dangerous or > subject to format-string expansion in dangerous ways. > > It also occurs to me that if this is implemented, it could create a > way for anonymous miscreants to cause a mailstorm for the targeted > user simply by trying to log in as hir. I think this is true even in > conjunction with MultiAuth, because it doesn't look like the MultiAuth > patch allows the server to mandate an order in which the > authentication flavors are run (client-chooses-auth seems to be built > into the SSH protocol, if i'm reading my ssh -vvv output correctly). > If those challenges are 10-penny-apiece text messages, this auth > method could rack up quite a bill. > > One last general thought: why not build this functionality as a PAM > module instead of a patch to OpenSSH? If you did that, OpenSSH > systems that use PAM could make use of it directly, and so could any > other PAM-enabled systems. > > Thanks for writing this up and publishing it, Paul. It's very > interesting. > > --dkg > From dkg-openssh.com at fifthhorseman.net Thu Feb 7 07:00:31 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Feb 2008 15:00:31 -0500 Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: (Ben Lindstrom's message of "Wed\, 6 Feb 2008 11\:29\:59 -0600 \(CST\)") References: <47A949DC.8070701@swcp.com> <877ihi7dyh.fsf@squeak.fifthhorseman.net> Message-ID: <874pclzwgw.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/20080206/3048bdfa/attachment.bin From carson at taltos.org Thu Feb 7 07:42:45 2008 From: carson at taltos.org (Carson Gaspar) Date: Wed, 06 Feb 2008 15:42:45 -0500 Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: <877ihi7dyh.fsf@squeak.fifthhorseman.net> References: <47A949DC.8070701@swcp.com> <877ihi7dyh.fsf@squeak.fifthhorseman.net> Message-ID: <47AA1BC5.80301@taltos.org> Daniel Kahn Gillmor wrote: > It also occurs to me that if this is implemented, it could create a > way for anonymous miscreants to cause a mailstorm for the targeted > user simply by trying to log in as hir. I think this is true even in > conjunction with MultiAuth, because it doesn't look like the MultiAuth > patch allows the server to mandate an order in which the > authentication flavors are run (client-chooses-auth seems to be built > into the SSH protocol, if i'm reading my ssh -vvv output correctly). > If those challenges are 10-penny-apiece text messages, this auth > method could rack up quite a bill. The server can force auth order by limiting the auth methods it sends to the client (as it re-sends them every auth round). I implemented this back in 2000, but sadly never got it merged. -- Carson From dkg-openssh.com at fifthhorseman.net Thu Feb 7 09:44:02 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Feb 2008 17:44:02 -0500 Subject: server-forced authentication order [was: Re: [PATCH] Out-of-band challenge (OBC) authentication method] In-Reply-To: <47AA1BC5.80301@taltos.org> (Carson Gaspar's message of "Wed\, 06 Feb 2008 15\:42\:45 -0500") References: <47A949DC.8070701@swcp.com> <877ihi7dyh.fsf@squeak.fifthhorseman.net> <47AA1BC5.80301@taltos.org> Message-ID: <87hcglu2ml.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/20080206/398203c6/attachment.bin From pgsery at swcp.com Thu Feb 7 16:20:33 2008 From: pgsery at swcp.com (Paul Sery) Date: Wed, 6 Feb 2008 22:20:33 -0700 (MST) Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: References: <47A949DC.8070701@swcp.com> <877ihi7dyh.fsf@squeak.fifthhorseman.net> Message-ID: On Wed, 6 Feb 2008, Ben Lindstrom wrote: > > To take this a step farther wouldn't it be better to build this more like > the "ProxyCommand". I'm not thrilled with the idea that we start adding > massive amount of authentication methods that are used by a dozen people. > I'd rather see someone invest the time in a good external proxy method for > adding in custom authentications (Even at that, I dislike it from a > security view since it makes it easier to compermise the deamon). > I chose this implementation because I thought kbdint was designed for adding new auth methods. I understand not wanting to add new features, especially ones likely to remain unused. However, this method should prove popular if it delivers reliable, server-based two-factor authentication. The server-based model allows any organization or individual the ability to provide and use two-factor authentication. > Also, email isn't very reliable and timely transmission of information. > Even worse if you are sending it to an SMS gateway. > But is email (I'm unfamiliar with SMS particulars) reliable enough for this purpose? My personal experience says yes. From pgsery at swcp.com Thu Feb 7 15:53:26 2008 From: pgsery at swcp.com (Paul Sery) Date: Wed, 6 Feb 2008 21:53:26 -0700 (MST) Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: <47AA82F7.8000308@swcp.com> References: <47AA82F7.8000308@swcp.com> Message-ID: Daniel Kahn Gillmor wrote: > On Wed 2008-02-06 00:47:08 -0500, paul wrote: > > Thereby proving the old adage that every program expands until it can > send mail ;) As they say, it seemed like a good idea at the time! I was unaware that this was a common pitfall. > This is a seriously neat idea, but i'm not sure why you'd want to > limit it to sending mail, or assuming that the particular type of SMTP > submission you've implemented here will work for everyone (port 25 > might be blocked, users might need TLS, SMTP authentication, etc). Email seems like the most logical channel for this system. I'll adopt any medium that proves better. > Wouldn't it make more sense to make this a spawnable, unprivileged > sub-process that accepts the challenge on stdin? For example, this > could be specified as: > > ChallengeMethod mail -s 'Challenge from %h' %u > ChallengeMethodUser nobody > > (meaning "for each challenge, as the user 'nobody', invoke > /usr/bin/mail with these arguments") > > This would be instead of having to specify ChallengeSMTPServer. That makes sense. I originally hard-wired an MTA/system call to do (crudely) just what you describe. It then seemed better to fold the function into sshd. I'll rewrite to learn the method to use from sshd_config. This would indeed be cool since the method could be anything including an ssh pipeline to some ssh-aware device that you carry around. > If you'd like to remove the challenge-generating part from ssh as > well, you could also implement it as a spawnable unprivileged > subprocess which emits the challenge on stdout, which would probably > be better. This would allow an external system to do things like > buffer a single challenge for a limited duration (instead of issuing a > dozen different challenges for a single user at once), or select its > challenge from an alternate randomized string space. > > An administrator could also make use of the already-present Match > functionality to avoid needing ChallengeUsers in the config file. > > This would remove the mail-sending and user-mapping functionality from > ssh, which means it would be much more flexible for other users (who > might prefer the OBC to be delievered to an authenticated RSS feed, > posted to a bulletin board in steganographic form, etc). > > The patch would need to make sure that the spawned out-of-band > challenge drops as much privileges as possible, and admins would need > to make sure that their chosen ChallengeMethod is not dangerous or > subject to format-string expansion in dangerous ways. > I'm all for making things simpler for my fellow admins. I'll start thinking about how to do it. Btw, my contrib/gnome-ssh-askpass2.c patch https://bugzilla.mindrot.org/show_bug.cgi?id=1393 does something similar to what you describe. As you know, it generates a random string and writes it to a fifo. A perl script reads the string and emails it to the user. > It also occurs to me that if this is implemented, it could create a > way for anonymous miscreants to cause a mailstorm for the targeted > user simply by trying to log in as hir. I think this is true even in > conjunction with MultiAuth, because it doesn't look like the MultiAuth > patch allows the server to mandate an order in which the > authentication flavors are run (client-chooses-auth seems to be built > into the SSH protocol, if i'm reading my ssh -vvv output correctly). > If those challenges are 10-penny-apiece text messages, this auth > method could rack up quite a bill. This must be addressed. I think Multiauth or https://bugzilla.mindrot.org/show_bug.cgi?id=983 could be modified to prevent this. For instance, stop overall authentication if pubkey fails. > One last general thought: why not build this functionality as a PAM > module instead of a patch to OpenSSH? If you did that, OpenSSH > systems that use PAM could make use of it directly, and so could any > other PAM-enabled systems. On my to-do list. I know a little about how OpenSSH internals work but nothing about PAM innards. > Thanks for writing this up and publishing it, Paul. It's very > interesting. > > --dkg Thanks for taking the time to review this idea. From stuge-openssh-unix-dev at cdy.org Thu Feb 7 17:10:22 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 7 Feb 2008 07:10:22 +0100 Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: References: <47A949DC.8070701@swcp.com> <877ihi7dyh.fsf@squeak.fifthhorseman.net> Message-ID: <20080207061022.17780.qmail@cdy.org> On Wed, Feb 06, 2008 at 10:20:33PM -0700, Paul Sery wrote: > But is email reliable enough for this purpose? My personal > experience says yes. I would say no. Internet email gives no guarantees of any kind and should not be considered reliable in any way. There is no end of things that can disrupt email. In this case something as trivial as a fairly long queue in one SMTP server on the path from sshd to user can easily cause a delay long enough for the TCP stack to time out the connection. > (I'm unfamiliar with SMS particulars) SMS isn't all that reliable either, though the GSM network is thus far under much less stress than the internet, and so SMS performance is fairly good. But SMS:es also does not have guaranteed delivery times. Again, uncontrollable backlogs in the SMSC will cause uncontrollable and unmeasurable delivery delays. This is assuming you actually get to speak directly to an SMSC in your country. This is usually not the case unless you pay a premium for bulk SMS services, and even then it's likely you only get to talk to a machine which is several hops away from the SMSC. Both email and SMS may work well enough for some of course. It depends on what kind of reliability one is ready to trade away for the benefit of stronger authentication. //Peter From mouring at eviladmin.org Fri Feb 8 02:59:25 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 7 Feb 2008 09:59:25 -0600 (CST) Subject: [PATCH] Out-of-band challenge (OBC) authentication method In-Reply-To: <20080207061022.17780.qmail@cdy.org> References: <47A949DC.8070701@swcp.com> <877ihi7dyh.fsf@squeak.fifthhorseman.net> <20080207061022.17780.qmail@cdy.org> Message-ID: On Thu, 7 Feb 2008, Peter Stuge wrote: > On Wed, Feb 06, 2008 at 10:20:33PM -0700, Paul Sery wrote: [..] >> (I'm unfamiliar with SMS particulars) > > SMS isn't all that reliable either, though the GSM network is thus > far under much less stress than the internet, and so SMS performance > is fairly good. But SMS:es also does not have guaranteed delivery > times. Again, uncontrollable backlogs in the SMSC will cause > uncontrollable and unmeasurable delivery delays. > It isn't so much delays, but SMS messages can outright vanish as well. I've been at a few conferences where folks have SMS messaged me for dinner or to meet at a panel and I've failed to get them (not delayed.. they just didn't show up). Back when I was doing dial-in text paging I was assured to lose 1 out of every 100 pages I sent to the pager company. It was almost like clockwork, and the company didn't care. (Granted, I didn't care because my paging software was a chatty beast and would nag at me every 15 minutes so at worse during off peek hours it would be 30 minutes assuming no one else called me) > This is assuming you actually get to speak directly to an SMSC in > your country. This is usually not the case unless you pay a premium > for bulk SMS services, and even then it's likely you only get to talk > to a machine which is several hops away from the SMSC. > > Both email and SMS may work well enough for some of course. It > depends on what kind of reliability one is ready to trade away > for the benefit of stronger authentication. > I see SMS and Email working "well-enough" for daily usage, but I fear the "oh shit" case... You are 10,000 miles away from the site, your cell phone company's SMS gateway is down (or you're on analog only).. your external email provider is down.. /var/spool is filled on the box, Linux kernel has OOM and gone on a killing spree sparing sshd, but taking out sendmail and others. Or the one that I can attest semi-lately to which is EXT3 gains a nice bad sector in the journal, the OS freeks throwing the filesystem into read only mode and you can't physically write anything to get mail off or on the box. I know these should be non-typical cases, but one should find a list of the scarest events so they know their edge cases. =) Because it will be under these cases you'll be swearing like a sailor as you hunt down someone else to get at the box via console. - Ben From rapier at psc.edu Fri Feb 8 04:30:47 2008 From: rapier at psc.edu (Chris Rapier) Date: Thu, 07 Feb 2008 12:30:47 -0500 Subject: HPN-SSH: HPN13v1 Released Message-ID: <47AB4047.5090006@psc.edu> Ben Bennett and I (both researchers at the Pittsburgh Supercomputing Center) have released the HPN13v1 patch set for OpenSSH 4.7p1. Primarily this release incorporates the previously announced multi-threaded AES-CTR mode cipher which will allow users to make better use of multi-core environments. In our test environments we've seen upwards of a 100% improvement in throughput performance compared to stock AES-CTR. Also, we're distributing patches in a different way. From now on there will be 'kitchen sink' and 'a la carte' versions of the patches available. The kitchen sink version includes dynamic SSH windows, none cipher switching, multithreaded AES-CTR, peak throughput display for SCP, and enhanced server side logging. The a la carte patches will provide each of these as a separate patch against the stock OpenSSH code. However, I've not yet split out the dynamic window patch from the none cipher patch. I hope to have that finished in the next week. The patches, papers, presentations, and more information are available from http://psc.edu/networking/projects/hpn-ssh/ Questions, comments, ideas, and requests are always appreciated. Thanks for your time, Chris Rapier Ben Bennett Pittsburgh Supercomputing Center From pgsery at swcp.com Fri Feb 8 17:25:41 2008 From: pgsery at swcp.com (paul) Date: Thu, 07 Feb 2008 23:25:41 -0700 Subject: [PATCH] Virtual Token (VToken) challenge authentication method Message-ID: <47ABF5E5.4090607@swcp.com> The Virtual Token (VToken) patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1439) creates a kbdint device that provides a new challenge-based authentication mechanism. The server calculates a challenge from two secrets and a counter. You authenticate by proving by correctly answering the challenge, proving you know the secrets. This creates a software-based token, similar in function to commercial ones, that can be run from your workstation or better yet, ubiquitous devices such as PDAs, cell phones, calculators, and even pen/paper. VToken has the advantage of not only using cheap, generic devices but also not requiring a dedicated network. Commercial system can only be used with networks configured for their use. VToken can be used on any machine running OpenSSH and a properly configured sshd_config file. Thus, a single virtual token can authenticate to an unlimited number of servers. The current challenge is a place-holder for a more rigorous one. It uses the simple equation: Challenge=Secret*Counter Mod(PIN). The secret is designed to be embedded in the virtual token, while you must keep the PIN secret; the counter protects against replay attacks. Taking the modulus of the product maps the answer into a number set (or something like that;). Ultimately, the calculation should probably be done by taking the hash of the combined terms (anyone who captures the current challenge will be able to calculate the secrets using brute force). vtoken.c is an example virtual token app. It prompts you for your PIN and calculates the challenge response from the secret, which is embedded in it's source. VToken in it's present form should be used in conjunction with the "Multiauth" patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1435), which allows you to use multiple authentication methods tolog into a machine. You'll want to use Pubkey together with VToken. In the future, VToken will by itself will provide two-factor authentication. The secret will be embedded in the app and effectively be embedded in your PDA, cell phone, etc. You'll keep your PIN separate, of course, and use the two just like on commercial tokens. This patch might indeed be better suited for PAM or other platform. However, I'm submitting here because I use OpenSSH every day and would like the ability to natively use stronger authentication. It's also been fun learning and hacking the code. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-kbdint-hack.patch Type: text/x-patch Size: 24583 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080207/7658f397/attachment-0001.bin From fishcustard at gmail.com Thu Feb 7 22:55:14 2008 From: fishcustard at gmail.com (Danny Mitchell) Date: Thu, 7 Feb 2008 22:55:14 +1100 Subject: "PermitRootLogin no" fails Message-ID: I'm running version 4.7p1 of OpenSSH on a Linux system (it was originally a RedHat system, but I've changed almost everything.) When I originally built OpenSSH I used the config option --without-pam, and installed the software in /usr/local. I explicitly forbade root login with sshd (by setting the PermitRootLogin to "no" in the sshd_config file), but found that I could login as root. Examination of the code revealed that PermitRootLogin is only dealt with in auth-pam.c, which is surrounded by #ifdef USE_PAM/#endif. I rebuilt OpenSSH with the --with-pam option enabled, installed, set PermitRootLogin to "no", and restarted. It still permits root login. This seems to raise two security problems, both serious: 1. PermitRootLogin is never used if sshd is built without PAM support, but the documentation is silent on this. 2. Even if sshd is built with PAM support, PermitRootLogin has no effect. -- ----------------------------------------------------------------------------------------- Wocky | A poem for the lonely: hello. fishcustard at gmail.com | -- Spike Milligan ----------------------------------------------------------------------------------------- From dtucker at zip.com.au Fri Feb 8 20:00:56 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Feb 2008 20:00:56 +1100 Subject: "PermitRootLogin no" fails In-Reply-To: References: Message-ID: <47AC1A48.6050903@zip.com.au> Danny Mitchell wrote: > I'm running version 4.7p1 of OpenSSH on a Linux system (it was > originally a RedHat system, but I've changed almost everything.) When > I originally built OpenSSH I used the config option --without-pam, and > installed the software in /usr/local. I explicitly forbade root login > with sshd (by setting the PermitRootLogin to "no" in the sshd_config > file), but found that I could login as root. Examination of the code > revealed that PermitRootLogin is only dealt with in auth-pam.c, which > is surrounded by #ifdef USE_PAM/#endif. It is also checked in auth.c in auth_root_allowed(), which is used as a final check in auth1.c and auth2.c. > I rebuilt OpenSSH with the > --with-pam option enabled, installed, set PermitRootLogin to "no", and > restarted. It still permits root login. What configure options did you build with? Did you remember to use --sysconfdir option to tell it to use the same files as the vendor sshd (probably /etc/ssh)? By default, OpenSSH Portable uses config files in /usr/local/etc. -- 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 fishcustard at gmail.com Fri Feb 8 20:56:36 2008 From: fishcustard at gmail.com (Danny Mitchell) Date: Fri, 8 Feb 2008 20:56:36 +1100 Subject: "PermitRootLogin no" fails In-Reply-To: <47AC1A48.6050903@zip.com.au> References: <47AC1A48.6050903@zip.com.au> Message-ID: On 08/02/2008, Darren Tucker wrote: > Danny Mitchell wrote: >... > but found that I could login as root. Examination of the code > > revealed that PermitRootLogin is only dealt with in auth-pam.c, which > > is surrounded by #ifdef USE_PAM/#endif. > > It is also checked in auth.c in auth_root_allowed(), which is used as a > final check in auth1.c and auth2.c. You're right, of course. I'd missed that one. > > > I rebuilt OpenSSH with the > > --with-pam option enabled, installed, set PermitRootLogin to "no", and > > restarted. It still permits root login. > > What configure options did you build with? Did you remember to use > --sysconfdir option to tell it to use the same files as the vendor sshd > (probably /etc/ssh)? By default, OpenSSH Portable uses config files in > /usr/local/etc. > The configure line was ./configure --prefix=/usr/local --with-pam --with-ssl-dir=/usr/local/openssl-0.9.8g --with-md5-passwords (that's a cut-and-paste of the line; it's in the config log files.) I explicitly edited the sshd_config files in /usr/local/etc/ssh. I have confirmed that the newly-built version is the one that's running (it supports ssh2, and my clients use aes; the one the vendor shipped only supports ssh1, and doesn't support aes), and "strings /usr/local/sbin/sshd | grep sshd_config" returns /usr/local/etc/ssh/sshd_config. Thanks for taking the time to reply. Dannt Mitchell -- ----------------------------------------------------------------------------------------- Wocky | A poem for the lonely: hello. fishcustard at gmail.com | -- Spike Milligan ----------------------------------------------------------------------------------------- From dtucker at zip.com.au Fri Feb 8 22:11:26 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 8 Feb 2008 22:11:26 +1100 Subject: "PermitRootLogin no" fails In-Reply-To: References: <47AC1A48.6050903@zip.com.au> Message-ID: <20080208111126.GA32758@gate.dtucker.net> On Fri, Feb 08, 2008 at 08:56:36PM +1100, Danny Mitchell wrote: > On 08/02/2008, Darren Tucker wrote: [...] > The configure line was > ./configure --prefix=/usr/local --with-pam > --with-ssl-dir=/usr/local/openssl-0.9.8g --with-md5-passwords > (that's a cut-and-paste of the line; it's in the config log files.) > > I explicitly edited the sshd_config files in /usr/local/etc/ssh. I > have confirmed that the newly-built version is the one that's running > (it supports ssh2, and my clients use aes; the one the vendor shipped > only supports ssh1, and doesn't support aes), and "strings > /usr/local/sbin/sshd | grep sshd_config" returns > /usr/local/etc/ssh/sshd_config. The correct pathname is /usr/local/etc/sshd_config based on the configure flags above. If you want the files in /usr/local/etc/ssh you also need "--sysconfdir=/usr/local/etc/ssh". > Thanks for taking the time to reply. > Dannt Mitchell You're welcome. -- 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 JRM1 at ntrs.com Fri Feb 8 07:15:01 2008 From: JRM1 at ntrs.com (John R. Mull) Date: Thu, 7 Feb 2008 14:15:01 -0600 Subject: Question on openSSH and sending file to MVS file formats Message-ID: Hello, I was looking for Damien Miller, Markus Friedl or Theo de Raadt to possibly answer an SFTP question. I am having trouble locating an example and think the task can not be done. Do you have an example of an unix host machine initiating a file transfer to an ibm z/OS and create a mvs file? I have examples from appendix A of the IBM Ported Tools for z?OS Users Guide that shows how from IBM jcl initiated, I shell down using the !cp command to pull it in to z/OS unix, then sFTP to the external unix machine. That works ok. I can also run an IBM mvs job and pull a file from my Tokyo site and create a MVS file, but it is running the program on the IBM side. If my client's unix Sun box in Tokyo connects to my chicago ibm mainframe, what sFTP commands to I use to create a MVS file? This perhaps? put john_sftp_test.txt "//'TEST.JOHN.SFTP.TEXT'" quit Or perhaps I need to have a file watcher running on ibm z/Os unix to run a program to complete the transfer. Thank you for your assistance. Regards, John Mull Northern Trust Bank, Chicago From mouring at eviladmin.org Sat Feb 9 04:21:11 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 8 Feb 2008 11:21:11 -0600 (CST) Subject: [PATCH] Requiring multiple auth mechanisms (updated) In-Reply-To: References: <47A4DED9.1080606@swcp.com> Message-ID: Out of interest... do either of these patches allow for multiple authentications of the same method? e.g. Data Domain OS by default requires you to enter your password correctly twice (blindly of course) before you can log in. - Ben On Mon, 4 Feb 2008, Damien Miller wrote: > See also https://bugzilla.mindrot.org/show_bug.cgi?id=983 > > On Sat, 2 Feb 2008, paul wrote: > >> Jefferson Ogata's patch >> http://marc.info/?l=openssh-unix-dev&m=108134938701018&w=2 adds a multiple >> authentication methods option to sshd. I updated the patch to 4.7p1 and added >> logic to allow it to work with privilege separation. >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=1435 >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From dnsands at sandia.gov Sat Feb 9 07:28:05 2008 From: dnsands at sandia.gov (Daniel Sands) Date: Fri, 8 Feb 2008 13:28:05 -0700 Subject: AIX build issues Message-ID: <47ACBB55.5070307@sandia.gov> I have uncovered a couple of issues building OpenSSH on an AIX platform. 1) blibpath does not include the location of the SSL library. This is fine if linking to /usr/lib/libcrypto.a, but not if linking to a local install of OpenSSL. Due to problems of collisions (even in /usr/local), I had to place Kerberos and OpenSSL within their own subdirs of /usr/local (/usr/local/openssl and /usr/local/krb5). So the libcrypto.a from openssl is not found when I try to run sshd. 2) blibpath places /usr/lib and /lib first. It is actually advised according to a page I read on IBM's site not to include these at all. But certainly not before the other paths such as the location of Kerberos and OpenSSL. 3) This blibpath should be placed last in the list. Since the config script calls krb5-config, and krb5-config returns a link line that includes its own blibpath setting, this actually ends up overriding the one constructed by the configure script. From stuge-openssh-unix-dev at cdy.org Sun Feb 10 04:02:22 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 9 Feb 2008 18:02:22 +0100 Subject: Question on openSSH and sending file to MVS file formats In-Reply-To: References: Message-ID: <20080209170222.12538.qmail@cdy.org> Hi John, On Thu, Feb 07, 2008 at 02:15:01PM -0600, John R. Mull wrote: > Do you have an example of an unix host machine initiating a file > transfer to an ibm z/OS and create a mvs file? I'm afraid the only ones who can help with this would be those who know how the implementation on z/OS was done. I guess that is IBM. > I have examples from appendix A of the IBM Ported Tools for z?OS > Users Guide that shows how from IBM jcl initiated, I shell down > using the !cp command to pull it in to z/OS unix, then sFTP to the > external unix machine. That works ok. I can also run an IBM mvs > job and pull a file from my Tokyo site and create a MVS file, but > it is running the program on the IBM side. > > If my client's unix Sun box in Tokyo connects to my chicago ibm > mainframe, what sFTP commands to I use to create a MVS file? I suggest starting with trying to downloading files from your IBM machine, even though this is not what you ultimately want to do. It might provide more helpful error messages or hints that will help understanding the required filename syntax. Oh, and are you absolutely sure that the IBM machine actually is able to act as an SFTP server? This may not be the case. > This perhaps? > > put john_sftp_test.txt "//'TEST.JOHN.SFTP.TEXT'" > quit Does this work? Then you're all set. > Or perhaps I need to have a file watcher running on ibm z/Os unix > to run a program to complete the transfer. One option is certainly to always initiate the transfer from the IBM machine, since you've found a working method for that. You would have to set up a staging server which both tokyoclient and youribm can log in to via SFTP. It could run some common Linux or other well-known system. Hope this helps. //Peter From jan.iven at cern.ch Mon Feb 11 19:58:48 2008 From: jan.iven at cern.ch (Jan Iven) Date: Mon, 11 Feb 2008 09:58:48 +0100 Subject: [Fwd: Some interesting hashes] Message-ID: <47B00E48.5070801@cern.ch> Would somebody perhaps have some background on these tar files with such interesting names? To my understanding, OpenBSD=4.1 == OpenSSHD-4.6. Of course, this could just be a prank. Google knows about the mail address this (presumably) came from since about mid-2007, so it apparently has not been created just for the occasion.. Thanks in advance Jan -------------- next part -------------- An embedded message was scrubbed... From: "Open Phugu" Subject: Some interesting hashes Date: Fri, 8 Feb 2008 19:03:11 -0700 Size: 3394 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080211/8924903b/attachment-0001.mht From djm at mindrot.org Mon Feb 11 21:04:33 2008 From: djm at mindrot.org (Damien Miller) Date: Mon, 11 Feb 2008 21:04:33 +1100 (EST) Subject: [PATCH] Requiring multiple auth mechanisms (updated) In-Reply-To: References: <47A4DED9.1080606@swcp.com> Message-ID: On Fri, 8 Feb 2008, Ben Lindstrom wrote: > > Out of interest... do either of these patches allow for multiple > authentications of the same method? Mine doesn't out of the box, but I guess it could be made to. -d From djm at mindrot.org Wed Feb 13 10:29:42 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Feb 2008 10:29:42 +1100 (EST) Subject: [Fwd: Some interesting hashes] In-Reply-To: <47B00E48.5070801@cern.ch> References: <47B00E48.5070801@cern.ch> Message-ID: On Mon, 11 Feb 2008, Jan Iven wrote: > Would somebody perhaps have some background on these tar files with such > interesting names? To my understanding, OpenBSD=4.1 == OpenSSHD-4.6. > > Of course, this could just be a prank. Google knows about the mail address > this (presumably) came from since about mid-2007, so it apparently has not > been created just for the occasion.. I am aware of no evidence that this is anything more than a troll. -d From curruscataphractus at gmail.com Thu Feb 14 05:34:32 2008 From: curruscataphractus at gmail.com (Jorge Abrines) Date: Wed, 13 Feb 2008 19:34:32 +0100 Subject: Openssh + x509 patch problem Message-ID: <47B33838.5030907@gmail.com> Hi all, I'm trying to install ssh server based on x509 certificates with no result. What I've done is the following: - Build openssh4.7p1 after patching with openssh-4.7p1+x509-6.1.diff.gz without error using ./configure --prefix=/opt/ssh && make && make install in both server and client machines - Create minimal openssl ca structure under /opt/ssh/etc/ca ( self signed CA certificate, server certificate signed by CA, client certificate signed by CA ). I now have certificates cacert.pem, server.pem and client.pem and keys for all three - Build server host id using (under /opt/ssh/etc): cat server-key.pem > ssh_host_key_cert cat server.pem >> ssh_host_key_cert chmod 0600 ssh_host_key_cert ../bin/ssh-keygen -y > ssh_host_key_cert.pub // entering ssh_host_key_cert as key - Changing /opt/ssh/etc/sshd_config: CACertificateFile /opt/ssh/etc/ca/crt/cacert.pem Port 4422 X509KeyAlgorithm x509v3-sign-rsa,rsa-md5 X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1 AllowedCertPurpose sslclient PasswordAuthentication no - Customizing server user configuration cat /opt/ssh/etc/ssh_host_key_cert.pub > .ssh/authorized_keys - Now __On client machine__ (after copying, client.pem, client-key.pem and cacert.pem) - Build identity - cat ~/.ssh/client-key.pem > /.ssh/id_rsa - cat ~/.ssh/client.pem >> ~/.ssh/id_rsa - chmod 0600 ~/.ssh/id_rsa - /opt/ssh/bin/ssh-keygen -y > ~/.ssh/id_rsa.pub // entering ~/.ssh/id_rsa as key - Introducing following changes into /opt/ssh/etc/ssh_config Port 4422 IdentityFile ~/.ssh/id_rsa UserCACertificateFile ~/.ssh/cacert.pem UserCACertificatePath ~/.ssh/crt UserCARevocationFile ~/.ssh/ca-bundle.crl UserCARevocationPath ~/.ssh/crl Finally lauching sshd on server with command: /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config -d -d -d And client with: /opt/ssh/bin/ssh-agent /opt/ssh/bin/ssh-add /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config -d -d -d \ myuser at myserver Which output is: The authenticity of host '[myserver]:4422 ([192.168.0.201]:4422)' can't be established. RSA+cert key fingerprint is 4c:3a:1b:2d:40:23:1d:99:aa:d2:eb:b3:28:8c:d2:d4. Distinguished name is 'C=ES,ST=Madrid,O=blub,CN=Server'. Are you sure you want to continue connecting (yes/no)? yes But I get 'Permission denied (publickey,keyboard-interactive)' error. I've sshd and ssh outputs but are quite long, I'll append them if above configuration seems ok. Many thanks in advance. Best regards, Jorge From openssh at roumenpetrov.info Thu Feb 14 07:01:11 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 13 Feb 2008 22:01:11 +0200 Subject: Openssh + x509 patch problem In-Reply-To: <47B33838.5030907@gmail.com> References: <47B33838.5030907@gmail.com> Message-ID: <47B34C87.2000300@roumenpetrov.info> Jorge Abrines wrote: > Hi all, > > I'm trying to install ssh server based on x509 certificates with no > result. What I've done is the following: > - Build openssh4.7p1 after patching with openssh-4.7p1+x509-6.1.diff.gz > without error using ./configure --prefix=/opt/ssh && make && make > install in both server and client machines > > - Create minimal openssl ca structure under /opt/ssh/etc/ca > ( self signed CA certificate, server certificate signed by CA, > client certificate signed by CA ). > I now have certificates cacert.pem, server.pem and client.pem and > keys for all three > > - Build server host id using (under /opt/ssh/etc): > cat server-key.pem > ssh_host_key_cert > cat server.pem >> ssh_host_key_cert > chmod 0600 ssh_host_key_cert > ../bin/ssh-keygen -y > ssh_host_key_cert.pub > // entering ssh_host_key_cert as key > i.e. HostKey /opt/ssh/etc/ssh_host_key_cert is in sshd_config ? > - Changing /opt/ssh/etc/sshd_config: > CACertificateFile /opt/ssh/etc/ca/crt/cacert.pem > Port 4422 > X509KeyAlgorithm x509v3-sign-rsa,rsa-md5 > X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1 > AllowedCertPurpose sslclient > PasswordAuthentication no > Fine but I assume that rest is left to default. > - Customizing server user configuration > > cat /opt/ssh/etc/ssh_host_key_cert.pub > .ssh/authorized_keys > Why ? Append client public part in authorized keys. > - Now __On client machine__ (after copying, client.pem, client-key.pem > and cacert.pem) > > - Build identity > - cat ~/.ssh/client-key.pem > /.ssh/id_rsa > - cat ~/.ssh/client.pem >> ~/.ssh/id_rsa > - chmod 0600 ~/.ssh/id_rsa > - /opt/ssh/bin/ssh-keygen -y > ~/.ssh/id_rsa.pub > // entering ~/.ssh/id_rsa as key > Copy id_rsa.pub to server and append to authorized keys file. > - Introducing following changes into /opt/ssh/etc/ssh_config > Port 4422 > IdentityFile ~/.ssh/id_rsa > UserCACertificateFile ~/.ssh/cacert.pem > UserCACertificatePath ~/.ssh/crt > UserCARevocationFile ~/.ssh/ca-bundle.crl > UserCARevocationPath ~/.ssh/crl > > > Finally lauching sshd on server with > command: > > /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config -d -d -d > > And client with: > /opt/ssh/bin/ssh-agent > /opt/ssh/bin/ssh-add > /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config -d -d -d \ > myuser at myserver > > Which output is: > > The authenticity of host '[myserver]:4422 ([192.168.0.201]:4422)' can't > be established. > RSA+cert key fingerprint is > 4c:3a:1b:2d:40:23:1d:99:aa:d2:eb:b3:28:8c:d2:d4. > Distinguished name is 'C=ES,ST=Madrid,O=blub,CN=Server'. > Are you sure you want to continue connecting (yes/no)? yes > > But I get 'Permission denied (publickey,keyboard-interactive)' error. > I've sshd and ssh outputs but are quite long, I'll append them if > above configuration seems ok. > > Many thanks in advance. > > Best regards, > > Jorge > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From mcgarr at umich.edu Thu Feb 14 06:33:49 2008 From: mcgarr at umich.edu (Mike Garrison) Date: Wed, 13 Feb 2008 14:33:49 -0500 Subject: sftp-server rename and handling of EXDEV Message-ID: <4E28F55A-82D9-4D63-84C2-5329F6B4E2AB@umich.edu> Greetings, One of the complaints we've commonly gotten from users is that modern versions of OpenSSH do not allow users to rename files in AFS across directories. Since OpenAFS only allows hardlinks in the parent directory, you can rename in the same directory but not across directory boundaries. This is the same behavior when you try to rename across regular partition boundaries, as a hardlink will fail. I understand that renaming was changed a while back so it would not be racy, but is there any reason it shouldn't fall back to a racy rename if EXDEV is returned? I know currently that if LINK_OPNOTSUPP_ERRNO is returned, we'll try a racy rename. Can this be extended to conditions where EXDEV is returned? -- Mike Garrison From curruscataphractus at gmail.com Thu Feb 14 20:21:19 2008 From: curruscataphractus at gmail.com (Jorge Abrines) Date: Thu, 14 Feb 2008 10:21:19 +0100 Subject: Openssh + x509 patch problem In-Reply-To: <47B34C87.2000300@roumenpetrov.info> References: <47B33838.5030907@gmail.com> <47B34C87.2000300@roumenpetrov.info> Message-ID: <47B4080F.4010409@gmail.com> Hi Roumen, Many thanks for your fast answer. I've checked your suggestions (HostKey was on sshd_config, finally) and only changed authorized_keys to contain client id_rsa.pub and it worked!!. Don't know what I was doing wrong, I'll try to build things again to see what went wrong (I'll bet authorized_keys stuff). Thank you very much again. Best regards, Jorge Roumen Petrov wrote: > Jorge Abrines wrote: >> Hi all, >> >> I'm trying to install ssh server based on x509 certificates with no >> result. What I've done is the following: >> - Build openssh4.7p1 after patching with >> openssh-4.7p1+x509-6.1.diff.gz without error using ./configure >> --prefix=/opt/ssh && make && make install in both server and client >> machines >> >> - Create minimal openssl ca structure under /opt/ssh/etc/ca >> ( self signed CA certificate, server certificate signed by CA, >> client certificate signed by CA ). >> I now have certificates cacert.pem, server.pem and client.pem and >> keys for all three >> >> - Build server host id using (under /opt/ssh/etc): >> cat server-key.pem > ssh_host_key_cert >> cat server.pem >> ssh_host_key_cert >> chmod 0600 ssh_host_key_cert >> ../bin/ssh-keygen -y > ssh_host_key_cert.pub >> // entering ssh_host_key_cert as key >> > i.e. HostKey /opt/ssh/etc/ssh_host_key_cert is in sshd_config ? > >> - Changing /opt/ssh/etc/sshd_config: >> CACertificateFile /opt/ssh/etc/ca/crt/cacert.pem >> Port 4422 >> X509KeyAlgorithm x509v3-sign-rsa,rsa-md5 >> X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1 >> AllowedCertPurpose sslclient >> PasswordAuthentication no >> > Fine but I assume that rest is left to default. > >> - Customizing server user configuration >> >> cat /opt/ssh/etc/ssh_host_key_cert.pub > .ssh/authorized_keys >> > Why ? > Append client public part in authorized keys. >> - Now __On client machine__ (after copying, client.pem, client-key.pem >> and cacert.pem) >> >> - Build identity >> - cat ~/.ssh/client-key.pem > /.ssh/id_rsa >> - cat ~/.ssh/client.pem >> ~/.ssh/id_rsa >> - chmod 0600 ~/.ssh/id_rsa >> - /opt/ssh/bin/ssh-keygen -y > ~/.ssh/id_rsa.pub >> // entering ~/.ssh/id_rsa as key >> > > Copy id_rsa.pub to server and append to authorized keys file. > >> - Introducing following changes into /opt/ssh/etc/ssh_config >> Port 4422 >> IdentityFile ~/.ssh/id_rsa >> UserCACertificateFile ~/.ssh/cacert.pem >> UserCACertificatePath ~/.ssh/crt >> UserCARevocationFile ~/.ssh/ca-bundle.crl >> UserCARevocationPath ~/.ssh/crl >> >> >> Finally lauching sshd on server with >> command: >> >> /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config -d -d -d >> >> And client with: >> /opt/ssh/bin/ssh-agent >> /opt/ssh/bin/ssh-add >> /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config -d -d -d \ >> myuser at myserver >> >> Which output is: >> >> The authenticity of host '[myserver]:4422 ([192.168.0.201]:4422)' >> can't be established. >> RSA+cert key fingerprint is >> 4c:3a:1b:2d:40:23:1d:99:aa:d2:eb:b3:28:8c:d2:d4. >> Distinguished name is 'C=ES,ST=Madrid,O=blub,CN=Server'. >> Are you sure you want to continue connecting (yes/no)? yes >> >> But I get 'Permission denied (publickey,keyboard-interactive)' error. >> I've sshd and ssh outputs but are quite long, I'll append them if >> above configuration seems ok. >> >> Many thanks in advance. >> >> Best regards, >> >> Jorge >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> > > > Roumen > From sampark_sj at yahoo.com Fri Feb 15 04:28:55 2008 From: sampark_sj at yahoo.com (Sam Park) Date: Thu, 14 Feb 2008 09:28:55 -0800 (PST) Subject: ssh_exchange_identification: Connection closed by remote host Message-ID: <199151.42464.qm@web34813.mail.mud.yahoo.com> Hi, I'm getting this error when I ssh to the servers. ssh_exchange_identification: Connection closed by remote host I added /etc/hosts.allow and it actually worked once and if I tried again I get the same error. OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug2: ssh_connect: needpriv 0 debug1: Connection established. debug1: identity file /username/.ssh/identity type -1 debug1: identity file /username/.ssh/id_rsa type -1 debug1: identity file /username/.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host debug1: Calling cleanup 0x2cc60(0x0) I look forward to your response. Thanks --------------------------------- Never miss a thing. Make Yahoo your homepage. From tim at multitalents.net Fri Feb 15 06:54:33 2008 From: tim at multitalents.net (Tim Rice) Date: Thu, 14 Feb 2008 11:54:33 -0800 (PST) Subject: ssh_exchange_identification: Connection closed by remote host In-Reply-To: <199151.42464.qm@web34813.mail.mud.yahoo.com> References: <199151.42464.qm@web34813.mail.mud.yahoo.com> Message-ID: On Thu, 14 Feb 2008, Sam Park wrote: > Hi, > > I'm getting this error when I ssh to the servers. > ssh_exchange_identification: Connection closed by remote host > > I added /etc/hosts.allow and it actually worked once and if I tried again I get the same error. You did not mention whether you added by name or by IP. Every time I've seen this error it has been a DNS problem. And I only see this on systems that are in hosts.allow by name. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From joes at theworld.com Sun Feb 10 02:54:15 2008 From: joes at theworld.com (joes at theworld.com) Date: Sat, 9 Feb 2008 10:54:15 -0500 (EST) Subject: Problems connecting with SSH2 Message-ID: <200802091554.m19FsFb00505@pooh.home.bogus> Hello, I've been using OpenSSH 3.6.1p2 for quite some time at work. We have a firewall, and I had no problems connecting to external machines. Today my machine was updated to version 4.1p1 and it has a problem. When I try to make an SSH2 connection to an external machine, everything seems to work right up to the very end: debug1: Authentication succeeded (publickey) debug1: channel 0: new [client-session] debug1: Entering interactive session. Received disconnect from 192.74.137.71: 2: Invalid ssh2 packet type: 192 I did some investigation and see that an "invalid packet check" was added to packet.c a few years ago, sometime between versions 3.6 and 3.9. But I have no idea why this now causing problems or how to diagnose it. Can anyone help me understand what this means and how to fix it? Thanks. From joes at TheWorld.com Fri Feb 15 13:11:55 2008 From: joes at TheWorld.com (Joe Smulowicz) Date: Thu, 14 Feb 2008 21:11:55 -0500 (EST) Subject: invalid packet type ? Message-ID: <200802150211.m1F2Btm32414072@shell01.TheWorld.com> Hello, I've been using OpenSSH 3.6.1p2 for quite some time at work. We have a firewall, and I had no problems connecting to external machines. Today my machine was updated to version 4.1p1 and it has a problem. When I try to make an SSH2 connection to an external machine, everything seems to work right up to the very end: debug1: Authentication succeeded (publickey) debug1: channel 0: new [client-session] debug1: Entering interactive session. Received disconnect from 192.74.137.71: 2: Invalid ssh2 packet type: 192 I did some investigation and see that an "invalid packet check" was added to packet.c a few years ago, sometime between versions 3.6 and 3.9. But I have no idea why this now causing problems or how to diagnose it. Can anyone help me understand what this means and how to fix it? Thanks. From stuge-openssh-unix-dev at cdy.org Fri Feb 15 13:23:19 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 15 Feb 2008 03:23:19 +0100 Subject: Problems connecting with SSH2 In-Reply-To: <200802091554.m19FsFb00505@pooh.home.bogus> References: <200802091554.m19FsFb00505@pooh.home.bogus> Message-ID: <20080215022319.22898.qmail@cdy.org> Hi, On Sat, Feb 09, 2008 at 10:54:15AM -0500, joes at theworld.com wrote: > Today my machine was updated to version 4.1p1 and it has a problem. > When I try to make an SSH2 connection to an external machine, > everything seems to work right up to the very end: > > Received disconnect from 192.74.137.71: 2: Invalid ssh2 packet type: 192 This is a local packet type introduced by the remote sshd for some private use. (Like 192.168.x.y IP addresses.) OpenSSH doesn't like these. Maybe it should simply ignore packet types between SSH2_MSG_LOCAL_MIN and SSH2_MSG_LOCAL_MAX, rather than disconnect? //Peter From stuge-openssh-unix-dev at cdy.org Fri Feb 15 13:57:59 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 15 Feb 2008 03:57:59 +0100 Subject: Problems connecting with SSH2 In-Reply-To: <20080215022319.22898.qmail@cdy.org> References: <200802091554.m19FsFb00505@pooh.home.bogus> <20080215022319.22898.qmail@cdy.org> Message-ID: <20080215025800.30762.qmail@cdy.org> On Fri, Feb 15, 2008 at 03:23:19AM +0100, Peter Stuge wrote: > OpenSSH doesn't like these. Maybe it should simply ignore packet > types between SSH2_MSG_LOCAL_MIN and SSH2_MSG_LOCAL_MAX, rather > than disconnect? Joe, here is a patch you could try. Written dry with no testing, so it may well break the communication in a different way. I am not sure if we need to consume the remaining bytes in the packet, or not. If not, this patch should work. I think not, since IGNORE packets can contain extra data and packet.c currently does not deal with that. Clever packet handling could just discard whatever is not consumed when the next packet is read. //Peter -------------- next part -------------- --- packet.c.orig 2007-06-11 06:01:42.000000000 +0200 +++ packet.c 2008-02-15 03:56:36.000000000 +0100 @@ -1167,8 +1167,10 @@ * return length of payload (without type field) */ type = buffer_get_char(&incoming_packet); - if (type < SSH2_MSG_MIN || type >= SSH2_MSG_LOCAL_MIN) + if (type < SSH2_MSG_MIN) packet_disconnect("Invalid ssh2 packet type: %d", type); + else if (type >= SSH2_MSG_LOCAL_MIN && type <= SSH2_MSG_LOCAL_MAX) + type = SSH2_MSG_IGNORE; if (type == SSH2_MSG_NEWKEYS) set_newkeys(MODE_IN); else if (type == SSH2_MSG_USERAUTH_SUCCESS && !server_side) From maf at appgate.com Fri Feb 15 17:55:42 2008 From: maf at appgate.com (maf at appgate.com) Date: Fri, 15 Feb 2008 07:55:42 +0100 (CET) Subject: ssh_exchange_identification: Connection closed by remote host In-Reply-To: References: <199151.42464.qm@web34813.mail.mud.yahoo.com> Message-ID: In my experience this error is typically really a network problem. Try doing manual telnet to port 22 on the server. This should show you the server ssh version (i.e. the initial identification) like "SSH-2.0-OpenSSH_4.3p2 Debian-7ubuntu1" If it does not then there is your problem. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From mh+openssh-unix-dev at zugschlus.de Fri Feb 15 18:23:22 2008 From: mh+openssh-unix-dev at zugschlus.de (Marc Haber) Date: Fri, 15 Feb 2008 08:23:22 +0100 Subject: ssh_exchange_identification: Connection closed by remote host In-Reply-To: <199151.42464.qm@web34813.mail.mud.yahoo.com> References: <199151.42464.qm@web34813.mail.mud.yahoo.com> Message-ID: <20080215072322.GA18371@torres.zugschlus.de> On Thu, Feb 14, 2008 at 09:28:55AM -0800, Sam Park wrote: > I'm getting this error when I ssh to the servers. > ssh_exchange_identification: Connection closed by remote host > > I added /etc/hosts.allow and it actually worked once and if I tried again I get the same error. What did you add to /etc/hosts.allow, and what do your logs say? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From Laatsch at uni-koeln.de Sat Feb 16 02:17:41 2008 From: Laatsch at uni-koeln.de (Rainer Laatsch) Date: Fri, 15 Feb 2008 16:17:41 +0100 (MET) Subject: Protocol 2 AfsTokenPassing Message-ID: Possibly someone might be interested in Protocol 2 AfsTokenPassing. Best regards Rainer Laatsch ________________________________ ______________________ E-mail: Laatsch at Uni-Koeln.DE Universitaet zu Koeln Reg. Rechenzentrum (ZAIK/RRZK) Fax : (0221) 478-5590 Robert-Koch-Str. 10 Tel : (0221) 478-5582 D-50931 Koeln == README.openssh-4.7p1+AFS == Patches to enhance openssh-4.7p1 for AFS token and KRB5 ticket passing in protocol 2 can be found in /afs/rrz.uni-koeln.de/admin/public/openssh-4.7p1-PatchDir/ These also allow AFS token passing in protocol 1 for backward compatibily. From vinschen at redhat.com Mon Feb 18 22:55:54 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 18 Feb 2008 12:55:54 +0100 Subject: [PATCH] Build problem in current portable CVS Message-ID: <20080218115554.GA30219@calimero.vinschen.de> Hi, I just tried to build the latest portable code from CVS on Cygwin. I stumbled over a problem with the definitions of gai_strerror and ssh_gai_strerror. On systems not having gai_strerror, the fake-rfc2553.c file defines its own version of gai_strerror, and fake-rfc2553.h additionally has this definition of gai_strerror: #define gai_strerror(a) (ssh_gai_strerror(a)) OTOH, misc.c defines the function ssh_gai_strerror unconditionally, and ssh_gai_strerror is used throughout the ssh sources. Since the ssh_gai_strerror implementation in misc.c special cases EAI_SYSTEM, and since it calls gai_strerror, the above define appears to be wrong. Patch below. Thanks, Corinna Index: openbsd-compat/fake-rfc2553.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/fake-rfc2553.h,v retrieving revision 1.13 diff -p -u -r1.13 fake-rfc2553.h --- openbsd-compat/fake-rfc2553.h 24 Jul 2006 03:51:52 -0000 1.13 +++ openbsd-compat/fake-rfc2553.h 18 Feb 2008 11:44:01 -0000 @@ -152,7 +152,6 @@ int getaddrinfo(const char *, const char #endif /* !HAVE_GETADDRINFO */ #if !defined(HAVE_GAI_STRERROR) && !defined(HAVE_CONST_GAI_STRERROR_PROTO) -#define gai_strerror(a) (ssh_gai_strerror(a)) char *gai_strerror(int); #endif /* !HAVE_GAI_STRERROR */ -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Tue Feb 19 05:10:49 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 18 Feb 2008 19:10:49 +0100 Subject: [PATCH] Make sure /var/empty dir really exists Message-ID: <20080218181049.GF30886@calimero.vinschen.de> Hi, could somebody please be so kind to apply the below patch to the Cygwin specific file contrib/cygwin/ssh-host-config? It checks more thorough that it's possible to create the /var/empty directory. It also fixes bad English. Thanks, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.20 diff -p -u -r1.20 ssh-host-config --- contrib/cygwin/ssh-host-config 31 Aug 2006 01:28:49 -0000 1.20 +++ contrib/cygwin/ssh-host-config 18 Feb 2008 18:07:28 -0000 @@ -131,7 +131,7 @@ fi if [ -e "${SYSCONFDIR}" -a ! -d "${SYSCONFDIR}" ] then echo - echo "${SYSCONFDIR} is existant but not a directory." + echo "${SYSCONFDIR} exists but is not a directory." echo "Cannot create global configuration files." echo exit 1 @@ -156,7 +156,7 @@ fi if [ -e ${LOCALSTATEDIR}/log -a ! -d ${LOCALSTATEDIR}/log ] then echo - echo "${LOCALSTATEDIR}/log is existant but not a directory." + echo "${LOCALSTATEDIR}/log exists but is not a directory." echo "Cannot create ssh host configuration." echo exit 1 @@ -181,11 +181,23 @@ then fi # Create /var/empty file used as chroot jail for privilege separation -if [ -f ${LOCALSTATEDIR}/empty ] +if [ -e ${LOCALSTATEDIR}/empty -a ! -d ${LOCALSTATEDIR}/empty ] then - echo "Creating ${LOCALSTATEDIR}/empty failed!" -else - mkdir -p ${LOCALSTATEDIR}/empty + echo + echo "${LOCALSTATEDIR}/empty exists but is not a directory." + echo "Cannot create ssh host configuration." + echo + exit 1 +if [ ! -e ${LOCALSTATEDIR}/empty ] +then + if ! mkdir -p ${LOCALSTATEDIR}/empty + then + echo + echo "Creating ${LOCALSTATEDIR}/empty directory failed." + echo "Cannot create ssh host configuration." + echo + exit 1 + fi if [ ${_nt} -gt 0 ] then chmod 755 ${LOCALSTATEDIR}/empty -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From jhay at meraka.org.za Wed Feb 20 20:31:42 2008 From: jhay at meraka.org.za (John Hay) Date: Wed, 20 Feb 2008 11:31:42 +0200 Subject: alignment problem in monitor_fdpass.c Message-ID: <20080220093142.GA78543@zibbi.meraka.csir.co.za> Hi, After FreeBSD changed from using -O2 to using -O on their ARM port, I found that sshd stopped working. (gcc version 4.2.1 20070719 [FreeBSD]) I have downloaded openssh-SNAP-20080220.tar.gz and the code still look the same. Anyway looking into it, I found that the problem is in monitor_fdpass.c in the functions mm_send_fd and mm_receive_fd. Using -O2 used to align the tmp array on a 4 byte boundary and using -O does not. On architectures that do not like unaligned accesses this will break. An extraction of mm_send_fd() look something like this: ############################## struct msghdr msg; char tmp[CMSG_SPACE(sizeof(int))]; struct cmsghdr *cmsg; msg.msg_control = (caddr_t)tmp; cmsg = CMSG_FIRSTHDR(&msg); cmsg->cmsg_len = CMSG_LEN(sizeof(int)); ############################## The bus error happens on the last line when a value is written into cmsg_len. In effect it does: cmsg = tmp; cmsg->cmsg_len = CMSG_LEN(sizeof(int)); So if tmp is not aligned, then cmsg is not and cmsg_len is of type socklen_t (at least on FreeBSD) and right at the start of the structure. So which way is the best to fix it? One way is to add __aligned(4) to the line where tmp is declared. Another is to put tmp and cmsg in an union, which will also cause it to be aligned. (I'm not on this list, so keep my address in please.) John -- John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org From sankalp_karpe at persistent.co.in Wed Feb 20 21:32:44 2008 From: sankalp_karpe at persistent.co.in (sankalp_karpe) Date: Wed, 20 Feb 2008 16:02:44 +0530 Subject: OpenSSH and X.509 Certificate Support Message-ID: <47BC01CC.60409@persistent.co.in> Hi, I need to add X.509 Certificate support to OpenSSH. I came across the following post on the openssh-unix-dev mailing list that is very useful: http://marc.info/?l=openssh-unix-dev&m=120298135706959&w=2 And also, http://marc.info/?l=openssh-unix-dev&m=104395024824680&w=2 that provides the required patches to dowload for OpenSSH to support X.509 certificates. I am using FC6 and have followed the steps mentioned in the above post, but I am unable to successfully complete the task :( Is there any step-by-step procedure that I could refer to to achieve the same? Thanks and Regards, Sankalp From jmknoble at pobox.com Thu Feb 21 04:09:29 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 20 Feb 2008 12:09:29 -0500 Subject: alignment problem in monitor_fdpass.c In-Reply-To: <20080220093142.GA78543@zibbi.meraka.csir.co.za> References: <20080220093142.GA78543@zibbi.meraka.csir.co.za> Message-ID: <20080220170929.GN20010@crawfish.ais.com> Circa 2008-02-20 04:31 dixit John Hay: : After FreeBSD changed from using -O2 to using -O on their ARM port, I : found that sshd stopped working. (gcc version 4.2.1 20070719 [FreeBSD]) : I have downloaded openssh-SNAP-20080220.tar.gz and the code still look : the same. : : Anyway looking into it, I found that the problem is in monitor_fdpass.c : in the functions mm_send_fd and mm_receive_fd. Using -O2 used to align : the tmp array on a 4 byte boundary and using -O does not. On : architectures that do not like unaligned accesses this will break. It's best to file a bug report about this at the OpenSSH bug tracker: http://www.openssh.com/report.html The developers are more likely to see it (and not to lose track of it). -- 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 openssh at roumenpetrov.info Thu Feb 21 06:47:23 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 20 Feb 2008 21:47:23 +0200 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47BC01CC.60409@persistent.co.in> References: <47BC01CC.60409@persistent.co.in> Message-ID: <47BC83CB.3080007@roumenpetrov.info> sankalp_karpe wrote: > Hi, > > I need to add X.509 Certificate support to OpenSSH. > > I came across the following post on the openssh-unix-dev mailing list > that is very useful: > http://marc.info/?l=openssh-unix-dev&m=120298135706959&w=2 > > > And also, http://marc.info/?l=openssh-unix-dev&m=104395024824680&w=2 > that > provides the required patches to dowload for OpenSSH to support X.509 > certificates. > > I am using FC6 and have followed the steps mentioned in the above post, > but I am unable to successfully complete the task :( > Is there any step-by-step procedure that I could refer to to achieve the > same? > > Thanks and Regards, > Sankalp > Please, could you clarify "successfully complete the task". RedHat OpenSSH sources are heavy patched and chance patch to be applied without problem is zero. References: - README.x509v3 for specified version http://roumenpetrov.info/openssh/download.html - http://roumenpetrov.info/domino_CA/ Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From dylan at dylex.net Thu Feb 21 14:00:19 2008 From: dylan at dylex.net (Dylan Alex Simon) Date: Wed, 20 Feb 2008 22:00:19 -0500 Subject: LocalCommand and control master/sshfs Message-ID: <20080221030019.GA4284@datura.dylex.net> I've run into a couple cases where it would be nice to use LocalCommand to run something to setup a session in some way when using ControlMaster. For example, to scp something or do an sshfs mount automatically once your session is established using the control socket. However, in 4.7, LocalCommand is run before ssh_control_listener. It's not terribly hard to work around (fork and sleep first in the command), but is there some reason these couldn't be swapped? (I see some discussion about LocalCommand and tunneling from last year which wanted to move it earlier, but it doesn't seem this was done.) :-Dylan From sankalp_karpe at persistent.co.in Thu Feb 21 23:43:10 2008 From: sankalp_karpe at persistent.co.in (sankalp_karpe) Date: Thu, 21 Feb 2008 18:13:10 +0530 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47BC83CB.3080007@roumenpetrov.info> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> Message-ID: <47BD71DE.3050002@persistent.co.in> Hi Roumen, I could successfully add X.509 Certificate support to OpenSSH. Earlier, the error I was facing was with "ssh-add": unable to open a connection to your authentication agent. I found some help on "http://funkaoshi.com/blog/could-not-open-a-connection-to-your-authentication-agent" with which I could resolve the same. Here is the entire step by step procedure that I followed to add X.509 certificate support to OpenSSH (implemented for "root" login on both the machines) Could you please confirm and suggest changes required if any. (1) Download OpenSSH-4.7p1 from: http://openbsd.md5.com.ar/pub/OpenBSD/OpenSSH/portable/ (2) Download x.509 patch for this version from: http://roumenpetrov.info/openssh/download.html (3) Patch the OpenSSH source with this patch and install it on both Server and Client machines (./configure --prefix=/opt/ssh && make && make install) Now on the Server machine perform the following: (4) Gnereate the ca, server, client certificates using the following procedure: mkdir certs && cd certs CA certificate generation openssl genrsa -out ca-key.pem 2048 openssl req -new -x509 -nodes -days 50000 -key ca-key.pem -out cacert.pem Answer questions with appropriate data. Openssl commands generate a 2048 bit key and a certificate valid for a fifty thousand day period. Server certificate generation openssl req -newkey rsa:2048 -days 50000 -nodes -keyout server-key.pem -out server-req.pem openssl x509 -req -in server-req.pem -days 50000 -CA cacert.pem -CAkey ca-key.pem -set_serial 01 -out server.pem Client certificate generation openssl req -newkey rsa:2048 -days 50000 -nodes -keyout client-key.pem -out client-req.pem openssl x509 -req -in client-req.pem -days 50000 -CA cacert.pem -CAkey ca-key.pem -set_serial 01 -out client.pem (5) Copy the generated certificates under /opt/ssh/etc/ca (6) Build server host id using (cd to /opt/ssh/etc): cat ca/server-key.pem > ssh_host_key_cert cat ca/server.pem >> ssh_host_key_cert chmod 0600 ssh_host_key_cert ../bin/ssh-keygen -y > ssh_host_key_cert.pub // entering 'ssh_host_key_cert' as key when prompted (7) Add the following directives in /opt/ssh/etc/sshd_config HostKey /opt/ssh/etc/ssh_host_key_cert CACertificateFile /opt/ssh/etc/ca/crt/cacert.pem Port 22 X509KeyAlgorithm x509v3-sign-rsa,rsa-md5 X509KeyAlgorithm x509v3-sign-rsa,rsa-sha1 AllowedCertPurpose sslclient PasswordAuthentication no Now on client machine perform the following: (8) under /root/.ssh/, copy client.pem, client-key.pem and cacert.pem from the Server Build identity, As root, execute the following commands: cat ~/.ssh/client-key.pem > ~/.ssh/id_rsa cat ~/.ssh/client.pem >> ~/.ssh/id_rsa chmod 0600 ~/.ssh/id_rsa /opt/ssh/bin/ssh-keygen -y > ~/.ssh/id_rsa.pub // entering ~/.ssh/id_rsa as key when prompted (9) Introduce following changes in /opt/ssh/etc/ssh_config: Port 22 IdentityFile ~/.ssh/id_rsa UserCACertificateFile ~/.ssh/cacert.pem (10) Copy /root/.ssh/id_rsa.pub from the Client to the Server (/root/) and append to authorized keys file. cat /root/id_rsa.pub >> ~/.ssh/authorized_keys (11) Finally launch sshd on Server with either of the following commands: /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config -d -d -d - to view the debug messages OR /opt/ssh/sbin/sshd -f /opt/ssh/etc/sshd_config - to run the daemon in background (11) On the Client execute the following commands: /opt/ssh/bin/ssh-agent eval `/opt/ssh/bin/ssh-add` /opt/ssh/bin/ssh-add (12) ssh to the Server machine from the Client, Here is the output that we see: [root at localhost ~]# /opt/ssh/bin/ssh root at 10.244.8.83 The authenticity of host '10.244.8.83 (10.244.8.83)' can't be established. RSA+cert key fingerprint is 6d:15:9f:26:fe:5c:16:4f:5e:80:12:80:54:cb:49:56. Distinguished name is 'C=IN,ST=GOA,L=GOA,O=PSL,OU=VLSI,CN=10.244.8.83,emailAddre ss=joviserver at jovi.com'. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.244.8.83' (RSA+cert) to the list of known hosts. Last login: Mon Jan 21 21:09:28 2008 from 10.244.8.167 debug1: permanently_set_uid: 0/0 Environment: USER=root LOGNAME=root HOME=/root PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/ssh/bin MAIL=/var/mail/root SHELL=/bin/bash SSH_CLIENT=10.244.8.167 41513 22 SSH_CONNECTION=10.244.8.167 41513 10.244.8.83 22 SSH_TTY=/dev/pts/2 TERM=xterm debug3: channel 0: close_fds r -1 w -1 e -1 c -1 [root at localhost ~]# *ISSUES faced:* The following commands did not execute and gave errors: (a) /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config -d -d -d myuser at myserver OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006 ssh: illegal option -- d usage: ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-w local_tun[:remote_tun]] [user@]hostname [command] (b) /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config myuser at myserver OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /opt/ssh//etc/ssh_config debug2: hash dir '/root/.ssh/crt' added to x509 store debug2: file '/root/.ssh/ca-cert.pem' added to x509 store debug2: hash dir '/root/.ssh/crl' added to x509 revocation store debug2: hash dir '/opt/ssh//etc/ca/crt' added to x509 store debug2: hash dir '/opt/ssh//etc/ca/crl' added to x509 revocation store debug1: ssh_set_validator: ignore responder url debug2: ssh_connect: needpriv 0 ssh: /opt/ssh/etc/ssh_config: Name or service not known Thanks, Sankalp Roumen Petrov wrote: >sankalp_karpe wrote: > > >>Hi, >> >>I need to add X.509 Certificate support to OpenSSH. >> >>I came across the following post on the openssh-unix-dev mailing list >>that is very useful: >>http://marc.info/?l=openssh-unix-dev&m=120298135706959&w=2 >> >> >>And also, http://marc.info/?l=openssh-unix-dev&m=104395024824680&w=2 >> that >>provides the required patches to dowload for OpenSSH to support X.509 >>certificates. >> >>I am using FC6 and have followed the steps mentioned in the above post, >>but I am unable to successfully complete the task :( >>Is there any step-by-step procedure that I could refer to to achieve the >>same? >> >>Thanks and Regards, >>Sankalp >> >> >> >Please, could you clarify "successfully complete the task". > >RedHat OpenSSH sources are heavy patched and chance patch to be applied >without problem is zero. > >References: >- README.x509v3 for specified version >http://roumenpetrov.info/openssh/download.html >- http://roumenpetrov.info/domino_CA/ > >Roumen > > > From openssh at roumenpetrov.info Fri Feb 22 07:10:12 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 21 Feb 2008 22:10:12 +0200 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47BD71DE.3050002@persistent.co.in> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> Message-ID: <47BDDAA4.3010405@roumenpetrov.info> sankalp_karpe wrote: > Hi Roumen, > > I could successfully add X.509 Certificate support to OpenSSH. > [SKIP] > > *ISSUES faced:* > > The following commands did not execute and gave errors: > > (a) /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config -d -d -d > myuser at myserver > > OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006 > ssh: illegal option -- d > usage: ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] > [-D [bind_address:]port] [-e escape_char] [-F configfile] > [-i identity_file] [-L [bind_address:]port:host:hostport] > [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] > [-R [bind_address:]port:host:hostport] [-S ctl_path] > [-w local_tun[:remote_tun]] [user@]hostname [command] > Yes, expected. The option -d in not in vanilla. Vanilla OpenSSH use -v as verbose mode for client and -d as debug mode for daemon (server). What is ssh option -d on RedHat distribution ? > (b) /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config myuser at myserver > > OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006 > debug1: Reading configuration data /opt/ssh//etc/ssh_config > debug2: hash dir '/root/.ssh/crt' added to x509 store > debug2: file '/root/.ssh/ca-cert.pem' added to x509 store > debug2: hash dir '/root/.ssh/crl' added to x509 revocation store > debug2: hash dir '/opt/ssh//etc/ca/crt' added to x509 store > debug2: hash dir '/opt/ssh//etc/ca/crl' added to x509 revocation store > debug1: ssh_set_validator: ignore responder url > debug2: ssh_connect: needpriv 0 > ssh: /opt/ssh/etc/ssh_config: Name or service not known > Sorry but OpenSSH -f option is not so consistent with other program. Usually -f is for file in many applications but OpenSSH. OpenSSH is inconsistent and options is: -F config_file. Option -f is "requests ssh to go to background just before command execution." So that client try to connect to host "/opt/ssh/etc/ssh_config" and to execute command "myuser at myserver" Did on RedHat option -f is followed by config-file ? > [SNIP] Sorry but reported issues is not related to X.509 certificate support. Roumen From qian.liguo at gvconcepts.com Wed Feb 20 13:28:07 2008 From: qian.liguo at gvconcepts.com (Qian Li Guo) Date: Tue, 19 Feb 2008 18:28:07 -0800 Subject: Run ssh problen Message-ID: Hi: I am a programmer.Now I port openssh and openssl to arm platform,but it will show segmentation fault info when running ssh and others command Version:openssh-3.9p1 openssl-0.9.7e Thanks QianLiGuo From tim at multitalents.net Sun Feb 24 09:49:17 2008 From: tim at multitalents.net (Tim Rice) Date: Sat, 23 Feb 2008 14:49:17 -0800 (PST) Subject: [PATCH] Make sure /var/empty dir really exists In-Reply-To: <20080218181049.GF30886@calimero.vinschen.de> References: <20080218181049.GF30886@calimero.vinschen.de> Message-ID: On Mon, 18 Feb 2008, Corinna Vinschen wrote: > Hi, > > could somebody please be so kind to apply the below patch to the Cygwin > specific file contrib/cygwin/ssh-host-config? It checks more thorough > that it's possible to create the /var/empty directory. It also fixes > bad English. Applied to HEAD. Thanks. > > > Thanks, > Corinna > [patch snipped] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From openssh-contact at fischglas.de Sun Feb 24 05:35:02 2008 From: openssh-contact at fischglas.de (Christian Recktenwald) Date: Sat, 23 Feb 2008 19:35:02 +0100 Subject: sftp-server failing to rename a file Message-ID: <20080223183502.GA25268@fischglas.de> What to try: $ cd /tmp $ touch a b $ sftp localhost sftp> cd /tmp sftp> rename a b Couldn't rename file "/tmp/a" to "/tmp/b": Failure sftp> rm b Removing /var/tmp/b sftp> rename a b sftp> So, the sftp "rename" command refuses to rename a file to an existing one. Instead of using the rename(2) system call, which is present at least on SunOS 5.x, Linux 2.4 & 2.6, FreeBSD 4.x & 5.x and exists as of BSD4.3, it uses link(2) which correctly refuses to overwrite an existing file. This is not only confusing but prevents Linux' FUSE supported sshfs from working correctly. If a client application on the sshfs client uses rename(2) - which is done by mv(1), ci(1) and other tools - this issues a call to sftp's rename command which then failes due to the usage of link(2) instead of rename(2). So I'd repectfully suggest to change the behaviour of sftp-server in this case. Best Regards, Chris Recktenwald -- Christian Recktenwald | openssh-contact at fischglas.de | From dtucker at zip.com.au Sun Feb 24 10:55:30 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 Feb 2008 10:55:30 +1100 Subject: sftp-server failing to rename a file In-Reply-To: <20080223183502.GA25268@fischglas.de> References: <20080223183502.GA25268@fischglas.de> Message-ID: <47C0B272.2000904@zip.com.au> Christian Recktenwald wrote: [...] > So, the sftp "rename" command refuses to rename a file > to an existing one. This behaviour is mandated by the version of the filexfer draft that OpenSSH implements [1]. About SSH_FXP_RENAME, section 6.5 says: "It is an error if there already exists a file with the name specified by newpath." [1] http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt, which somewhat confusingly defines version 3 of the protocol. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Sun Feb 24 12:05:37 2008 From: djm at mindrot.org (Damien Miller) Date: Sun, 24 Feb 2008 12:05:37 +1100 (EST) Subject: sftp-server failing to rename a file In-Reply-To: <47C0B272.2000904@zip.com.au> References: <20080223183502.GA25268@fischglas.de> <47C0B272.2000904@zip.com.au> Message-ID: On Sun, 24 Feb 2008, Darren Tucker wrote: > Christian Recktenwald wrote: > [...] > > So, the sftp "rename" command refuses to rename a file > > to an existing one. > > This behaviour is mandated by the version of the filexfer draft that > OpenSSH implements [1]. About SSH_FXP_RENAME, section 6.5 says: > > "It is an error if there already exists a file > with the name specified by newpath." > > [1] http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt, > which somewhat confusingly defines version 3 of the protocol. There is an open enhancement request to add this at: https://bugzilla.mindrot.org/show_bug.cgi?id=1400 -d From vinschen at redhat.com Sun Feb 24 20:52:17 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 24 Feb 2008 10:52:17 +0100 Subject: [PATCH] Make sure /var/empty dir really exists In-Reply-To: References: <20080218181049.GF30886@calimero.vinschen.de> Message-ID: <20080224095217.GX21945@calimero.vinschen.de> Hi Tim, On Feb 23 14:49, Tim Rice wrote: > On Mon, 18 Feb 2008, Corinna Vinschen wrote: > > > Hi, > > > > could somebody please be so kind to apply the below patch to the Cygwin > > specific file contrib/cygwin/ssh-host-config? It checks more thorough > > that it's possible to create the /var/empty directory. It also fixes > > bad English. > > Applied to HEAD. > Thanks. Thanks! Any chance you could have a look into http://marc.info/?l=openssh-unix-dev&m=120334302732695&w=2 ? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Mon Feb 25 20:16:12 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 25 Feb 2008 20:16:12 +1100 Subject: [PATCH] Build problem in current portable CVS In-Reply-To: <20080218115554.GA30219@calimero.vinschen.de> References: <20080218115554.GA30219@calimero.vinschen.de> Message-ID: <20080225091612.GA28362@gate.dtucker.net> On Mon, Feb 18, 2008 at 12:55:54PM +0100, Corinna Vinschen wrote: > Hi, > > I just tried to build the latest portable code from CVS on Cygwin. > I stumbled over a problem with the definitions of gai_strerror and > ssh_gai_strerror. > > On systems not having gai_strerror, the fake-rfc2553.c file defines > its own version of gai_strerror, and fake-rfc2553.h additionally has > this definition of gai_strerror: > > #define gai_strerror(a) (ssh_gai_strerror(a)) What moron put that there? oh wait, it was me :-) Actually it's been there for a while and there's a reason for it: it prevents name clash problems with Heimdal's libroken. Unfortunately, when I added that helper function to the OpenBSD version, I picked the same name, thus the problem. Just removing it will reintroduce the libroken problem, but changing the name should sort both out. I'm about to commit the following which should do the job. Thanks. Index: openbsd-compat/fake-rfc2553.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/fake-rfc2553.h,v retrieving revision 1.13 diff -u -p -r1.13 fake-rfc2553.h --- openbsd-compat/fake-rfc2553.h 24 Jul 2006 03:51:52 -0000 1.13 +++ openbsd-compat/fake-rfc2553.h 25 Feb 2008 09:11:43 -0000 @@ -152,7 +152,7 @@ int getaddrinfo(const char *, const char #endif /* !HAVE_GETADDRINFO */ #if !defined(HAVE_GAI_STRERROR) && !defined(HAVE_CONST_GAI_STRERROR_PROTO) -#define gai_strerror(a) (ssh_gai_strerror(a)) +#define gai_strerror(a) (_ssh_compat_gai_strerror(a)) char *gai_strerror(int); #endif /* !HAVE_GAI_STRERROR */ -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Mon Feb 25 23:02:05 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 25 Feb 2008 13:02:05 +0100 Subject: [PATCH] Build problem in current portable CVS In-Reply-To: <20080225091612.GA28362@gate.dtucker.net> References: <20080218115554.GA30219@calimero.vinschen.de> <20080225091612.GA28362@gate.dtucker.net> Message-ID: <20080225120205.GF21945@calimero.vinschen.de> On Feb 25 20:16, Darren Tucker wrote: > On Mon, Feb 18, 2008 at 12:55:54PM +0100, Corinna Vinschen wrote: > > Hi, > > > > I just tried to build the latest portable code from CVS on Cygwin. > > I stumbled over a problem with the definitions of gai_strerror and > > ssh_gai_strerror. > > > > On systems not having gai_strerror, the fake-rfc2553.c file defines > > its own version of gai_strerror, and fake-rfc2553.h additionally has > > this definition of gai_strerror: > > > > #define gai_strerror(a) (ssh_gai_strerror(a)) > > What moron put that there? oh wait, it was me :-) > > Actually it's been there for a while and there's a reason for it: it > prevents name clash problems with Heimdal's libroken. > > Unfortunately, when I added that helper function to the OpenBSD version, > I picked the same name, thus the problem. > > Just removing it will reintroduce the libroken problem, but changing the > name should sort both out. I'm about to commit the following which should > do the job. Thanks. Builds fine on Cygwin again. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From openssh-contact at fischglas.de Tue Feb 26 02:43:47 2008 From: openssh-contact at fischglas.de (Christian Recktenwald) Date: Mon, 25 Feb 2008 16:43:47 +0100 Subject: sftp-server failing to rename a file In-Reply-To: <47C0B272.2000904@zip.com.au> References: <20080223183502.GA25268@fischglas.de> <47C0B272.2000904@zip.com.au> Message-ID: <20080225154347.GA21904@fischglas.de> On Sun, Feb 24, 2008 at 10:55:30AM +1100, Darren Tucker wrote: > Christian Recktenwald wrote: > [...] > >So, the sftp "rename" command refuses to rename a file > >to an existing one. > > This behaviour is mandated by the version of the filexfer draft that > OpenSSH implements [1]. About SSH_FXP_RENAME, section 6.5 says: > > "It is an error if there already exists a file > with the name specified by newpath." Yeah sure. But it would be of great benefit to change this. And as it is an (outdated) draft, you may take this as a suggestion to change it also :-) -- Christian Recktenwald | elwood sys adm openssh-contact at fischglas.de | From dtucker at zip.com.au Tue Feb 26 10:30:42 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Feb 2008 10:30:42 +1100 Subject: sftp-server failing to rename a file In-Reply-To: <20080225154347.GA21904@fischglas.de> References: <20080223183502.GA25268@fischglas.de> <47C0B272.2000904@zip.com.au> <20080225154347.GA21904@fischglas.de> Message-ID: <47C34FA2.40907@zip.com.au> Christian Recktenwald wrote: > On Sun, Feb 24, 2008 at 10:55:30AM +1100, Darren Tucker wrote: >> Christian Recktenwald wrote: >> [...] >>> So, the sftp "rename" command refuses to rename a file >>> to an existing one. >> This behaviour is mandated by the version of the filexfer draft that >> OpenSSH implements [1]. About SSH_FXP_RENAME, section 6.5 says: >> >> "It is an error if there already exists a file >> with the name specified by newpath." > > Yeah sure. But it would be of great benefit to change this. Changing it is the wrong thing to do. It may break a compliant client that relies on behaviour *required* by the spec. Implementing an additional vendor extension as described by Damien would be ok, though. > And as it is an (outdated) draft, you may take this as a > suggestion to change it also :-) The later drafts also mandate increasing levels of other crud, so much so that it hasn't (and probably never will) reach standardization. -- 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 Tue Feb 26 18:12:23 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 26 Feb 2008 08:12:23 +0100 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0801090504n2c3d3be3oa9722dc934d8de62@mail.gmail.com> References: <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> <20080108041546.13057.qmail@cdy.org> <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> <20080108224244.26725.qmail@cdy.org> <20080109042552.22760.qmail@cdy.org> <9e0cf0bf0801090504n2c3d3be3oa9722dc934d8de62@mail.gmail.com> Message-ID: <20080226071223.21047.qmail@cdy.org> On Wed, Jan 09, 2008 at 03:04:39PM +0200, Alon Bar-Lev wrote: > > Cool! Have you made any research on pkcs#11 in OpenBSD? I asked > > around in #openbsd on freenode some time ago but noone there had > > heard any strong opinions either for or against it. > > PKCS#11 is just an interface... I don't think people should be > against it... :) Just a note to say that I've pushed the question to a friend of mine who knows OBSD hardware crypto people. //Peter From alon.barlev at gmail.com Tue Feb 26 18:35:37 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 26 Feb 2008 09:35:37 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <20080226071223.21047.qmail@cdy.org> References: <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> <20080108041546.13057.qmail@cdy.org> <9e0cf0bf0801080539p3520a56boa447a020a90166f7@mail.gmail.com> <20080108224244.26725.qmail@cdy.org> <20080109042552.22760.qmail@cdy.org> <9e0cf0bf0801090504n2c3d3be3oa9722dc934d8de62@mail.gmail.com> <20080226071223.21047.qmail@cdy.org> Message-ID: <9e0cf0bf0802252335w20c1540an8cf92a651280d5d1@mail.gmail.com> On 2/26/08, Peter Stuge wrote: > Just a note to say that I've pushed the question to a friend of mine > who knows OBSD hardware crypto people. Thanks! Is there anything I can do to push this further? Is something missing? Need some more information? Alon. From bulk88 at hotmail.com Wed Feb 27 11:41:18 2008 From: bulk88 at hotmail.com (bulk88) Date: Tue, 26 Feb 2008 19:41:18 -0500 Subject: remote/reverse port forward, ssh client setting source IPs to what ssh server reports Message-ID: <5f8d3b030802261641t77715ff2o8b08edecbbf7d18c@mail.gmail.com> Note: most but not all of this message is about OpenSSH When I do a remote forward (port on server listens for incoming traffic, traffic gets forwarded to port that is listening on client), the source IPs of all the incoming connections in the server app on the client machine are 127.0.0.1/localhost. Using "-v", I can see that sshd passes the IP addresses of what computers connected to the sshd's port that forwards to the client. The client does not use/set the originating information when connect. RFC 4254 requires the server send the originating IP across the wire to the client so I believe all ssh servers will send this across the wire. ------------------------------------------------------------------------------------------------------------------------- 7.2. TCP/IP Forwarding Channels When a connection comes to a port for which remote forwarding has been requested, a channel is opened to forward the port to the other side. byte SSH_MSG_CHANNEL_OPEN string "forwarded-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string address that was connected uint32 port that was connected ###string originator IP address########################################### uint32 originator port -------------------------------------------------------------------------------------------------------------------------- The 'originator IP address' is the numeric IP address of the machine from where the connection request originates, and the 'originator port' is the port on the host from where the connection originated. -------------------------------------------------------------------------------------------------------------------------- from -v of ssh, proof that the ssh client does know the originator IP and port, but server app on computer with ssh client will never see this -------------------------------------------------------------------------------------------------------------------------- debug1: client_input_channel_open: ctype forwarded-tcpip rchan 6 win 131072 max 32768 debug1: client_request_forwarded_tcpip: listen localhost port 80, originator 81.910.872.450 port 50454 debug1: channel 7: new [81.910.872.450] debug1: confirm forwarded-tcpip debug1: channel 7: connected debug1: channel 7: free: 81.910.872.450, nchannels 11 -------------------------------------------------------------------------------------------------------------------------- The fact that all incoming connection to the server app running on the client are 127.0.0.1/localhost causes severe problems. Any security scheme relying on looking at the IPs of the incoming connections to the server app are now useless. For example if the server app is a webserver, it can't record the IPs of customers who buy something in an online store. My question is, are there any ssh clients, FOSS or commercial that will set the source IP addresses to what the ssh server reports? Either through being a VPN, emulating a NIC/network interface, or playing with raw sockets/socket options, or something else? For OpenSSH this is a feature request. I also dug around in the source of OpenSSH, "connect_to" function in channels.c is what I think creates the connection on the ssh client to the destination in a remote forward. It uses Berkeley Sockets. Perhaps there should be a option to use raw sockets and spoof the source IP to what the ssh server passed to the ssh client, or set "ip_nonlocal_bind" with sysctl on linux or do whatever it takes to have a arbitrary IP address bind with a particular OS (not portable, I know), and then do a bind with the source IP from the ssh server on the socket before doing the connect to the server app on OpenSSH client. Then OpenSSH client will be reporting the correct source IP to the server app. Note, adding the feature to "connect_to" would also require editing "channel_connect_by_listen_address" function in channels.c and "client_request_forwarded_tcpip" function in clientloop.c to forward the originating IP I think. I am not an expert at programing or C or posix OSes so my implementation theories and analysis might be faulty. From william at 25thandClement.com Wed Feb 27 13:46:00 2008 From: william at 25thandClement.com (William Ahern) Date: Tue, 26 Feb 2008 18:46:00 -0800 Subject: remote/reverse port forward, ssh client setting source IPs to what ssh server reports In-Reply-To: <5f8d3b030802261641t77715ff2o8b08edecbbf7d18c@mail.gmail.com> References: <5f8d3b030802261641t77715ff2o8b08edecbbf7d18c@mail.gmail.com> Message-ID: <20080227024600.GA3041@wilbur.25thandClement.com> On Tue, Feb 26, 2008 at 07:41:18PM -0500, bulk88 wrote: > Note: most but not all of this message is about OpenSSH > > When I do a remote forward (port on server listens for incoming > traffic, traffic gets forwarded to port that is listening on client), > the source IPs of all the incoming connections in the server app on > the client machine are 127.0.0.1/localhost. Using "-v", I can see that > sshd passes the IP addresses of what computers connected to the sshd's > port that forwards to the client. The client does not use/set the > originating information when connect. > clientloop.c to forward the originating IP I think. I am not an expert > at programing or C or posix OSes so my implementation theories and > analysis might be faulty. So, you're worried about a user who has a shell (or at least a local account w/ forwarding privileges) accessing services as a local user, but not so much about letting such users spoof other arbitrary IP addresses? More over, in order to use raw sockets, or use any of the others tricks (which may or may not be available), the process must have root privileges. But, in OpenSSH these forwards are done from a process with the UID of the user. OpenSSH does support TUN/TAP (emulated network device). But this isn't something you normally allow arbitrary users to manipulate. And, in any event, it requires root permissions. On other other hand, on OpenBSD you can define packet filter rules based on the UID of the connecting process. PF has been ported to various systems, but I'm not sure if this ability works elsewhere. From qian.liguo at gvconcepts.com Thu Feb 28 13:27:23 2008 From: qian.liguo at gvconcepts.com (Qian Li Guo) Date: Wed, 27 Feb 2008 18:27:23 -0800 Subject: Problem of porting openssh to arm9 platform Message-ID: Hi; I meet some problem when porting openssh.Please help me The following content is wrong info: # strace ssh execve("/usr/bin/ssh", ["ssh"], [/* 16 vars */]) = 0 mmap2(NULL, 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40005000 stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=1796, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY) = 4 mmap2(NULL, 1796, PROT_READ, MAP_SHARED, 4, 0) = 0x40006000 close(4) = 0 open("/lib/libcrypto.so.0.9.8", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=1136576, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0,X\3\0004"..., 4096) = 4096 mmap2(NULL, 1183744, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000e000 mmap2(0x4000e000, 1060052, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4000e000 mmap2(0x40119000, 74620, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x103) = 0x40119000 mmap2(0x4012c000, 10364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4012c000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libutil.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=4656, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0008\10\0\000"..., 4096) = 4096 mmap2(NULL, 36864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4012f000 mmap2(0x4012f000, 3160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4012f000 mmap2(0x40137000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x40137000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libz.so.1", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=71984, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\304\26\0"..., 4096) = 4096 mmap2(NULL, 106496, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40138000 mmap2(0x40138000, 70176, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x40138000 mmap2(0x40151000, 1260, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x11) = 0x40151000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libcrypt.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=12892, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\234\4\0\000"..., 4096) = 4096 mmap2(NULL, 118784, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40152000 mmap2(0x40152000, 9380, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x40152000 mmap2(0x4015c000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x2) = 0x4015c000 mmap2(0x4015d000, 70864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4015d000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libresolv.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=4640, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\204\2\0\000"..., 4096) = 4096 mmap2(NULL, 36864, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4016f000 mmap2(0x4016f000, 668, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x4016f000 mmap2(0x40177000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x40177000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libgcc_s.so.1", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=31736, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0X\25\0\000"..., 4096) = 4096 mmap2(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40178000 mmap2(0x40178000, 28800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x40178000 mmap2(0x40187000, 548, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x7) = 0x40187000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0 \251\0\000"..., 4096) = 4096 mmap2(NULL, 360448, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40188000 mmap2(0x40188000, 303940, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x40188000 mmap2(0x401da000, 5172, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x4a) = 0x401da000 mmap2(0x401dc000, 16020, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401dc000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libdl.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=8900, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 read(4, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0(\10\0\000"..., 4096) = 4096 mmap2(NULL, 40960, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401e0000 mmap2(0x401e0000, 5868, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x401e0000 mmap2(0x401e9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1) = 0x401e9000 close(4) = 0 munmap(0x40007000, 4096) = 0 open("/lib/libgcc_s.so.1", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=31736, ...}) = 0 close(4) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 close(4) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 close(4) = 0 open("/lib/libgcc_s.so.1", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=31736, ...}) = 0 close(4) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 close(4) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 close(4) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 close(4) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 close(4) = 0 open("/lib/libc.so.0", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=309856, ...}) = 0 close(4) = 0 munmap(0x40006000, 1796) = 0 stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=21096, ...}) = 0 mprotect(0x40137000, 4096, PROT_READ) = 0 mprotect(0x4015c000, 4096, PROT_READ) = 0 mprotect(0x40177000, 4096, PROT_READ) = 0 mprotect(0x401da000, 4096, PROT_READ) = 0 mprotect(0x401e9000, 4096, PROT_READ) = 0 mprotect(0x4000c000, 4096, PROT_READ) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 open("/dev/null", O_RDWR|O_LARGEFILE) = 4 close(4) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 343 detached Thanks From stuge-openssh-unix-dev at cdy.org Thu Feb 28 20:38:00 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 28 Feb 2008 10:38:00 +0100 Subject: Problem of porting openssh to arm9 platform In-Reply-To: References: Message-ID: <20080228093800.17721.qmail@cdy.org> On Wed, Feb 27, 2008 at 06:27:23PM -0800, Qian Li Guo wrote: > I meet some problem when porting openssh.Please help me Let's hope we can. > stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=21096, ...}) = 0 .. > open("/dev/null", O_RDWR|O_LARGEFILE) = 4 > close(4) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > Process 343 detached This doesn't reveal too much. It doesn't show where ssh crashes. Could you try building ssh with debugging enabled (-g option to gcc) and running ssh under gdb - then when it crashes type "bt" to recieve a backtrace showing in which function the crash happens. Another, somewhat less informative but still interesting, method is to run ssh -vvv and see what output you get. That can also indicate where the problem is happening but running with gdb would be best. //Peter From sankalp_karpe at persistent.co.in Thu Feb 28 23:33:11 2008 From: sankalp_karpe at persistent.co.in (sankalp_karpe) Date: Thu, 28 Feb 2008 18:03:11 +0530 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47BDDAA4.3010405@roumenpetrov.info> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> Message-ID: <47C6AA07.2050003@persistent.co.in> Hi Roumen, Thanks for your comments. The issues reported by me were not X.509 specific. Sorry about that. So now I have SSH Server & Client, both patched with X.509 and I can successfully connect to the Server using X.509 Certificates. I have several Linux clients some of which are patched with x.509 patch. Is it possible for those linux machines (not patched with x.509) to log-in to the server with username/password since they do not support x.509 certificates (by doing some configuration changes on the Server)? I have tried to log-in from a ssh client (without X.509 patch) to a ssh server (with X.509 patch), but the server refuses connection with the following error on the console: "no hostkey alg" My goal, is to make the OpenSSH Server (with X.509 patch) compatible with all SSH Clients irrespective of whether the client is patched with X.509 or not. Would there be any workaround? Your help would be highly appreciated. Thanking you in anticipation. Thanks and Best Regards, Sankalp Roumen Petrov wrote: > sankalp_karpe wrote: > >> Hi Roumen, >> >> I could successfully add X.509 Certificate support to OpenSSH. >> [SKIP] >> > > >> *ISSUES faced:* >> >> The following commands did not execute and gave errors: >> >> (a) /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config -d -d -d >> myuser at myserver >> >> OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006 >> ssh: illegal option -- d >> usage: ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] >> [-D [bind_address:]port] [-e escape_char] [-F configfile] >> [-i identity_file] [-L [bind_address:]port:host:hostport] >> [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p >> port] >> [-R [bind_address:]port:host:hostport] [-S ctl_path] >> [-w local_tun[:remote_tun]] [user@]hostname [command] >> > > Yes, expected. The option -d in not in vanilla. > Vanilla OpenSSH use -v as verbose mode for client and -d as debug mode > for daemon (server). > > What is ssh option -d on RedHat distribution ? > > >> (b) /opt/ssh/bin/ssh -vvv -f /opt/ssh/etc/ssh_config myuser at myserver >> >> OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006 >> debug1: Reading configuration data /opt/ssh//etc/ssh_config >> debug2: hash dir '/root/.ssh/crt' added to x509 store >> debug2: file '/root/.ssh/ca-cert.pem' added to x509 store >> debug2: hash dir '/root/.ssh/crl' added to x509 revocation store >> debug2: hash dir '/opt/ssh//etc/ca/crt' added to x509 store >> debug2: hash dir '/opt/ssh//etc/ca/crl' added to x509 revocation store >> debug1: ssh_set_validator: ignore responder url >> debug2: ssh_connect: needpriv 0 >> ssh: /opt/ssh/etc/ssh_config: Name or service not known >> > > Sorry but OpenSSH -f option is not so consistent with other program. > Usually -f is for file in many applications but OpenSSH. > OpenSSH is inconsistent and options is: -F config_file. > Option -f is "requests ssh to go to background just before command > execution." > So that client try to connect to host "/opt/ssh/etc/ssh_config" and to > execute command "myuser at myserver" > > Did on RedHat option -f is followed by config-file ? > >> [SNIP] > > > Sorry but reported issues is not related to X.509 certificate support. > > Roumen > > From openssh at roumenpetrov.info Fri Feb 29 06:23:49 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 28 Feb 2008 21:23:49 +0200 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47C6AA07.2050003@persistent.co.in> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> Message-ID: <47C70A45.7090903@roumenpetrov.info> sankalp_karpe wrote: > Hi Roumen, > > Thanks for your comments. > The issues reported by me were not X.509 specific. Sorry about that. > > So now I have SSH Server & Client, both patched with X.509 and I can > successfully connect to the Server using X.509 Certificates. > > I have several Linux clients some of which are patched with x.509 patch. > > Is it possible for those linux machines (not patched with x.509) to > log-in to the server with username/password since they do not support > x.509 certificates (by doing some configuration changes on the Server)? > I have tried to log-in from a ssh client (without X.509 patch) to a > ssh server (with X.509 patch), but the server refuses connection with > the following error on the console: > > "no hostkey alg" > > My goal, is to make the OpenSSH Server (with X.509 patch) compatible > with all SSH Clients irrespective of whether the client is patched > with X.509 or not. > Would there be any workaround? > > Your help would be highly appreciated. > Thanking you in anticipation. > > Thanks and Best Regards, > Sankalp > > Roumen Petrov wrote: > >> sankalp_karpe wrote: >> [SNIP] You could list in sshd_config all supported key types: $ grep ^HostKey /etc/ssh/sshd_config HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/SAVE/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key Also you could check key-types supported by server: $ ssh-keyscan localhost # localhost SSH-2.0-OpenSSH_4.7 localhost x509v3-sign-rsa Subject:C=XX,... # localhost SSH-2.0-OpenSSH_4.7 localhost x509v3-sign-dss Subject:C=XX,... # localhost SSH-2.0-OpenSSH_4.7 localhost ssh-rsa AAAAB3Nza.... # localhost SSH-2.0-OpenSSH_4.7 no hostkey alg Command ssh-keyscan (see man page) scan for protocol version 2 keys by default. Roumen