From matt at slackers.net Sat Mar 1 13:54:20 2008 From: matt at slackers.net (Matthew Andrews) Date: Fri, 29 Feb 2008 18:54:20 -0800 Subject: GSSAPI Key Exchange Patch for OpenSSH 4.7p1 In-Reply-To: <20070928214023.GP11376@Sun.COM> References: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> <46FD7176.3020108@anl.gov> <20070928214023.GP11376@Sun.COM> Message-ID: <47C8C55C.4020706@slackers.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmmm.... The cascading credentials code sounds interesting, but raises the practical question of how does one deal with derived credentials. For example some sites configure the pam_session code to use delegated krb5 credentials to acquire additional credentials such as afs tokens, or x509 certificates. Since there would be no new session created, these derived credentials would not get refreshed. I think you'd need some way to hook site specific actions into the refresh activity, and of course that raises the hairy problem whether this refresh activity occurs in the same process, or one of it's descendants where the pam_session was established. In any case I'm interested in the feature, but am trying to think of what other features are needed to take full advantage of it in a number of common environments. - -Matt Andrews Nicolas Williams wrote: | On Fri, Sep 28, 2007 at 04:26:14PM -0500, Douglas E. Engert wrote: |> Sounds interesting. And yes, I would be interested in |> the cascading credentials delegation code. Does the |> delegation code depend on the key exchange code? | | Protocol-wise, yes, it does. | | There's two ways to use the GSS-API in SSHv2: | | - userauth only, but this happens once at the start of the session, so | you can't delegate credentials after that | | - key exchange (and optionally userauth), which can be done again and | again over the lifetime of the session | | Nico -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHyMVcpLF3UzlwZVgRAutsAKD7a33FKqROnIzPzXP5hbO6CqXkzgCfezdH G+Fzx1/0z8OwPEgU2WNY+gc= =gfd7 -----END PGP SIGNATURE----- From simon at sxw.org.uk Sat Mar 1 23:06:41 2008 From: simon at sxw.org.uk (Simon Wilkinson) Date: Sat, 1 Mar 2008 12:06:41 +0000 Subject: GSSAPI Key Exchange Patch for OpenSSH 4.7p1 In-Reply-To: <87mypj2l4u.fsf@windlord.stanford.edu> References: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> <46FD7176.3020108@anl.gov> <20070928214023.GP11376@Sun.COM> <47C8C55C.4020706@slackers.net> <87mypj2l4u.fsf@windlord.stanford.edu> Message-ID: <76A8CC04-E1B6-45EE-B8E8-09C51303D293@sxw.org.uk> On 1 Mar 2008, at 03:12, Russ Allbery wrote: > Matthew Andrews writes: > >> Hmmm.... The cascading credentials code sounds interesting, but >> raises >> the practical question of how does one deal with derived credentials. >> > Just re-run the session PAM stack with PAM_REFRESH_CREDS set, the > same as > what a screensaver would do. This does all the right things with > derived > credentials if your PAM modules are properly written. This is exactly what my cascading credentials code for OpenSSH does. It uses an additional PAM stack (so you can set different options than the 'main' ssh PAM stack) which it calls the session layer of whenever credentials are renewed. We use this to renew both AFS tokens, and KX509 certificates. Informatics are now running this code in production. I expect to be making a public release next week. Cheers, Simon. From jrmull at eagle88.com Mon Mar 3 12:55:31 2008 From: jrmull at eagle88.com (John Mull) Date: Sun, 2 Mar 2008 19:55:31 -0600 Subject: Posting request Message-ID: <29A7A091E6164FC89EAC118B0EC00D0A@JohnMullPC> Peter Please delete this posting are at least remove the company name. thanks john Question on openSSH and sending file to MVS file formats Remove Highlighting -------------------------------------------------------- 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev[at]mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev stuge-openssh-unix-dev at cdy Feb 9, 2008, 9:02 AM Post #2 of 2 (44 views) Permalink Re: Question on openSSH and sending file to MVS file formats Remove Highlighting [In reply to] -------------------------------------------------------- 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev[at]mindrot.org From petesea at bigfoot.com Fri Mar 7 11:06:04 2008 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Thu, 06 Mar 2008 16:06:04 -0800 (PST) Subject: Command-based ssh_config declarations Message-ID: How difficult would it be to enhance the client ssh_config file to allow command-based declarations similar to that provided by the "Host" keyword? The main reason I need something like this is when ssh is used via CVS and Subversion. I want all CVS/Subversion traffic to use a different SSH port and different authentication options. So... you might have an ssh_config file that contained: Command '*cvs.mydomain.com cvs server' '*svn.mydomain.com svnserve -t' Port 2200 Protocol 2 BatchMode yes PasswordAuthentication no PubkeyAuthentication yes Where the string matched against the pattern is the complete command line passed to the ssh client. This would allow all CVS traffic to use one setting, but normal SSH traffic to the same host could use different settings. From jmknoble at pobox.com Fri Mar 7 18:03:47 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 7 Mar 2008 02:03:47 -0500 Subject: Command-based ssh_config declarations In-Reply-To: References: Message-ID: <20080307070347.GC4279@crawfish.ais.com> Circa 2008-03-06 19:06 dixit petesea at bigfoot.com: : How difficult would it be to enhance the client ssh_config file to allow : command-based declarations similar to that provided by the "Host" keyword? Not necessary; see below. : The main reason I need something like this is when ssh is used via CVS and : Subversion. I want all CVS/Subversion traffic to use a different SSH port : and different authentication options. [...] This is where the 'HostName' directive is your friend. Your ssh_config file can look like this: Host svn.example.com HostName server.example.com Port 2200 BatchMode yes # etc. Host * Protocol 2 # etc. Now, for your Subversion commands, use 'svn+ssh://svn.example.com/repository' as the repository specification, rather than 'svn+ssh://server.example.com/repository'. You can even use a different identity for pubkey authentication, if you wish. This is mainly a matter of discipline or policy in what name is used to access the Subversion or CVS server. The names in the Host stanzas aren't even required to be valid DNS names, as long as the HostName directive contains a either a valid IP address or a name that's defined in DNS or /etc/hosts or whatever your system uses. If you have more than one such host running a Subversion or CVS server, you can add a Host stanza for each one into ssh_config. If you have thousands of them, you should consider using a wrapper script for the 'ssh' command instead. -- 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 dwmw2 at infradead.org Sat Mar 8 11:23:46 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 08 Mar 2008 01:23:46 +0100 Subject: Command-based ssh_config declarations In-Reply-To: <20080307070347.GC4279@crawfish.ais.com> References: <20080307070347.GC4279@crawfish.ais.com> Message-ID: <1204935826.2495.18.camel@shinybook.infradead.org> On Fri, 2008-03-07 at 02:03 -0500, Jim Knoble wrote: > This is mainly a matter of discipline or policy in what name is used to > access the Subversion or CVS server. The names in the Host stanzas > aren't even required to be valid DNS names, as long as the HostName > directive contains a either a valid IP address or a name that's > defined in DNS or /etc/hosts or whatever your system uses. You don't even need that, as long as you have a ProxyCommand which will talk SSH protocol on its stdin/stdout. Such as: host *.mydomain.internal ProxyCommand ssh bastionhost.mydomain.com exec netcat %h %p -- dwmw2 From joviano_dias at persistent.co.in Mon Mar 10 18:56:47 2008 From: joviano_dias at persistent.co.in (Joviano Dias) Date: Mon, 10 Mar 2008 13:26:47 +0530 Subject: Benefits of OpenSSH X.509 over key based authentication? Message-ID: <005901c88284$4ab1cf40$e0156dc0$@co.in> Hi, I have some observations regarding the X.509 patch developed by Roumen Petrov for OpenSSH available at http://roumenpetrov.info/openssh/ , I don't understand some things here like 1. When certificate based authentication of the client is desired, shouldn't it be something like what mod_ssl does in Apache where u have a CA certificate at the server, and then the client certificate installed in the client browser. You do not have to update the server everytime u update the client 2. Whereas in the case of using the OpenSSH x.509 patch, we have to generate an id_rsa.pub file for every id_rsa (client cert +client key) file and place append it to authorized_keys file on the server. This means every time u generate a client cert(cert+key), you have to append the .pub part to the server. So isn't this like key-based authentication. 3. So, How is the practicality of this solution better than key based authentication? Regards, Joviano Dias From joviano_dias at persistent.co.in Mon Mar 10 19:58:44 2008 From: joviano_dias at persistent.co.in (Joviano Dias) Date: Mon, 10 Mar 2008 14:28:44 +0530 Subject: Benefits of OpenSSH X.509 over key based authentication? Message-ID: <005e01c8828c$f2278e10$d676aa30$@co.in> Hi, I have some observations regarding the X.509 patch developed by Roumen Petrov for OpenSSH available at http://roumenpetrov.info/openssh/ , I don't understand some things here like 1. When certificate based authentication of the client is desired, shouldn't it be something like what mod_ssl does in Apache where u have a CA certificate at the server, and then the client certificate installed in the client browser. You do not have to update the server everytime u update the client 2. Whereas in the case of using the OpenSSH x.509 patch, we have to generate an id_rsa.pub file for every id_rsa (client cert +client key) file and place append it to authorized_keys file on the server. This means every time u generate a client cert(cert+key), you have to append the .pub part to the server. So isn't this like key-based authentication. 3. So, How is the practicality of this solution better than key based authentication? Regards, Joviano Dias From sankalp_karpe at persistent.co.in Wed Mar 12 22:51:26 2008 From: sankalp_karpe at persistent.co.in (sankalp_karpe) Date: Wed, 12 Mar 2008 17:21:26 +0530 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47C70A45.7090903@roumenpetrov.info> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> Message-ID: <47D7C3BE.1080502@persistent.co.in> Hi Roumen, I tried your suggestions and could successfully connect to the OpenSSH Server with X.509 patch from a non-patched SSH Client using username/password. The main requirement that I have is for the Client to be authenticated via a Client certificate using SSH and Apache. I have been able to successfully achieve the same using Apache + mod_ssl for web server access to my system. In order to enable the same authentication mechanism for command-line access to my system that uses OpenSSH, I patched OpenSSH with the X.509 patch you developed between two Linux FC6 machines. Ideally I would like it to be something like: 1. The client sends the user certificate (which includes the user's public key) to the server. The packet also contains data unique to the session and it is signed by the user's private key. 2. The server uses the CA certificate to check that the user's certificate is valid. 3. The server verifies that the user has a valid private key by checking the signature in the initial packet. 4. The server matches the user certificate against the rules in the server configuration file to decide whether login is allowed or not. When looking for information on X.509 Certificate support for SSH, I had come across a commercial version of SSH (SSH Tectia Client/Server) which claims to support the above authentication sequence. Also, it supports selective field based authentication of the Client Certificates, for example: However, I need to see how I can extend the OpenSSH of my system to support X.509 Certificates and cannot use any commercial version of SSH. Implementing X.509 Certificate support for OpenSSH (using the X.509 patch you developed) requires that the client certificate be appended to the Client key in id_rsa and public part of the client key+certificate (i.e. id_rsa.pub) to be appended to the authorized_keys file on the server, and each time a new client (OpenSSH patched with X.509) is added to the network, its corresponding id_rsa.pub has to be appended to the server's authorized_keys. So, I have the following concerns and would request your comments on the same: (1) Isn't this an overhead as compared to what we would do in Web Server Authentication (Apache) where-in we provide the client with just a certificate, and not having to create a custom file containing the Client key+certificate (id_rsa) like we do for OpenSSH patched with X.509. (2) If we need to have the "client key + client certificate" in id_rsa, then, is there any workaround to eliminate the need to append the ".pub" part of it to the "authorized_keys" file on the Server. (3) Also how can we authenticate clients selectively using the fields of the client certificate in case of OpenSSH (with X.509 support). Your help would be highly appreciated. Thanking you in anticipation. Thanks and Best Regards, Sankalp Roumen Petrov wrote: >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 >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From djm at mindrot.org Thu Mar 13 11:50:25 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Mar 2008 11:50:25 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 Message-ID: Hi, We are preparing to make the release of OpenSSH 4.8 soon, so we would greatly appreciate testing of snapshot releases in as many environments and on as many operating systems as possible. The highlights of this release are: * Added chroot(2) support for sshd(8), controlled by a new option "ChrootDirectory". Please refer to sshd_config(5) for details, and please use this feature carefully. (bz#177 bz#1352) * Linked sftp-server(8) into sshd(8). The internal sftp server is used when the command "internal-sftp" is specified in a Subsystem or ForceCommand declaration. When used with ChrootDirectory, the internal sftp server requires no special configuration of files inside the chroot environment. Please refer to sshd_config(5) for more information. * Added a protocol extension method "posix-rename at openssh.com" for sftp-server(8) to perform POSIX atomic rename() operations. (bz#1400) * Removed the fixed limit of 100 file handles in sftp-server(8). The server will now dynamically allocate handles up to the number of available file descriptors. (bz#1397) * ssh(8) will now skip generation of SSH protocol 1 ephemeral server keys when in inetd mode and protocol 2 connections are negotiated. This speeds up protocol 2 connections to inetd-mode servers that also allow Protocol 1 (bz#440) * Accept the PermitRootLogin directive in a sshd_config(5) Match block. Allows for, e.g. permitting root only from the local network. * Reworked sftp(1) argument splitting and escaping to be more internally consistent (i.e. between sftp commands) and more consistent with sh(1). Please note that this will change the interpretation of some quoted strings, especially those with embedded backslash escape sequences. (bz#778) * Support "Banner=none" in sshd_config(5) to disable sending of a pre-login banner (e.g. in a Match block). * ssh(1) ProxyCommands are now executed with $SHELL rather than /bin/sh. * ssh(1)'s ConnectTimeout option is now applied to both the TCP connection and the SSH banner exchange (previously it just covered the TCP connection). This allows callers of ssh(1) to better detect and deal with stuck servers that accept a TCP connection but don't progress the protocol, and also makes ConnectTimeout useful for connections via a ProxyCommand. * Many new regression tests, including interop tests against PuTTY's plink. * Support BSM auditing on Mac OS X This release also contains many bugfixes. Please refer to the tracking bug https://bugzilla.mindrot.org/show_bug.cgi?id=1353 for a partial list. The ChangeLog file in the portable OpenSSH tarballs contains a full list. Please fetch and test the release that is appropriate for your platform: If you are running OpenBSD the latest version is available in CVS HEAD, as described at http://www.openbsd.org/anoncvs.html Otherwise, portable snapshots are available from http://www.mindrot.org/openssh_snap/ and also by anonymous CVS. CVS instructions are here: http://www.openssh.com/portable.html#cvs Running the regression tests supplied with Portable does not require installation and is a simply: $ ./configure && make tests This release includes some interoperability tests against PuTTY's plink(1). These tests may be run using "make interop-tests" if you have plink(1) installed. Testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. From stuge-openssh-unix-dev at cdy.org Thu Mar 13 12:03:24 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 13 Mar 2008 02:03:24 +0100 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47D7C3BE.1080502@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> <47C70A45.7090903@roumenpetrov.info> <47D7C3BE.1080502@persistent.co.in> Message-ID: <20080313010324.21750.qmail@cdy.org> On Wed, Mar 12, 2008 at 05:21:26PM +0530, sankalp_karpe wrote: > (1) Isn't this an overhead as compared to what we would do in Web > Server Authentication (Apache) where-in we provide the client with > just a certificate, and not having to create a custom file > containing the Client key+certificate (id_rsa) like we do for > OpenSSH patched with X.509. Disregarding the file format issue, a certificate does not make sense if there is no private key. The certificate is just a "face" to go with the key. If Roumen's patch doesn't already support .pem files with key and cert I think it would be trivial to add. > (2) If we need to have the "client key + client certificate" in > id_rsa, Yes, the client will always need both key and cert. > then, is there any workaround to eliminate the need to append the > ".pub" part of it to the "authorized_keys" file on the Server. Here I agree with you - the administrative advantages of PKI seem to be lost if each client's cert needs to be distributed to all servers. But on the other hand - how will the certificate->username mapping be done otherwise? (Each cert should only be allowed for one username.) > (3) Also how can we authenticate clients selectively using the > fields of the client certificate in case of OpenSSH (with X.509 > support). Again I suspect this would be trivial to add, depending on the criterias you would like to use. //Peter From djm at mindrot.org Thu Mar 13 12:28:13 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Mar 2008 12:28:13 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: On Thu, 13 Mar 2008, Damien Miller wrote: > This release includes some interoperability tests against PuTTY's > plink(1). These tests may be run using "make interop-tests" if you > have plink(1) installed. FYI these tests were broken unless you happened to have plink and puttygen installed in /usr/local/bin. I'm just about to commit a fix, so if you want to play with these then grab a snapshot dated after 20080314 (this will be available in about 12 hours) or use anoncvs in an hour or so. -d From tusker at tusker.org Thu Mar 13 13:17:44 2008 From: tusker at tusker.org (Damien Mascord) Date: Thu, 13 Mar 2008 10:17:44 +0800 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <20080313010324.21750.qmail@cdy.org> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47D7C3BE.1080502@persistent.co.in> <20080313010324.21750.qmail@cdy.org> Message-ID: <47D88EC8.4070105@tusker.org> Peter Stuge wrote: >> then, is there any workaround to eliminate the need to append the >> ".pub" part of it to the "authorized_keys" file on the Server. >> > > Here I agree with you - the administrative advantages of PKI seem to > be lost if each client's cert needs to be distributed to all servers. > > But on the other hand - how will the certificate->username mapping be > done otherwise? (Each cert should only be allowed for one username.) > Hi Peter, Wouldn't you be able to do this with the certificate signature, rather than the entire certificate ? Cheers, Damien From stuge-openssh-unix-dev at cdy.org Thu Mar 13 15:13:42 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 13 Mar 2008 05:13:42 +0100 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47D88EC8.4070105@tusker.org> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47D7C3BE.1080502@persistent.co.in> <20080313010324.21750.qmail@cdy.org> <47D88EC8.4070105@tusker.org> Message-ID: <20080313041342.10689.qmail@cdy.org> On Thu, Mar 13, 2008 at 10:17:44AM +0800, Damien Mascord wrote: > > But on the other hand - how will the certificate->username mapping be > > done otherwise? (Each cert should only be allowed for one username.) First a correction; one cert might be allowed for several usernames, but not neccessarily all usernames. > Wouldn't you be able to do this with the certificate signature, > rather than the entire certificate ? Where is/are username(s) stored? How will sshd match cert with username once the CA signature has been validated? //Peter From stuge-openssh-unix-dev at cdy.org Thu Mar 13 15:14:53 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 13 Mar 2008 05:14:53 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: <20080313041453.11009.qmail@cdy.org> On Thu, Mar 13, 2008 at 12:28:13PM +1100, Damien Miller wrote: > > This release includes some interoperability tests against PuTTY's > > plink(1). These tests may be run using "make interop-tests" if > > you have plink(1) installed. > > FYI these tests were broken unless you happened to have plink and > puttygen installed in /usr/local/bin. I'm just about to commit a > fix, so if you want to play with these then grab a snapshot dated > after 20080314 (this will be available in about 12 hours) or use > anoncvs in an hour or so. Just did cvs get, but still: /home/ossh/openssh/regress/test-exec.sh: line 297: puttygen: command not found /home/ossh/openssh/regress/test-exec.sh: line 298: puttygen: command not found //Peter From stuge-openssh-unix-dev at cdy.org Thu Mar 13 15:17:36 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 13 Mar 2008 05:17:36 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080313041453.11009.qmail@cdy.org> References: <20080313041453.11009.qmail@cdy.org> Message-ID: <20080313041736.11628.qmail@cdy.org> Nice sftp improvements btw! :) On Thu, Mar 13, 2008 at 05:14:53AM +0100, Peter Stuge wrote: > Just did cvs get, but still: > > /home/ossh/openssh/regress/test-exec.sh: line 297: puttygen: command not found > /home/ossh/openssh/regress/test-exec.sh: line 298: puttygen: command not found ..and: run test sftp-cmds.sh ... which: no plink in .. which: no puttygen in .. /home/ossh/openssh/regress/test-exec.sh: line 297: puttygen: command not found /home/ossh/openssh/regress/test-exec.sh: line 298: puttygen: command not found sftp commands: lls lls failed .. failed sftp commands make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/home/ossh/openssh/regress' make: *** [tests] Error 2 //Peter From djm at mindrot.org Thu Mar 13 15:41:37 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Mar 2008 15:41:37 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080313041453.11009.qmail@cdy.org> References: <20080313041453.11009.qmail@cdy.org> Message-ID: On Thu, 13 Mar 2008, Peter Stuge wrote: > On Thu, Mar 13, 2008 at 12:28:13PM +1100, Damien Miller wrote: > > > This release includes some interoperability tests against PuTTY's > > > plink(1). These tests may be run using "make interop-tests" if > > > you have plink(1) installed. > > > > FYI these tests were broken unless you happened to have plink and > > puttygen installed in /usr/local/bin. I'm just about to commit a > > fix, so if you want to play with these then grab a snapshot dated > > after 20080314 (this will be available in about 12 hours) or use > > anoncvs in an hour or so. > > Just did cvs get, but still: > > /home/ossh/openssh/regress/test-exec.sh: line 297: puttygen: command not found > /home/ossh/openssh/regress/test-exec.sh: line 298: puttygen: command not found Is puttygen in your $PATH? or do you not have it installed at all? Either way, please try this diff: Index: regress/test-exec.sh =================================================================== RCS file: /var/cvs/openssh/regress/test-exec.sh,v retrieving revision 1.32 diff -u -p -r1.32 test-exec.sh --- regress/test-exec.sh 13 Mar 2008 01:41:31 -0000 1.32 +++ regress/test-exec.sh 13 Mar 2008 04:40:32 -0000 @@ -104,14 +104,14 @@ if [ "x$TEST_SSH_PLINK" != "x" ]; then # Find real binary, if it exists case "${TEST_SSH_PLINK}" in /*) PLINK="${TEST_SSH_PLINK}" ;; - *) PLINK=`which ${TEST_SSH_PLINK}` ;; + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; esac fi if [ "x$TEST_SSH_PUTTYGEN" != "x" ]; then # Find real binary, if it exists case "${TEST_SSH_PUTTYGEN}" in /*) PUTTYGEN="${TEST_SSH_PUTTYGEN}" ;; - *) PUTTYGEN=`which ${TEST_SSH_PUTTYGEN}` ;; + *) PUTTYGEN=`which ${TEST_SSH_PUTTYGEN} 2>/dev/null` ;; esac fi From djm at mindrot.org Thu Mar 13 15:45:39 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Mar 2008 15:45:39 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080313041736.11628.qmail@cdy.org> References: <20080313041453.11009.qmail@cdy.org> <20080313041736.11628.qmail@cdy.org> Message-ID: On Thu, 13 Mar 2008, Peter Stuge wrote: > Nice sftp improvements btw! :) Thanks, and double thanks for testing. > run test sftp-cmds.sh ... > which: no plink in .. > which: no puttygen in .. > /home/ossh/openssh/regress/test-exec.sh: line 297: puttygen: command > not found > /home/ossh/openssh/regress/test-exec.sh: line 298: puttygen: command > not found > sftp commands: lls > lls failed Unfortunately the regress tests aren't too friendly in logging what has actually gone wrong (especially for the sftp ones). To see what broke, you can edit regress/sftp-cmds.sh and change: verbose "$tid: lls" echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ grep -q copy.dd || fail "lls failed" (around line 241) to: echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} and inspect the output yourself. -d From Benjamin.Kellermann at gmx.de Thu Mar 13 06:23:47 2008 From: Benjamin.Kellermann at gmx.de (Benjamin Kellermann) Date: Wed, 12 Mar 2008 20:23:47 +0100 Subject: Bug+bugfix in ssh-copy-id Message-ID: <1205349827.11605.4.camel@dud77.inf.tu-dresden.de> Hi! the script ssh-copy-id assumes, that the remote machine has a POSIX Compatible shell as login shell. So you have to write in line 41: ? ssh $1 'sh -c "umask 077; test ? instead of ? ssh $1 "umask 077; test ? Patch is appended. Greetings, Benjamin Kellermann -- GPG-Key-ID: 491A3D9C Fingerprint: D19E 04A8 8895 020A 8DF6 0092 3501 1A32 491A 3D9C http://pgpkeys.pca.dfn.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-copy-id.patch Type: text/x-patch Size: 246 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080312/89d15ed4/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080312/89d15ed4/attachment-0001.bin From jonhson.ian at gmail.com Thu Mar 13 19:27:10 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Thu, 13 Mar 2008 16:27:10 +0800 Subject: Openssh to support X509 certificates Message-ID: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> Hello, I have paid attention to the issue about the X509-based certificate support in standard openssh. Because I also need the support of X509-based certificates in my project, and also I have developed specific version of openssh to pass the proxy certificate from client to server. But I used the PAM module to verify the proxy and authorize the accessors. I wonder whether current support in openssh mainstream can pass the client proxy certificate to server, so that PAM module can authenticate user by its proxy certificate. Thanks a lot, Ian From vinschen at redhat.com Thu Mar 13 21:35:30 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 13 Mar 2008 11:35:30 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: <20080313103530.GD18407@calimero.vinschen.de> Hi, On Mar 13 11:50, Damien Miller wrote: > Hi, > > We are preparing to make the release of OpenSSH 4.8 soon, so we would > greatly appreciate testing of snapshot releases in as many environments > and on as many operating systems as possible. Built for current Cygwin relase 1.5.25-11. There's a bug in scp.c when including poll.h. For some reason it only tries to include sys/poll.h, but not the POSIX-compliant poll.h. I had to apply the below patch to be able to build scp: Index: scp.c =================================================================== RCS file: /cvs/openssh/scp.c,v retrieving revision 1.178 diff -p -u -r1.178 scp.c --- scp.c 29 Feb 2008 04:07:02 -0000 1.178 +++ scp.c 13 Mar 2008 09:38:56 -0000 @@ -78,8 +78,12 @@ #ifdef HAVE_SYS_STAT_H # include #endif -#ifdef HAVE_SYS_POLL_H -# include +#ifdef HAVE_POLL_H +#include +#else +# ifdef HAVE_SYS_POLL_H +# include +# endif #endif #ifdef HAVE_SYS_TIME_H # include After applying this patch, everything built OOTB and the testsuite ran more or less fine, except for the puttygen stuff, which I don't have installed. There's also a fail in sftp-cmds.sh: sftp commands: lls lls failed It turns out to be two bugs in the test script: verbose "$tid: lls" echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ grep -q copy.dd || fail "lls failed" First of all, when testing "lls", the cd should be "lcd". Second, coreutils' echo(1) command does not understand the \n syntax, unless you also specify the -e option. I assume the most portable approach is to embed a real LF in the command, like in the below patch (which also fixes the cd v. lcd bug: Index: regress/sftp-cmds.sh =================================================================== RCS file: /cvs/openssh/regress/sftp-cmds.sh,v retrieving revision 1.16 diff -p -u -r1.16 sftp-cmds.sh --- regress/sftp-cmds.sh 12 Mar 2008 12:59:44 -0000 1.16 +++ regress/sftp-cmds.sh 13 Mar 2008 10:14:33 -0000 @@ -44,7 +44,8 @@ rm -rf ${COPY} ${COPY}.1 ${COPY}.2 ${COP mkdir ${COPY}.dd verbose "$tid: lls" -echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ +echo "lcd ${OBJ} +lls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ grep -q copy.dd || fail "lls failed" verbose "$tid: lls w/path" Also sftp-glob fails on Cygwin, because it tests for files which can't be created on Windows file systems where certain characters are not allowed in filenames ( '"', '<', '>', '?', '\\', '|', '*' ':' ). I don't have a patch for that right now, especially given that the next major version of Cygwin will probably allow to create files with these characters using a trick which is also used by Interix(*) :) Corinna (*) Filenames are stored in UTF-16 on Windows filesystems. All invalid chars just get or'ed with 0xf000 when storing the filename and and'ed with 0xff when retrieving the filename from the file system. -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From sankalp_karpe at persistent.co.in Fri Mar 14 01:57:47 2008 From: sankalp_karpe at persistent.co.in (sankalp_karpe) Date: Thu, 13 Mar 2008 20:27:47 +0530 Subject: [Fwd: Re: OpenSSH and X.509 Certificate Support] Message-ID: <47D940EB.6060106@persistent.co.in> Hi Roumen, I discovered that the need of appending the .pub part of id_rsa(client key+cert) on the server can be eliminated by adding the Certificate Blob to authorized_keys which could look something like this: x509v3-sign-rsa subject= /C=FR/ST=PARIS/L=DESEl/O=SSL/OU=VLSI/CN=10.244.82.83/emailAddress=client at company.com This is extracted from the client certificate using openssl as described in the README file provided by you at http://roumenpetrov.info/openssh/x509h/README.x509v3 This system works fine, however my only concern is that I would like all Clients (possessing a valid Client-Certifcates signed by the CA) to be authenticated without having to place anything in the ~/.ssh/authorized_keys file on the server.(i.e authenticate all users if they have a valid certificate without any subject line checking). In Apache this is very much possible via mod_ssl as described in http://www.modssl.org/docs/2.8/ssl_howto.html#ToC6 . Can a similar behavior be emulated in OpenSSH using the X.509 patch? Please let me know your comments. Thanks and Best Regards, Sankalp -------- Original Message -------- Subject: Re: OpenSSH and X.509 Certificate Support Date: Wed, 12 Mar 2008 17:21:26 +0530 From: sankalp_karpe To: Roumen Petrov CC: OpenSSH Devel List , sankalp_karpe References: <47BC01CC.60409 at persistent.co.in> <47BC83CB.3080007 at roumenpetrov.info> <47BD71DE.3050002 at persistent.co.in> <47BDDAA4.3010405 at roumenpetrov.info> <47C6AA07.2050003 at persistent.co.in> <47C70A45.7090903 at roumenpetrov.info> Hi Roumen, I tried your suggestions and could successfully connect to the OpenSSH Server with X.509 patch from a non-patched SSH Client using username/password. The main requirement that I have is for the Client to be authenticated via a Client certificate using SSH and Apache. I have been able to successfully achieve the same using Apache + mod_ssl for web server access to my system. In order to enable the same authentication mechanism for command-line access to my system that uses OpenSSH, I patched OpenSSH with the X.509 patch you developed between two Linux FC6 machines. Ideally I would like it to be something like: 1. The client sends the user certificate (which includes the user's public key) to the server. The packet also contains data unique to the session and it is signed by the user's private key. 2. The server uses the CA certificate to check that the user's certificate is valid. 3. The server verifies that the user has a valid private key by checking the signature in the initial packet. 4. The server matches the user certificate against the rules in the server configuration file to decide whether login is allowed or not. When looking for information on X.509 Certificate support for SSH, I had come across a commercial version of SSH (SSH Tectia Client/Server) which claims to support the above authentication sequence. Also, it supports selective field based authentication of the Client Certificates, for example: However, I need to see how I can extend the OpenSSH of my system to support X.509 Certificates and cannot use any commercial version of SSH. Implementing X.509 Certificate support for OpenSSH (using the X.509 patch you developed) requires that the client certificate be appended to the Client key in id_rsa and public part of the client key+certificate (i.e. id_rsa.pub) to be appended to the authorized_keys file on the server, and each time a new client (OpenSSH patched with X.509) is added to the network, its corresponding id_rsa.pub has to be appended to the server's authorized_keys. So, I have the following concerns and would request your comments on the same: (1) Isn't this an overhead as compared to what we would do in Web Server Authentication (Apache) where-in we provide the client with just a certificate, and not having to create a custom file containing the Client key+certificate (id_rsa) like we do for OpenSSH patched with X.509. (2) If we need to have the "client key + client certificate" in id_rsa, then, is there any workaround to eliminate the need to append the ".pub" part of it to the "authorized_keys" file on the Server. (3) Also how can we authenticate clients selectively using the fields of the client certificate in case of OpenSSH (with X.509 support). Your help would be highly appreciated. Thanking you in anticipation. Thanks and Best Regards, Sankalp Roumen Petrov wrote: >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 >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From tim at multitalents.net Fri Mar 14 02:07:11 2008 From: tim at multitalents.net (Tim Rice) Date: Thu, 13 Mar 2008 08:07:11 -0700 (PDT) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313041453.11009.qmail@cdy.org> Message-ID: On Thu, 13 Mar 2008, Damien Miller wrote: > > Either way, please try this diff: > - *) PLINK=`which ${TEST_SSH_PLINK}` ;; > + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; You can not expect which to be on all platforms. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From imorgan at nas.nasa.gov Fri Mar 14 05:16:05 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 13 Mar 2008 11:16:05 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080313173722.GA24697@linux55.nas.nasa.gov> References: <20080313173722.GA24697@linux55.nas.nasa.gov> Message-ID: <20080313181605.GA21542@linux55.nas.nasa.gov> On Thu, Mar 13, 2008 at 10:37:22 -0700, Iain Morgan wrote: > > Both builds fail the regression tests: > > sftp commands: put to directory > sftp commands: glob put to directory > sftp commands: put to local dir > sftp commands: glob put to local dir > sftp commands: rename > sftp commands: rename directory > sftp commands: ln > sftp commands: mkdir > sftp commands: chdir > sftp commands: rmdir > sftp commands: lmkdir > sftp commands: lchdir > failed sftp commands > make[1]: *** [t-exec] Error 1 > Scrolling back I see that this seems to be the same plink/puttygen issue thta Peter reported. -- Iain Morgan From bob at proulx.com Fri Mar 14 05:23:09 2008 From: bob at proulx.com (Bob Proulx) Date: Thu, 13 Mar 2008 12:23:09 -0600 Subject: Bug+bugfix in ssh-copy-id In-Reply-To: <1205349827.11605.4.camel@dud77.inf.tu-dresden.de> References: <1205349827.11605.4.camel@dud77.inf.tu-dresden.de> Message-ID: <20080313182309.GC26215@dementia.proulx.com> Benjamin Kellermann wrote: > the script ssh-copy-id assumes, that the remote machine has a POSIX > Compatible shell as login shell. > ... > Patch is appended. Thank you for your submission. The ssh-copy-id command was just recently the subject of intense discussion this last month. To catch up on the discussion you may want to review the mailing list archives. Here are pointers to the start of several related threads. https://lists.mindrot.org/pipermail/openssh-unix-dev/2008-February/026116.html https://lists.mindrot.org/pipermail/openssh-unix-dev/2008-February/026125.html https://lists.mindrot.org/pipermail/openssh-unix-dev/2008-February/026129.html https://lists.mindrot.org/pipermail/openssh-unix-dev/2008-February/026140.html Bob From imorgan at nas.nasa.gov Fri Mar 14 04:37:22 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 13 Mar 2008 10:37:22 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: <20080313173722.GA24697@linux55.nas.nasa.gov> On Thu, Mar 13, 2008 at 11:50:25 +1100, Damien Miller wrote: > Hi, > > We are preparing to make the release of OpenSSH 4.8 soon, so we would > greatly appreciate testing of snapshot releases in as many environments > and on as many operating systems as possible. > I've noticed a few quirks thus far using the 20080314 snapshot. First, doing 'make realclean' removes the configure script. Next, it builds on RHEL 4 using gcc, but it fails when using c99. make[1]: Entering directory `/u/wk/imorgan/src/openssh/openssh/openbsd-compat' c99 -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -I. -I.. -I. -I./.. -I/u/wk/imorgan/build/include -DHAVE_CONFIG_H -c bsd-arc4random.c In file included from ../openbsd-compat/openbsd-compat.h:194, from ../includes.h:167, from bsd-arc4random.c:17: ../openbsd-compat/fake-rfc2553.h:133: error: redefinition of `struct addrinfo' make[1]: *** [bsd-arc4random.o] Error 1 On SLES 10 using icc 9.1, it builds. Strangely, it attempts to use the gcc stack protection option with the Intel compiler. Both builds fail the regression tests: sftp commands: put to directory sftp commands: glob put to directory sftp commands: put to local dir sftp commands: glob put to local dir sftp commands: rename sftp commands: rename directory sftp commands: ln sftp commands: mkdir sftp commands: chdir sftp commands: rmdir sftp commands: lmkdir sftp commands: lchdir failed sftp commands make[1]: *** [t-exec] Error 1 -- Iain Morgan From imorgan at nas.nasa.gov Fri Mar 14 07:11:13 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 13 Mar 2008 13:11:13 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: <20080313201113.GA22761@linux55.nas.nasa.gov> regress/sftp-cmds.sh will fail on some platforms because it assumes that the echo command supports C-style escape codes. verbose "$tid: lls" echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ grep -q copy.dd || fail "lls failed" To fix this, it might be better to do something like this: verbose "$tid: lls" (echo "cd ${OBJ}"; echo "lls") | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ grep -q copy.dd || fail "lls failed" Using 'echo -e' would be nicer, but that's not universal either. -- Iain Morgan From mouring at eviladmin.org Fri Mar 14 08:12:16 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 13 Mar 2008 16:12:16 -0500 (CDT) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080313173722.GA24697@linux55.nas.nasa.gov> References: <20080313173722.GA24697@linux55.nas.nasa.gov> Message-ID: On Thu, 13 Mar 2008, Iain Morgan wrote: > On Thu, Mar 13, 2008 at 11:50:25 +1100, Damien Miller wrote: >> Hi, >> >> We are preparing to make the release of OpenSSH 4.8 soon, so we would >> greatly appreciate testing of snapshot releases in as many environments >> and on as many operating systems as possible. >> > > I've noticed a few quirks thus far using the 20080314 snapshot. > > First, doing 'make realclean' removes the configure script. > Has done that for the last 4+ years.. Nothing new here. - Ben From stuge-openssh-unix-dev at cdy.org Fri Mar 14 08:42:23 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 13 Mar 2008 22:42:23 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313041453.11009.qmail@cdy.org> Message-ID: <20080313214223.30060.qmail@cdy.org> On Thu, Mar 13, 2008 at 03:41:37PM +1100, Damien Miller wrote: > > > FYI these tests were broken unless you happened to have plink and > > > puttygen installed in /usr/local/bin. I'm just about to commit a > > > fix > > /home/ossh/openssh/regress/test-exec.sh: line 297: puttygen: command not found > > /home/ossh/openssh/regress/test-exec.sh: line 298: puttygen: command not found > > Is puttygen in your $PATH? or do you not have it installed at all? Not installed at all. > Either way, please try this diff: > > Index: regress/test-exec.sh > =================================================================== > RCS file: /var/cvs/openssh/regress/test-exec.sh,v > retrieving revision 1.32 > diff -u -p -r1.32 test-exec.sh > --- regress/test-exec.sh 13 Mar 2008 01:41:31 -0000 1.32 > +++ regress/test-exec.sh 13 Mar 2008 04:40:32 -0000 > @@ -104,14 +104,14 @@ if [ "x$TEST_SSH_PLINK" != "x" ]; then > # Find real binary, if it exists > case "${TEST_SSH_PLINK}" in > /*) PLINK="${TEST_SSH_PLINK}" ;; > - *) PLINK=`which ${TEST_SSH_PLINK}` ;; > + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; This helps remove the error message from which. In addition I need the following patch to fix the errors I reported: Index: regress/test-exec.sh =================================================================== RCS file: /cvs/openssh/regress/test-exec.sh,v retrieving revision 1.32 diff -u -r1.32 test-exec.sh --- regress/test-exec.sh 13 Mar 2008 01:41:31 -0000 1.32 +++ regress/test-exec.sh 13 Mar 2008 17:31:28 -0000 @@ -289,7 +289,7 @@ # If PuTTY is present, prepare keys and configuration REGRESS_INTEROP_PUTTY=no -if test -x $PUTTYGEN -a -x $PLINK ; then +if test -x "${PUTTYGEN}" -a -x "${PLINK}" ; then mkdir -p ${OBJ}/.putty # Add a PuTTY key to authorized_keys Along with Corinna's sftp-cmds.sh patch all tests now pass on i686 Gentoo Linux with glibc-2.6.1. //Peter From imorgan at nas.nasa.gov Fri Mar 14 11:20:16 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 13 Mar 2008 17:20:16 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080313201113.GA22761@linux55.nas.nasa.gov> References: <20080313201113.GA22761@linux55.nas.nasa.gov> Message-ID: <20080314002016.GB22761@linux55.nas.nasa.gov> On Thu, Mar 13, 2008 at 13:11:13 -0700, Iain Morgan wrote: > regress/sftp-cmds.sh will fail on some platforms because it assumes that > the echo command supports C-style escape codes. > > verbose "$tid: lls" > echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > grep -q copy.dd || fail "lls failed" > > To fix this, it might be better to do something like this: > > verbose "$tid: lls" > (echo "cd ${OBJ}"; echo "lls") | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > grep -q copy.dd || fail "lls failed" > > Using 'echo -e' would be nicer, but that's not universal either. > One further note: On Solaris 9 /usr/bin/grep does not support a -q option, whereas /usr/xpg4/bin/grep does. It may be best to just direct the output to /dev/null rather than relying on -q. -- Iain Morgan From tim at multitalents.net Fri Mar 14 12:49:11 2008 From: tim at multitalents.net (Tim Rice) Date: Thu, 13 Mar 2008 18:49:11 -0700 (PDT) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080313103530.GD18407@calimero.vinschen.de> References: <20080313103530.GD18407@calimero.vinschen.de> Message-ID: On Thu, 13 Mar 2008, Corinna Vinschen wrote: > Hi, > > > Built for current Cygwin relase 1.5.25-11. > > There's a bug in scp.c when including poll.h. For some reason it only > tries to include sys/poll.h, but not the POSIX-compliant poll.h. I had > to apply the below patch to be able to build scp: Commited. Thanks for the report/patch/testing. > verbose "$tid: lls" > echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > grep -q copy.dd || fail "lls failed" > > First of all, when testing "lls", the cd should be "lcd". Maybe it'll be obvious in the morning but right now I have to ask why "lcd"? > Second, coreutils' echo(1) command does not understand the \n syntax, > unless you also specify the -e option. I assume the most portable > approach is to embed a real LF in the command, like in the below patch > (which also fixes the cd v. lcd bug: Fix for \n commited. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Fri Mar 14 13:20:09 2008 From: tim at multitalents.net (Tim Rice) Date: Thu, 13 Mar 2008 19:20:09 -0700 (PDT) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080314002016.GB22761@linux55.nas.nasa.gov> References: <20080313201113.GA22761@linux55.nas.nasa.gov> <20080314002016.GB22761@linux55.nas.nasa.gov> Message-ID: On Thu, 13 Mar 2008, Iain Morgan wrote: > On Thu, Mar 13, 2008 at 13:11:13 -0700, Iain Morgan wrote: > > (echo "cd ${OBJ}"; echo "lls") | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > > grep -q copy.dd || fail "lls failed" > > > > Using 'echo -e' would be nicer, but that's not universal either. > > > > One further note: On Solaris 9 /usr/bin/grep does not support a -q > option, whereas /usr/xpg4/bin/grep does. It may be best to just direct > the output to /dev/null rather than relying on -q. Commited fixes for the \n and grep -q. Thanks for the report. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From sankalp_karpe at persistent.co.in Fri Mar 14 15:54:58 2008 From: sankalp_karpe at persistent.co.in (sankalp_karpe) Date: Fri, 14 Mar 2008 10:24:58 +0530 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47C70A45.7090903@roumenpetrov.info> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> Message-ID: <47DA0522.6090904@persistent.co.in> Hi Roumen, I discovered that the need of appending the .pub part of id_rsa(client key+cert) on the server can be eliminated by adding the Certificate Blob to authorized_keys which could look something like this: x509v3-sign-rsa subject= /C=FR/ST=PARIS/L=DESEl/O=SSL/OU=VLSI/CN=10.244.82.83/emailAddress=client at company.com This is extracted from the client certificate using openssl as described in the README file provided by you at http://roumenpetrov.info/openssh/x509h/README.x509v3 This system works fine, however my only concern is that I would like all Clients (possessing a valid Client-Certifcates signed by the CA) to be authenticated without having to place anything in the ~/.ssh/authorized_keys file on the server.(i.e authenticate all users if they have a valid certificate without any subject line checking). In Apache this is very much possible via mod_ssl as described in http://www.modssl.org/docs/2.8/ssl_howto.html#ToC6 . Can a similar behavior be emulated in OpenSSH using the X.509 patch? Please let me know your comments. Thanks and Best Regards, Sankalp From jonhson.ian at gmail.com Fri Mar 14 20:36:58 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Fri, 14 Mar 2008 17:36:58 +0800 Subject: Openssh to support X509 certificates In-Reply-To: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> References: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> Message-ID: <8f34198c0803140236q4ee3829co4e26d058a497bef8@mail.gmail.com> No one is welling to answer me? On Thu, Mar 13, 2008 at 4:27 PM, Ian jonhson wrote: > Hello, > > I have paid attention to the issue about the X509-based certificate support in > standard openssh. > > Because I also need the support of X509-based certificates in my project, > and also I have developed specific version of openssh to pass the > proxy certificate from client to server. But I used the PAM module > to verify the proxy and authorize the accessors. > > I wonder whether current support in openssh mainstream can pass > the client proxy certificate to server, so that PAM module can > authenticate user by its proxy certificate. > > Thanks a lot, > > Ian > From vinschen at redhat.com Fri Mar 14 21:20:31 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 14 Mar 2008 11:20:31 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313103530.GD18407@calimero.vinschen.de> Message-ID: <20080314102031.GB14647@calimero.vinschen.de> On Mar 13 18:49, Tim Rice wrote: > On Thu, 13 Mar 2008, Corinna Vinschen wrote: > [...] > > echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > > grep -q copy.dd || fail "lls failed" > > > > First of all, when testing "lls", the cd should be "lcd". > > Maybe it'll be obvious in the morning but right now I have to ask why "lcd"? When you test ls in a *local* directory, you probably should cd to the *local* directory you want to call ls in? cd -> ls lcd -> lls Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From janfrode at tanso.net Fri Mar 14 22:25:33 2008 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Fri, 14 Mar 2008 12:25:33 +0100 Subject: Testing wanted: OpenSSH 4.8 References: Message-ID: On 2008-03-13, Damien Miller wrote: > > The highlights of this release are: > > * Added chroot(2) support for sshd(8), controlled by a new option > "ChrootDirectory". Please refer to sshd_config(5) for details, and > please use this feature carefully. (bz#177 bz#1352) I miss some documentation on this feature... It seems to require: UsePrivilegeSeparation no and maybe it's strongly adviceable to also use: AllowTcpForwarding no X11Forwarding no PermitUserEnvironment no # and more ? Here's my current config. Any comments on other things that should be set for a safe chrooted sftp-server ? Protocol 2 PermitRootLogin no StrictModes yes IgnoreRhosts yes PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no AllowTcpForwarding no X11Forwarding no PrintMotd yes PrintLastLog yes UsePrivilegeSeparation no PermitUserEnvironment no PidFile /var/run/sshd-external.pid PermitTunnel no Banner no Subsystem sftp internal-sftp ChrootDirectory /var/empty/sshd-external-chroot/ ForceCommand internal-sftp AllowGroup chroot_users Match group chroot_users ChrootDirectory /var/ftp/%u -jf From imorgan at nas.nasa.gov Sat Mar 15 04:28:20 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 14 Mar 2008 10:28:20 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080314002016.GB22761@linux55.nas.nasa.gov> References: <20080313201113.GA22761@linux55.nas.nasa.gov> <20080314002016.GB22761@linux55.nas.nasa.gov> Message-ID: <20080314172820.GC22761@linux55.nas.nasa.gov> On Thu, Mar 13, 2008 at 17:20:16 -0700, Iain Morgan wrote: > On Thu, Mar 13, 2008 at 13:11:13 -0700, Iain Morgan wrote: > > regress/sftp-cmds.sh will fail on some platforms because it assumes that > > the echo command supports C-style escape codes. > > > > verbose "$tid: lls" > > echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > > grep -q copy.dd || fail "lls failed" > > > > To fix this, it might be better to do something like this: > > > > verbose "$tid: lls" > > (echo "cd ${OBJ}"; echo "lls") | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > > grep -q copy.dd || fail "lls failed" > > > > Using 'echo -e' would be nicer, but that's not universal either. > > > > One further note: On Solaris 9 /usr/bin/grep does not support a -q > option, whereas /usr/xpg4/bin/grep does. It may be best to just direct > the output to /dev/null rather than relying on -q. > One more regression test issue found on Solaris. /bin/sh on Solaris does not support the $() syntax. this breaks regress/localcommand.sh. It would be more portable to use backticks instead. With that adjustment along with the others previously mentioned on the list, the 20080314 snapshot builds and tests OK on Solaris 9/SPARC with with the Sun Forte compilers. -- Iain Morgan From tim at multitalents.net Sat Mar 15 04:41:17 2008 From: tim at multitalents.net (Tim Rice) Date: Fri, 14 Mar 2008 10:41:17 -0700 (PDT) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080314102031.GB14647@calimero.vinschen.de> References: <20080313103530.GD18407@calimero.vinschen.de> <20080314102031.GB14647@calimero.vinschen.de> Message-ID: On Fri, 14 Mar 2008, Corinna Vinschen wrote: > On Mar 13 18:49, Tim Rice wrote: > > On Thu, 13 Mar 2008, Corinna Vinschen wrote: > > [...] > > > echo "cd ${OBJ}\nlls" | ${SFTP} -P ${SFTPSERVER} 2>&1 | \ > > > grep -q copy.dd || fail "lls failed" > > > > > > First of all, when testing "lls", the cd should be "lcd". > > > > Maybe it'll be obvious in the morning but right now I have to ask why "lcd"? > > When you test ls in a *local* directory, you probably should cd to the > *local* directory you want to call ls in? > > cd -> ls > lcd -> lls Duh, agreed. Change commited. Thanks > > Corinna > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vinschen at redhat.com Sat Mar 15 04:54:14 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 14 Mar 2008 18:54:14 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313103530.GD18407@calimero.vinschen.de> <20080314102031.GB14647@calimero.vinschen.de> Message-ID: <20080314175414.GM5306@calimero.vinschen.de> On Mar 14 10:41, Tim Rice wrote: > On Fri, 14 Mar 2008, Corinna Vinschen wrote: > > On Mar 13 18:49, Tim Rice wrote: > > > On Thu, 13 Mar 2008, Corinna Vinschen wrote: > > > > First of all, when testing "lls", the cd should be "lcd". > > > > > > Maybe it'll be obvious in the morning but right now I have to ask why "lcd"? > > > > When you test ls in a *local* directory, you probably should cd to the > > *local* directory you want to call ls in? > > Duh, agreed. Change commited. Thanks! Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Sat Mar 15 05:04:56 2008 From: tim at multitalents.net (Tim Rice) Date: Fri, 14 Mar 2008 11:04:56 -0700 (PDT) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080314172820.GC22761@linux55.nas.nasa.gov> References: <20080313201113.GA22761@linux55.nas.nasa.gov> <20080314002016.GB22761@linux55.nas.nasa.gov> <20080314172820.GC22761@linux55.nas.nasa.gov> Message-ID: On Fri, 14 Mar 2008, Iain Morgan wrote: > One more regression test issue found on Solaris. /bin/sh on Solaris does > not support the $() syntax. this breaks regress/localcommand.sh. It > would be more portable to use backticks instead. I just noticed that on UnixWare too. Fix commited. Thanks for the report. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From stuge-openssh-unix-dev at cdy.org Sat Mar 15 05:16:06 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 14 Mar 2008 19:16:06 +0100 Subject: Openssh to support X509 certificates In-Reply-To: <8f34198c0803140236q4ee3829co4e26d058a497bef8@mail.gmail.com> References: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> <8f34198c0803140236q4ee3829co4e26d058a497bef8@mail.gmail.com> Message-ID: <20080314181606.23762.qmail@cdy.org> On Fri, Mar 14, 2008 at 05:36:58PM +0800, Ian jonhson wrote: > No one is welling to answer me? I don't think that is the case. Keep in mind that any help on this list is strictly voluntary and free of charge. Maybe you could find someone who offers a commercial support service for the certificate extension if that is what you're after? //Peter From stuge-openssh-unix-dev at cdy.org Sat Mar 15 06:03:37 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 14 Mar 2008 20:03:37 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313201113.GA22761@linux55.nas.nasa.gov> <20080314002016.GB22761@linux55.nas.nasa.gov> Message-ID: <20080314190337.5820.qmail@cdy.org> On Thu, Mar 13, 2008 at 07:20:09PM -0700, Tim Rice wrote: > Commited fixes for the \n and grep -q. Ping on the putty -x quoting so it isn't dropped. //Peter From djm at mindrot.org Sat Mar 15 09:20:21 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Mar 2008 09:20:21 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: On Fri, 14 Mar 2008, Jan-Frode Myklebust wrote: > On 2008-03-13, Damien Miller wrote: > > > > The highlights of this release are: > > > > * Added chroot(2) support for sshd(8), controlled by a new option > > "ChrootDirectory". Please refer to sshd_config(5) for details, and > > please use this feature carefully. (bz#177 bz#1352) > > I miss some documentation on this feature... > > It seems to require: > > UsePrivilegeSeparation no No, it should not and does not on the platforms I have tested on. What errors do you see when privsep is enabled? > and maybe it's strongly adviceable to also use: > > AllowTcpForwarding no > X11Forwarding no > PermitUserEnvironment no > # and more ? For some uses, sure. -d From djm at mindrot.org Sat Mar 15 09:23:05 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Mar 2008 09:23:05 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313041453.11009.qmail@cdy.org> Message-ID: On Thu, 13 Mar 2008, Tim Rice wrote: > On Thu, 13 Mar 2008, Damien Miller wrote: > > > > > Either way, please try this diff: > > - *) PLINK=`which ${TEST_SSH_PLINK}` ;; > > + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; > > You can not expect which to be on all platforms. We already use `which` for determining an absolute path to sshd in test-exec.sh. Do you have an alternative? -d From djm at mindrot.org Sat Mar 15 09:29:18 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Mar 2008 09:29:18 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080314190337.5820.qmail@cdy.org> References: <20080313201113.GA22761@linux55.nas.nasa.gov> <20080314002016.GB22761@linux55.nas.nasa.gov> <20080314190337.5820.qmail@cdy.org> Message-ID: On Fri, 14 Mar 2008, Peter Stuge wrote: > On Thu, Mar 13, 2008 at 07:20:09PM -0700, Tim Rice wrote: > > Commited fixes for the \n and grep -q. > > Ping on the putty -x quoting so it isn't dropped. Committed - thanks for the reminder. -d From tim at multitalents.net Sat Mar 15 09:32:17 2008 From: tim at multitalents.net (Tim Rice) Date: Fri, 14 Mar 2008 15:32:17 -0700 (PDT) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313041453.11009.qmail@cdy.org> Message-ID: On Sat, 15 Mar 2008, Damien Miller wrote: > On Thu, 13 Mar 2008, Tim Rice wrote: > > > On Thu, 13 Mar 2008, Damien Miller wrote: > > > Either way, please try this diff: > > > - *) PLINK=`which ${TEST_SSH_PLINK}` ;; > > > + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; > > > > You can not expect which to be on all platforms. > > We already use `which` for determining an absolute path to sshd in > test-exec.sh. Do you have an alternative? Yes I noticed that after I posted. No I don't have an alternative. On further reflection I think it's only some older openserver platforms that will be affected and they will have other things broken in them anyway. Go ahead and use which. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From janfrode at tanso.net Sat Mar 15 11:23:12 2008 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Sat, 15 Mar 2008 01:23:12 +0100 Subject: Testing wanted: OpenSSH 4.8 References: Message-ID: On 2008-03-14, Damien Miller wrote: >> >> It seems to require: >> >> UsePrivilegeSeparation no > > No, it should not and does not on the platforms I have tested on. What > errors do you see when privsep is enabled? > On RHEL3u2 using sftp client version OpenSSH_3.6.1p2: # /usr/local/openssh-external/sbin/sshd -D -ddddd -f /usr/local/openssh-external/etc/sshd_config debug2: load_server_config: filename /usr/local/openssh-external/etc/sshd_config debug2: load_server_config: done config len = 710 debug2: parse_server_config: config /usr/local/openssh-external/etc/sshd_config len 710 debug3: /usr/local/openssh-external/etc/sshd_config:2 setting ListenAddress xxx.yyy.zz.68 debug3: /usr/local/openssh-external/etc/sshd_config:3 setting ListenAddress xxx.yyy.zz.69 debug3: /usr/local/openssh-external/etc/sshd_config:4 setting ListenAddress xxx.yyy.zz.70 debug3: /usr/local/openssh-external/etc/sshd_config:5 setting ListenAddress xxx.yyy.zz.78 debug3: /usr/local/openssh-external/etc/sshd_config:6 setting ListenAddress xxx.yyy.zz.81 debug3: /usr/local/openssh-external/etc/sshd_config:7 setting ListenAddress xxx.yyy.zz.82 debug3: /usr/local/openssh-external/etc/sshd_config:9 setting Protocol 2 debug3: /usr/local/openssh-external/etc/sshd_config:11 setting PermitRootLogin no debug3: /usr/local/openssh-external/etc/sshd_config:12 setting StrictModes yes debug3: /usr/local/openssh-external/etc/sshd_config:13 setting IgnoreRhosts yes debug3: /usr/local/openssh-external/etc/sshd_config:15 setting PasswordAuthentication no debug3: /usr/local/openssh-external/etc/sshd_config:16 setting PermitEmptyPasswords no debug3: /usr/local/openssh-external/etc/sshd_config:17 setting ChallengeResponseAuthentication no debug3: /usr/local/openssh-external/etc/sshd_config:19 setting AllowTcpForwarding no debug3: /usr/local/openssh-external/etc/sshd_config:20 setting X11Forwarding no debug3: /usr/local/openssh-external/etc/sshd_config:21 setting PrintMotd yes debug3: /usr/local/openssh-external/etc/sshd_config:22 setting PrintLastLog yes debug3: /usr/local/openssh-external/etc/sshd_config:23 setting UsePrivilegeSeparation yes debug3: /usr/local/openssh-external/etc/sshd_config:24 setting PermitUserEnvironment no debug3: /usr/local/openssh-external/etc/sshd_config:25 setting PidFile /var/run/sshd-external.pid debug3: /usr/local/openssh-external/etc/sshd_config:26 setting PermitTunnel no debug3: /usr/local/openssh-external/etc/sshd_config:27 setting Banner no debug3: /usr/local/openssh-external/etc/sshd_config:28 setting Subsystem sftp internal-sftp debug3: /usr/local/openssh-external/etc/sshd_config:33 setting ChrootDirectory /var/empty/sshd-external-chroot/ debug3: /usr/local/openssh-external/etc/sshd_config:34 setting ForceCommand internal-sftp debug3: /usr/local/openssh-external/etc/sshd_config:44 setting AllowUsers sftpuser debug3: checking syntax for 'Match User sftpuser' debug1: sshd version OpenSSH_4.8p1-snap20080313 debug3: Not a RSA1 key file /usr/local/openssh-external/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /usr/local/openssh-external/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/local/openssh-external/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-ddddd' debug1: rexec_argv[3]='-f' debug1: rexec_argv[4]='/usr/local/openssh-external/etc/sshd_config' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on xxx.yyy.zz.82. Server listening on xxx.yyy.zz.82 port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on xxx.yyy.zz.81. Server listening on xxx.yyy.zz.81 port 22. debug2: fd 5 setting O_NONBLOCK debug1: Bind to port 22 on xxx.yyy.zz.78. Server listening on xxx.yyy.zz.78 port 22. debug2: fd 6 setting O_NONBLOCK debug1: Bind to port 22 on xxx.yyy.zz.70. Server listening on xxx.yyy.zz.70 port 22. debug2: fd 7 setting O_NONBLOCK debug1: Bind to port 22 on xxx.yyy.zz.69. Server listening on xxx.yyy.zz.69 port 22. debug2: fd 8 setting O_NONBLOCK debug1: Bind to port 22 on xxx.yyy.zz.68. Server listening on xxx.yyy.zz.68 port 22. debug3: fd 9 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 12 config len 710 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 9 out 9 newsock 9 pipe -1 sock 12 debug1: inetd sockets after dupping: 3, 3 Connection from xxx.yyy.zz.70 port 45031 debug1: Client protocol version 2.0; client software version OpenSSH_3.6.1p2 debug1: match: OpenSSH_3.6.1p2 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.8 debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 74:74 debug1: permanently_set_uid: 74/74 debug2: Network child is on pid 26043 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug3: preauth child monitor started debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 2048 8192 debug3: mm_request_send entering: type 1 debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: dh_gen_key: priv key bits set: 128/256 debug2: bits set: 998/2048 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 1038/2048 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug3: mm_answer_sign: signature 0x80975b0(271) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user sftpuser service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: Trying to reverse map address xxx.yyy.zz.70. debug3: mm_request_receive entering debug2: parse_server_config: config reprocess config len 710 debug3: checking match for 'User sftpuser' user sftpuser host xxx.yyy.zz.70 addr xxx.yyy.zz.70 debug1: user sftpuser matched 'User sftpuser' at line 48 debug3: match found debug3: reprocess config:49 setting ChrootDirectory /var/ftp/sftpuser debug3: auth_shadow_acctexpired: today 13953 sp_expire -1 days left -13954 debug3: account expiration disabled debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for sftpuser debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: try method none debug3: mm_auth2_read_banner entering debug3: mm_request_send entering: type 8 debug3: monitor_read: checking request 8 debug3: mm_request_send entering: type 9 debug2: monitor_read: 8 used once, disabling now debug3: mm_request_receive entering debug3: mm_request_receive_expect entering: type 9 debug3: mm_request_receive entering debug1: userauth-request for user sftpuser service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug1: test whether pkalg/pkblob are acceptable debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x8097788 debug1: temporarily_use_uid: 521/521 (e=0/0) debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug1: trying public key file /home/sftpuser/.ssh/authorized_keys debug3: secure_filename: checking '/home/sftpuser/.ssh' debug3: secure_filename: checking '/home/sftpuser' debug3: secure_filename: terminating check at '/home/sftpuser' debug1: matching key found: file /home/sftpuser/.ssh/authorized_keys, line 1 Found matching RSA key: 35:5d:c5:9c:73:28:7c:eb:dc:d8:92:0c:32:6a:0e:f4 debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x8097788 is allowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa Postponed publickey for sftpuser from xxx.yyy.zz.70 port 45031 ssh2 debug1: userauth-request for user sftpuser service ssh-connection method publickey debug1: attempt 2 failures 1 debug2: input_userauth_request: try method publickey debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x80977a8 debug1: temporarily_use_uid: 521/521 (e=0/0) debug1: trying public key file /home/sftpuser/.ssh/authorized_keys debug3: secure_filename: checking '/home/sftpuser/.ssh' debug3: secure_filename: checking '/home/sftpuser' debug3: secure_filename: terminating check at '/home/sftpuser' debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug1: matching key found: file /home/sftpuser/.ssh/authorized_keys, line 1 Found matching RSA key: 35:5d:c5:9c:73:28:7c:eb:dc:d8:92:0c:32:6a:0e:f4 debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x80977a8 is allowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug3: mm_key_verify entering debug3: mm_request_send entering: type 22 debug3: monitor_read: checking request 22 debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY debug3: mm_request_receive_expect entering: type 23 debug3: mm_request_receive entering debug1: ssh_rsa_verify: signature correct debug3: mm_answer_keyverify: key 0x80977a8 signature verified debug3: mm_request_send entering: type 23 Accepted publickey for sftpuser from xxx.yyy.zz.70 port 45031 ssh2 debug1: monitor_child_preauth: sftpuser has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 24 debug3: mm_request_receive entering debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa debug3: mm_send_keystate: Sending new keys: 0x8097398 0x8097bd0 debug3: mm_newkeys_to_blob: converting 0x8097398 debug3: mm_newkeys_to_blob: converting 0x8097bd0 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state debug3: mm_newkeys_from_blob: 0x80976c8(118) debug2: mac_setup: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x80976c8(118) debug2: mac_setup: found hmac-md5 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug2: User child is on pid 26044 debug3: mm_request_receive entering debug3: safely_chroot: checking '/' debug3: safely_chroot: checking '/var/' debug3: safely_chroot: checking '/var/ftp/' debug3: safely_chroot: checking '/var/ftp/sftpuser' debug1: do_cleanup Changed root directory to "/var/ftp/sftpuser" debug1: permanently_set_uid: 521/521 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 3 setting O_NONBLOCK debug2: fd 4 setting O_NONBLOCK debug1: server_init_dispatch_20 $ sftp -vvvvvvv sftpuser at xxx.yyy.zz.70 Connecting to xxx.yyy.zz.70... OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug2: ssh_connect: needpriv 0 debug1: Connecting to xxx.yyy.zz.70 [xxx.yyy.zz.70] port 22. debug1: Connection established. debug1: identity file /home/testuser/.ssh/id_rsa type -1 debug1: identity file /home/testuser/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.8 debug1: match: OpenSSH_4.8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 135/256 debug2: bits set: 1038/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/testuser/.ssh/known_hosts debug3: check_host_in_hostfile: match line 8 debug1: Host 'xxx.yyy.zz.70' is known and matches the RSA host key. debug1: Found key in /home/testuser/.ssh/known_hosts:8 debug2: bits set: 998/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering agent key: /home/janfrode/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 0x808dc38 hint -1 debug2: input_userauth_pk_ok: fp 35:5d:c5:9c:73:28:7c:eb:dc:d8:92:0c:32:6a:0e:f4 debug3: sign_and_send_pubkey debug3: clear_auth_state: key_free 0x808dc38 debug1: Authentication succeeded (publickey). debug1: fd 4 setting O_NONBLOCK debug2: fd 5 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open:\015 #0 client-session (t3 r-1 i0/0 o0/0 fd 4/5)\015 debug3: channel_close_fds: channel 0: r 4 w 5 e 6 debug1: fd 0 clearing O_NONBLOCK debug2: fd 1 is not O_NONBLOCK Read from remote host xxx.yyy.zz.70: Connection reset by peer debug1: Transferred: stdin 0, stdout 0, stderr 63 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 32759.6 debug1: Exit status -1 Couldn't read packet: Connection reset by peer From djm at mindrot.org Sat Mar 15 17:30:01 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Mar 2008 17:30:01 +1100 (EST) Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: On Sat, 15 Mar 2008, Jan-Frode Myklebust wrote: > On 2008-03-14, Damien Miller wrote: > >> > >> It seems to require: > >> > >> UsePrivilegeSeparation no > > > > No, it should not and does not on the platforms I have tested on. What > > errors do you see when privsep is enabled? > > > > On RHEL3u2 using sftp client version OpenSSH_3.6.1p2: This should fix it (already committed): Index: ChangeLog =================================================================== RCS file: /var/cvs/openssh/ChangeLog,v retrieving revision 1.4878 diff -u -p -r1.4878 ChangeLog --- ChangeLog 14 Mar 2008 22:25:54 -0000 1.4878 +++ ChangeLog 15 Mar 2008 06:27:53 -0000 @@ -3,6 +3,8 @@ empty; report and patch from Peter Stuge - (djm) [regress/test-exec.sh] Silence noise from detection of putty commands; report from Peter Stuge + - (djm) [session.c] Relocate incorrectly-placed closefrom() that was causing + crashes when used with ChrootDirectory 20080314 - (tim) [regress/sftp-cmds.sh] s/cd/lcd/ in lls test. Reported by Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.363 diff -u -p -r1.363 session.c --- session.c 11 Mar 2008 11:58:25 -0000 1.363 +++ session.c 15 Mar 2008 06:27:53 -0000 @@ -1328,8 +1328,6 @@ safely_chroot(const char *path, uid_t ui } - closefrom(STDERR_FILENO + 1); - if (chdir(path) == -1) fatal("Unable to chdir to chroot path \"%s\": " "%s", path, strerror(errno)); @@ -1658,6 +1656,8 @@ do_child(Session *s, const char *command exit(1); #endif } + + closefrom(STDERR_FILENO + 1); if (!options.use_login) do_rc_files(s, shell); From vinschen at redhat.com Sat Mar 15 20:50:30 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 15 Mar 2008 10:50:30 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313041453.11009.qmail@cdy.org> Message-ID: <20080315095030.GA26001@calimero.vinschen.de> On Mar 15 09:23, Damien Miller wrote: > On Thu, 13 Mar 2008, Tim Rice wrote: > > > On Thu, 13 Mar 2008, Damien Miller wrote: > > > > > > > > Either way, please try this diff: > > > - *) PLINK=`which ${TEST_SSH_PLINK}` ;; > > > + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; > > > > You can not expect which to be on all platforms. > > We already use `which` for determining an absolute path to sshd in > test-exec.sh. Do you have an alternative? Shouldn't all POSIX compliant shells understand `type -p '? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From ballen at gravity.phys.uwm.edu Sat Mar 15 21:27:09 2008 From: ballen at gravity.phys.uwm.edu (Bruce Allen) Date: Sat, 15 Mar 2008 04:27:09 -0600 (CST) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" Message-ID: Dear openssh developers, Sorry to bother you with this, but I am stumped! ssh client version: OpenSSH_3.9p1 NCSA_GSSAPI_3.5 GSI, OpenSSL 0.9.7d 17 Mar 2004 sshd server version: OpenSSH_4.6p1-hpn12v17 NCSA_GSSAPI_GPT_4.0 GSI, OpenSSL 0.9.7d 17 Mar 2004 The client/server interaction hangs just at the very end, after authentication is complete. Here are a few lines of ssh -v -v -v output: ------------------------------------------------------------ ... debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 [HANGS HERE FOR A COUPLE OF MINUTES! Then after an agonizing wait...] debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 5/7 cfd -1) debug3: channel 0: close_fds r 5 w 7 e 8 c -1 Read from remote host XXX.XXX.uwm.edu: Operation timed out ------------------------------------------------------------ This bug has appeared on a stable set of systems that have worked well for quite some time. The only thing that has changed is that I am in a hotel room with some new ISP (in a few hours I'll try from a different location). We have a number of hosts set up the same way, and I can not log into any of them, so it's probably not machine misconfiguration on the server side. And the client works fine with a different set of hosts! So it's probably not machine misconfiguration on the client side either. Only thing I have checked is that I've dropped my MTU to 576 thinking that there might be some packet fragmentation issues with the hotel's NAT box but that didn't help. PS: Thanks for openssh. We wouldn't be able to work without it! Cheers, Bruce Allen From jdvf at optonline.net Sat Mar 15 23:39:00 2008 From: jdvf at optonline.net (John Devitofranceschi) Date: Sat, 15 Mar 2008 08:39:00 -0400 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: <47DBC364.7090506@optonline.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I made and regression tested openssh-SNAP-20080314 last night on Mac OS X 10.5.2 (Leopard). I installed plink and puttygen before running the tests. Everything checks out. No errors. jd Damien Miller wrote: | Hi, | | We are preparing to make the release of OpenSSH 4.8 soon, so we would | greatly appreciate testing of snapshot releases in as many environments | and on as many operating systems as possible. | | The highlights of this release are: | | * Added chroot(2) support for sshd(8), controlled by a new option | "ChrootDirectory". Please refer to sshd_config(5) for details, and | please use this feature carefully. (bz#177 bz#1352) | * Linked sftp-server(8) into sshd(8). The internal sftp server is | used when the command "internal-sftp" is specified in a Subsystem | or ForceCommand declaration. When used with ChrootDirectory, the | internal sftp server requires no special configuration of files | inside the chroot environment. Please refer to sshd_config(5) for | more information. | * Added a protocol extension method "posix-rename at openssh.com" for | sftp-server(8) to perform POSIX atomic rename() operations. | (bz#1400) | * Removed the fixed limit of 100 file handles in sftp-server(8). The | server will now dynamically allocate handles up to the number of | available file descriptors. (bz#1397) | * ssh(8) will now skip generation of SSH protocol 1 ephemeral server | keys when in inetd mode and protocol 2 connections are negotiated. | This speeds up protocol 2 connections to inetd-mode servers that | also allow Protocol 1 (bz#440) | * Accept the PermitRootLogin directive in a sshd_config(5) Match | block. Allows for, e.g. permitting root only from the local | network. | * Reworked sftp(1) argument splitting and escaping to be more | internally consistent (i.e. between sftp commands) and more | consistent with sh(1). Please note that this will change the | interpretation of some quoted strings, especially those with | embedded backslash escape sequences. (bz#778) | * Support "Banner=none" in sshd_config(5) to disable sending of a | pre-login banner (e.g. in a Match block). | * ssh(1) ProxyCommands are now executed with $SHELL rather than | /bin/sh. | * ssh(1)'s ConnectTimeout option is now applied to both the TCP | connection and the SSH banner exchange (previously it just covered | the TCP connection). This allows callers of ssh(1) to better detect | and deal with stuck servers that accept a TCP connection but don't | progress the protocol, and also makes ConnectTimeout useful for | connections via a ProxyCommand. | * Many new regression tests, including interop tests against PuTTY's | plink. | * Support BSM auditing on Mac OS X | | This release also contains many bugfixes. Please refer to the tracking bug | https://bugzilla.mindrot.org/show_bug.cgi?id=1353 for a partial list. | The ChangeLog file in the portable OpenSSH tarballs contains a full list. | | Please fetch and test the release that is appropriate for your platform: | | If you are running OpenBSD the latest version is available in CVS HEAD, | as described at http://www.openbsd.org/anoncvs.html | | Otherwise, portable snapshots are available from | http://www.mindrot.org/openssh_snap/ and also by anonymous CVS. CVS | instructions are here: http://www.openssh.com/portable.html#cvs | | Running the regression tests supplied with Portable does not require | installation and is a simply: | | $ ./configure && make tests | | This release includes some interoperability tests against PuTTY's | plink(1). These tests may be run using "make interop-tests" if you | have plink(1) installed. | | Testing on suitable non-production systems is also appreciated. | Please send reports of success or failure to | openssh-unix-dev at mindrot.org. | | _______________________________________________ | openssh-unix-dev mailing list | openssh-unix-dev at mindrot.org | https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev | | - -- John Devitofranceschi, E-Mail: jdvf at optonline.net Fax: +1 203 348 8219 PGP Fingerprint: 0D33 5A27 0810 9543 64FB DF4A 54CF 4B40 1335 4673 "What," asked Mr. Croup, "do you want?" "What," asked the marquis de Carabas, a little more rhetorically, "does anyone want?" "Dead things," suggested Mr. Vandemar. "Extra teeth." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH28NjVM9LQBM1RnMRAglJAKDoXf6TKkwz+yCOamwQtydoq6/mJACdFcHP 9IvZZ8W0yN3jRqzSgNEHnH8= =v9fq -----END PGP SIGNATURE----- From stuge-openssh-unix-dev at cdy.org Sun Mar 16 01:03:10 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 15 Mar 2008 15:03:10 +0100 Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: References: Message-ID: <20080315140310.5006.qmail@cdy.org> On Sat, Mar 15, 2008 at 04:27:09AM -0600, Bruce Allen wrote: > So it's probably not machine misconfiguration on the client side either. Do you know if your own hosts require correct reverse DNS records? Maybe the hotel ISP doesn't have names set up and you're not being let in because of that - while other hosts with less strict requirements allow you access. //Peter From ballen at gravity.phys.uwm.edu Sun Mar 16 01:32:12 2008 From: ballen at gravity.phys.uwm.edu (Bruce Allen) Date: Sat, 15 Mar 2008 08:32:12 -0600 (CST) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: <20080315140310.5006.qmail@cdy.org> References: <20080315140310.5006.qmail@cdy.org> Message-ID: Hi Peter, Thanks for the quick reply! > Do you know if your own hosts require correct reverse DNS records? No. Is this part of sshd config? If so, what should I look for? Is there a simple test that I can run to determine if reverse DNS is being required? > Maybe the hotel ISP doesn't have names set up and you're not being > let in because of that - while other hosts with less strict > requirements allow you access. That's certainly possible. Cheers, Bruce From jonhson.ian at gmail.com Sun Mar 16 02:52:45 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Sat, 15 Mar 2008 23:52:45 +0800 Subject: Openssh to support X509 certificates In-Reply-To: <20080314181606.23762.qmail@cdy.org> References: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> <8f34198c0803140236q4ee3829co4e26d058a497bef8@mail.gmail.com> <20080314181606.23762.qmail@cdy.org> Message-ID: <8f34198c0803150852h65de4ac5qe3cdc4386f4d724e@mail.gmail.com> No, what I mean is not that I seek some commercial support service. I just hope that X509 certificate support will be a part of openssh mainstream, because it becomes necessary in many applications. At least, it should become a option in openssh mainstream, so that some applications can choose to open this part of functionality. And, more importantly, I hope that my PAM module for X509-based certificate verification can serve as a module of openssh in the future.My PAM module can do authentication via user certificates and do mapping to local accounts. Based on the module, a user can login remote server via his certificate and traverse around the whole network built on openssh by single-sign-on(SSO). (Now, I have successfully implemented most of functionalities except delegation, which is needed to support SSO). I am willing to make some contribution to mainstream version of openssh and willing to open my all codes (including PAM module and modified openssh4.5). Hope openssh more powerful. Any comment? Regards, Ian On Sat, Mar 15, 2008 at 2:16 AM, Peter Stuge wrote: > On Fri, Mar 14, 2008 at 05:36:58PM +0800, Ian jonhson wrote: > > No one is welling to answer me? > > I don't think that is the case. > > Keep in mind that any help on this list is strictly voluntary and > free of charge. > > Maybe you could find someone who offers a commercial support service > for the certificate extension if that is what you're after? > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From joviano_dias at persistent.co.in Sun Mar 16 04:59:37 2008 From: joviano_dias at persistent.co.in (joviano_dias at persistent.co.in) Date: Sat, 15 Mar 2008 23:29:37 +0530 (IST) Subject: Openssh to support X509 certificates In-Reply-To: <8f34198c0803150852h65de4ac5qe3cdc4386f4d724e@mail.gmail.com> References: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> <8f34198c0803140236q4ee3829co4e26d058a497bef8@mail.gmail.com> <20080314181606.23762.qmail@cdy.org> <8f34198c0803150852h65de4ac5qe3cdc4386f4d724e@mail.gmail.com> Message-ID: <1230.59.161.28.211.1205603977.squirrel@goamail.persistent.co.in> yes a module to provide authentication is essential as a part of released OpenSSH i feel, there is also one developed by Roumen Petrov, is your PAM module in anyway advantageous over that? A module which could do remote certificate authentication through some authentication server would be even better, e.g a OpenSSH client passes cert to OpenSSH server and server in turn authenticates it through a remote RADIUS server! -Joviano > No, what I mean is not that I seek some commercial support service. > > I just hope that X509 certificate support will be a part of openssh > mainstream, > because it becomes necessary in many applications. At least, > it should become a option in openssh mainstream, so that some applications > can choose to open this part of functionality. > > And, more importantly, I hope that my PAM module for X509-based > certificate > verification can serve as a module of openssh in the future.My PAM module > can do authentication via user certificates and do mapping to local > accounts. > Based on the module, a user can login remote server via his certificate > and > traverse around the whole network built on openssh by single-sign-on(SSO). > (Now, I have successfully implemented most of functionalities except > delegation, > which is needed to support SSO). > > I am willing to make some contribution to mainstream version of openssh > and > willing to open my all codes (including PAM module and modified > openssh4.5). > Hope openssh more powerful. > > Any comment? > > Regards, > > Ian > > > On Sat, Mar 15, 2008 at 2:16 AM, Peter Stuge > wrote: >> On Fri, Mar 14, 2008 at 05:36:58PM +0800, Ian jonhson wrote: >> > No one is welling to answer me? >> >> I don't think that is the case. >> >> Keep in mind that any help on this list is strictly voluntary and >> free of charge. >> >> Maybe you could find someone who offers a commercial support service >> for the certificate extension if that is what you're after? >> >> >> //Peter >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From openssh at roumenpetrov.info Sun Mar 16 05:26:18 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 15 Mar 2008 20:26:18 +0200 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47DA0522.6090904@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> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> Message-ID: <47DC14CA.80509@roumenpetrov.info> sankalp_karpe wrote: > Hi Roumen, > > I discovered that the need of appending the .pub part of id_rsa(client > key+cert) on the server can be eliminated by adding the Certificate Blob > to authorized_keys which could look something like this: > > x509v3-sign-rsa subject= > /C=FR/ST=PARIS/L=DESEl/O=SSL/OU=VLSI/CN=10.244.82.83/emailAddress=client at company.com > > This is extracted from the client certificate using openssl as described > in the README file provided by you at > http://roumenpetrov.info/openssh/x509h/README.x509v3 > > This system works fine, however my only concern is that I would like all > Clients (possessing a valid Client-Certifcates signed by the CA) to be > authenticated without having to place anything in the > ~/.ssh/authorized_keys file on the server.(i.e authenticate all users if > they have a valid certificate without any subject line checking). > > In Apache this is very much possible via mod_ssl as described in > http://www.modssl.org/docs/2.8/ssl_howto.html#ToC6 . > Can a similar behavior be emulated in OpenSSH using the X.509 patch? > > Please let me know your comments. > > Thanks and Best Regards, > Sankalp http://roumenpetrov.info/openssh/#todo - to implement wildcards(patterns) for DN in "authorized keys" and "know hosts" files So above is similar to apache SSLRequire. Patches are welcome. Roumen From openssh at roumenpetrov.info Sun Mar 16 05:41:50 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 15 Mar 2008 20:41:50 +0200 Subject: Openssh to support X509 certificates In-Reply-To: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> References: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> Message-ID: <47DC186E.6030205@roumenpetrov.info> Ian jonhson wrote: > Hello, > > I have paid attention to the issue about the X509-based certificate support in > standard openssh. > > Because I also need the support of X509-based certificates in my project, > and also I have developed specific version of openssh to pass the > proxy certificate from client to server. But I used the PAM module > to verify the proxy and authorize the accessors. > > I wonder whether current support in openssh mainstream can pass > the client proxy certificate to server, so that PAM module can > authenticate user by its proxy certificate. > > Thanks a lot, > > Ian I would like to take interest in you work for proxy-certificate but only as extension to openssh public-key algorithm. To me is of no interest pam authentication. Roumen From ballen at gravity.phys.uwm.edu Sun Mar 16 05:54:37 2008 From: ballen at gravity.phys.uwm.edu (Bruce Allen) Date: Sat, 15 Mar 2008 12:54:37 -0600 (CST) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: <20080315140310.5006.qmail@cdy.org> References: <20080315140310.5006.qmail@cdy.org> Message-ID: >> So it's probably not machine misconfiguration on the client side either. > Do you know if your own hosts require correct reverse DNS records? > Maybe the hotel ISP doesn't have names set up and you're not being > let in because of that - while other hosts with less strict > requirements allow you access. Peter, as I recall one can disable the reverse DNS in ssh1 but not in ssh2. Is that right? I have seen this problem in the past and as I recall, the ssh-sshd dialog stops much earlier than I am seeing, and with a fairly clear error message saying that the reverse DNS lookup failed or didn't resolve to the same name/IP combination. So I am inclined to think that this is not the problem. Cheers, Bruce From stuge-openssh-unix-dev at cdy.org Sun Mar 16 06:24:09 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 15 Mar 2008 20:24:09 +0100 Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: References: <20080315140310.5006.qmail@cdy.org> <20080315140310.5006.qmail@cdy.org> Message-ID: <20080315192410.6403.qmail@cdy.org> Hi again, On Sat, Mar 15, 2008 at 08:32:12AM -0600, Bruce Allen wrote: > > Do you know if your own hosts require correct reverse DNS records? > > No. Is this part of sshd config? If so, what should I look for? Yes, look at the UseDNS directive. > Is there a simple test that I can run to determine if reverse DNS > is being required? grep -i usedns sshd_config It can't be checked from the client. On Sat, Mar 15, 2008 at 12:54:37PM -0600, Bruce Allen wrote: > > Maybe the hotel ISP doesn't have names set up and you're not > > being let in because of that > > Peter, as I recall one can disable the reverse DNS in ssh1 but not > in ssh2. Is that right? Not that I know, no. I doubt sshd makes a difference between the higher layer protocols here. sshd_config(5) also does not say anything about this. > I have seen this problem in the past and as I recall, the ssh-sshd > dialog stops much earlier than I am seeing, and with a fairly clear > error message saying that the reverse DNS lookup failed or didn't > resolve to the same name/IP combination. With UseDNS set to yes (which is also the default) sshd behavior depends on a bunch of DNS servers typically outside your control, in particular when at a remote location. Maybe the DNS server that sshd is talking to regarding your remote location is acting up and delaying answers because of load or misconfiguration or maybe it's just down and so you have to wait for a timeout. If you've had other DNS problems before at a different remote site they could very well have taken a different form depending on that particular DNS server's behaviour. If possible I would try setting UseDNS no in sshd_config and logging in again from the hotel ISP. //Peter From openssh at roumenpetrov.info Sun Mar 16 06:48:26 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 15 Mar 2008 21:48:26 +0200 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080315095030.GA26001@calimero.vinschen.de> References: <20080313041453.11009.qmail@cdy.org> <20080315095030.GA26001@calimero.vinschen.de> Message-ID: <47DC280A.9000000@roumenpetrov.info> Corinna Vinschen wrote: > On Mar 15 09:23, Damien Miller wrote: >> On Thu, 13 Mar 2008, Tim Rice wrote: >> >>> On Thu, 13 Mar 2008, Damien Miller wrote: >>> >>>> Either way, please try this diff: >>>> - *) PLINK=`which ${TEST_SSH_PLINK}` ;; >>>> + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; >>> You can not expect which to be on all platforms. >> We already use `which` for determining an absolute path to sshd in >> test-exec.sh. Do you have an alternative? > > Shouldn't all POSIX compliant shells understand `type -p '? > > > Corinna > in ksh: $ type -p ssh ssh is a tracked alias for /usr/bin/ssh in ash: $ type -p ssh -p: not found ssh is /usr/bin/ssh If "which" is problem on some platforms may be "command -v" work on them ? Roumen From joviano_dias at persistent.co.in Sun Mar 16 08:00:13 2008 From: joviano_dias at persistent.co.in (joviano_dias at persistent.co.in) Date: Sun, 16 Mar 2008 02:30:13 +0530 (IST) Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47DC14CA.80509@roumenpetrov.info> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> <47DC14CA.80509@roumenpetrov.info> Message-ID: <2041.59.161.18.57.1205614813.squirrel@goamail.persistent.co.in> Roumen, While using Distinguished Names in authorized_keys: Is it possible that all clients possessing a valid certificate are authenticated, and not just those clients who have certificates containing subject lines specified in authorized_keys? Shouldn't it be sufficient that the client certificate signature is checked against the CA certificate on the server, i.e server authenticating without having to perform any sort of specific configuration to the server's authorized_keys file. I know the above would be quite possible with wildcards, but is there any other way it can be done, that is accepting all Client Certificates signed by the CA whose CA certificate is present on the Server? -Joviano Dias > sankalp_karpe wrote: >> Hi Roumen, >> >> I discovered that the need of appending the .pub part of id_rsa(client >> key+cert) on the server can be eliminated by adding the Certificate Blob >> to authorized_keys which could look something like this: >> >> x509v3-sign-rsa subject= >> /C=FR/ST=PARIS/L=DESEl/O=SSL/OU=VLSI/CN=10.244.82.83/emailAddress=client at company.com >> >> This is extracted from the client certificate using openssl as described >> in the README file provided by you at >> http://roumenpetrov.info/openssh/x509h/README.x509v3 >> >> This system works fine, however my only concern is that I would like all >> Clients (possessing a valid Client-Certifcates signed by the CA) to be >> authenticated without having to place anything in the >> ~/.ssh/authorized_keys file on the server.(i.e authenticate all users if >> they have a valid certificate without any subject line checking). >> >> In Apache this is very much possible via mod_ssl as described in >> http://www.modssl.org/docs/2.8/ssl_howto.html#ToC6 . >> Can a similar behavior be emulated in OpenSSH using the X.509 patch? >> >> Please let me know your comments. >> >> Thanks and Best Regards, >> Sankalp > > > http://roumenpetrov.info/openssh/#todo > - to implement wildcards(patterns) for DN in "authorized keys" and "know > hosts" files > > So above is similar to apache SSLRequire. Patches are welcome. > > Roumen > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From openssh at roumenpetrov.info Sun Mar 16 08:41:05 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 15 Mar 2008 23:41:05 +0200 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <2041.59.161.18.57.1205614813.squirrel@goamail.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> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> <47DC14CA.80509@roumenpetrov.info> <2041.59.161.18.57.1205614813.squirrel@goamail.persistent.co.in> Message-ID: <47DC4271.70600@roumenpetrov.info> joviano_dias at persistent.co.in wrote: > Roumen, > > While using Distinguished Names in authorized_keys: > Is it possible that all clients possessing a valid certificate are > authenticated, and not just those clients who have certificates containing > subject lines specified in authorized_keys? > > Shouldn't it be sufficient that the client certificate signature is > checked against the CA certificate on the server, i.e server > authenticating without having to perform any sort of specific > configuration to the server's authorized_keys file. Sure, if you like every client with valid certificate to login into every logon account on the server. > I know the above would be quite possible with wildcards, but is there any > other way it can be done, that is accepting all Client Certificates signed > by the CA whose CA certificate is present on the Server? > > -Joviano Dias > >> [SNIP] Roumen From carson at taltos.org Sun Mar 16 12:32:51 2008 From: carson at taltos.org (Carson Gaspar) Date: Sat, 15 Mar 2008 21:32:51 -0400 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: <20080313041453.11009.qmail@cdy.org> Message-ID: <47DC78C3.4010701@taltos.org> Tim Rice wrote: > On Sat, 15 Mar 2008, Damien Miller wrote: > >> On Thu, 13 Mar 2008, Tim Rice wrote: ... >>> You can not expect which to be on all platforms. >> We already use `which` for determining an absolute path to sshd in >> test-exec.sh. Do you have an alternative? > > Yes I noticed that after I posted. No I don't have an alternative. > On further reflection I think it's only some older openserver platforms > that will be affected and they will have other things broken in them anyway. > > Go ahead and use which. Or, you could just use something like (tested with spaces in dirnames): function mywhich { TBIN="$1" OIFS="$IFS" IFS=':' for p in $PATH; do if test -x "$p"/"$TBIN"; then echo "$p"/"$TBIN" IFS="$OIFS" return 1 fi done IFS="$OIFS" return 0 } From ballen at gravity.phys.uwm.edu Sun Mar 16 22:20:18 2008 From: ballen at gravity.phys.uwm.edu (Bruce Allen) Date: Sun, 16 Mar 2008 05:20:18 -0600 (CST) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: References: <20080315140310.5006.qmail@cdy.org> Message-ID: Hi Peter, A bit more information: (1) My hotel's IP (Pasadena Hilton, service from AT&T) is NOT properly registered in DNS: ballen$ nslookup > 12.191.122.167 Server: 85.37.17.16 Address: 85.37.17.16#53 ** server can't find 167.122.191.12.in-addr.arpa: NXDOMAIN (2) On opensshd version 4.8, turning UseDNS off makes no difference. Is there some other config switch I should try? (3) I CAN connect to an opensshd version 3.6 ssh daemon. (4) As far as I can tell, the sshd_config files being used for the v 3.6 and v 4.8 sshd servers have only unimportant differences. Any further thoughts or suggestions? I have a few more days in the hotel so I can try some other things. Cheers, Bruce On Sat, 15 Mar 2008, Bruce Allen wrote: >>> So it's probably not machine misconfiguration on the client side either. > >> Do you know if your own hosts require correct reverse DNS records? > >> Maybe the hotel ISP doesn't have names set up and you're not being >> let in because of that - while other hosts with less strict >> requirements allow you access. > > Peter, as I recall one can disable the reverse DNS in ssh1 but not in ssh2. > Is that right? > > I have seen this problem in the past and as I recall, the ssh-sshd dialog > stops much earlier than I am seeing, and with a fairly clear error message > saying that the reverse DNS lookup failed or didn't resolve to the same > name/IP combination. > > So I am inclined to think that this is not the problem. > > Cheers, > Bruce > From djm at mindrot.org Sun Mar 16 22:33:58 2008 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Mar 2008 22:33:58 +1100 (EST) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: References: <20080315140310.5006.qmail@cdy.org> Message-ID: On Sun, 16 Mar 2008, Bruce Allen wrote: > Hi Peter, > > A bit more information: > > (1) My hotel's IP (Pasadena Hilton, service from AT&T) is NOT properly > registered in DNS: > > ballen$ nslookup > > 12.191.122.167 > Server: 85.37.17.16 > Address: 85.37.17.16#53 > ** server can't find 167.122.191.12.in-addr.arpa: NXDOMAIN > > (2) On opensshd version 4.8, turning UseDNS off makes no difference. > Is there some other config switch I should try? > > (3) I CAN connect to an opensshd version 3.6 ssh daemon. > > (4) As far as I can tell, the sshd_config files being used for the v 3.6 > and v 4.8 sshd servers have only unimportant differences. > > Any further thoughts or suggestions? I have a few more days in the hotel > so I can try some other things. You could try to strace/truss or ltrace the server to see where it is stopping. -d From ballen at gravity.phys.uwm.edu Sun Mar 16 22:54:25 2008 From: ballen at gravity.phys.uwm.edu (Bruce Allen) Date: Sun, 16 Mar 2008 05:54:25 -0600 (CST) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: References: <20080315140310.5006.qmail@cdy.org> Message-ID: Hi Damien, Thanks for your note. >> (1) My hotel's IP (Pasadena Hilton, service from AT&T) is NOT properly >> registered in DNS: >> >> ballen$ nslookup >> > 12.191.122.167 >> Server: 85.37.17.16 >> Address: 85.37.17.16#53 >> ** server can't find 167.122.191.12.in-addr.arpa: NXDOMAIN >> >> (2) On opensshd version 4.8, turning UseDNS off makes no difference. >> Is there some other config switch I should try? >> >> (3) I CAN connect to an opensshd version 3.6 ssh daemon. >> >> (4) As far as I can tell, the sshd_config files being used for the v 3.6 >> and v 4.8 sshd servers have only unimportant differences. >> >> Any further thoughts or suggestions? I have a few more days in the hotel >> so I can try some other things. > > You could try to strace/truss or ltrace the server to see where it is > stopping. I should be able to strace this process in a little while. For the moment I've got sshd debug output from a successful connection to the opensshd v4.8 server from outside the hotel, and sshd debug output from a failed connection to the opensshd v4.8 server from within the hotel. Here is where they diverge: FAILED CONNECTION FROM HOTEL (opensshd 4.8) debug2: User child is on pid 3035 debug3: mm_request_receive entering debug1: temporarily_use_uid: 501/500 (e=0/500) debug1: restore_uid: 0/500 debug1: permanently_set_uid: 501/500 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 6 setting O_NONBLOCK debug2: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session Read error from remote host 12.191.122.167: Connection reset by peer debug1: do_cleanup debug1: removing gssapi cred file"/tmp/x509up_p3035.filehEOFbn.1" debug1: do_cleanup SUCCESSFUL CONNECTION FROM CALTECH (opensshd 4.8) debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request x11-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req debug2: bind port 6010: Address already in use debug2: bind port 6010: Address already in use debug2: bind port 6011: Address already in use debug2: bind port 6011: Address already in use debug2: fd 8 setting O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug1: channel 1: new [X11 inet listener] debug2: fd 9 setting O_NONBLOCK debug3: fd 9 is O_NONBLOCK debug1: channel 2: new [X11 inet listener] Cheers, Bruce From ballen at gravity.phys.uwm.edu Sun Mar 16 23:30:49 2008 From: ballen at gravity.phys.uwm.edu (Bruce Allen) Date: Sun, 16 Mar 2008 06:30:49 -0600 (CST) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: References: <20080315140310.5006.qmail@cdy.org> Message-ID: Hi Damien, Here's the tail of the sshd strace output that you asked for: rt_sigaction(SIGHUP, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGHUP, {0x8062c49, [], 0}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x8062c49, [], 0}, NULL, 8) = 0 write(2, "debug3: mm_request_receive enter"..., 37debug3: mm_request_receive entering ) = 37 read(6, debug1: temporarily_use_uid: 501/500 (e=0/500) debug1: restore_uid: 0/500 debug1: permanently_set_uid: 501/500 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 6 setting O_NONBLOCK debug2: fd 7 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session 0xbfe49080, 4) = ? ERESTARTSYS (To be restarted) --- SIGCHLD (Child exited) @ 0 (0) --- --- SIGCONT (Continued) @ 0 (0) --- read(6, The sshd process is hanging on the read() from file descriptor 6. Note 1: I did this by running 'strace sshd' on a nonstandard port (port 2000) and then trying to make a connection to it. As far as I can see, all the authentication is fine. Just the connection itself fails. Note 2: I didn't have any arguments to strace other than the sshd command line. Let me know if I need some options added, for example to follow forks or something. Cheers, Bruce On Sun, 16 Mar 2008, Damien Miller wrote: > On Sun, 16 Mar 2008, Bruce Allen wrote: > >> Hi Peter, >> >> A bit more information: >> >> (1) My hotel's IP (Pasadena Hilton, service from AT&T) is NOT properly >> registered in DNS: >> >> ballen$ nslookup >> > 12.191.122.167 >> Server: 85.37.17.16 >> Address: 85.37.17.16#53 >> ** server can't find 167.122.191.12.in-addr.arpa: NXDOMAIN >> >> (2) On opensshd version 4.8, turning UseDNS off makes no difference. >> Is there some other config switch I should try? >> >> (3) I CAN connect to an opensshd version 3.6 ssh daemon. >> >> (4) As far as I can tell, the sshd_config files being used for the v 3.6 >> and v 4.8 sshd servers have only unimportant differences. >> >> Any further thoughts or suggestions? I have a few more days in the hotel >> so I can try some other things. > > You could try to strace/truss or ltrace the server to see where it is > stopping. > > -d > From dan at nf15.lightwave.net.ru Sun Mar 16 23:55:56 2008 From: dan at nf15.lightwave.net.ru (Dan Yefimov) Date: Sun, 16 Mar 2008 15:55:56 +0300 (MSK) Subject: ssh/sshd hang after "debug2: channel 0: open confirm rwindow 0 rmax 32768" In-Reply-To: Message-ID: On Sun, 16 Mar 2008, Bruce Allen wrote: > Here's the tail of the sshd strace output that you asked for: > ... > --- SIGCHLD (Child exited) @ 0 (0) --- > --- SIGCONT (Continued) @ 0 (0) --- > read(6, > I'd suggest you rerunning strace with the following addiional command line parameters: -f -F -ff -o That will produce 3 files named .. Each of them will contain strace output for monitor process and it's children. The most interesting will be output for the last child. -- Sincerely Your, Dan. From vinschen at redhat.com Mon Mar 17 01:27:04 2008 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 16 Mar 2008 15:27:04 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <47DC280A.9000000@roumenpetrov.info> References: <20080313041453.11009.qmail@cdy.org> <20080315095030.GA26001@calimero.vinschen.de> <47DC280A.9000000@roumenpetrov.info> Message-ID: <20080316142704.GA4677@calimero.vinschen.de> On Mar 15 21:48, Roumen Petrov wrote: > Corinna Vinschen wrote: > > On Mar 15 09:23, Damien Miller wrote: > >> On Thu, 13 Mar 2008, Tim Rice wrote: > >>> On Thu, 13 Mar 2008, Damien Miller wrote: > >>>> Either way, please try this diff: > >>>> - *) PLINK=`which ${TEST_SSH_PLINK}` ;; > >>>> + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; > >>> You can not expect which to be on all platforms. > >> We already use `which` for determining an absolute path to sshd in > >> test-exec.sh. Do you have an alternative? > > > > Shouldn't all POSIX compliant shells understand `type -p '? > > in ksh: > $ type -p ssh > ssh is a tracked alias for /usr/bin/ssh > > in ash: > $ type -p ssh > -p: not found > ssh is /usr/bin/ssh Maybe `type | awk '{print $NF}'` but then again we would have to check if every supported system has awk. That's a never ending story. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From stuge-openssh-unix-dev at cdy.org Mon Mar 17 02:20:32 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 16 Mar 2008 16:20:32 +0100 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080316142704.GA4677@calimero.vinschen.de> References: <20080313041453.11009.qmail@cdy.org> <20080315095030.GA26001@calimero.vinschen.de> <47DC280A.9000000@roumenpetrov.info> <20080316142704.GA4677@calimero.vinschen.de> Message-ID: <20080316152032.14499.qmail@cdy.org> On Sun, Mar 16, 2008 at 03:27:04PM +0100, Corinna Vinschen wrote: > Maybe `type | awk '{print $NF}'` but then again we would have to > check if every supported system has awk. That's a never ending story. mdoc2man requires awk anyway. //Peter From cmadams at hiwaay.net Mon Mar 17 01:47:57 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 16 Mar 2008 09:47:57 -0500 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080316142704.GA4677@calimero.vinschen.de> References: <20080313041453.11009.qmail@cdy.org> <20080315095030.GA26001@calimero.vinschen.de> <47DC280A.9000000@roumenpetrov.info> <20080316142704.GA4677@calimero.vinschen.de> Message-ID: <20080316144757.GA1555959@hiwaay.net> Once upon a time, Corinna Vinschen said: > Maybe `type | awk '{print $NF}'` but then again we would have to > check if every supported system has awk. That's a never ending story. On Tru64: $ /bin/sh -c 'type ls' ls is /usr/local/bin/ls. The Tru64 ksh doesn't add a trailing period, but sh does. I don't think the output of "type" is standardized in any way. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From joviano_dias at persistent.co.in Mon Mar 17 04:46:00 2008 From: joviano_dias at persistent.co.in (joviano_dias at persistent.co.in) Date: Sun, 16 Mar 2008 23:16:00 +0530 (IST) Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47DC4271.70600@roumenpetrov.info> References: <47BC01CC.60409@persistent.co.in> <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> <47DC14CA.80509@roumenpetrov.info> <2041.59.161.18.57.1205614813.squirrel@goamail.persistent.co.in> <47DC4271.70600@roumenpetrov.info> Message-ID: <1554.59.161.3.117.1205689560.squirrel@goamail.persistent.co.in> > joviano_dias at persistent.co.in wrote: >> Roumen, >> >> While using Distinguished Names in authorized_keys: >> Is it possible that all clients possessing a valid certificate are >> authenticated, and not just those clients who have certificates >> containing >> subject lines specified in authorized_keys? >> >> Shouldn't it be sufficient that the client certificate signature is >> checked against the CA certificate on the server, i.e server >> authenticating without having to perform any sort of specific >> configuration to the server's authorized_keys file. > > Sure, if you like every client with valid certificate to login into > every logon account on the server. > i should be able to do that,but i cant quite figure out how to do that... right now i am using DN's in authorized keys and for every client, i need to put the subject line of the client certificate in authorized_keys. how do i authenticate all client's having a valid certificate, and not just those clients possessing a valid client cert. I tried removing all entries from authorized_keys, but the the sshd server would not authenticate any client, even if they had a valid certificate any idea on this?... > >> I know the above would be quite possible with wildcards, but is there >> any >> other way it can be done, that is accepting all Client Certificates >> signed >> by the CA whose CA certificate is present on the Server? >> >> -Joviano Dias >> >>> [SNIP] > > > Roumen > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -Joviano From stuge-openssh-unix-dev at cdy.org Mon Mar 17 05:15:36 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 16 Mar 2008 19:15:36 +0100 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <1554.59.161.3.117.1205689560.squirrel@goamail.persistent.co.in> References: <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> <47DC14CA.80509@roumenpetrov.info> <2041.59.161.18.57.1205614813.squirrel@goamail.persistent.co.in> <47DC4271.70600@roumenpetrov.info> <1554.59.161.3.117.1205689560.squirrel@goamail.persistent.co.in> Message-ID: <20080316181536.24120.qmail@cdy.org> On Sun, Mar 16, 2008 at 11:16:00PM +0530, joviano_dias at persistent.co.in wrote: > > Sure, if you like every client with valid certificate to login > > into every logon account on the server. > > i should be able to do that,but i cant quite figure out how to do that... .. > any idea on this?... That should only need a small change to the patch. //Peter From dogcow at babymeat.com Mon Mar 17 19:10:29 2008 From: dogcow at babymeat.com (Tom Spindler) Date: Mon, 17 Mar 2008 01:10:29 -0700 Subject: feature request: single flag to unset ControlPath Message-ID: <20080317081028.GA41500@babymeat.com> While it's real handy to have "ControlMaster auto" to have multiple sessions get muxed into one, sometimes it's really helpful to _not_ use the same session (e.g. if you want to ssh -2fNR). It'd be quite nice if there were a flag to tell openssh to not mux the new connection at all - i.e. what "ssh -o ControlPath=none" does. (The 'obvious' invocation `ssh -S /dev/null` doesn't work unless you also specify `-o ControlMaster=no` - and that still produces a warning about connection refused.) The ControlPath=none bit is somewhat buried in the manpages, and somewhat annoying to type interactively - hence this request. "-P" seems like it might be the best choice for such a flag, as it's related to the control Path. If I'm reading the source correctly, all that'd be required for the flag is to have 'options->control_oath = NULL;'. From djm at mindrot.org Mon Mar 17 22:16:05 2008 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Mar 2008 22:16:05 +1100 (EST) Subject: feature request: single flag to unset ControlPath In-Reply-To: <20080317081028.GA41500@babymeat.com> References: <20080317081028.GA41500@babymeat.com> Message-ID: On Mon, 17 Mar 2008, Tom Spindler wrote: > While it's real handy to have "ControlMaster auto" to have multiple > sessions get muxed into one, sometimes it's really helpful to _not_ > use the same session (e.g. if you want to ssh -2fNR). > > It'd be quite nice if there were a flag to tell openssh to not mux > the new connection at all - i.e. what "ssh -o ControlPath=none" > does. (The 'obvious' invocation `ssh -S /dev/null` doesn't work > unless you also specify `-o ControlMaster=no` No, but "ssh -Snone [hostname]" does. I really don't want to add more options... -d From dogcow at babymeat.com Mon Mar 17 22:45:47 2008 From: dogcow at babymeat.com (Tom Spindler) Date: Mon, 17 Mar 2008 04:45:47 -0700 Subject: feature request: single flag to unset ControlPath In-Reply-To: References: <20080317081028.GA41500@babymeat.com> Message-ID: <20080317114547.GB73096@babymeat.com> > No, but "ssh -Snone [hostname]" does. Oh, -Sfoo is identically equal to -o ControlPath=foo, then? In that case, yeah, another option ain't needed. Thanks for the tip. From jonhson.ian at gmail.com Mon Mar 17 16:22:58 2008 From: jonhson.ian at gmail.com (Ian jonhson) Date: Mon, 17 Mar 2008 13:22:58 +0800 Subject: Openssh to support X509 certificates In-Reply-To: <1230.59.161.28.211.1205603977.squirrel@goamail.persistent.co.in> References: <8f34198c0803130127r2729a073sa681f6fbfe7ceb49@mail.gmail.com> <8f34198c0803140236q4ee3829co4e26d058a497bef8@mail.gmail.com> <20080314181606.23762.qmail@cdy.org> <8f34198c0803150852h65de4ac5qe3cdc4386f4d724e@mail.gmail.com> <1230.59.161.28.211.1205603977.squirrel@goamail.persistent.co.in> Message-ID: <8f34198c0803162222y6f963c5ucabab09c5d95f678@mail.gmail.com> On Sun, Mar 16, 2008 at 1:59 AM, wrote: > yes a module to provide authentication is essential as a part of released > OpenSSH i feel, there is also one developed by Roumen Petrov, is your PAM > module in anyway advantageous over that? I don't know, but please see my following explanation. > A module which could do remote certificate authentication through some > authentication server would be even better, e.g a OpenSSH client passes > cert to OpenSSH server and server in turn authenticates it through a > remote RADIUS server! > I think the working of my PAM module has some similar aspect with you had said. It does authentication at local node but it should be configured firstly to trust some remote CA. The difference is that PAM module can be seen as a plug-in modules for openssh to meet different authentication modes, such as GSI and MyProxy. And also, it does easily change authentication modes via PAM plug-in framework. For example, some applications currently used the GSI as authentication mode want to change to MyProxy-based authentication or applying both of them. it would be more easy to accomplish this by PAM plugins. Now, I have developed a GSI-based PAM module, and another one for MyProxy authentication is ongoing. For my modified openssh, it is easy to change authentication by changing the configuration in /etc/pam.d/. To Roumen, > I would like to take interest in you work for proxy-certificate but only > as extension to openssh public-key algorithm. To me is of no interest > pam authentication. Another point to adopt PAM module in local authentication is to deal with user accounts. If someone who has valid certificate but has not account in remote sshd server, can you let him/her login? How to deal with the non-existing account? Now the PAM-based modified openssh can accomplish these targets, which can let any users with valid certificates can traverse around the network trusting to same CA and need not to pre-allocate several accounts in each traversed nodes. to connect with different From imorgan at nas.nasa.gov Tue Mar 18 04:43:46 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 17 Mar 2008 10:43:46 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <47DC280A.9000000@roumenpetrov.info> References: <20080313041453.11009.qmail@cdy.org> <20080315095030.GA26001@calimero.vinschen.de> <47DC280A.9000000@roumenpetrov.info> Message-ID: <20080317174346.GD22761@linux55.nas.nasa.gov> On Sat, Mar 15, 2008 at 21:48:26 +0200, Roumen Petrov wrote: > Corinna Vinschen wrote: > > On Mar 15 09:23, Damien Miller wrote: > >> On Thu, 13 Mar 2008, Tim Rice wrote: > >> > >>> On Thu, 13 Mar 2008, Damien Miller wrote: > >>> > >>>> Either way, please try this diff: > >>>> - *) PLINK=`which ${TEST_SSH_PLINK}` ;; > >>>> + *) PLINK=`which ${TEST_SSH_PLINK} 2>/dev/null` ;; > >>> You can not expect which to be on all platforms. > >> We already use `which` for determining an absolute path to sshd in > >> test-exec.sh. Do you have an alternative? > > > > Shouldn't all POSIX compliant shells understand `type -p '? > > > > > > Corinna > > > > > in ksh: > $ type -p ssh > ssh is a tracked alias for /usr/bin/ssh > > in ash: > $ type -p ssh > -p: not found > ssh is /usr/bin/ssh > > > If "which" is problem on some platforms may be "command -v" work on them ? > > Roumen Of the platforms I have access to, it looks like 'command -v' would work. For example, Solaris and AIX have a /bin/command shell script that does the right thing. Of course, there may still be OS's out there where 'command -v' does not work. -- Iain Morgan From imorgan at nas.nasa.gov Tue Mar 18 08:02:33 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 17 Mar 2008 14:02:33 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: <20080317210233.GE22761@linux55.nas.nasa.gov> On Thu, Mar 13, 2008 at 11:50:25 +1100, Damien Miller wrote: > Hi, > > We are preparing to make the release of OpenSSH 4.8 soon, so we would > greatly appreciate testing of snapshot releases in as many environments > and on as many operating systems as possible. > The 20080318 snapshot builds and tests OK on the following platforms: RHEL 4/x86_64 w/ gcc SLES 10/IA64 w/icc 9.1 Solaris 9/SPARC w/ Sun Forte compilers It builds on AIX 5.3, but I haven't gotten through the regression tests yet. (This is most likely due to my lack of familiarity with AIX.) As noted previously, -fstack-protector-all is mistakenly used with the Intel (icc) compiler. Here's the snippet from the config.log configure:5418: checking if icc supports -fstack-protector-all configure:5441: icc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -fstack-protector-al l -Werror -no_cpprt -ldl -fstack-protector-all -Werror conftest.c >&5 icc: Command line warning: ignoring unknown option '-fstack-protector-all' icc: Command line warning: ignoring unknown option '-fstack-protector-all' configure:5447: $? = 0 configure:5453: result: yes configure:5457: checking if -fstack-protector-all works configure:5482: icc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -fstack-protector-al l -no_cpprt -ldl -fstack-protector-all conftest.c >&5 icc: Command line warning: ignoring unknown option '-fstack-protector-all' icc: Command line warning: ignoring unknown option '-fstack-protector-all' configure:5485: $? = 0 configure:5491: ./conftest configure:5494: $? = 0 configure:5496: result: yes Apparently, Intel is managing to fool configure into detecting icc as gcc, but -Werror is not causing the test to exit with a non-zero status. -- Iain Morgan From bob at proulx.com Tue Mar 18 09:56:26 2008 From: bob at proulx.com (Bob Proulx) Date: Mon, 17 Mar 2008 16:56:26 -0600 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080317174346.GD22761@linux55.nas.nasa.gov> References: <20080313041453.11009.qmail@cdy.org> <20080315095030.GA26001@calimero.vinschen.de> <47DC280A.9000000@roumenpetrov.info> <20080317174346.GD22761@linux55.nas.nasa.gov> Message-ID: <20080317225626.GA25626@dementia.proulx.com> Iain Morgan wrote: > Roumen Petrov wrote: > > > Shouldn't all POSIX compliant shells understand `type -p '? People are often surprised to learn that which, type, command, and so forth are about as portable as echo. Which is to say, not very portable. It has been a long running problem. > > If "which" is problem on some platforms may be "command -v" work on them ? > > Of the platforms I have access to, it looks like 'command -v' would > work. For example, Solaris and AIX have a /bin/command shell script that > does the right thing. Of course, there may still be OS's out there where > 'command -v' does not work. Since 'command -v' is an XSI extension a strictly POSIX conforming system need not implement it. The most portable solutions I have seen use portable shell to accomplish the task. Bob From imorgan at nas.nasa.gov Tue Mar 18 11:17:46 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 17 Mar 2008 17:17:46 -0700 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: <20080317210233.GE22761@linux55.nas.nasa.gov> References: <20080317210233.GE22761@linux55.nas.nasa.gov> Message-ID: <20080318001746.GF22761@linux55.nas.nasa.gov> On Mon, Mar 17, 2008 at 14:02:33 -0700, Iain Morgan wrote: > On Thu, Mar 13, 2008 at 11:50:25 +1100, Damien Miller wrote: > > Hi, > > > > We are preparing to make the release of OpenSSH 4.8 soon, so we would > > greatly appreciate testing of snapshot releases in as many environments > > and on as many operating systems as possible. > > > > The 20080318 snapshot builds and tests OK on the following platforms: > > RHEL 4/x86_64 w/ gcc > SLES 10/IA64 w/icc 9.1 > Solaris 9/SPARC w/ Sun Forte compilers > > It builds on AIX 5.3, but I haven't gotten through the regression tests > yet. (This is most likely due to my lack of familiarity with AIX.) > Once I read README.platforms and set blibpath prior to configuring, it built and tested OK on AIX 5.3. -- Iain Morgan From joviano_dias at persistent.co.in Wed Mar 19 02:03:18 2008 From: joviano_dias at persistent.co.in (Joviano Dias) Date: Tue, 18 Mar 2008 20:33:18 +0530 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <20080316181536.24120.qmail@cdy.org> References: <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> <47DC14CA.80509@roumenpetrov.info> <2041.59.161.18.57.1205614813.squirrel@goamail.persistent.co.in> <47DC4271.70600@roumenpetrov.info> <1554.59.161.3.117.1205689560.squirrel@goamail.persistent.co.in> <20080316181536.24120.qmail@cdy.org> Message-ID: <009c01c88909$4e6aeb40$eb40c1c0$@co.in> As I had mentioned previously that I building a system with OpenSSH + X.509 using the patch provided by Roumen, I have to have the subject lines in my authorized keys in order to authenticate clients based on the match of these subject lines. I wanted to authenticate all clients who were issued a client certificate by the CA whose CA certificate is present on the Server as I believe that this should be sufficient and would avoid the overhead of adding subject lines (to authorized_keys on the server) of each client certificate issued... Here is what I am considering... -----Original Message----- From: openssh-unix-dev-bounces+joviano_dias=persistent.co.in at mindrot.org [mailto:openssh-unix-dev-bounces+joviano_dias=persistent.co.in at mindrot.org] On Behalf Of Peter Stuge Sent: Sunday, March 16, 2008 11:46 PM To: OpenSSH Devel List Subject: Re: OpenSSH and X.509 Certificate Support On Sun, Mar 16, 2008 at 11:16:00PM +0530, joviano_dias at persistent.co.in wrote: > > Sure, if you like every client with valid certificate to login > > into every logon account on the server. > > i should be able to do that,but i cant quite figure out how to do that... .. > any idea on this?... That should only need a small change to the patch. I see that I would have to modify ssh-x509.c, however I was just wondering if there were any configuration options available to achieve the same. Switching between authenticating the client using "client cert subject lines" and "without any selective authentication (no subject lines in authorized_keys)" in authorized_keys on the server would be really good for me. Anyone ever did this before, or any suggestions on the same? //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From zsego at yahoo.ca Wed Mar 19 04:20:51 2008 From: zsego at yahoo.ca (Zdenko Sego) Date: Tue, 18 Mar 2008 13:20:51 -0400 (EDT) Subject: ssh: Disconnecting: Bad packet length Message-ID: <194596.70222.qm@web54408.mail.yahoo.com> Hello, I have the following problem with ssh on Solaris 10, 64bitx86 systems: bash-3.00# ssh -v admin at 172.20.11.244 OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to 172.20.11.244 [172.20.11.244] port 22. debug1: Connection established. debug1: identity file /.ssh/identity type -1 debug1: identity file /.ssh/id_rsa type -1 debug1: identity file /.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.5p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 126/256 debug1: bits set: 1662/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '172.20.11.244' is known and matches the RSA host key. debug1: Found key in /.ssh/known_hosts:3 debug1: bits set: 1590/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST 0e0a f978 a440 b424 779d b827 bcb6 951e Disconnecting: Bad packet length 235600248. debug1: Calling cleanup 0x8099050(0x0) *** I do not have this problem on Solaris-sparc, HP-UX or Linux platforms. Any information how to fix this will be much appreciated. Z. Sego Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca From openssh at roumenpetrov.info Wed Mar 19 07:18:08 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Tue, 18 Mar 2008 22:18:08 +0200 Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <009c01c88909$4e6aeb40$eb40c1c0$@co.in> References: <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> <47DC14CA.80509@roumenpetrov.info> <2041.59.161.18.57.1205614813.squirrel@goamail.persistent.co.in> <47DC4271.70600@roumenpetrov.info> <1554.59.161.3.117.1205689560.squirrel@goamail.persistent.co.in> <20080316181536.24120.qmail@cdy.org> <009c01c88909$4e6aeb40$eb40c1c0$@co.in> Message-ID: <47E02380.2090106@roumenpetrov.info> Joviano Dias wrote: > As I had mentioned previously that I building a system with OpenSSH + X.509 > using the patch provided by Roumen, > I have to have the subject lines in my authorized keys in order to > authenticate clients based on the match of these subject lines. > > I wanted to authenticate all clients who were issued a client certificate by > the CA whose CA certificate is present on the Server as I believe that this > should be sufficient and would avoid the overhead of adding subject lines > (to authorized_keys on the server) of each client certificate issued... > > Here is what I am considering... > > [SNIP] >>> Sure, if you like every client with valid certificate to login >>> into every logon account on the server. Did you like every client with valid and verified certificate to log into every logon account even as root ? If you don't like this, then you should create a map between certificate distinguished name or public part and logon accounts. Also note that authorized-keys file is such map. Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From stuge-openssh-unix-dev at cdy.org Wed Mar 19 08:58:57 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 18 Mar 2008 22:58:57 +0100 Subject: ssh: Disconnecting: Bad packet length In-Reply-To: <194596.70222.qm@web54408.mail.yahoo.com> References: <194596.70222.qm@web54408.mail.yahoo.com> Message-ID: <20080318215857.16896.qmail@cdy.org> On Tue, Mar 18, 2008 at 01:20:51PM -0400, Zdenko Sego wrote: > I have the following problem with ssh on Solaris 10, > 64bitx86 systems: .. > debug1: send SSH2_MSG_SERVICE_REQUEST > 0e0a f978 a440 b424 779d b827 bcb6 951e > > Disconnecting: Bad packet length 235600248. This is probably a 32/64 bit issue. Make sure OpenSSH and OpenSSL are built for the same wordlength. //Peter From anqin.qin at gmail.com Wed Mar 19 12:57:32 2008 From: anqin.qin at gmail.com (qin an) Date: Wed, 19 Mar 2008 09:57:32 +0800 Subject: I got a strange "connection refused" Message-ID: Hi everybody, I got a strange error message when I used the openssh. When I run it with debug mode, like this: # /usr/local/sbin/sshd -d I can open the session via ssh command. However, when I run with daemon mode, the ssh client was closed down and threw out the following message: debug1: dispatch_run:dispatch done debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Entering interactive session. debug1: channel 0: free: client-session, nchannels 1 Read from remote host localhost: Connection reset by peer Connection to localhost closed. debug1: Transferred: stdin 0, stdout 0, stderr 92 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 18444.3 debug1: Exit status -1 Any help? Thanks in advance, Anqin From nisargraj at gmail.com Sat Mar 8 17:03:54 2008 From: nisargraj at gmail.com (nisarg raja) Date: Sat, 8 Mar 2008 11:33:54 +0530 Subject: Fwd: Transfer log for openssh & sftp In-Reply-To: <18223bce0803072202p2ed79752xa179a21655305ba6@mail.gmail.com> References: <18223bce0803072202p2ed79752xa179a21655305ba6@mail.gmail.com> Message-ID: <18223bce0803072203h75d03486s7fd329232f6fda58@mail.gmail.com> *hello,* *I am using openssh-3.5p1.tar.gz with vsftpd, * *I am not getting transfer log with speed of transfer through "sftp using ssh2" for any event, I can see logging information only,* ** *Can any budy have any patch for above mension openssh version,* ** *Regards,* *nisarg raj* ** From djm at mindrot.org Thu Mar 20 08:08:08 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Mar 2008 08:08:08 +1100 (EST) Subject: Fwd: Transfer log for openssh & sftp In-Reply-To: <18223bce0803072203h75d03486s7fd329232f6fda58@mail.gmail.com> References: <18223bce0803072202p2ed79752xa179a21655305ba6@mail.gmail.com> <18223bce0803072203h75d03486s7fd329232f6fda58@mail.gmail.com> Message-ID: On Sat, 8 Mar 2008, nisarg raja wrote: > *hello,* > *I am using openssh-3.5p1.tar.gz with vsftpd, * Hi, OpenSSH doesn't use vsftpd for sftp transfers. vsftpd is a FTP server, not a "sftp" server. > *I am not getting transfer log with speed of transfer through "sftp using > ssh2" for any event, I can see logging information only,* OpenSSH 3.5 did not support logging for sftp transfers, that was added in 4.4p1. > *Can any budy have any patch for above mension openssh version,* You could extract the sftp-server.c from a more recent OpenSSH version and use that. -d From djm at mindrot.org Thu Mar 20 08:08:48 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Mar 2008 08:08:48 +1100 (EST) Subject: I got a strange "connection refused" In-Reply-To: References: Message-ID: On Wed, 19 Mar 2008, qin an wrote: > Hi everybody, > > I got a strange error message when I used the openssh. > When I run it with debug mode, like this: > > # /usr/local/sbin/sshd -d > > I can open the session via ssh command. However, > when I run with daemon mode, the ssh client was > closed down and threw out the following message: > > debug1: dispatch_run:dispatch done > debug1: Authentication succeeded (keyboard-interactive). > debug1: channel 0: new [client-session] > debug2: channel 0: send open > debug1: Entering interactive session. > debug1: channel 0: free: client-session, nchannels 1 > Read from remote host localhost: Connection reset by peer > Connection to localhost closed. > debug1: Transferred: stdin 0, stdout 0, stderr 92 bytes in 0.0 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 18444.3 > debug1: Exit status -1 What does the server say when it disconnects the client? -d From djm at mindrot.org Thu Mar 20 15:19:54 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Mar 2008 15:19:54 +1100 (EST) Subject: Fwd: Transfer log for openssh & sftp In-Reply-To: <18223bce0803192015r1d11edf8q5962039f89b7748e@mail.gmail.com> References: <18223bce0803072202p2ed79752xa179a21655305ba6@mail.gmail.com> <18223bce0803072203h75d03486s7fd329232f6fda58@mail.gmail.com> <18223bce0803192015r1d11edf8q5962039f89b7748e@mail.gmail.com> Message-ID: On Thu, 20 Mar 2008, nisarg raja wrote: > hello, > Thanks you verry much, I can test it and let you know also, > > FYI:- I can use OpenSSH 3.5 and vsftpd , I can loging by filezilla by using > option "sftp using > ssh2", the only thing I am not getting is transfer log, When you connect using "sftp using ssh2" you are not using vsftpd at all, you are using sshd(8) and its sftp-server(8). SFTP is a completely different protocol to FTP. -d From anqin.qin at gmail.com Thu Mar 20 16:04:52 2008 From: anqin.qin at gmail.com (qin an) Date: Thu, 20 Mar 2008 13:04:52 +0800 Subject: I got a strange "connection refused" In-Reply-To: References: Message-ID: If I run with -d, all is OK. However, when I run sshd in daemon, it clashed. I don't know how to collect the debug information in this case. On Thu, Mar 20, 2008 at 5:08 AM, Damien Miller wrote: > > On Wed, 19 Mar 2008, qin an wrote: > > > Hi everybody, > > > > I got a strange error message when I used the openssh. > > When I run it with debug mode, like this: > > > > # /usr/local/sbin/sshd -d > > > > I can open the session via ssh command. However, > > when I run with daemon mode, the ssh client was > > closed down and threw out the following message: > > > > debug1: dispatch_run:dispatch done > > debug1: Authentication succeeded (keyboard-interactive). > > debug1: channel 0: new [client-session] > > debug2: channel 0: send open > > debug1: Entering interactive session. > > debug1: channel 0: free: client-session, nchannels 1 > > Read from remote host localhost: Connection reset by peer > > Connection to localhost closed. > > debug1: Transferred: stdin 0, stdout 0, stderr 92 bytes in 0.0 seconds > > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 18444.3 > > debug1: Exit status -1 > > What does the server say when it disconnects the client? > > -d > From wangchen at cn.fujitsu.com Thu Mar 20 16:47:35 2008 From: wangchen at cn.fujitsu.com (Wang Chen) Date: Thu, 20 Mar 2008 13:47:35 +0800 Subject: [QUESTION] how to auto-exec cmd when login Message-ID: <47E1FA77.5020402@cn.fujitsu.com> Sorry, this post is neither for patch not for bug reporting. I just want to ask a question. Requirement: --- User want to login to a server(which has a chroot environment) by ssh. And when user login to the server, sshd will automatically make the login account to chroot first, and user can only use that chroot env. --- I know we have a ChrootDirectory feature in current development tree. But on RHEL, SLED and other distributions, there are only old openssh (maybe OpenSSH_4.2). So I think ChrootDirectory is not a good solution for this kind of requirement. Can you tell me how to achieve this purpose by old Openssh, such as OpenSSH_4.2? -- WCN From stuge-openssh-unix-dev at cdy.org Fri Mar 21 03:20:31 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 20 Mar 2008 17:20:31 +0100 Subject: I got a strange "connection refused" In-Reply-To: References: Message-ID: <20080320162031.29326.qmail@cdy.org> On Thu, Mar 20, 2008 at 01:04:52PM +0800, qin an wrote: > If I run with -d, all is OK. However, when I run sshd in > daemon, it clashed. I don't know how to collect the debug > information in this case. On Linux you can use strace: ps $(pidof sshd) and then strace -fFs 256 -o output.txt put_proper_pid_here Do the connection, then send Ctrl-C to strace. It will exit. //Peter From stuge-openssh-unix-dev at cdy.org Fri Mar 21 03:23:03 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 20 Mar 2008 17:23:03 +0100 Subject: [QUESTION] how to auto-exec cmd when login In-Reply-To: <47E1FA77.5020402@cn.fujitsu.com> References: <47E1FA77.5020402@cn.fujitsu.com> Message-ID: <20080320162303.30320.qmail@cdy.org> On Thu, Mar 20, 2008 at 01:47:35PM +0800, Wang Chen wrote: > chroot .. > Can you tell me how to achieve this purpose by old Openssh, such > as OpenSSH_4.2? If it is an important feature I think upgrading is a good idea. If upgrading is impossible you can use a custom shell that implements any desired policy. IIRC rssh was one shell that did chroot. //Peter From termim at gmail.com Fri Mar 21 09:19:02 2008 From: termim at gmail.com (Mikhail Terekhov) Date: Thu, 20 Mar 2008 18:19:02 -0400 Subject: ForceCommand and ~/.ssh/rc Message-ID: <12aaa0810803201519s65677865l52004509eeca41e9@mail.gmail.com> Hi, As I understand the "ForceCommand" in the sshd_confing file is meant to ignore any command supplied by the client, but if user's home is shared by server and client machines over network (ex. NFS) then user can still put something else into ~/.ssh/rc file and overcome this limitation. Is it possible to disable execution of the ~/.ssh/rc file in such a case? Thaks, Mike From alexandre.rossi at gmail.com Sat Mar 22 03:16:56 2008 From: alexandre.rossi at gmail.com (Alexandre Rossi) Date: Fri, 21 Mar 2008 17:16:56 +0100 Subject: ChrootDirectory fails if compiled with SELinux support (whether or not using SELinux) Message-ID: <9b01ce9b0803210916rde27d7bpef87c8c70a7f1c85@mail.gmail.com> Hi, (please CC me as I'm not subscribed to the list) If compiled with SELinux support, OpenSSH 4.8 current cvs fails for accounts where the new ChrootDirectory option is active : debug1: PAM: establishing credentials debug3: PAM: opening session debug2: User child is on pid 1695 debug3: mm_request_receive entering debug1: PAM: establishing credentials debug3: safely_chroot: checking '/' debug3: safely_chroot: checking '/home/' debug3: safely_chroot: checking '/home/user' Changed root directory to "/home/user" debug1: permanently_set_uid: 1002/1005 debug1: SELinux support enabled debug3: ssh_selinux_setup_exec_context: setting execution context ssh_selinux_getctxbyname: ssh_selinux_getctxbyname: security_getenforce() failed debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering debug1: do_cleanup debug1: PAM: cleanup debug1: PAM: deleting credentials debug1: PAM: closing session debug3: PAM: sshpam_thread_cleanup entering I do not use SELinux nor know how it works but my guess would be that the ssh_selinux_setup_exec_context() call at line 1442 of ./session.c fails because it expects to find some /dev or /proc SELinux interface. But the call to chroot() is before that, so the call fails. As most distros ship openssh with SELinux support compiled in, this makes ChrootDirectory unusable without a recompile or special SELinux setup in the chroot even if one does not use it. I have no clue on a fix because it does not seem possible to chroot AFTER executing the SELinux context. Cheers, Alexandre From dtucker at zip.com.au Sat Mar 22 12:38:22 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 22 Mar 2008 12:38:22 +1100 Subject: ChrootDirectory fails if compiled with SELinux support (whether or not using SELinux) In-Reply-To: <9b01ce9b0803210916rde27d7bpef87c8c70a7f1c85@mail.gmail.com> References: <9b01ce9b0803210916rde27d7bpef87c8c70a7f1c85@mail.gmail.com> Message-ID: <20080322013822.GA22497@gate.dtucker.net> On Fri, Mar 21, 2008 at 05:16:56PM +0100, Alexandre Rossi wrote: > If compiled with SELinux support, OpenSSH 4.8 current cvs fails for > accounts where the new ChrootDirectory option is active : [...] > I do not use SELinux nor know how it works but my guess would be that > the ssh_selinux_setup_exec_context() call at line 1442 of ./session.c > fails because it expects to find some /dev or /proc SELinux interface. > But the call to chroot() is before that, so the call fails. > > As most distros ship openssh with SELinux support compiled in, this > makes ChrootDirectory unusable without a recompile or special SELinux > setup in the chroot even if one does not use it. > > I have no clue on a fix because it does not seem possible to chroot > AFTER executing the SELinux context. This should at least allow it to work when selinux support is compiled in but selinux is disabled. I have no idea if it's possible to make it work with selinux enabled. Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/session.c,v retrieving revision 1.364 diff -u -p -r1.364 session.c --- session.c 15 Mar 2008 06:27:58 -0000 1.364 +++ session.c 22 Mar 2008 01:23:48 -0000 @@ -1350,6 +1350,10 @@ do_setusercontext(struct passwd *pw) #endif /* HAVE_CYGWIN */ { +#ifdef WITH_SELINUX + /* Cache selinux status for later use */ + (void)ssh_selinux_enabled(); +#endif #ifdef HAVE_SETPCRED if (setpcred(pw->pw_name, (char **)NULL) == -1) fatal("Failed to set process credentials"); Index: openbsd-compat/port-linux.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/openbsd-compat/port-linux.c,v retrieving revision 1.4 diff -u -p -r1.4 port-linux.c --- openbsd-compat/port-linux.c 27 Jun 2007 22:48:03 -0000 1.4 +++ openbsd-compat/port-linux.c 22 Mar 2008 01:24:06 -0000 @@ -36,7 +36,7 @@ #include /* Wrapper around is_selinux_enabled() to log its return value once only */ -static int +int ssh_selinux_enabled(void) { static int enabled = -1; Index: openbsd-compat/port-linux.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/openbsd-compat/port-linux.h,v retrieving revision 1.1 diff -u -p -r1.1 port-linux.h --- openbsd-compat/port-linux.h 22 Apr 2006 11:26:08 -0000 1.1 +++ openbsd-compat/port-linux.h 22 Mar 2008 01:28:06 -0000 @@ -20,6 +20,7 @@ #define _PORT_LINUX_H #ifdef WITH_SELINUX +int ssh_selinux_enabled(void); void ssh_selinux_setup_pty(char *, const char *); void ssh_selinux_setup_exec_context(char *); #endif -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From joviano_dias at persistent.co.in Sun Mar 23 07:30:06 2008 From: joviano_dias at persistent.co.in (joviano_dias at persistent.co.in) Date: Sun, 23 Mar 2008 02:00:06 +0530 (IST) Subject: OpenSSH and X.509 Certificate Support In-Reply-To: <47E02380.2090106@roumenpetrov.info> References: <47BC83CB.3080007@roumenpetrov.info> <47BD71DE.3050002@persistent.co.in> <47BDDAA4.3010405@roumenpetrov.info> <47C6AA07.2050003@persistent.co.in> <47C70A45.7090903@roumenpetrov.info> <47DA0522.6090904@persistent.co.in> <47DC14CA.80509@roumenpetrov.info> <2041.59.161.18.57.1205614813.squirrel@goamail.persistent.co.in> <47DC4271.70600@roumenpetrov.info> <1554.59.161.3.117.1205689560.squirrel@goamail.persistent.co.in> <20080316181536.24120.qmail@cdy.org> <009c01c88909$4e6aeb40$eb40c1c0$@co.in> <47E02380.2090106@roumenpetrov.info> Message-ID: <1831.59.161.27.197.1206217806.squirrel@goamail.persistent.co.in> > Joviano Dias wrote: >> As I had mentioned previously that I building a system with OpenSSH + >> X.509 >> using the patch provided by Roumen, >> I have to have the subject lines in my authorized keys in order to >> authenticate clients based on the match of these subject lines. >> >> I wanted to authenticate all clients who were issued a client >> certificate by >> the CA whose CA certificate is present on the Server as I believe that >> this >> should be sufficient and would avoid the overhead of adding subject >> lines >> (to authorized_keys on the server) of each client certificate issued... >> >> Here is what I am considering... >> >> [SNIP] >>>> Sure, if you like every client with valid certificate to login >>>> into every logon account on the server. > > Did you like every client with valid and verified certificate to log > into every logon account even as root ? Yes i would like to implement such a scenario, as all users issued a client certificate have root privileges and they should be able to login into all accounts on the server with the same certificate, even root (Don't mind clients with certificate being able to access as root.) > If you don't like this, then you should create a map between certificate > distinguished name or public part and logon accounts. > Also note that authorized-keys file is such map. I agree that this would be a good approach, however i am trying to eliminate the need for any kind of checking of the "authorized_keys" file. To achieve this and after analyzing the code, I had originally planned to modify the file ssh-x509.c since this was the place where the subject lines (of authorized_keys) are checked. However, the checking of the key type (RSA/DSA x509-key which precedes the subject lines for every entry in the authorized_keys file) would still be performed if would have done this. So in order to eliminate the checking of entire strings in authorized_keys(key type+subject line), I figured out that I could short circuit the function "user_key_allowed2()" in the file "auth2-pubkey.c" (return 1 for all scenarios). I am yet to implement this, just wanted to know if whether it would actually work and if this approach is fine considering i don't need to check the authorized_keys file?... Thanks, Joviano From aphor at speakeasy.net Mon Mar 24 02:12:42 2008 From: aphor at speakeasy.net (Jeremy McMillan) Date: Sun, 23 Mar 2008 10:12:42 -0500 Subject: openssh-unix-dev Digest, Vol 59, Issue 12 In-Reply-To: References: Message-ID: This problem can be solved by chowning the rc (and user conf files) files to some other user and chmod'ing the group and other write bits off. I say this because usually, when people use "ForceCommand" the intention is to severely restrict a particular account. Going down this path requires that you do a lot of homework around restricted shells/profiles/etc. and changes you might need to make to the default environment your OS provides. Ssh cannot and should not be expected to encapsulate all of the things that need attention if this is your goal. If you reply directly to me with some background on your OS and what kind of behavior you would like to end up with, I will send you some pointers to get you started in the right direction. On Mar 22, 2008, at 3:32 PM, openssh-unix-dev-request at mindrot.org wrote: > Date: Thu, 20 Mar 2008 18:19:02 -0400 > From: "Mikhail Terekhov" > Subject: ForceCommand and ~/.ssh/rc > > Hi, > > As I understand the "ForceCommand" in the sshd_confing file is > meant to > ignore any command supplied by the client, but if user's home is > shared by > server and client machines over network (ex. NFS) then user can > still put > something else into ~/.ssh/rc file and overcome this limitation. Is it > possible to disable execution of the ~/.ssh/rc file in such a case? > > Thaks, > Mike From chris at qwirx.com Mon Mar 24 02:19:26 2008 From: chris at qwirx.com (Chris Wilson) Date: Sun, 23 Mar 2008 15:19:26 +0000 (GMT) Subject: ForceCommand and NFS-shared home directories (was re: openssh-unix-dev Digest, Vol 59, Issue 12) In-Reply-To: References: Message-ID: Hi Jeremy and Mikhail, Jeremy, thanks for offering assistance but please don't top-post, it doesn't help us to follow the thread (especially with that subject line). I've rearranged the posts here for the benefit of others. > On Mar 22, 2008, at 3:32 PM, openssh-unix-dev-request at mindrot.org wrote: > >> As I understand the "ForceCommand" in the sshd_confing file is meant to >> ignore any command supplied by the client, but if user's home is shared >> by server and client machines over network (ex. NFS) then user can >> still put something else into ~/.ssh/rc file and overcome this >> limitation. Is it possible to disable execution of the ~/.ssh/rc file >> in such a case? On Sun, 23 Mar 2008, Jeremy McMillan wrote: > This problem can be solved by chowning the rc (and user conf files) > files to some other user and chmod'ing the group and other write bits > off. I say this because usually, when people use "ForceCommand" the > intention is to severely restrict a particular account. Going down > this path requires that you do a lot of homework around restricted > shells/profiles/etc. and changes you might need to make to the > default environment your OS provides. Ssh cannot and should not be > expected to encapsulate all of the things that need attention if this > is your goal. Unfortunately I don't believe that you are correct in general. If the user has read-write access to their home directory, and it's not protected by some bizarre magical filesystem, then they can replace .ssh at will. For example: mkdir ~/.ssh2 echo "echo 'Hello there!'" > ~/.ssh2/rc mv ~/.ssh ~/.ssh.old mv ~/.ssh2 ~/.ssh This should be possible, whatever permissions you place on ~/.ssh or its contents. If you can see a flaw in my logic then I'd be very interested to hear it. Mikhail, I don't believe there is an option to disable the rc file at present, but it sounds like a useful thing to add. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From termim at gmail.com Tue Mar 25 01:18:57 2008 From: termim at gmail.com (Mikhail Terekhov) Date: Mon, 24 Mar 2008 10:18:57 -0400 Subject: ForceCommand and NFS-shared home directories Message-ID: <12aaa0810803240718s303e2a9bgb58915aa4d5562d6@mail.gmail.com> > > On Mar 22, 2008, at 3:32 PM, Chris Wilson wrote: > > > >> As I understand the "ForceCommand" in the sshd_confing file is meant to > >> ignore any command supplied by the client, but if user's home is shared > >> by server and client machines over network (ex. NFS) then user can > >> still put something else into ~/.ssh/rc file and overcome this > >> limitation. Is it possible to disable execution of the ~/.ssh/rc file > >> in such a case? > > On Sun, 23 Mar 2008, Jeremy McMillan wrote: > > > This problem can be solved by chowning the rc (and user conf files) > > files to some other user and chmod'ing the group and other write bits > > off. I say this because usually, when people use "ForceCommand" the > > intention is to severely restrict a particular account. Going down > > this path requires that you do a lot of homework around restricted > > shells/profiles/etc. and changes you might need to make to the > > default environment your OS provides. Ssh cannot and should not be > > expected to encapsulate all of the things that need attention if this > > is your goal. > Frankly I can't imagine a case where while using "ForceCommand" the shell/profile or user environment could be useful. But certanly I could be mistaken. What I have in mind here is a CVS/SVN server that uses SSH for authorization. In this case users should have no shell access to the server at all. > Unfortunately I don't believe that you are correct in general. > > If the user has read-write access to their home directory, and it's not > protected by some bizarre magical filesystem, then they can replace .ssh > at will. For example: > > mkdir ~/.ssh2 > echo "echo 'Hello there!'" > ~/.ssh2/rc > mv ~/.ssh ~/.ssh.old > mv ~/.ssh2 ~/.ssh > > This should be possible, whatever permissions you place on ~/.ssh or its > contents. If you can see a flaw in my logic then I'd be very interested to > hear it. > > Mikhail, I don't believe there is an option to disable the rc file at > present, but it sounds like a useful thing to add. > Yes in cases like my this option would be very useful. Meantime do you think that writing a wrapper script for the shell on the server that bypasses everything but the predefined in "ForceCommand" command would be a reasonable workaround? Regards, Mikhail From mouring at eviladmin.org Tue Mar 25 01:37:08 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 24 Mar 2008 09:37:08 -0500 (CDT) Subject: ForceCommand and NFS-shared home directories In-Reply-To: <12aaa0810803240718s303e2a9bgb58915aa4d5562d6@mail.gmail.com> References: <12aaa0810803240718s303e2a9bgb58915aa4d5562d6@mail.gmail.com> Message-ID: On Mon, 24 Mar 2008, Mikhail Terekhov wrote: > > Yes in cases like my this option would be very useful. > Meantime do you think that writing a wrapper script for the shell on the > server that bypasses everything but the predefined in "ForceCommand" > command would be a reasonable workaround? > Since it is sshd and not any shell running the ~/.ssh/rc file. No amount of workarounds will resolve this. Only change the sshd can change this behavior. Taking a glance (because I don't have time to look at it fully right now) the changes are ... 1. add: int is_forcedcommand; to session.h 2. modify line 1206 (or so) to read: - /* ignore _PATH_SSH_USER_RC for subsystems */ + /* ignore _PATH_SSH_USER_RC for subsystems and forced commands */ - if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { + if (!s->is_subsystem && !s->forcedcommand && + (stat(_PATH_SSH_USER_RC, &st) >= 0)) { snprintf(cmd, sizeof cmd, "%s -c '%s %s'", shell, _PATH_BSHELL, _PATH_SSH_USER_RC); 4. Maybe initialize s->is_forcedcommand = 0; (maybe, because we may do a bzero() or other such magic to clear memory for this struct) 3. Find the right place to set s->is_forcedcommand = 1; (Since I've been out of the code for too many years. I can't state the right place at this moment. I assume still somewhere in sessions.c) - Ben From termim at gmail.com Tue Mar 25 02:56:56 2008 From: termim at gmail.com (Mikhail Terekhov) Date: Mon, 24 Mar 2008 11:56:56 -0400 Subject: ForceCommand and NFS-shared home directories In-Reply-To: References: <12aaa0810803240718s303e2a9bgb58915aa4d5562d6@mail.gmail.com> Message-ID: <12aaa0810803240856g6d53fe6dy46f75075d3b15825@mail.gmail.com> On Mon, Mar 24, 2008 at 10:37 AM, Ben Lindstrom wrote: > > > On Mon, 24 Mar 2008, Mikhail Terekhov wrote: > > > > Yes in cases like my this option would be very useful. > > Meantime do you think that writing a wrapper script for the shell on the > > server that bypasses everything but the predefined in "ForceCommand" > > command would be a reasonable workaround? > > > > Since it is sshd and not any shell running the ~/.ssh/rc file. No amount > of workarounds will resolve this. Only change the sshd can change this > behavior. > Actually I did the following experiment. I've created a test VM with SuSE 10.3 (this is openssh-4.6p1-58.3). Then I've put the following line into /etc/passwd: +mynisloginname::::::/etc/ssh/sh Then I've added this line to /etc/ssh/sshd_config: ForceCommand svnserve -t Then in /etc/ssh/sh: #!/bin/sh echo "HELLO from /etc/ssh/sh: 0=$0 @=$@" Finally I've put something into my ~/.ssh/rc file. Then when I connect to this VM machine I get: ~> ssh the.ip.of.vm ls HELLO from /etc/ssh/sh: 0=/etc/ssh/sh @=-c /bin/sh .ssh/rc HELLO from /etc/ssh/sh: 0=/etc/ssh/sh @=-c svnserve -t This example shows that it is possible to create a wrapper around user shell that will trick the sshd and skip everything but our desired command. Does this sound like a reasonable workaround? > Taking a glance (because I don't have time to look at it fully right now) > the changes are ... > > 1. add: int is_forcedcommand; to session.h > 2. modify line 1206 (or so) to read: > > - /* ignore _PATH_SSH_USER_RC for subsystems */ > + /* ignore _PATH_SSH_USER_RC for subsystems and forced commands */ > - if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { > + if (!s->is_subsystem && !s->forcedcommand && > + (stat(_PATH_SSH_USER_RC, &st) >= 0)) { > snprintf(cmd, sizeof cmd, "%s -c '%s %s'", > shell, _PATH_BSHELL, _PATH_SSH_USER_RC); > 4. Maybe initialize s->is_forcedcommand = 0; (maybe, because we may do a > bzero() or other such magic to clear memory for this struct) > 3. Find the right place to set s->is_forcedcommand = 1; (Since I've been > out of the code for too many years. I can't state the right > place at this moment. I assume still somewhere in sessions.c) > >From this description it looks like for the core OpenSSH developer it would be an easy task to implement this change. Nevertheless I'm ready to dig into the sources and try to realize your plan if people think it worth it. Mikhail From djm at mindrot.org Tue Mar 25 08:57:39 2008 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 Mar 2008 08:57:39 +1100 (EST) Subject: ForceCommand and ~/.ssh/rc In-Reply-To: <12aaa0810803201519s65677865l52004509eeca41e9@mail.gmail.com> References: <12aaa0810803201519s65677865l52004509eeca41e9@mail.gmail.com> Message-ID: On Thu, 20 Mar 2008, Mikhail Terekhov wrote: > Hi, > > As I understand the "ForceCommand" in the sshd_confing file is meant to > ignore any command supplied by the client, but if user's home is shared by > server and client machines over network (ex. NFS) then user can still put > something else into ~/.ssh/rc file and overcome this limitation. Is it > possible to disable execution of the ~/.ssh/rc file in such a case? Could you please try this? Index: session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.230 diff -u -p -r1.230 session.c --- session.c 22 Feb 2008 05:58:56 -0000 1.230 +++ session.c 24 Mar 2008 21:52:49 -0000 @@ -1217,7 +1217,7 @@ do_child(Session *s, const char *command closefrom(STDERR_FILENO + 1); - if (!options.use_login) + if (!options.use_login && options.adm_forced_command == NULL) do_rc_files(s, shell); /* restore SIGPIPE for child */ From dtucker at zip.com.au Tue Mar 25 09:21:20 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 Mar 2008 09:21:20 +1100 Subject: ForceCommand and ~/.ssh/rc In-Reply-To: References: <12aaa0810803201519s65677865l52004509eeca41e9@mail.gmail.com> Message-ID: <20080324222120.GA21752@gate.dtucker.net> On Tue, Mar 25, 2008 at 08:57:39AM +1100, Damien Miller wrote: > On Thu, 20 Mar 2008, Mikhail Terekhov wrote: > > As I understand the "ForceCommand" in the sshd_confing file is meant to > > ignore any command supplied by the client, but if user's home is shared by > > server and client machines over network (ex. NFS) then user can still put > > something else into ~/.ssh/rc file and overcome this limitation. Is it > > possible to disable execution of the ~/.ssh/rc file in such a case? > > Could you please try this? [..] > - if (!options.use_login) > + if (!options.use_login && options.adm_forced_command == NULL) This should also check forced_command too, no? That usually comes from a user-controlled authorized_keys file in ~/.ssh, however that's not necessarily the case (eg AuthorizedKeysFile /etc/ssh/keys or some such). Also, this will disable the root-owned rc file which isn't necessary. How about something like this? Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/session.c,v retrieving revision 1.364 diff -u -p -r1.364 session.c --- session.c 15 Mar 2008 06:27:58 -0000 1.364 +++ session.c 24 Mar 2008 22:19:08 -0000 @@ -1196,14 +1196,18 @@ do_rc_files(Session *s, const char *shel { FILE *f = NULL; char cmd[1024]; - int do_xauth; + int do_xauth, do_user_rc = 1; struct stat st; do_xauth = s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL; - /* ignore _PATH_SSH_USER_RC for subsystems */ - if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { + /* ignore _PATH_SSH_USER_RC for subsystems and forced commands */ + if (s->is_subsystem || options.adm_forced_command != NULL || + forced_command != NULL) + do_user_rc = 0; + + if (do_user_rc && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { snprintf(cmd, sizeof cmd, "%s -c '%s %s'", shell, _PATH_BSHELL, _PATH_SSH_USER_RC); if (debug_flag) -- 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 janfrode at tanso.net Tue Mar 25 23:09:02 2008 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Tue, 25 Mar 2008 13:09:02 +0100 Subject: Testing wanted: OpenSSH 4.8 References: Message-ID: On 2008-03-15, Damien Miller wrote: >> >> >> >> It seems to require: >> >> >> >> UsePrivilegeSeparation no >> > >> > No, it should not and does not on the platforms I have tested on. What >> > errors do you see when privsep is enabled? >> > >> >> On RHEL3u2 using sftp client version OpenSSH_3.6.1p2: > > This should fix it (already committed): > Thanks for the fix! I just tested openssh-SNAP-20080325, and now it works with "UsePrivilegeSeparation yes". -jf From termim at gmail.com Wed Mar 26 03:06:40 2008 From: termim at gmail.com (Mikhail Terekhov) Date: Tue, 25 Mar 2008 12:06:40 -0400 Subject: ForceCommand and ~/.ssh/rc In-Reply-To: <20080324222120.GA21752@gate.dtucker.net> References: <12aaa0810803201519s65677865l52004509eeca41e9@mail.gmail.com> <20080324222120.GA21752@gate.dtucker.net> Message-ID: <12aaa0810803250906n728d05c4yceacd467b80a85ff@mail.gmail.com> On Mon, Mar 24, 2008 at 6:21 PM, Darren Tucker wrote: > On Tue, Mar 25, 2008 at 08:57:39AM +1100, Damien Miller wrote: > > On Thu, 20 Mar 2008, Mikhail Terekhov wrote: > > > > As I understand the "ForceCommand" in the sshd_confing file is meant to > > > ignore any command supplied by the client, but if user's home is shared by > > > server and client machines over network (ex. NFS) then user can still put > > > something else into ~/.ssh/rc file and overcome this limitation. Is it > > > possible to disable execution of the ~/.ssh/rc file in such a case? > > > > Could you please try this? > [..] > > > - if (!options.use_login) > > + if (!options.use_login && options.adm_forced_command == NULL) > > This should also check forced_command too, no? That usually comes from > a user-controlled authorized_keys file in ~/.ssh, however that's not > necessarily the case (eg AuthorizedKeysFile /etc/ssh/keys or some such). > > Also, this will disable the root-owned rc file which isn't necessary. > How about something like this? > > Index: session.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/session.c,v > retrieving revision 1.364 > diff -u -p -r1.364 session.c > --- session.c 15 Mar 2008 06:27:58 -0000 1.364 > +++ session.c 24 Mar 2008 22:19:08 -0000 > @@ -1196,14 +1196,18 @@ do_rc_files(Session *s, const char *shel > { > FILE *f = NULL; > char cmd[1024]; > - int do_xauth; > + int do_xauth, do_user_rc = 1; > struct stat st; > > do_xauth = > s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL; > > - /* ignore _PATH_SSH_USER_RC for subsystems */ > - if (!s->is_subsystem && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { > + /* ignore _PATH_SSH_USER_RC for subsystems and forced commands */ > + if (s->is_subsystem || options.adm_forced_command != NULL || > + forced_command != NULL) > + do_user_rc = 0; > + > + if (do_user_rc && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { > snprintf(cmd, sizeof cmd, "%s -c '%s %s'", > shell, _PATH_BSHELL, _PATH_SSH_USER_RC); > if (debug_flag) > > -- > 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. > I'm a little confused about version number. Your patch shows session.c rev.1.364 but I've got rev. 1.231 from CVS. Anyway, it looks like rev.1.231 did the required changes. Unfortunately there is a typo in this revision that reverses the effect. The following patch fixes that. *** session.c 25 Mar 2008 09:47:50 -0400 1.231 --- session.c 25 Mar 2008 11:56:24 -0400 *************** *** 879,885 **** s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL; /* ignore _PATH_SSH_USER_RC for subsystems and admin forced commands */ ! if (!s->is_subsystem && options.adm_forced_command != NULL && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { snprintf(cmd, sizeof cmd, "%s -c '%s %s'", shell, _PATH_BSHELL, _PATH_SSH_USER_RC); --- 879,885 ---- s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL; /* ignore _PATH_SSH_USER_RC for subsystems and admin forced commands */ ! if (!s->is_subsystem && options.adm_forced_command == NULL && (stat(_PATH_SSH_USER_RC, &st) >= 0)) { snprintf(cmd, sizeof cmd, "%s -c '%s %s'", shell, _PATH_BSHELL, _PATH_SSH_USER_RC); From shahid.shaikh at in.ibm.com Wed Mar 26 05:07:11 2008 From: shahid.shaikh at in.ibm.com (Shahid M Shaikh) Date: Tue, 25 Mar 2008 23:37:11 +0530 Subject: Shahid M Shaikh is out of the office. Message-ID: I will be out of the office starting 03/25/2008 and will not return until 04/06/2008. I will respond to your message when I return. If its necessary, please contact my Manager Arun Anbalagan(arunprasath at in.ibm.com) From djm at mindrot.org Wed Mar 26 13:59:48 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 26 Mar 2008 13:59:48 +1100 (EST) Subject: ForceCommand and ~/.ssh/rc In-Reply-To: <12aaa0810803250906n728d05c4yceacd467b80a85ff@mail.gmail.com> References: <12aaa0810803201519s65677865l52004509eeca41e9@mail.gmail.com> <20080324222120.GA21752@gate.dtucker.net> <12aaa0810803250906n728d05c4yceacd467b80a85ff@mail.gmail.com> Message-ID: On Tue, 25 Mar 2008, Mikhail Terekhov wrote: I just noticed this myself, fix committed - thanks. > I'm a little confused about version number. Your patch shows session.c > rev.1.364 but I've got > rev. 1.231 from CVS. Anyway, it looks like rev.1.231 did the required > changes. Unfortunately > there is a typo in this revision that reverses the effect. The > following patch fixes that. > > *** session.c 25 Mar 2008 09:47:50 -0400 1.231 > --- session.c 25 Mar 2008 11:56:24 -0400 > *************** > *** 879,885 **** > s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL; > > /* ignore _PATH_SSH_USER_RC for subsystems and admin forced commands */ > ! if (!s->is_subsystem && options.adm_forced_command != NULL && > (stat(_PATH_SSH_USER_RC, &st) >= 0)) { > snprintf(cmd, sizeof cmd, "%s -c '%s %s'", > shell, _PATH_BSHELL, _PATH_SSH_USER_RC); > --- 879,885 ---- > s->display != NULL && s->auth_proto != NULL && s->auth_data != NULL; > > /* ignore _PATH_SSH_USER_RC for subsystems and admin forced commands */ > ! if (!s->is_subsystem && options.adm_forced_command == NULL && > (stat(_PATH_SSH_USER_RC, &st) >= 0)) { > snprintf(cmd, sizeof cmd, "%s -c '%s %s'", > shell, _PATH_BSHELL, _PATH_SSH_USER_RC); > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From hmouhammed at gmail.com Wed Mar 26 00:51:13 2008 From: hmouhammed at gmail.com (Hayder Mouhammed) Date: Tue, 25 Mar 2008 08:51:13 -0500 Subject: OpenSSH_4.7p1, OpenSSL 0.9.8g Host Key Verification Failed Message-ID: <186efa540803250651q17eadc96vcd9b65164cf16dd4@mail.gmail.com> Greetings, I am trying to cross compile OpenSSH 4.7 for ppc with QNX Neutrino as my OS. I have a workstation with QNX on it (x86) and I have linked the utils used by autoconf to their ppc versions. I have been able to successfully build sshd/ssh. I copy the binaries built on the x86 to the ppc, and sshd works great. I can ssh from any machine to it, but when I try to ssh from the ppc machine to another ppc machine or the x86 machine, I get the error "debug1: read_passphrase: can't open /dev/tty: No such device or address Host key verification failed." If I run it with -vvv, I get (see below): I am not running Xserver on the ppc, but it is on the x86 machine. Going through some message boards I have tried setting the DISPLAY environment variable to DISPLAY=IPAddress:1, but this doesn't change the output. I think it wants to output to the console that the rsa fingerprint (etc) is new and i can say yes/no, but this message isnt making it to the console. If I do an ls -al /dev/tty I get: "crw-rw-rw- 1 0 root 1, 4 Jan 01 01:25 /dev/tty". I have also tried touch /dev/tty and this returns with "/dev/tty: No such file or directory". Any suggestions that you may give will be very helpful. Many thanks. --H $ /tmp/ssh -vvv gosbee at 10.4.0.8 OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007 debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.4.0.8 [10.4.0.8] port 22. debug1: Connection established. Could not create directory '/gosbee/.ssh'. debug1: identity file /gosbee/.ssh/identity type -1 debug1: identity file /gosbee/.ssh/id_rsa type -1 debug1: identity file /gosbee/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.7 debug1: match: OpenSSH_4.7 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.7 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 125/256 debug2: bits set: 1068/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /gosbee/.ssh/known_hosts debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts debug3: check_host_in_hostfile: filename /gosbee/.ssh/known_hosts debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts debug2: no key of type 0 for host 10.4.0.8 debug3: check_host_in_hostfile: filename /gosbee/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /gosbee/.ssh/known_hosts debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts debug2: no key of type 2 for host 10.4.0.8 debug1: read_passphrase: can't open /dev/tty: No such device or address Host key verification failed. From mouring at eviladmin.org Thu Mar 27 00:27:39 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 26 Mar 2008 08:27:39 -0500 (CDT) Subject: OpenSSH_4.7p1, OpenSSL 0.9.8g Host Key Verification Failed In-Reply-To: <186efa540803250651q17eadc96vcd9b65164cf16dd4@mail.gmail.com> References: <186efa540803250651q17eadc96vcd9b65164cf16dd4@mail.gmail.com> Message-ID: On Tue, 25 Mar 2008, Hayder Mouhammed wrote: [..] > debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts > debug2: no key of type 2 for host 10.4.0.8 > debug1: read_passphrase: can't open /dev/tty: No such device or address > Host key verification failed. This would imply that OpenSSH can't find a /dev/tty device. Do you have "Dev.tty" driver running and have you creating your ptys devices on the client side? - Ben From kaushalshriyan at gmail.com Thu Mar 27 05:54:11 2008 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Thu, 27 Mar 2008 00:24:11 +0530 Subject: PRNG is not seeded Message-ID: <6b16fb4c0803261154x5b5350efk571c62ec268a0fd7@mail.gmail.com> Hi when i restart sshd I get PRNG is not seeded # /etc/init.d/sshd restart PRNG is not seeded # No idea as what is going on Thanks and Regards Kaushal From djm at mindrot.org Thu Mar 27 09:01:42 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Mar 2008 09:01:42 +1100 (EST) Subject: PRNG is not seeded In-Reply-To: <6b16fb4c0803261154x5b5350efk571c62ec268a0fd7@mail.gmail.com> References: <6b16fb4c0803261154x5b5350efk571c62ec268a0fd7@mail.gmail.com> Message-ID: On Thu, 27 Mar 2008, Kaushal Shriyan wrote: > Hi > > when i restart sshd I get PRNG is not seeded > > # /etc/init.d/sshd restart > PRNG is not seeded > # > > No idea as what is going on Because of a complete lack of detail in your problem report, we don't have any idea of what is going wrong either. -d From dtucker at zip.com.au Thu Mar 27 09:58:41 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 27 Mar 2008 09:58:41 +1100 Subject: PRNG is not seeded In-Reply-To: <6b16fb4c0803261154x5b5350efk571c62ec268a0fd7@mail.gmail.com> References: <6b16fb4c0803261154x5b5350efk571c62ec268a0fd7@mail.gmail.com> Message-ID: <47EAD521.90109@zip.com.au> Kaushal Shriyan wrote: > when i restart sshd I get PRNG is not seeded > > # /etc/init.d/sshd restart > PRNG is not seeded The usual cause of this is that OpenSSH is built with a self-seeding RNG (ie prngd is running) but then is run without it. That's just a guess, though. To help you more than that, you need to supply more information, such as what platform you're using, what version of OpenSSH (and OpenSSL) you have and what options you built them with. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From openssh at roumenpetrov.info Mon Mar 31 04:39:45 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 30 Mar 2008 20:39:45 +0300 Subject: Testing wanted: OpenSSH 4.8 In-Reply-To: References: Message-ID: <47EFD061.3070504@roumenpetrov.info> Damien Miller wrote: > Hi, > > We are preparing to make the release of OpenSSH 4.8 soon, so we would > greatly appreciate testing of snapshot releases in as many environments > and on as many operating systems as possible. but changelog 20080327 and other files show version 4.9 ! Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From djm at cvs.openbsd.org Mon Mar 31 12:35:53 2008 From: djm at cvs.openbsd.org (Damien Miller) Date: Sun, 30 Mar 2008 19:35:53 -0600 (MDT) Subject: Announce: OpenSSH 4.9 released Message-ID: <200803310135.m2V1Zrb3001735@cvs.openbsd.org> OpenSSH 4.9 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots and purchased T-shirts or posters. T-shirt, poster and CD sales directly support the project. Pictures and more information can be found at: http://www.openbsd.org/tshirts.html and http://www.openbsd.org/orders.html For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Note that OpenSSH 4.8 was an OpenBSD-only release shipped with the OpenBSD 4.3 CD. Changes since OpenSSH 4.7: ============================ Security: * Disable execution of ~/.ssh/rc for sessions where a command has been forced by the sshd_config ForceCommand directive. Users who had write access to this file could use it to execute abritrary commands. This behaviour was documented, but was an unsafe default and an extra hassle for administrators. New features: * Added chroot(2) support for sshd(8), controlled by a new option "ChrootDirectory". Please refer to sshd_config(5) for details, and please use this feature carefully. (bz#177 bz#1352) * Linked sftp-server(8) into sshd(8). The internal sftp server is used when the command "internal-sftp" is specified in a Subsystem or ForceCommand declaration. When used with ChrootDirectory, the internal sftp server requires no special configuration of files inside the chroot environment. Please refer to sshd_config(5) for more information. * Added a "no-user-rc" option for authorized_keys to disable execution of ~/.ssh/rc * Added a protocol extension method "posix-rename at openssh.com" for sftp-server(8) to perform POSIX atomic rename() operations. (bz#1400) * Removed the fixed limit of 100 file handles in sftp-server(8). The server will now dynamically allocate handles up to the number of available file descriptors. (bz#1397) * ssh(8) will now skip generation of SSH protocol 1 ephemeral server keys when in inetd mode and protocol 2 connections are negotiated. This speeds up protocol 2 connections to inetd-mode servers that also allow Protocol 1 (bz#440) * Accept the PermitRootLogin directive in a sshd_config(5) Match block. Allows for, e.g. permitting root only from the local network. * Reworked sftp(1) argument splitting and escaping to be more internally consistent (i.e. between sftp commands) and more consistent with sh(1). Please note that this will change the interpretation of some quoted strings, especially those with embedded backslash escape sequences. (bz#778) * Support "Banner=none" in sshd_config(5) to disable sending of a pre-login banner (e.g. in a Match block). * ssh(1) ProxyCommands are now executed with $SHELL rather than /bin/sh. * ssh(1)'s ConnectTimeout option is now applied to both the TCP connection and the SSH banner exchange (previously it just covered the TCP connection). This allows callers of ssh(1) to better detect and deal with stuck servers that accept a TCP connection but don't progress the protocol, and also makes ConnectTimeout useful for connections via a ProxyCommand. * Many new regression tests, including interop tests against PuTTY's plink. * Support BSM auditing on Mac OS X The following bugs have been fixed in this release: - scp(1) incorrectly reported "stalled" on slow copies. (bz#799) - scp(1) date underflow for timestamps before epoch. (bz#828) - scp(1) and sftp(1) progressmeter type fixes. (bz#842) - SSH2_MSG_UNIMPLEMENTED packets did not correctly reset the client keepalive logic, causing disconnections on servers that did not explicitly implement "keepalive at openssh.com". (bz#1307) - ssh(1) used the obsolete SIG DNS RRtype for host keys in DNS, instead of the current standard RRSIG. (bz#1317) - Extract magic buffer size constants in scp(1) to #defines. (bz#1333) - Correctly drain ACKs when a sftp(1) upload write fails midway, avoids a fatal() exit from what should be a recoverable condition. (bz#1354) - Avoid pointer arithmetic and strict aliasing warnings. (bz#1355) - Fixed packet size advertisements. Previously TCP and agent forwarding incorrectly advertised the channel window size as the packet size, causing fatal errors under some conditions. (bz#1360) - Document KbdInteractiveAuthentication in sshd_config(5). (bz#1367) - Fixed sftp(1) file handle leak on download when the local file could not be opened. (bz#1375) - Fixed ssh-keygen(1) selective host key hashing (i.e. "ssh-keygen -HF hostname") to not include any IP address in the data to be hashed. (bz#1376) - Fix clobbering of struct passwd from multiple getpwid calls, resulting in fatal errors inside tilde_expand_filename. (bz#1377) - Fix parsing of port-forwarding specifications to correctly detect errors in either specified port number. (bz#1378) - Fix memory leak in ssh(1) ~ escape commandline handling. (bz#1379) - Make ssh(1) skip listening on the IPv6 wildcard address when a binding address of 0.0.0.0 is used against an old SSH server that does not support the RFC4254 syntax for wildcard bind addresses. (bz#1381) - Remove extra backslashes in the RB_PROTOTYPE macro definition. (bz#1385) - Support ssh(1) RekeyLimits up to the maximum allowed by the protocol: 2**32-1. (bz#1390) - Enable IPV6_V6ONLY socket option on sshd(8) listen socket, as is already done for X11/TCP forwarding sockets. (bz#1392) - Fix FD leak that could hang a ssh(1) connection multiplexing master. (bz#1398) - Improve error messages when hostname resolution fails due to a system error. (bz#1417) - Make ssh(1) -q option documentation consistent with reality. (bz#1427 bz#1429) Portable OpenSSH bugs fixed: - Fixed sshd(8) PAM support not calling pam_session_close(), or failing to call it with root privileges. (bz#926) - Made sshd(8) use configuration-specified SyslogFacility for hosts_access(3) messages for denied connections. (bz#1042) - Implement getgrouplist(3) for AIX, enabling NSS LDAP to work on this platform. (bz#1081) - Fix compilation errors on AIX due to misdefinition of LLONG_MAX. (bz#1347) - Force use of local glob(3) implementation on Mac OS X and FreeBSD, as the platform versions lack features or have unexpected behaviour. (bz#1407) - Reduce stdout/stderr noise from ssh-copy-id. (bz#1431) - Fix activation of OpenSSL engine support when requested in configure. (bz#1437) Checksums: ========== - SHA1 (openssh-4.9.tar.gz) = fa7d1b3dcb093bd0dfc643b33b1a57a26f459373 - SHA1 (openssh-4.9p1.tar.gz) = 91575878883065bd777f82b47e0d481ac69ee7fe Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From jpv50 at hotmail.com Mon Mar 31 23:41:11 2008 From: jpv50 at hotmail.com (John Vincent) Date: Mon, 31 Mar 2008 12:41:11 +0000 Subject: suggested minor improvement to ssh argument parsing Message-ID: Hi, I use "ssh" often, and within bash I find it useful to define the IP address in "/etc/hosts" and then use the bash auto-complete feature for the hsot name. For this to work bash needs to see a "@" in front of the host name. This works perfectly for a command like "ssh user at host". However if I want to use the current user by default, I can't get the bash to auto complete the hostname. My suggestion is to allow ssh to accept the hostname like this "ssh @host" as well as the current "ssh host". This would enable the bash auto-complete function to work. I hope someone likes this idea enough to make it happen. Thanks, John Vincent. _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live