From scott_n at xypro.com Tue Sep 1 09:43:41 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 31 Aug 2009 16:43:41 -0700 Subject: mput/mget misbehavior Message-ID: <78DD71C304F38B41885A242996B96F7301ECC9C9@xyservd.XYPRO-23.LOCAL> A couple of notes about mget/mput in SFTP (5.1p1). 1. They aren't documented in the SFTP man page 2 They misbehave -- "mput a.txt b.txt" copies a.txt to b.txt on the server "mput *.txt b.txt" copies the first wildcard match to b.txt on the server "mput a.txt b.txt c.txt" copies a.txt to b.txt on the server "mput a.txt b.txt /tmp" copies a.txt to b.txt on the server ---- Scott Neugroschl XYPRO Technology Corporation scott_n at xypro.com 805-583-2874 From djm at mindrot.org Tue Sep 1 10:18:12 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Sep 2009 10:18:12 +1000 (EST) Subject: mput/mget misbehavior In-Reply-To: <78DD71C304F38B41885A242996B96F7301ECC9C9@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F7301ECC9C9@xyservd.XYPRO-23.LOCAL> Message-ID: this will be changing soon: there are some patches coming from Carlos Silva, our Google Summer of Code Intern. -d On Mon, 31 Aug 2009, Scott Neugroschl wrote: > A couple of notes about mget/mput in SFTP (5.1p1). > > 1. They aren't documented in the SFTP man page > 2 They misbehave -- > "mput a.txt b.txt" copies a.txt to b.txt on the server > "mput *.txt b.txt" copies the first wildcard match to b.txt on > the server > "mput a.txt b.txt c.txt" copies a.txt to b.txt on the server > "mput a.txt b.txt /tmp" copies a.txt to b.txt on the server > > > > ---- > Scott Neugroschl > XYPRO Technology Corporation > scott_n at xypro.com > 805-583-2874 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From petesea at bigfoot.com Wed Sep 2 09:51:43 2009 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Tue, 01 Sep 2009 16:51:43 -0700 (PDT) Subject: ssh_exchange_identification: Connection closed by remote host Message-ID: I'm randomly getting the following error on a server from various remote hosts: ssh_exchange_identification: Connection closed by remote host The server is running OpenSSH 4.5p1 w/GSSAPI Key Exchange patch. The hosts connecting to it should all be using OpenSSH 5.0p1 w/GSSAPI Key Exchange patch and using gssapi-keyex authentication. Normally, when I've seen this error, it means access to the SSH port is blocked by TCP wrappers or something like that, but I'm sure that's not the case here since /etc/hosts.allow and /etc/hosts.deny haven't changed for quite some time. Also, the failures are random from many different remote hosts and I can try a connection from a host right after it's failed and it will work. Under what other conditions might I get this error and how can I track down what's causing it? From tim at multitalents.net Wed Sep 2 14:36:09 2009 From: tim at multitalents.net (Tim Rice) Date: Tue, 1 Sep 2009 21:36:09 -0700 (PDT) Subject: ssh_exchange_identification: Connection closed by remote host In-Reply-To: References: Message-ID: On Tue, 1 Sep 2009, petesea at bigfoot.com wrote: > I'm randomly getting the following error on a server from various remote > hosts: > > ssh_exchange_identification: Connection closed by remote host > > The server is running OpenSSH 4.5p1 w/GSSAPI Key Exchange patch. The hosts > connecting to it should all be using OpenSSH 5.0p1 w/GSSAPI Key Exchange patch > and using gssapi-keyex authentication. > > Normally, when I've seen this error, it means access to the SSH port is > blocked by TCP wrappers or something like that, but I'm sure that's not the > case here since /etc/hosts.allow and /etc/hosts.deny haven't changed for quite > some time. Also, the failures are random from many different remote hosts and > I can try a connection from a host right after it's failed and it will work. I've seen this with DNS failures when my hosts.allow entry is a domain rather than an IP. > Under what other conditions might I get this error and how can I track down > what's causing it? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From jamie.beverly at yahoo.com Wed Sep 2 15:24:15 2009 From: jamie.beverly at yahoo.com (Jamie Beverly) Date: Tue, 1 Sep 2009 22:24:15 -0700 (PDT) Subject: ssh_exchange_identification: Connection closed by remote host Message-ID: <277737.33218.qm@web31812.mail.mud.yahoo.com> I frequently see this error when / goes away, e.g. hdd failure. Sent from my iPhone On Sep 1, 2009, at 9:36 PM, Tim Rice wrote: On Tue, 1 Sep 2009, petesea at bigfoot.com wrote: I'm randomly getting the following error on a server from various remote hosts: ssh_exchange_identification: Connection closed by remote host The server is running OpenSSH 4.5p1 w/GSSAPI Key Exchange patch. The hosts connecting to it should all be using OpenSSH 5.0p1 w/GSSAPI Key Exchange patch and using gssapi-keyex authentication. Normally, when I've seen this error, it means access to the SSH port is blocked by TCP wrappers or something like that, but I'm sure that's not the case here since /etc/hosts.allow and /etc/hosts.deny haven't changed for quite some time. Also, the failures are random from many different remote hosts and I can try a connection from a host right after it's failed and it will work. I've seen this with DNS failures when my hosts.allow entry is a domain rather than an IP. Under what other conditions might I get this error and how can I track down what's causing it? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From drallen at cs.uwaterloo.ca Fri Sep 4 23:46:12 2009 From: drallen at cs.uwaterloo.ca (Daniel Allen) Date: Fri, 4 Sep 2009 09:46:12 -0400 Subject: PermitUserEnvironment in sshd match block? Message-ID: Daniel Allen wrote: > Would the best answer be a patch that adds PermitUserEnvironment support > inside match blocks? Darren Tucker wrote: > The approach to adding things to Match has been on a case by case basis, > checking if the thing is a) useful and b) safe. It's a lot easier to > evaluate these thing one at a time than in a large batch of them. Damien Miller wrote: > We could make PermitUserEnvironment accept a pattern-list to match > environment variables, while retaining "yes", "no", "true" and "false" > as their current meanings of allow/deny-all. Both (or either) of these options would meet our current needs very well. The pattern-list would seem the more elegant approach for our use. I am sorry that I don't have the wherewithal to submit a patch now, though if it helps things along I'd be happy to submit a bugzilla request. Or not, if you prefer. Thanks for your work, Daniel Allen Computing Technology Specialist Computer Science Computing Facility (CSCF) David R. Cheriton School of Computer Science University of Waterloo (519) 888-4567 ext. 35448 drallen at uwaterloo dot ca From peter at stuge.se Sat Sep 5 00:13:54 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 4 Sep 2009 16:13:54 +0200 Subject: PermitUserEnvironment in sshd match block? In-Reply-To: References: Message-ID: <20090904141354.16736.qmail@stuge.se> Daniel Allen wrote: > Our campus environment would find it very useful to pass > user-environment variables for certain login ssh connections, I guess it's arbitrary variables? If only a limited set you could sprinkle some AcceptEnv into sshd_config. //Peter From djm at mindrot.org Sat Sep 5 06:13:56 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 5 Sep 2009 06:13:56 +1000 (EST) Subject: PermitUserEnvironment in sshd match block? In-Reply-To: <20090904141354.16736.qmail@stuge.se> References: <20090904141354.16736.qmail@stuge.se> Message-ID: On Fri, 4 Sep 2009, Peter Stuge wrote: > Daniel Allen wrote: > > Our campus environment would find it very useful to pass > > user-environment variables for certain login ssh connections, > > I guess it's arbitrary variables? If only a limited set you could > sprinkle some AcceptEnv into sshd_config. AcceptEnv only applies to environment variables passed by the ssh(1) client, not to ~/.ssh/environment. -d From lauri.vosandi at gmail.com Mon Sep 7 01:53:01 2009 From: lauri.vosandi at gmail.com (lauri) Date: Sun, 6 Sep 2009 18:53:01 +0300 Subject: Integration of streamlocal patch In-Reply-To: <1285cde60909030103p68dacb2bl62998590d8f806ab@mail.gmail.com> References: <1285cde60909030103p68dacb2bl62998590d8f806ab@mail.gmail.com> Message-ID: <1285cde60909060853l536afd1h560871e0a6cd617b@mail.gmail.com> Hello, there is a patch which allows redirecting UNIX domain sockets here: http://www.25thandclement.com/~william/projects/streamlocal.html We really need it in our institution. It's for OpenSSH 4.4 but I managed to adopt it for 4.7p1 included in Ubuntu 8.04. http://v6sa.itcollege.ee/shared/patches/openssh-4.7p1-streamlocal-20090831-v6sa-for-ubuntu-8.04.patch It would be very nice if you guys would integrate it upstream. -- Lauri V?sandi tel: +372 53329412 e-mail: lauri.vosandi at gmail.com university: Estonian IT College please share: http://windows7sins.org/ From petfire85 at yahoo.fr Tue Sep 8 08:08:46 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Mon, 7 Sep 2009 22:08:46 +0000 (GMT) Subject: Question about Server Authentication Message-ID: <324763.44539.qm@web24710.mail.ird.yahoo.com> Hi guys, I'm working on a project which concern SSH and there is something i don't understand about server authentication. So I explain my problem: - When you authorize only RSA keys in the sshd_config on the server, you need to have the RSA public key of this server in the known_hosts file of the client. This is absolutely normal. - When you authorize only DSA keys in the sshd_config on the server, you need to have the DSA public key of this server in the known_hosts file of the client. This is also absolutely normal. - But when you authorize both RSA and DSA keys, you are obliged to have the RSA public key in the known_hosts file, without it fails. If there is only DSA in the known_hosts file it fails, and this is that I don't understand. Why the server authentication doesn't work with the DSA key when both DSA and RSA are authorize. (Of course if both are present in the known_host file, it works). So if somebody can help me about this, it will be nice ;) I've read lot of documentation, a little the 4 RFC but I haven't found the answer to my question. Steeve From skalak at monetplus.cz Tue Sep 8 18:12:37 2009 From: skalak at monetplus.cz (Skalak Zdenek) Date: Tue, 08 Sep 2009 09:12:37 +0100 Subject: openssh, pam, challenge-response problem Message-ID: <4AA611F5.20301@monetplus.cz> Hello, when configuring the OpenSSH to authenticate through pam_radius, I encountered the following problem: The radius server is configured to accept username and generic password, it then generates some textual string as a challenge-request and waits again for username and this time for challenge-response. Pam_radius use pam->conv function, retrieved with pam_get_item(PAM_COM), with challenge-request and type PAM_PROMPT_ECHO_ON, to present the challenge-request to user and to retrieve the challenge-response. OpenSSH sets the PAM_CONV function to sshpam_passwd_conv() (defined in pam_auth.c). But this function doesn't have implemented the PAM_PROMPT_ECHO_ON flavor, and returns the PAM_CONV_ERROR :-( It should be possible to implement the PAM_PROMPT_ECHO_ON conversation either with read()/write() or with fdopen()/fprintf()/fgets()/fclose() (as is done similary for stdin in sshpam_tty_conv()), but we need the socket. The only way to pass the information into the pam module is by Authctxt structure. So we need to add the "int socket" field into the Convctxt structure and then use it (if not set to -1) for challenge-response authentication. Sounds possible? Best regards Zdenek OGAR Skalak -- Ing. Zdenek OGAR Skal?k Monet+ a.s. Za Dvorem 505, 763 14 Zl?n - ?t?pa, CZ Tel: +420 / 577 110 411, Fax: +420 / 577 914 557 -- Tato zprava byla prohledana na vyskyt viru a nebezpecneho obsahu antivirovym systemem MailScanner a zda se byt cista. From dtucker at zip.com.au Tue Sep 8 22:24:08 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 08 Sep 2009 22:24:08 +1000 Subject: openssh, pam, challenge-response problem In-Reply-To: <4AA611F5.20301@monetplus.cz> References: <4AA611F5.20301@monetplus.cz> Message-ID: <4AA64CE8.2090507@zip.com.au> Skalak Zdenek wrote: > Hello, > > when configuring the OpenSSH to authenticate through pam_radius, I > encountered the following problem: > > The radius server is configured to accept username and generic > password, it then generates some textual string as a challenge-request > and waits again for username and this time for challenge-response. > > Pam_radius use pam->conv function, retrieved with > pam_get_item(PAM_COM), with challenge-request and type > PAM_PROMPT_ECHO_ON, to present the challenge-request to user and to > retrieve the challenge-response. > > OpenSSH sets the PAM_CONV function to sshpam_passwd_conv() (defined > in pam_auth.c). But this function doesn't have implemented the > PAM_PROMPT_ECHO_ON flavor, and returns the PAM_CONV_ERROR :-( > > It should be possible to implement the PAM_PROMPT_ECHO_ON > conversation either with read()/write() or with > fdopen()/fprintf()/fgets()/fclose() (as is done similary for stdin in > sshpam_tty_conv()), but we need the socket. The only way to pass the > information into the pam module is by Authctxt structure. So we need to > add the "int socket" field into the Convctxt structure and then use it > (if not set to -1) for challenge-response authentication. > > Sounds possible? No. At the authentication stage there's no connection to the user other than the encrypted channel, so there's no place to write plaintext to. If you did manage to write to the socket connected to the client it would almost certainly kill the connection with a MAC failure. That said, what you're describing *should* work with the SSH2 keyboard-interactive authentication type, which was designed to do exactly this type of multiple-step challenge-response. Does "ssh -2 -o PreferredAuthentications=keyboard-interactive yourserver" work? If so, you can just disable PasswordAuthenticaton in sshd_config and leave ChallengeResponseAuthentication enabled. If not, what does the client give with "-vvv", and what does the server give with debugging (-ddde) enabled? The next problem you may have is that sshd doesn't allow changes of username in the middle of an authentication. There's more information (but no ideal solution) at https://bugzilla.mindrot.org/show_bug.cgi?id=1215. -- 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 hyc at symas.com Wed Sep 9 06:04:11 2009 From: hyc at symas.com (Howard Chu) Date: Tue, 08 Sep 2009 13:04:11 -0700 Subject: Support for merging LPK and hpn-ssh into mainline openssh? Message-ID: <4AA6B8BB.8070306@symas.com> > From: Damien Miller > Date: 2009-02-17 4:22:05 > Message-ID: alpine.BSO.2.00.0902171519190.1946 () fuyu ! mindrot ! org > On Tue, 17 Feb 2009, Peter Lambrechtsen wrote: > >> On Tue, Feb 17, 2009 at 3:18 PM, Damien Miller wrote: >> > I don't think there are any plans to merge the LPK patch. We really >> > don't want a dependency on LDAP libraries in sshd. Maybe if it were >> > abstracted into a helper app that sshd could consult to verify keys >> > then it would be more palatable, but even this is doubtful unless it >> > can be done in a way that avoids complexity - there is a lot that can >> > go wrong. >> >> Yes, the OpenLDAP+OpenSSL dependencies can make it a challenge to >> compile. However if it was not a default module, and when compiling >> OpenSSH you could add --with-ldap=/ldap/shared/libs then that would >> give end-users the option to build OpenSSH with LDAP support or not. > > My concern is more with the complexity and maintenance hassle of LDAP, > not the run-time linkage. Could you elaborate on this comment? Most sysadmins are looking for this feature precisely because it *reduces* the complexity and hassle of maintaining user login info across large networks. Certainly the existing patch is pretty non-optimal, but the basic idea is sound. What specific problems are you concerned about? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc at symas.com Wed Sep 9 07:44:00 2009 From: hyc at symas.com (Howard Chu) Date: Tue, 08 Sep 2009 14:44:00 -0700 Subject: OpenSSH and keystroke timings Message-ID: <4AA6D020.4070103@symas.com> Old news, but ... http://lwn.net/Articles/298833/ I first posted about this back in 2001 and it's still not resolved: http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html 1) high latency networks are a reality that will never go away. In fact they will only become more prevalent since distributed networks continue to grow broader but (surprise) the speed of light remains a constant. 2) character-at-a-time protocols have both security and performance costs. 3) a solution for this has existed in common operating systems for a couple of decades already (LINEMODE tty support). It's strange how the secsh group at the IETF refused to learn from the lessons already gained from the years of experience with the telnet protocol. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc at symas.com Wed Sep 9 08:38:11 2009 From: hyc at symas.com (Howard Chu) Date: Tue, 08 Sep 2009 15:38:11 -0700 Subject: OpenSSH and keystroke timings In-Reply-To: References: <4AA6D020.4070103@symas.com> Message-ID: <4AA6DCD3.7040107@symas.com> Dan Kaminsky wrote: > Well, there's a lot here. Lets go down the line. > > 1) Password entry only occurs during keyboard-interactive mode, which at > least isn't used by default (though it may be set on some distros). > There's no way to downgrade someone as a MITM either. Password entry is not the only point of vulnerability. Character timing can be analyzed continuously, to create a profile of the user generating the input. > 2) Passwords in general are a terribly flawed technology, made only > palatable by the disaster that is everything else (yes, this includes > rsa/dsa in SSH). Yes, but that's only one specific example of the overall problem. > 3) Only the most basic of interactions with a server are line based. > Even something as simple as vi requires full character mode > interactivity. Heck, tab completion doesn't even work without it. Please read the telnet RFCs regarding LINEMODE. Tab completion is still supported; the protocol allows "forwarding characters" to be specified on the fly. You can have complete local editing when in command-line mode without losing any of the conveniences that modern shells provide. Obviously vi still requires character-at-a-time mode, but if you're connecting to a distant system over a tin-can-and-string network you should know about ex, ed, or sed... There's also tn3270, for a model of page-at-a-time full screen editing. Again: these are problems that were solved decades ago in the telnet specifications. Why not take the few minutes to read them, rather than suffer from the same problems over and over again... Interactivity is best handled on the local client; forcing people to wait a full packet roundtrip time for every byte of data they type is a waste of life. > 4) The right way to solve this class of problem isn't with LINEMODE tty, > it's with constant timing / constant bandwidth padding in the underlying > transport -- or at least, to make changes in timing and bandwidth happen > a few orders of magnitude slower than the data that's driving them. > SSH1 and SSH2 as protocols have full support for contentless packets > that contain only padding; I'd love to see a patch. "This class of problem" is only a part of the problem. If you "solve" this by injecting additional packets/padding, you only make usage over congested high latency networks worse. Bandwidth is neither unlimited nor free, and here's another truism: congestion, like latency, will only increase over time, it will never decrease. Someday, someone on Earth is going to want to open a secure shell session to a machine on the moon, or on Mars, or wherever, or vice versa. You can fix this in ssh now, or let people keep reinventing remote login protocols for decades to come... > On Tue, Sep 8, 2009 at 11:44 PM, Howard Chu > wrote: > > Old news, but ... http://lwn.net/Articles/298833/ > > I first posted about this back in 2001 and it's still not resolved: > http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html > > 1) high latency networks are a reality that will never go away. In > fact they will only become more prevalent since distributed networks > continue to grow broader but (surprise) the speed of light remains a > constant. > 2) character-at-a-time protocols have both security and performance > costs. > 3) a solution for this has existed in common operating systems for a > couple of decades already (LINEMODE tty support). > > It's strange how the secsh group at the IETF refused to learn from > the lessons already gained from the years of experience with the > telnet protocol. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From dan at doxpara.com Wed Sep 9 08:10:29 2009 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 9 Sep 2009 00:10:29 +0200 Subject: OpenSSH and keystroke timings In-Reply-To: <4AA6D020.4070103@symas.com> References: <4AA6D020.4070103@symas.com> Message-ID: Well, there's a lot here. Lets go down the line. 1) Password entry only occurs during keyboard-interactive mode, which at least isn't used by default (though it may be set on some distros). There's no way to downgrade someone as a MITM either. 2) Passwords in general are a terribly flawed technology, made only palatable by the disaster that is everything else (yes, this includes rsa/dsa in SSH). 3) Only the most basic of interactions with a server are line based. Even something as simple as vi requires full character mode interactivity. Heck, tab completion doesn't even work without it. 4) The right way to solve this class of problem isn't with LINEMODE tty, it's with constant timing / constant bandwidth padding in the underlying transport -- or at least, to make changes in timing and bandwidth happen a few orders of magnitude slower than the data that's driving them. SSH1 and SSH2 as protocols have full support for contentless packets that contain only padding; I'd love to see a patch. On Tue, Sep 8, 2009 at 11:44 PM, Howard Chu wrote: > Old news, but ... http://lwn.net/Articles/298833/ > > I first posted about this back in 2001 and it's still not resolved: > http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html > > 1) high latency networks are a reality that will never go away. In fact > they will only become more prevalent since distributed networks continue to > grow broader but (surprise) the speed of light remains a constant. > 2) character-at-a-time protocols have both security and performance costs. > 3) a solution for this has existed in common operating systems for a couple > of decades already (LINEMODE tty support). > > It's strange how the secsh group at the IETF refused to learn from the > lessons already gained from the years of experience with the telnet > protocol. > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From wknox at mitre.org Wed Sep 9 13:01:35 2009 From: wknox at mitre.org (Knox, Bill) Date: Tue, 8 Sep 2009 23:01:35 -0400 Subject: OpenSSH and keystroke timings In-Reply-To: References: <4AA6D020.4070103@symas.com> Message-ID: <8DA11B342D7A5643A515ACBF8B72D9876955C74A@IMCMBX3.MITRE.ORG> Your point 1) is a very narrow interpretation of the problem space - password entry that can be exposed happens not only during initial authentication in specific modes, but rather whenever you are prompted to enter a password (or private key passphrase). A case where entry of either of these is obvious on the network and for which this timing attack would work very nicely is as follows: User is connected from A to B via SSH (authentication method unimportant) User then connects within the above session from B to C and is required to enter authentication credentials (either a password or the passphrase of a private key) In this case, an adversary watching at B from the network perspective sees the A -> B connection open. There is a then a brief spurt of activity B to C as that session is set up, followed by the prompt being written back from B to A for authentication and then the typing from A to B of the SSH passphrase or the password, each character of which is sent in its own packet (this scenario is based upon the response to the LWN article found at http://lwn.net/Articles/299112/) and which, based on an empirical test just now, is very easily discernible. Even if you can't figure out the passphrase based on timing if jitter were added (one of the ideas proposed in response to the article), or even if it is a password or a private key passphrase, you at least now know how long it is. And to partially answer 2), even if passwords are a terribly flawed technology, they are still, along with SSH keys, what a significant number of people use, and it is potentially useful to try and overcome data leakage in SSH related to password/passphrase usage instead of discounting them as flawed authentication methods. I'll leave giving you a hard time about your points 3) and 4) to those more knowledgeable than myself. :-) Bill Knox Lead Infosec Engineer/Scientist The MITRE Corporation -----Original Message----- From: openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org [mailto:openssh-unix-dev-bounces+wknox=mitre.org at mindrot.org] On Behalf Of Dan Kaminsky Sent: Tuesday, September 08, 2009 6:10 PM To: Howard Chu Cc: openssh-unix-dev at mindrot.org Subject: Re: OpenSSH and keystroke timings Well, there's a lot here. Lets go down the line. 1) Password entry only occurs during keyboard-interactive mode, which at least isn't used by default (though it may be set on some distros). There's no way to downgrade someone as a MITM either. 2) Passwords in general are a terribly flawed technology, made only palatable by the disaster that is everything else (yes, this includes rsa/dsa in SSH). 3) Only the most basic of interactions with a server are line based. Even something as simple as vi requires full character mode interactivity. Heck, tab completion doesn't even work without it. 4) The right way to solve this class of problem isn't with LINEMODE tty, it's with constant timing / constant bandwidth padding in the underlying transport -- or at least, to make changes in timing and bandwidth happen a few orders of magnitude slower than the data that's driving them. SSH1 and SSH2 as protocols have full support for contentless packets that contain only padding; I'd love to see a patch. On Tue, Sep 8, 2009 at 11:44 PM, Howard Chu wrote: > Old news, but ... http://lwn.net/Articles/298833/ > > I first posted about this back in 2001 and it's still not resolved: > http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html > > 1) high latency networks are a reality that will never go away. In fact > they will only become more prevalent since distributed networks continue to > grow broader but (surprise) the speed of light remains a constant. > 2) character-at-a-time protocols have both security and performance costs. > 3) a solution for this has existed in common operating systems for a couple > of decades already (LINEMODE tty support). > > It's strange how the secsh group at the IETF refused to learn from the > lessons already gained from the years of experience with the telnet > protocol. > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > _______________________________________________ > 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 djm at mindrot.org Thu Sep 10 00:56:13 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Sep 2009 00:56:13 +1000 (EST) Subject: OpenSSH and keystroke timings In-Reply-To: <4AA6D020.4070103@symas.com> References: <4AA6D020.4070103@symas.com> Message-ID: On Tue, 8 Sep 2009, Howard Chu wrote: > Old news, but ... http://lwn.net/Articles/298833/ > > I first posted about this back in 2001 and it's still not resolved: > http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html So, if you were thinking about it back in 2001 then why haven't you implemented it yet? We don't really care for wishlists, but if you come up with a concrete specification (in the form of a Internet-draft) or a patch to implement your desired behaviour the we can talk about it. Complaining that we aren't working to your program is neither effective nor respectful. -d From djm at mindrot.org Thu Sep 10 03:00:14 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Sep 2009 03:00:14 +1000 (EST) Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: <4AA6B8BB.8070306@symas.com> References: <4AA6B8BB.8070306@symas.com> Message-ID: On Tue, 8 Sep 2009, Howard Chu wrote: > > My concern is more with the complexity and maintenance hassle of LDAP, > > not the run-time linkage. > > Could you elaborate on this comment? Most sysadmins are looking for this > feature precisely because it *reduces* the complexity and hassle of > maintaining user login info across large networks. Complexity and maintenance hassle _for the OpenSSH developers_. > Certainly the existing patch is pretty non-optimal, but the basic idea is > sound. If you want this, here is the path that I proposed to get it working: > I don't think there are any plans to merge the LPK patch. We really > don't want a dependency on LDAP libraries in sshd. Maybe if it were > abstracted into a helper app that sshd could consult to verify keys > then it would be more palatable, but even this is doubtful unless it > can be done in a way that avoids complexity - there is a lot that can > go wrong. Patches welcome. -d From hyc at symas.com Thu Sep 10 04:35:02 2009 From: hyc at symas.com (Howard Chu) Date: Wed, 09 Sep 2009 11:35:02 -0700 Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: References: <4AA6B8BB.8070306@symas.com> Message-ID: <4AA7F556.8030304@symas.com> Damien Miller wrote: > On Tue, 8 Sep 2009, Howard Chu wrote: > >>> My concern is more with the complexity and maintenance hassle of LDAP, >>> not the run-time linkage. >> >> Could you elaborate on this comment? Most sysadmins are looking for this >> feature precisely because it *reduces* the complexity and hassle of >> maintaining user login info across large networks. > > Complexity and maintenance hassle _for the OpenSSH developers_. > >> Certainly the existing patch is pretty non-optimal, but the basic idea is >> sound. > > If you want this, here is the path that I proposed to get it working: > >> I don't think there are any plans to merge the LPK patch. We really >> don't want a dependency on LDAP libraries in sshd. Maybe if it were >> abstracted into a helper app that sshd could consult to verify keys >> then it would be more palatable, but even this is doubtful unless it >> can be done in a way that avoids complexity - there is a lot that can >> go wrong. Hmm. Pushing this out to a separate process requires inventing yet another IPC protocol, and adds one more moving piece that can break. How does this approach avoid complexity? How is it any hassle to add libldap to the link dependencies of sshd? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc at symas.com Thu Sep 10 04:39:38 2009 From: hyc at symas.com (Howard Chu) Date: Wed, 09 Sep 2009 11:39:38 -0700 Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: References: <4AA6B8BB.8070306@symas.com> Message-ID: <4AA7F66A.1010001@symas.com> Damien Miller wrote: > On Tue, 8 Sep 2009, Howard Chu wrote: > >> > Old news, but ... http://lwn.net/Articles/298833/ >> > >> > I first posted about this back in 2001 and it's still not resolved: >> > http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html > So, if you were thinking about it back in 2001 then why haven't you > implemented it yet? The lack of response from the IETF list indicated to me that the likelihood of getting a protocol extension accepted/adopted was near zero. > We don't really care for wishlists, but if you come up with a concrete > specification (in the form of a Internet-draft) or a patch to implement > your desired behaviour the we can talk about it. OK. That, at least, invites the possibility. > Complaining that we > aren't working to your program is neither effective nor respectful. I didn't realize that I represented such a minority interest in wanting security. Sorry for trying to impose my selfish agenda on you. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From djm at mindrot.org Thu Sep 10 04:44:24 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Sep 2009 04:44:24 +1000 (EST) Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: <4AA7F556.8030304@symas.com> References: <4AA6B8BB.8070306@symas.com> <4AA7F556.8030304@symas.com> Message-ID: On Wed, 9 Sep 2009, Howard Chu wrote: > Hmm. Pushing this out to a separate process requires inventing yet > another IPC protocol, and adds one more moving piece that can break. > How does this approach avoid complexity? It avoids complexity in the critical part - the sshd daemon. It is more orthogonal too - if someone wants to store keys in xyzdb then they can make a subprocess to do that too. > How is it any hassle to add libldap to the link dependencies of sshd? Because the API presented by the LDAP libraries that I have looked at is quite ugly, because different platforms have different favourite LDAP APIs, because we don't want to build in support for every crazy variant schema that people will inevitably come up with. -d From djm at mindrot.org Thu Sep 10 04:54:36 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Sep 2009 04:54:36 +1000 (EST) Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: <4AA7F66A.1010001@symas.com> References: <4AA6B8BB.8070306@symas.com> <4AA7F66A.1010001@symas.com> Message-ID: On Wed, 9 Sep 2009, Howard Chu wrote: > Damien Miller wrote: > > On Tue, 8 Sep 2009, Howard Chu wrote: > > > > > > Old news, but ... http://lwn.net/Articles/298833/ > > > > > > > > I first posted about this back in 2001 and it's still not resolved: > > > > http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html > > So, if you were thinking about it back in 2001 then why haven't you > > implemented it yet? > > The lack of response from the IETF list indicated to me that the > likelihood of getting a protocol extension accepted/adopted was near > zero. Yeah, it sucks to have to actually do the work in making a wishlist item into a proposal that people can evaluate. -d From hyc at symas.com Thu Sep 10 05:17:49 2009 From: hyc at symas.com (Howard Chu) Date: Wed, 09 Sep 2009 12:17:49 -0700 Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: References: <4AA6B8BB.8070306@symas.com> <4AA7F66A.1010001@symas.com> Message-ID: <4AA7FF5D.2000905@symas.com> Damien Miller wrote: > On Wed, 9 Sep 2009, Howard Chu wrote: > >> Damien Miller wrote: >>> On Tue, 8 Sep 2009, Howard Chu wrote: >>> >>>>> Old news, but ... http://lwn.net/Articles/298833/ >>>>> >>>>> I first posted about this back in 2001 and it's still not resolved: >>>>> http://osdir.com/ml/ietf.secsh/2001-09/msg00000.html >>> So, if you were thinking about it back in 2001 then why haven't you >>> implemented it yet? >> The lack of response from the IETF list indicated to me that the >> likelihood of getting a protocol extension accepted/adopted was near >> zero. > Yeah, it sucks to have to actually do the work in making a wishlist > item into a proposal that people can evaluate. Given the existence of this feature in telnet, with its complete behavior already spelled out in RFCs http://www.ietf.org/rfc/rfc1184.txt the only thing left is to map the command sequences into the ssh protocol, which can be accomplished pretty mechanically. Actual implementations in the telnet context have been available to evaluate for 2 decades. If you go back through the comp.sources.unix archives from 1989 or so you'll also find the patches I wrote to implement a local command history buffer (ala Gnu readline, but obviously different since that didn't exist yet) for the telnet client. If you need to evaluate how well the feature can work, and how much work it is to implement it, then you already have all the information you need. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From djm at mindrot.org Thu Sep 10 05:57:05 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Sep 2009 05:57:05 +1000 (EST) Subject: Support for merging LPK and hpn-ssh into mainline openssh? In-Reply-To: <4AA7FF5D.2000905@symas.com> References: <4AA6B8BB.8070306@symas.com> <4AA7F66A.1010001@symas.com> <4AA7FF5D.2000905@symas.com> Message-ID: On Wed, 9 Sep 2009, Howard Chu wrote: > Given the existence of this feature in telnet, with its complete behavior > already spelled out in RFCs http://www.ietf.org/rfc/rfc1184.txt the only thing > left is to map the command sequences into the ssh protocol, which can be > accomplished pretty mechanically. Actual implementations in the telnet context > have been available to evaluate for 2 decades. If you go back through the > comp.sources.unix archives from 1989 or so you'll also find the patches I > wrote to implement a local command history buffer (ala Gnu readline, but > obviously different since that didn't exist yet) for the telnet client. It sounds like you are uniquely familiar with what needs to be done, so you should get on it right away. -d From Rainer.Winhard at bmw.de Thu Sep 10 21:00:56 2009 From: Rainer.Winhard at bmw.de (Rainer.Winhard at bmw.de) Date: Thu, 10 Sep 2009 13:00:56 +0200 Subject: Multiple (multiplexed) simultaneous ssh connections - Cygwin bug? Message-ID: Hello, I've see you answered a problem with simultaneous ssh connections in cygwin. The version I'm using is CYGWIN_NT-5.2 I've change the sshd_config and put the Parameter maxsessions 100 in it. But it doesn't work. Ich have still 10 limited ssh session at onen time. I need at least approx 100 to fix our specific problem. I've also tried mas_ssh_starts=100 but this prevent the ssh server to start up again. Did you have an Idea, or the right syntax for maxsessions mit freundlichen Gr??en / best regards Rainer Winhard ------------------------------------------------------- BMW Group Rainer Winhard IT Service Management Informationstechnologiezentrum - ITZ Bremer Str. 6 80807 M?nchen Tel: +49 89 382 58363 mobil : +49 176 601 58363 mailto: Rainer.Winhard at bmw.de Url: http://www.bmwgroup.com/ -------------------------------------------------------- Bayerische Motoren Werke Aktiengesellschaft Vorstand: Norbert Reithofer, Vorsitzender, Frank-Peter Arndt, Herbert Diess, Klaus Draeger, Friedrich Eichiner, Harald Kr?ger, Ian Robertson Vorsitzender des Aufsichtsrats: Joachim Milberg Sitz und Registergericht: M?nchen HRB 42243 -------------------------------------------------------- From peter at stuge.se Fri Sep 11 06:55:23 2009 From: peter at stuge.se (Peter Stuge) Date: Thu, 10 Sep 2009 22:55:23 +0200 Subject: your mail In-Reply-To: <470CEC9B.8070904@psc.edu> References: <20071010041238.2211.qmail@cdy.org> <470CEC9B.8070904@psc.edu> Message-ID: <20090910205524.5209.qmail@stuge.se> Chris Rapier wrote: > >> I understand that that is not how scp works today. > > > > And it will likely never change. > > Which is unfortunate because scp is, based on the logs I have > access to, what most users are using to transfer files. As much as > it might be nice if they moved to sftp I don't see it happening > with any real rapidity. We can argue all we like that sftp is > better or rsync is superior but unless the users agree it doesn't > matter what we might happen to think. I agree. We need scp to use sftp. On that note - I'm excited about the outcome of the Google Summer of Code project! How did it go? :) //Peter From jbasney at ncsa.uiuc.edu Fri Sep 11 07:03:46 2009 From: jbasney at ncsa.uiuc.edu (Jim Basney) Date: Thu, 10 Sep 2009 16:03:46 -0500 Subject: need -lresolv on MacOSX 10.6 Message-ID: <4AA969B2.5040001@ncsa.uiuc.edu> Hi, When building OpenSSH 5.2p1 on MacOSX 10.6.0, I get the following ld error gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o -L. -Lopenbsd-compat/ -fstack-protector-all -lssh -lopenbsd-compat -lcrypto -lz Undefined symbols: "_res_9_query", referenced from: _getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o) "_res_9_getshort", referenced from: _parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o) _parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o) _parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o) _getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o) _getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o) "_res_9_getlong", referenced from: _parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o) "_res_9_init", referenced from: _getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o) "_res_9_dn_expand", referenced from: _parse_dns_rrsection in libopenbsd-compat.a(getrrsetbyname.o) _getrrsetbyname in libopenbsd-compat.a(getrrsetbyname.o) ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [ssh] Error 1 Adding -lresolv to the link line fixes it. Checking , I see that Apple's OpenSSH package adds -lresolv to "Extra_LD_Flags". I notice that /usr/include/resolve.h on MacOSX 10.6.0 no longer contains #ifdef BIND_8_COMPAT #include as seen in previous MacOSX releases, so we get #define res_query res_9_query which creates the dependency on -lresolv. OpenSSH's configure script tests for res_query with AC_TRY_LINK_FUNC(res_query, ...) which doesn't #include , so it doesn't detect that -lresolv is needed for res_9_query. The attached patch is my attempt to fix it. -Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-5.2p1.resolv.patch URL: From dtucker at zip.com.au Fri Sep 11 14:56:44 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Sep 2009 14:56:44 +1000 Subject: need -lresolv on MacOSX 10.6 In-Reply-To: <4AA969B2.5040001@ncsa.uiuc.edu> References: <4AA969B2.5040001@ncsa.uiuc.edu> Message-ID: <4AA9D88C.6080006@zip.com.au> Jim Basney wrote: [...] > OpenSSH's configure script tests for res_query with > AC_TRY_LINK_FUNC(res_query, ...) which doesn't #include , so > it doesn't detect that -lresolv is needed for res_9_query. The attached > patch is my attempt to fix it. Seems reasonable to me. Committed, thanks! -- 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 antoniomignolli at gmail.com Sat Sep 12 00:16:01 2009 From: antoniomignolli at gmail.com (Antonio Mignolli) Date: Fri, 11 Sep 2009 16:16:01 +0200 Subject: ProxyCommand not working if $SHELL not defined Message-ID: #ssh -V OpenSSH_5.1p1, OpenSSL 0.9.8i 15 Sep 2008 Probably is not a real issue, because everyone should have its SHELL var defined, but as said above, when it's not, ssh with ProxyCommand will fail. I use connect.c, but with no SHELL var defined is not executed, ssh -v will give "No such file", and I'm pretty sure it refers to the shell, I read in ChangeLog that now ProxyCommand will use $SHELL instead of /bin/sh. Maybe consider using /bin/sh as default when SHELL is not defined? my .ssh/config Host myhost ProxyCommand connect -a none -S proxyIP myhost From dtucker at zip.com.au Sat Sep 12 07:21:34 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Sep 2009 07:21:34 +1000 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: Message-ID: <4AAABF5E.4010207@zip.com.au> Antonio Mignolli wrote: > Probably is not a real issue, because everyone should have its SHELL var > defined, > but as said above, when it's not, ssh with ProxyCommand will fail. > I use connect.c, but with no SHELL var defined is not executed, ssh -v > will give "No such file", and I'm pretty sure it refers to the shell, > I read in ChangeLog that now ProxyCommand will use $SHELL instead > of /bin/sh. > Maybe consider using /bin/sh as default when SHELL is not defined? It already does that. From sshconnect.c:ssh_proxy_connect() if ((shell = getenv("SHELL")) == NULL) shell = _PATH_BSHELL; where _PATH_BSHELL is defined in defines.h as: #ifndef _PATH_BSHELL # define _PATH_BSHELL "/bin/sh" The only thing I can think of is _PATH_BSHELL being defined in the system headers and pointing somewhere else. If you strace/truss ssh can you see what it's trying to open immediately before the "No such file"? -- 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 antoniomignolli at gmail.com Sat Sep 12 22:16:42 2009 From: antoniomignolli at gmail.com (Antonio Mignolli) Date: Sat, 12 Sep 2009 14:16:42 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: <4AAABF5E.4010207@zip.com.au> References: <4AAABF5E.4010207@zip.com.au> Message-ID: Now I got it. It happens when SHELL is defined but as empty string, so I don't know if is to be considered an openssh issue. My user had a blank field in /etc/passwd, and logging in in a icewm environment will give me shells with an empty SHELL variable, causing getenv return a not NULL value. Same issue when executing ssh_local_cmd, for the same reason, there is another check on SHELL not null. I have tested that, and with SHELL="" I got "Couldn't execute ..". Thanks for your attention. 2009/9/11 Darren Tucker > Antonio Mignolli wrote: > >> Probably is not a real issue, because everyone should have its SHELL var >> defined, >> but as said above, when it's not, ssh with ProxyCommand will fail. >> I use connect.c, but with no SHELL var defined is not executed, ssh -v >> will give "No such file", and I'm pretty sure it refers to the shell, >> I read in ChangeLog that now ProxyCommand will use $SHELL instead >> of /bin/sh. >> Maybe consider using /bin/sh as default when SHELL is not defined? >> > > It already does that. From sshconnect.c:ssh_proxy_connect() > > if ((shell = getenv("SHELL")) == NULL) > shell = _PATH_BSHELL; > > where _PATH_BSHELL is defined in defines.h as: > > #ifndef _PATH_BSHELL > # define _PATH_BSHELL "/bin/sh" > > The only thing I can think of is _PATH_BSHELL being defined in the system > headers and pointing somewhere else. If you strace/truss ssh can you see > what it's trying to open immediately before the "No such file"? > > -- > 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 antoniomignolli at gmail.com Sat Sep 12 22:24:49 2009 From: antoniomignolli at gmail.com (Antonio Mignolli) Date: Sat, 12 Sep 2009 14:24:49 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: I forgot, same issue with sftp, when executing local commands. 2009/9/12 Antonio Mignolli > Now I got it. > It happens when SHELL is defined but as empty string, > so I don't know if is to be considered an openssh issue. > > My user had a blank field in /etc/passwd, and logging in > in a icewm environment will give me shells with > an empty SHELL variable, causing getenv return a not NULL value. > Same issue when executing ssh_local_cmd, for the same reason, > there is another check on SHELL not null. > I have tested that, and with SHELL="" I got "Couldn't execute ..". > > Thanks for your attention. > > 2009/9/11 Darren Tucker > > Antonio Mignolli wrote: >> >>> Probably is not a real issue, because everyone should have its SHELL var >>> defined, >>> but as said above, when it's not, ssh with ProxyCommand will fail. >>> I use connect.c, but with no SHELL var defined is not executed, ssh -v >>> will give "No such file", and I'm pretty sure it refers to the shell, >>> I read in ChangeLog that now ProxyCommand will use $SHELL instead >>> of /bin/sh. >>> Maybe consider using /bin/sh as default when SHELL is not defined? >>> >> >> It already does that. From sshconnect.c:ssh_proxy_connect() >> >> if ((shell = getenv("SHELL")) == NULL) >> shell = _PATH_BSHELL; >> >> where _PATH_BSHELL is defined in defines.h as: >> >> #ifndef _PATH_BSHELL >> # define _PATH_BSHELL "/bin/sh" >> >> The only thing I can think of is _PATH_BSHELL being defined in the system >> headers and pointing somewhere else. If you strace/truss ssh can you see >> what it's trying to open immediately before the "No such file"? >> >> -- >> 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 antoniomignolli at gmail.com Wed Sep 16 20:05:23 2009 From: antoniomignolli at gmail.com (Antonio Mignolli) Date: Wed, 16 Sep 2009 12:05:23 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: I have a suggested patch for the discussed SHELL var issue. With the help of a function get_shell_from_env(), in misc.c, it is now able to set always a good shell, falling back to default if SHELL is not defined or it is not a valid executable, hence including SHELL="" (empty string). Tested in all cases: . ssh with proxycommand . ssh with local command execution . sftp with local command execution (ex. lls) (The patch also changes getenv("SHELL") with get_shell_from_env() in ssh-agent.c, where there is a check whether csh is specified). The patch is made (and inspired) also by my friend Daniele Calore ( orkaan () orkaan dot org ). 2009/9/12 Antonio Mignolli > I forgot, same issue with sftp, when executing local commands. > > > > 2009/9/12 Antonio Mignolli > > Now I got it. >> It happens when SHELL is defined but as empty string, >> so I don't know if is to be considered an openssh issue. >> >> My user had a blank field in /etc/passwd, and logging in >> in a icewm environment will give me shells with >> an empty SHELL variable, causing getenv return a not NULL value. >> Same issue when executing ssh_local_cmd, for the same reason, >> there is another check on SHELL not null. >> I have tested that, and with SHELL="" I got "Couldn't execute ..". >> >> Thanks for your attention. >> >> 2009/9/11 Darren Tucker >> >> Antonio Mignolli wrote: >>> >>>> Probably is not a real issue, because everyone should have its SHELL var >>>> defined, >>>> but as said above, when it's not, ssh with ProxyCommand will fail. >>>> I use connect.c, but with no SHELL var defined is not executed, ssh -v >>>> will give "No such file", and I'm pretty sure it refers to the shell, >>>> I read in ChangeLog that now ProxyCommand will use $SHELL instead >>>> of /bin/sh. >>>> Maybe consider using /bin/sh as default when SHELL is not defined? >>>> >>> >>> It already does that. From sshconnect.c:ssh_proxy_connect() >>> >>> if ((shell = getenv("SHELL")) == NULL) >>> shell = _PATH_BSHELL; >>> >>> where _PATH_BSHELL is defined in defines.h as: >>> >>> #ifndef _PATH_BSHELL >>> # define _PATH_BSHELL "/bin/sh" >>> >>> The only thing I can think of is _PATH_BSHELL being defined in the system >>> headers and pointing somewhere else. If you strace/truss ssh can you see >>> what it's trying to open immediately before the "No such file"? >>> >>> -- >>> 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 antonio.mignolli at yahoo.it Wed Sep 16 20:49:49 2009 From: antonio.mignolli at yahoo.it (Antonio Mignolli) Date: Wed, 16 Sep 2009 12:49:49 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: Here is the suggested patch fixing the SHELL env var issues. 2009/9/16 Antonio Mignolli > > I have a suggested patch for the discussed SHELL var issue. > With the help of a function get_shell_from_env(), in misc.c, > it is now able to set always a good shell, falling back > to default if SHELL is not defined or it is not a valid executable, > hence including SHELL="" (empty string). > > Tested in all cases: > . ssh with proxycommand > . ssh with local command execution > . sftp with local command execution (ex. lls) > > (The patch also changes getenv("SHELL") with get_shell_from_env() > ? in ssh-agent.c, where there is a check whether csh is specified). > > The patch is made (and inspired) also by my friend Daniele Calore ( orkaan () orkaan dot org ). > > 2009/9/12 Antonio Mignolli >> >> I forgot, same issue with sftp, when executing local commands. >> >> >> >> 2009/9/12 Antonio Mignolli >>> >>> Now I got it. >>> It happens when SHELL is defined but as empty string, >>> so I don't know if is to be considered an openssh issue. >>> >>> My user had a blank field in /etc/passwd, and logging in >>> in a icewm environment will give me shells with >>> an empty SHELL variable, causing getenv return a not NULL value. >>> Same issue when executing ssh_local_cmd, for the same reason, >>> there is another check on SHELL not null. >>> I have tested that, and with SHELL="" I got "Couldn't execute ..". >>> >>> Thanks for your attention. >>> >>> 2009/9/11 Darren Tucker >>>> >>>> Antonio Mignolli wrote: >>>>> >>>>> Probably is not a real issue, because everyone should have its SHELL var >>>>> defined, >>>>> but as said above, when it's not, ssh with ProxyCommand will fail. >>>>> I use connect.c, but with no SHELL var defined is not executed, ssh -v >>>>> will give "No such file", and I'm pretty sure it refers to the shell, >>>>> I read in ChangeLog that now ProxyCommand will use $SHELL instead >>>>> of /bin/sh. >>>>> Maybe consider using /bin/sh as default when SHELL is not defined? >>>> >>>> It already does that. ?From sshconnect.c:ssh_proxy_connect() >>>> >>>> ? ? ? ?if ((shell = getenv("SHELL")) == NULL) >>>> ? ? ? ? ? ? ? ?shell = _PATH_BSHELL; >>>> >>>> where _PATH_BSHELL is defined in defines.h as: >>>> >>>> #ifndef _PATH_BSHELL >>>> # define _PATH_BSHELL "/bin/sh" >>>> >>>> The only thing I can think of is _PATH_BSHELL being defined in the system headers and pointing somewhere else. ?If you strace/truss ssh can you see what it's trying to open immediately before the "No such file"? >>>> >>>> -- >>>> 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 antonio.mignolli at yahoo.it Thu Sep 17 19:21:54 2009 From: antonio.mignolli at yahoo.it (Antonio Mignolli) Date: Thu, 17 Sep 2009 11:21:54 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: Someone told me the patch was not attached. I see it as correctly attached in my sent mail, now I retry changing the file name. 2009/9/16 Antonio Mignolli : > Here is the suggested patch fixing the SHELL env var issues. > > 2009/9/16 Antonio Mignolli >> >> I have a suggested patch for the discussed SHELL var issue. >> With the help of a function get_shell_from_env(), in misc.c, >> it is now able to set always a good shell, falling back >> to default if SHELL is not defined or it is not a valid executable, >> hence including SHELL="" (empty string). >> >> Tested in all cases: >> . ssh with proxycommand >> . ssh with local command execution >> . sftp with local command execution (ex. lls) >> >> (The patch also changes getenv("SHELL") with get_shell_from_env() >> ? in ssh-agent.c, where there is a check whether csh is specified). >> >> The patch is made (and inspired) also by my friend Daniele Calore ( orkaan () orkaan dot org ). >> >> 2009/9/12 Antonio Mignolli >>> >>> I forgot, same issue with sftp, when executing local commands. >>> >>> >>> >>> 2009/9/12 Antonio Mignolli >>>> >>>> Now I got it. >>>> It happens when SHELL is defined but as empty string, >>>> so I don't know if is to be considered an openssh issue. >>>> >>>> My user had a blank field in /etc/passwd, and logging in >>>> in a icewm environment will give me shells with >>>> an empty SHELL variable, causing getenv return a not NULL value. >>>> Same issue when executing ssh_local_cmd, for the same reason, >>>> there is another check on SHELL not null. >>>> I have tested that, and with SHELL="" I got "Couldn't execute ..". >>>> >>>> Thanks for your attention. >>>> >>>> 2009/9/11 Darren Tucker >>>>> >>>>> Antonio Mignolli wrote: >>>>>> >>>>>> Probably is not a real issue, because everyone should have its SHELL var >>>>>> defined, >>>>>> but as said above, when it's not, ssh with ProxyCommand will fail. >>>>>> I use connect.c, but with no SHELL var defined is not executed, ssh -v >>>>>> will give "No such file", and I'm pretty sure it refers to the shell, >>>>>> I read in ChangeLog that now ProxyCommand will use $SHELL instead >>>>>> of /bin/sh. >>>>>> Maybe consider using /bin/sh as default when SHELL is not defined? >>>>> >>>>> It already does that. ?From sshconnect.c:ssh_proxy_connect() >>>>> >>>>> ? ? ? ?if ((shell = getenv("SHELL")) == NULL) >>>>> ? ? ? ? ? ? ? ?shell = _PATH_BSHELL; >>>>> >>>>> where _PATH_BSHELL is defined in defines.h as: >>>>> >>>>> #ifndef _PATH_BSHELL >>>>> # define _PATH_BSHELL "/bin/sh" >>>>> >>>>> The only thing I can think of is _PATH_BSHELL being defined in the system headers and pointing somewhere else. ?If you strace/truss ssh can you see what it's trying to open immediately before the "No such file"? >>>>> >>>>> -- >>>>> 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 bert.wesarg at googlemail.com Thu Sep 17 20:00:19 2009 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Thu, 17 Sep 2009 12:00:19 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: <36ca99e90909170300m6e84b752u644384f1e7d2bcb@mail.gmail.com> On Thu, Sep 17, 2009 at 11:21, Antonio Mignolli wrote: > Someone told me the patch was not attached. > I see it as correctly attached in my sent mail, > now I retry changing the file name. It's still not attached. From antonio.mignolli at yahoo.it Thu Sep 17 20:16:44 2009 From: antonio.mignolli at yahoo.it (Antonio Mignolli) Date: Thu, 17 Sep 2009 12:16:44 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: Maybe the mailing list cuts the attachments. patch.openssh-5.2p1.SHELLfix: 8<----------------------------------------------------------------- Common subdirectories: openssh-5.2p1/contrib and openssh-5.2p1.new/contrib diff -NupwB openssh-5.2p1/misc.c openssh-5.2p1.new/misc.c --- openssh-5.2p1/misc.c 2009-02-21 22:47:02.000000000 +0100 +++ openssh-5.2p1.new/misc.c 2009-09-16 02:21:11.000000000 +0200 @@ -849,3 +849,29 @@ ms_to_timeval(struct timeval *tv, int ms tv->tv_usec = (ms % 1000) * 1000; } +/* + * Get shell from env or use default '/bin/sh' + */ +char * +get_shell_from_env() +{ + struct stat st; + char *shell; + + shell = getenv("SHELL"); + + /* If shell does not exist or it is not executable switch to '/bin/sh' */ + + if (stat(shell, &st) == 0) { + if (S_ISREG(st.st_mode) == 0 || + (st.st_mode & (S_IXOTH|S_IXUSR|S_IXGRP)) == 0) { + debug("Warning, environment variable $SHELL='%s' points to a non-executable, using default: %s",shell,_PATH_BSHELL); + shell = _PATH_BSHELL; + } + } + else { + debug("Warning, shell not found (environment $SHELL='%s'), using default: %s",shell,_PATH_BSHELL); + shell = _PATH_BSHELL; + } + return shell; +} diff -NupwB openssh-5.2p1/misc.h openssh-5.2p1.new/misc.h --- openssh-5.2p1/misc.h 2008-06-12 22:42:45.000000000 +0200 +++ openssh-5.2p1.new/misc.h 2009-09-15 23:30:08.000000000 +0200 @@ -53,6 +53,8 @@ void freeargs(arglist *); int tun_open(int, int); +char *get_shell_from_env(); + /* Common definitions for ssh tunnel device forwarding */ #define SSH_TUNMODE_NO 0x00 #define SSH_TUNMODE_POINTOPOINT 0x01 Common subdirectories: openssh-5.2p1/openbsd-compat and openssh-5.2p1.new/openbsd-compat Common subdirectories: openssh-5.2p1/regress and openssh-5.2p1.new/regress Common subdirectories: openssh-5.2p1/scard and openssh-5.2p1.new/scard diff -NupwB openssh-5.2p1/sftp.c openssh-5.2p1.new/sftp.c --- openssh-5.2p1/sftp.c 2009-02-14 06:26:19.000000000 +0100 +++ openssh-5.2p1.new/sftp.c 2009-09-15 18:01:12.000000000 +0200 @@ -250,8 +250,7 @@ local_do_shell(const char *args) if (!*args) args = NULL; - if ((shell = getenv("SHELL")) == NULL) - shell = _PATH_BSHELL; + shell = get_shell_from_env(); if ((pid = fork()) == -1) fatal("Couldn't fork: %s", strerror(errno)); diff -NupwB openssh-5.2p1/ssh-agent.c openssh-5.2p1.new/ssh-agent.c --- openssh-5.2p1/ssh-agent.c 2008-07-04 15:10:49.000000000 +0200 +++ openssh-5.2p1.new/ssh-agent.c 2009-09-15 22:57:17.000000000 +0200 @@ -1120,9 +1120,8 @@ main(int ac, char **av) usage(); if (ac == 0 && !c_flag && !s_flag) { - shell = getenv("SHELL"); - if (shell != NULL && - strncmp(shell + strlen(shell) - 3, "csh", 3) == 0) + shell = get_shell_from_env(); /* shell can never be NULL */ + if (strncmp(shell + strlen(shell) - 3, "csh", 3) == 0) c_flag = 1; } if (k_flag) { diff -NupwB openssh-5.2p1/sshconnect.c openssh-5.2p1.new/sshconnect.c --- openssh-5.2p1/sshconnect.c 2009-02-01 12:19:54.000000000 +0100 +++ openssh-5.2p1.new/sshconnect.c 2009-09-16 02:14:19.000000000 +0200 @@ -84,8 +84,7 @@ ssh_proxy_connect(const char *host, u_sh pid_t pid; char *shell, strport[NI_MAXSERV]; - if ((shell = getenv("SHELL")) == NULL) - shell = _PATH_BSHELL; + shell = get_shell_from_env(); /* Convert the port number into a string. */ snprintf(strport, sizeof strport, "%hu", port); @@ -1159,8 +1158,7 @@ ssh_local_cmd(const char *args) args == NULL || !*args) return (1); - if ((shell = getenv("SHELL")) == NULL) - shell = _PATH_BSHELL; + shell = get_shell_from_env(); pid = fork(); if (pid == 0) { ----------------------------------------------------------------->8 2009/9/17 Antonio Mignolli : > Someone told me the patch was not attached. > I see it as correctly attached in my sent mail, > now I retry changing the file name. > > 2009/9/16 Antonio Mignolli : >> Here is the suggested patch fixing the SHELL env var issues. >> >> 2009/9/16 Antonio Mignolli >>> >>> I have a suggested patch for the discussed SHELL var issue. >>> With the help of a function get_shell_from_env(), in misc.c, >>> it is now able to set always a good shell, falling back >>> to default if SHELL is not defined or it is not a valid executable, >>> hence including SHELL="" (empty string). >>> >>> Tested in all cases: >>> . ssh with proxycommand >>> . ssh with local command execution >>> . sftp with local command execution (ex. lls) >>> >>> (The patch also changes getenv("SHELL") with get_shell_from_env() >>> ? in ssh-agent.c, where there is a check whether csh is specified). >>> >>> The patch is made (and inspired) also by my friend Daniele Calore ( orkaan () orkaan dot org ). >>> >>> 2009/9/12 Antonio Mignolli >>>> >>>> I forgot, same issue with sftp, when executing local commands. >>>> >>>> >>>> >>>> 2009/9/12 Antonio Mignolli >>>>> >>>>> Now I got it. >>>>> It happens when SHELL is defined but as empty string, >>>>> so I don't know if is to be considered an openssh issue. >>>>> >>>>> My user had a blank field in /etc/passwd, and logging in >>>>> in a icewm environment will give me shells with >>>>> an empty SHELL variable, causing getenv return a not NULL value. >>>>> Same issue when executing ssh_local_cmd, for the same reason, >>>>> there is another check on SHELL not null. >>>>> I have tested that, and with SHELL="" I got "Couldn't execute ..". >>>>> >>>>> Thanks for your attention. >>>>> >>>>> 2009/9/11 Darren Tucker >>>>>> >>>>>> Antonio Mignolli wrote: >>>>>>> >>>>>>> Probably is not a real issue, because everyone should have its SHELL var >>>>>>> defined, >>>>>>> but as said above, when it's not, ssh with ProxyCommand will fail. >>>>>>> I use connect.c, but with no SHELL var defined is not executed, ssh -v >>>>>>> will give "No such file", and I'm pretty sure it refers to the shell, >>>>>>> I read in ChangeLog that now ProxyCommand will use $SHELL instead >>>>>>> of /bin/sh. >>>>>>> Maybe consider using /bin/sh as default when SHELL is not defined? >>>>>> >>>>>> It already does that. ?From sshconnect.c:ssh_proxy_connect() >>>>>> >>>>>> ? ? ? ?if ((shell = getenv("SHELL")) == NULL) >>>>>> ? ? ? ? ? ? ? ?shell = _PATH_BSHELL; >>>>>> >>>>>> where _PATH_BSHELL is defined in defines.h as: >>>>>> >>>>>> #ifndef _PATH_BSHELL >>>>>> # define _PATH_BSHELL "/bin/sh" >>>>>> >>>>>> The only thing I can think of is _PATH_BSHELL being defined in the system headers and pointing somewhere else. ?If you strace/truss ssh can you see what it's trying to open immediately before the "No such file"? >>>>>> >>>>>> -- >>>>>> 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 bert.wesarg at googlemail.com Thu Sep 17 20:33:08 2009 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Thu, 17 Sep 2009 12:33:08 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: <36ca99e90909170333p3a9e541al3f450304ae5cc3d@mail.gmail.com> On Thu, Sep 17, 2009 at 12:16, Antonio Mignolli wrote: > Maybe the mailing list cuts the attachments. > > patch.openssh-5.2p1.SHELLfix: > > 8<----------------------------------------------------------------- > diff -NupwB openssh-5.2p1/ssh-agent.c openssh-5.2p1.new/ssh-agent.c > --- openssh-5.2p1/ssh-agent.c ? 2008-07-04 15:10:49.000000000 +0200 > +++ openssh-5.2p1.new/ssh-agent.c ? ? ? 2009-09-15 22:57:17.000000000 +0200 > @@ -1120,9 +1120,8 @@ main(int ac, char **av) > ? ? ? ? ? ? ? ?usage(); > > ? ? ? ?if (ac == 0 && !c_flag && !s_flag) { > - ? ? ? ? ? ? ? shell = getenv("SHELL"); > - ? ? ? ? ? ? ? if (shell != NULL && > - ? ? ? ? ? ? ? ? ? strncmp(shell + strlen(shell) - 3, "csh", 3) == 0) > + ? ? ? ? ? ? ? shell = get_shell_from_env(); /* shell can never be NULL */ > + ? ? ? ? ? ? ? if (strncmp(shell + strlen(shell) - 3, "csh", 3) == 0) This is not your fault, but someone should add a check, if shell is at least 3 characters long! Bert > ? ? ? ? ? ? ? ? ? ? ? ?c_flag = 1; > ? ? ? ?} > ? ? ? ?if (k_flag) { From djm at mindrot.org Thu Sep 17 22:28:04 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 17 Sep 2009 22:28:04 +1000 (EST) Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: On Thu, 17 Sep 2009, Antonio Mignolli wrote: > Maybe the mailing list cuts the attachments. Yes, we strip pretty much everything but text/plain to avoid spam and malware. > patch.openssh-5.2p1.SHELLfix: > > 8<----------------------------------------------------------------- > Common subdirectories: openssh-5.2p1/contrib and openssh-5.2p1.new/contrib > diff -NupwB openssh-5.2p1/misc.c openssh-5.2p1.new/misc.c > --- openssh-5.2p1/misc.c 2009-02-21 22:47:02.000000000 +0100 > +++ openssh-5.2p1.new/misc.c 2009-09-16 02:21:11.000000000 +0200 > @@ -849,3 +849,29 @@ ms_to_timeval(struct timeval *tv, int ms > tv->tv_usec = (ms % 1000) * 1000; > } > > +/* > + * Get shell from env or use default '/bin/sh' > + */ > +char * > +get_shell_from_env() ... I think that this is quite overcomplicated. This is probably sufficient. Index: sftp.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp.c,v retrieving revision 1.111 diff -u -p -r1.111 sftp.c --- sftp.c 18 Aug 2009 18:36:21 -0000 1.111 +++ sftp.c 17 Sep 2009 12:26:04 -0000 @@ -236,7 +236,7 @@ local_do_shell(const char *args) if (!*args) args = NULL; - if ((shell = getenv("SHELL")) == NULL) + if ((shell = getenv("SHELL")) == NULL || *shell == '\0') shell = _PATH_BSHELL; if ((pid = fork()) == -1) Index: sshconnect.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v retrieving revision 1.214 diff -u -p -r1.214 sshconnect.c --- sshconnect.c 28 May 2009 16:50:16 -0000 1.214 +++ sshconnect.c 17 Sep 2009 12:26:05 -0000 @@ -76,7 +76,7 @@ ssh_proxy_connect(const char *host, u_sh pid_t pid; char *shell, strport[NI_MAXSERV]; - if ((shell = getenv("SHELL")) == NULL) + if ((shell = getenv("SHELL")) == NULL || *shell == '\0') shell = _PATH_BSHELL; /* Convert the port number into a string. */ @@ -1148,7 +1148,7 @@ ssh_local_cmd(const char *args) args == NULL || !*args) return (1); - if ((shell = getenv("SHELL")) == NULL) + if ((shell = getenv("SHELL")) == NULL || *shell == '\0') shell = _PATH_BSHELL; pid = fork(); From antonio.mignolli at yahoo.it Thu Sep 17 22:47:19 2009 From: antonio.mignolli at yahoo.it (Antonio Mignolli) Date: Thu, 17 Sep 2009 14:47:19 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: Ok, but the case with a not valid shell (non executable) is not covered. It is also a user (or sysadm) fault, though, if SHELL is not properly set. Bye. 2009/9/17 Damien Miller : > On Thu, 17 Sep 2009, Antonio Mignolli wrote: > >> Maybe the mailing list cuts the attachments. > > Yes, we strip pretty much everything but text/plain to avoid spam and > malware. > >> patch.openssh-5.2p1.SHELLfix: >> >> 8<----------------------------------------------------------------- >> Common subdirectories: openssh-5.2p1/contrib and openssh-5.2p1.new/contrib >> diff -NupwB openssh-5.2p1/misc.c openssh-5.2p1.new/misc.c >> --- openssh-5.2p1/misc.c ? ? ?2009-02-21 22:47:02.000000000 +0100 >> +++ openssh-5.2p1.new/misc.c ?2009-09-16 02:21:11.000000000 +0200 >> @@ -849,3 +849,29 @@ ms_to_timeval(struct timeval *tv, int ms >> ? ? ? tv->tv_usec = (ms % 1000) * 1000; >> ?} >> >> +/* >> + * Get shell from env or use default '/bin/sh' >> + */ >> +char * >> +get_shell_from_env() > > ... > > I think that this is quite overcomplicated. This is probably sufficient. > > Index: sftp.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/sftp.c,v > retrieving revision 1.111 > diff -u -p -r1.111 sftp.c > --- sftp.c ? ? ?18 Aug 2009 18:36:21 -0000 ? ? ?1.111 > +++ sftp.c ? ? ?17 Sep 2009 12:26:04 -0000 > @@ -236,7 +236,7 @@ local_do_shell(const char *args) > ? ? ? ?if (!*args) > ? ? ? ? ? ? ? ?args = NULL; > > - ? ? ? if ((shell = getenv("SHELL")) == NULL) > + ? ? ? if ((shell = getenv("SHELL")) == NULL || *shell == '\0') > ? ? ? ? ? ? ? ?shell = _PATH_BSHELL; > > ? ? ? ?if ((pid = fork()) == -1) > Index: sshconnect.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v > retrieving revision 1.214 > diff -u -p -r1.214 sshconnect.c > --- sshconnect.c ? ? ? ?28 May 2009 16:50:16 -0000 ? ? ?1.214 > +++ sshconnect.c ? ? ? ?17 Sep 2009 12:26:05 -0000 > @@ -76,7 +76,7 @@ ssh_proxy_connect(const char *host, u_sh > ? ? ? ?pid_t pid; > ? ? ? ?char *shell, strport[NI_MAXSERV]; > > - ? ? ? if ((shell = getenv("SHELL")) == NULL) > + ? ? ? if ((shell = getenv("SHELL")) == NULL || *shell == '\0') > ? ? ? ? ? ? ? ?shell = _PATH_BSHELL; > > ? ? ? ?/* Convert the port number into a string. */ > @@ -1148,7 +1148,7 @@ ssh_local_cmd(const char *args) > ? ? ? ? ? ?args == NULL || !*args) > ? ? ? ? ? ? ? ?return (1); > > - ? ? ? if ((shell = getenv("SHELL")) == NULL) > + ? ? ? if ((shell = getenv("SHELL")) == NULL || *shell == '\0') > ? ? ? ? ? ? ? ?shell = _PATH_BSHELL; > > ? ? ? ?pid = fork(); > From mouring at eviladmin.org Fri Sep 18 00:30:57 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 17 Sep 2009 09:30:57 -0500 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: References: <4AAABF5E.4010207@zip.com.au> Message-ID: <43A3B7F3-DBAD-4694-8EA5-9C73DAF2A0B4@eviladmin.org> How does one get into a case where they are allowed to be logged in, but they don't have a valid executable shell? This seems like a very odd condition and one that shouldn't happen. - Ben On Sep 17, 2009, at 7:47 AM, Antonio Mignolli wrote: > Ok, but the case with a not valid shell (non executable) > is not covered. > It is also a user (or sysadm) fault, though, if SHELL is not > properly set. > > Bye. > > 2009/9/17 Damien Miller : >> On Thu, 17 Sep 2009, Antonio Mignolli wrote: >> >>> Maybe the mailing list cuts the attachments. >> >> Yes, we strip pretty much everything but text/plain to avoid spam and >> malware. >> >>> patch.openssh-5.2p1.SHELLfix: >>> >>> 8<----------------------------------------------------------------- >>> Common subdirectories: openssh-5.2p1/contrib and openssh-5.2p1.new/ >>> contrib >>> diff -NupwB openssh-5.2p1/misc.c openssh-5.2p1.new/misc.c >>> --- openssh-5.2p1/misc.c 2009-02-21 22:47:02.000000000 +0100 >>> +++ openssh-5.2p1.new/misc.c 2009-09-16 02:21:11.000000000 +0200 >>> @@ -849,3 +849,29 @@ ms_to_timeval(struct timeval *tv, int ms >>> tv->tv_usec = (ms % 1000) * 1000; >>> } >>> >>> +/* >>> + * Get shell from env or use default '/bin/sh' >>> + */ >>> +char * >>> +get_shell_from_env() >> >> ... >> >> I think that this is quite overcomplicated. This is probably >> sufficient. >> >> Index: sftp.c >> =================================================================== >> RCS file: /cvs/src/usr.bin/ssh/sftp.c,v >> retrieving revision 1.111 >> diff -u -p -r1.111 sftp.c >> --- sftp.c 18 Aug 2009 18:36:21 -0000 1.111 >> +++ sftp.c 17 Sep 2009 12:26:04 -0000 >> @@ -236,7 +236,7 @@ local_do_shell(const char *args) >> if (!*args) >> args = NULL; >> >> - if ((shell = getenv("SHELL")) == NULL) >> + if ((shell = getenv("SHELL")) == NULL || *shell == '\0') >> shell = _PATH_BSHELL; >> >> if ((pid = fork()) == -1) >> Index: sshconnect.c >> =================================================================== >> RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v >> retrieving revision 1.214 >> diff -u -p -r1.214 sshconnect.c >> --- sshconnect.c 28 May 2009 16:50:16 -0000 1.214 >> +++ sshconnect.c 17 Sep 2009 12:26:05 -0000 >> @@ -76,7 +76,7 @@ ssh_proxy_connect(const char *host, u_sh >> pid_t pid; >> char *shell, strport[NI_MAXSERV]; >> >> - if ((shell = getenv("SHELL")) == NULL) >> + if ((shell = getenv("SHELL")) == NULL || *shell == '\0') >> shell = _PATH_BSHELL; >> >> /* Convert the port number into a string. */ >> @@ -1148,7 +1148,7 @@ ssh_local_cmd(const char *args) >> args == NULL || !*args) >> return (1); >> >> - if ((shell = getenv("SHELL")) == NULL) >> + if ((shell = getenv("SHELL")) == NULL || *shell == '\0') >> shell = _PATH_BSHELL; >> >> pid = fork(); >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From antonio.mignolli at yahoo.it Fri Sep 18 01:02:11 2009 From: antonio.mignolli at yahoo.it (Antonio Mignolli) Date: Thu, 17 Sep 2009 17:02:11 +0200 Subject: ProxyCommand not working if $SHELL not defined In-Reply-To: <43A3B7F3-DBAD-4694-8EA5-9C73DAF2A0B4@eviladmin.org> References: <43A3B7F3-DBAD-4694-8EA5-9C73DAF2A0B4@eviladmin.org> Message-ID: Indeed, the only case is when someone manually set SHELL to an invalid value after login, but I agree with you, it should not happen. Maybe a debug message can be added, otherwise is difficult to undestand where the error is. Suppose: (I'm using proxyconnect) # export SHELL=/tmp # ssh host /tmp: Permission denied It is quite good, but maybe it would be better if a debug message shows what's happening. I noticed execv or execl is without errors control. The "Permission denied" above is given by execv. The reason because the check "not executable" was added is because a similar check is already present in auth.c for obvious login purposes in sshd. In practice, the suggested check is the same as in auth.c. 2009/9/17 Ben Lindstrom : > > How does one get into a case where they are allowed to be logged in, but > they don't have a valid executable shell? ?This seems like a very odd > condition and one that shouldn't happen. > > - Ben > > On Sep 17, 2009, at 7:47 AM, Antonio Mignolli wrote: > >> Ok, but the case with a not valid shell (non executable) >> is not covered. >> It is also a user (or sysadm) fault, though, if SHELL is not >> properly set. >> >> Bye. >> >> 2009/9/17 Damien Miller : >>> >>> On Thu, 17 Sep 2009, Antonio Mignolli wrote: >>> >>>> Maybe the mailing list cuts the attachments. >>> >>> Yes, we strip pretty much everything but text/plain to avoid spam and >>> malware. >>> >>>> patch.openssh-5.2p1.SHELLfix: >>>> >>>> 8<----------------------------------------------------------------- >>>> Common subdirectories: openssh-5.2p1/contrib and >>>> openssh-5.2p1.new/contrib >>>> diff -NupwB openssh-5.2p1/misc.c openssh-5.2p1.new/misc.c >>>> --- openssh-5.2p1/misc.c ? ? ?2009-02-21 22:47:02.000000000 +0100 >>>> +++ openssh-5.2p1.new/misc.c ?2009-09-16 02:21:11.000000000 +0200 >>>> @@ -849,3 +849,29 @@ ms_to_timeval(struct timeval *tv, int ms >>>> ? ? ?tv->tv_usec = (ms % 1000) * 1000; >>>> ?} >>>> >>>> +/* >>>> + * Get shell from env or use default '/bin/sh' >>>> + */ >>>> +char * >>>> +get_shell_from_env() >>> >>> ... >>> >>> I think that this is quite overcomplicated. This is probably sufficient. >>> >>> Index: sftp.c >>> =================================================================== >>> RCS file: /cvs/src/usr.bin/ssh/sftp.c,v >>> retrieving revision 1.111 >>> diff -u -p -r1.111 sftp.c >>> --- sftp.c ? ? ?18 Aug 2009 18:36:21 -0000 ? ? ?1.111 >>> +++ sftp.c ? ? ?17 Sep 2009 12:26:04 -0000 >>> @@ -236,7 +236,7 @@ local_do_shell(const char *args) >>> ? ? ? if (!*args) >>> ? ? ? ? ? ? ? args = NULL; >>> >>> - ? ? ? if ((shell = getenv("SHELL")) == NULL) >>> + ? ? ? if ((shell = getenv("SHELL")) == NULL || *shell == '\0') >>> ? ? ? ? ? ? ? shell = _PATH_BSHELL; >>> >>> ? ? ? if ((pid = fork()) == -1) >>> Index: sshconnect.c >>> =================================================================== >>> RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v >>> retrieving revision 1.214 >>> diff -u -p -r1.214 sshconnect.c >>> --- sshconnect.c ? ? ? ?28 May 2009 16:50:16 -0000 ? ? ?1.214 >>> +++ sshconnect.c ? ? ? ?17 Sep 2009 12:26:05 -0000 >>> @@ -76,7 +76,7 @@ ssh_proxy_connect(const char *host, u_sh >>> ? ? ? pid_t pid; >>> ? ? ? char *shell, strport[NI_MAXSERV]; >>> >>> - ? ? ? if ((shell = getenv("SHELL")) == NULL) >>> + ? ? ? if ((shell = getenv("SHELL")) == NULL || *shell == '\0') >>> ? ? ? ? ? ? ? shell = _PATH_BSHELL; >>> >>> ? ? ? /* Convert the port number into a string. */ >>> @@ -1148,7 +1148,7 @@ ssh_local_cmd(const char *args) >>> ? ? ? ? ? args == NULL || !*args) >>> ? ? ? ? ? ? ? return (1); >>> >>> - ? ? ? if ((shell = getenv("SHELL")) == NULL) >>> + ? ? ? if ((shell = getenv("SHELL")) == NULL || *shell == '\0') >>> ? ? ? ? ? ? ? shell = _PATH_BSHELL; >>> >>> ? ? ? pid = fork(); >>> >> _______________________________________________ >> 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 petfire85 at yahoo.fr Fri Sep 18 02:46:20 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Thu, 17 Sep 2009 18:46:20 +0200 Subject: Question about Server Authentication In-Reply-To: <324763.44539.qm@web24710.mail.ird.yahoo.com> References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: no ideas about my problem ? I don't known where i can found the answer so i need your help On Tue, Sep 8, 2009 at 12:08 AM, Steeve BARBEAU wrote: > > Hi guys, > > I'm working on a project which concern SSH and there is something i don't > understand about server authentication. So I explain my problem: > > - When you authorize only RSA keys in the sshd_config on the server, you > need to have the RSA public key of this server in the known_hosts file of > the client. This is absolutely normal. > > - When you authorize only DSA keys in the sshd_config on the server, you > need to have the DSA public key of this server in the known_hosts file of > the client. This is also absolutely normal. > > - But when you authorize both RSA and DSA keys, you are obliged to have the > RSA public key in the known_hosts file, without it fails. If there is only > DSA in the known_hosts file it fails, and this is that I don't understand. > Why the server authentication doesn't work with the DSA key when both DSA > and RSA are authorize. (Of course if both are present in the known_host > file, it works). So if somebody can help me about this, it will be nice ;) > I've read lot of documentation, a little the 4 RFC but I haven't found the > answer to my question. > > Steeve > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From bitpoet at linux-config.de Fri Sep 18 16:02:10 2009 From: bitpoet at linux-config.de (Christian Winter) Date: Fri, 18 Sep 2009 08:02:10 +0200 Subject: Selective and efficient logging of auth/connection information Message-ID: <4AB32262.9030104@linux-config.de> Hello everyone, this is my first mail to the list, please forgive me if some of my questions have been asked before. I'm currently thinking about a way to implement an efficient logging method for authentication results together with client connection info on my linux boxes. My aim is to circumvent expensive and delayed mechanisms like tail()ing syslog to get to the required info and be able to take appropriate action (like blocking a host via the firewall) as quick as possible. So I thought about implementing a simple daemon that listens on a Unix Fifo and gets fed the neccessary parts from opensshd in a concise single-line format. The reason for using a Fifo is simply speed, but I'm not hundred percent sure yet whether a local socket might be a better approach (have to play the different locking/blocking/timing scenarios through my head). Digging through the sources I stumbled over the audit modules and thought about hooking into that, but it seems that there are two downsides to that approach: - It looks as if audit doesn't really have access to the client connection information at the time it can log connection info - I don't see a way to add configuration parameters for audit modules to sshd_config without patching the main source (readconf/serverconf) But maybe the things I want are already there and I'm just overlooking them, if I do so I'd be grateful for any pointers in the right direction. If it's not there, I'd be willing to invest some time to add the neccessary functionality and would welcome all thoughts about the correct approach. Best Greetings -Chris From peter at stuge.se Fri Sep 18 22:22:32 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 18 Sep 2009 14:22:32 +0200 Subject: Selective and efficient logging of auth/connection information In-Reply-To: <4AB32262.9030104@linux-config.de> References: <4AB32262.9030104@linux-config.de> Message-ID: <20090918122232.23517.qmail@stuge.se> Christian Winter wrote: > aim is to circumvent expensive and delayed mechanisms like > tail()ing syslog to get to the required info > and be able to take appropriate action (like blocking > a host via the firewall) as quick as possible. > > So I thought about implementing a simple daemon that listens on a > Unix Fifo and gets fed The above is exactly what syslog does. There are many different syslogds out there, I particularly like syslog-ng because it's easy to create filters, and it can log selectively to pipes. This makes it very easy to accomplish what you want. > the neccessary parts from opensshd in a concise single-line format. So this would be the real addition - that sshd contains policy on what the system should do. This has been brought up several times, and always rejected for good reason; It's not the job of sshd to implement e.g. a firewall policy. //Peter From bitpoet at linux-config.de Sat Sep 19 00:04:38 2009 From: bitpoet at linux-config.de (Christian Winter) Date: Fri, 18 Sep 2009 16:04:38 +0200 Subject: Selective and efficient logging of auth/connection information In-Reply-To: <20090918122232.23517.qmail@stuge.se> References: <4AB32262.9030104@linux-config.de> <20090918122232.23517.qmail@stuge.se> Message-ID: <4AB39376.8050206@linux-config.de> Peter Stuge wrote: > Christian Winter wrote: > >> aim is to circumvent expensive and delayed mechanisms like >> tail()ing syslog to get to the required info >> >> and be able to take appropriate action (like blocking >> a host via the firewall) as quick as possible. >> >> So I thought about implementing a simple daemon that listens on a >> Unix Fifo and gets fed >> > > The above is exactly what syslog does. There are many different > syslogds out there, I particularly like syslog-ng because it's easy > to create filters, and it can log selectively to pipes. This makes it > very easy to accomplish what you want. > I'm aware that syslog is capable of that, but I'm not very fond of the thought of feeding all information unassorted to a monolithic dinosaur only to pick them apart afterwards. I've done filtering and parsing in syslog or written my optimized alternatives to that, but in the long run, disassembling what shouldn't be mixed together in the first place turned out to be PITA, and nothing more. I don't want to have to make up my mind each time anew with each minor update and check whether some odd change has been introduced into the log format. And the whole mix-and-filter setup brings with itself performance penalties which, in my personal opinion, could and should be reduced by a huge number. >> the neccessary parts from opensshd in a concise single-line format. >> > > So this would be the real addition - that sshd contains policy on > what the system should do. > Forgive me if I sound a bit harsh, but you're seriously misinterpreting what is clearly written. sshd should neither contain anything policy- like, nor should it even be aware that there might be something like that. All I want is a performant, clean interface where I can fetch well-formated and -defined status changes. > This has been brought up several times, and always rejected for good > reason; It's not the job of sshd to implement e.g. a firewall policy. > Though it should be the job of sshd to make its information available selectively, concisely and in a performance optimized and secure way. In a perfect world, I'd be able to tell sshd I want to be notified of successful logins, failed logins and perhaps other things like failed connection attempts. In that perfect world, I'd have all the crucial information which define such an event available, like client and server ip, the attempted user name and a timestamp. In that perfect world, even a bot net attacking my server on all open ports with invalid data and causing syslog to almost freak wouldn't immediately cause things to go haywire, because my listening daemon would still get the information for every connection in time and react accordingly. In the perfect world, even syslog running out of disk space wouldn't kill me, because I'd fetch all the neccessary information in-memory. In the imperfect world I'm now in, I have syslog as a single point of failure and a constantly changing set of patterns that I have to monitor to become aware of attacks, sometimes with quite a delay too. The only place to change that seems to be in sshd, so for me the question is how, not if. Best Greetings -Chris From peter at stuge.se Sat Sep 19 00:57:05 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 18 Sep 2009 16:57:05 +0200 Subject: Selective and efficient logging of auth/connection information In-Reply-To: <4AB39376.8050206@linux-config.de> References: <4AB32262.9030104@linux-config.de> <20090918122232.23517.qmail@stuge.se> <4AB39376.8050206@linux-config.de> Message-ID: <20090918145705.22944.qmail@stuge.se> Christian Winter wrote: > each time anew with each minor update and check whether some odd > change has been introduced into the log format. I think you'll find that odd changes to the log messages are rare in OpenSSH. And yes, each time you update your software, you really do need to check if all your assumptions still hold true. There's no shortcut.. > And the whole mix-and-filter setup brings with itself performance > penalties which, in my personal opinion, could and should be > reduced by a huge number. It seems to me that mixing can be avoided to a high degree by using syslog facility and level wisely. >>> the neccessary parts from opensshd in a concise single-line format. >> >> So this would be the real addition - that sshd contains policy on >> what the system should do. > > sshd should neither contain anything policylike, nor should it even > be aware that there might be something like that. All I want is a > performant, clean interface where I can fetch well-formated and > -defined status changes. What defines a status change? This is controlled by a policy. In order for the setup to be as efficient as possible, this policy must be within sshd. sshd doesn't want that. > Though it should be the job of sshd to make its information available > selectively, concisely and in a performance optimized and secure way. I disagree on the selectively part. > In a perfect world, I'd be able to tell sshd I want to be notified > of successful logins, failed logins and perhaps other things like > failed connection attempts. So you want to describe a policy for sshd. sshd is not interested, it has enough to do already and the policy can be implemented just as well if not better outside of sshd. > In the perfect world, even syslog running out of disk space > wouldn't kill me, because I'd fetch all the neccessary information > in-memory. Why bother with logging to disk if you don't want to store the data? This is why I made sure to mention that syslog-ng can use pipes. Really, I think you can get much of what you request by using your syslogd in a new way. Maybe you NEED to store all data? Then you better make sure to always have enough disk space.. > In the imperfect world I'm now in, I have syslog as a single point > of failure (as opposed to your new management software being the single point of failure) > and a constantly changing set of patterns that I have to monitor (do sshd log messages really change that often?) > The only place to change that seems to be in sshd, so for me the > question is how, not if. You are requesting a new management interface without spec and without a suggested implementation. I think that will be ignored. Now, the audit functionality you looked into is probably meant for the very same purpose, so it seems like the best way forward might be to find out how to make that work for you? I believe (small) improvements there (with high impact) would be much better received. //Peter From bitpoet at linux-config.de Sat Sep 19 02:47:00 2009 From: bitpoet at linux-config.de (Christian Winter) Date: Fri, 18 Sep 2009 18:47:00 +0200 Subject: Selective and efficient logging of auth/connection information In-Reply-To: <20090918145705.22944.qmail@stuge.se> References: <4AB32262.9030104@linux-config.de> <20090918122232.23517.qmail@stuge.se> <4AB39376.8050206@linux-config.de> <20090918145705.22944.qmail@stuge.se> Message-ID: <4AB3B984.7050507@linux-config.de> Peter Stuge wrote: > Christian Winter wrote: > >> each time anew with each minor update and check whether some odd >> change has been introduced into the log format. >> > > I think you'll find that odd changes to the log messages are rare in > OpenSSH. > > And yes, each time you update your software, you really do need to > check if all your assumptions still hold true. There's no shortcut.. > That's why I'm trying for concise and fixed format (as in 'changes there need to be announced in the changelog') instead of a format meant to be interpreted by human eyes and that has no official spec. >> And the whole mix-and-filter setup brings with itself performance >> penalties which, in my personal opinion, could and should be >> reduced by a huge number. >> > > It seems to me that mixing can be avoided to a high degree by using > syslog facility and level wisely. > The moment syslog has to look into the message the penalty's already there. I agree that it can be lightened up to a certain point, but with configuration efforts that are again based on assumptions about the logging behaviour. >>>> the neccessary parts from opensshd in a concise single-line format. >>>> >>> So this would be the real addition - that sshd contains policy on >>> what the system should do. >>> >> sshd should neither contain anything policylike, nor should it even >> be aware that there might be something like that. All I want is a >> performant, clean interface where I can fetch well-formated and >> -defined status changes. >> > > What defines a status change? This is controlled by a policy. In > order for the setup to be as efficient as possible, this policy > must be within sshd. sshd doesn't want that. > sshd knows that anyway. Connected, successfully authenticated, authentication failed, disconnected, these are stati inherent to the ssh protocol. I'm not talking about making up new ones. >> Though it should be the job of sshd to make its information available >> selectively, concisely and in a performance optimized and secure way. >> > > I disagree on the selectively part. > I'd too if the places to do so weren't already there and the program flow had to be changed to isolate them. >> In a perfect world, I'd be able to tell sshd I want to be notified >> of successful logins, failed logins and perhaps other things like >> failed connection attempts. >> > > So you want to describe a policy for sshd. sshd is not interested, it > has enough to do already and the policy can be implemented just as > well if not better outside of sshd. > It seems to be the 'as well if not better' part we're really disagreeing. For me, there are a number of questions that decide that part, namely - would I gain resources by implenting the functionality directly in sshd? - would it impact maintainability of the sshd codebase? - would it critically degrade sshd's performance? - would it open up security holes in sshd? >> In the perfect world, even syslog running out of disk space >> wouldn't kill me, because I'd fetch all the neccessary information >> in-memory. >> > > Why bother with logging to disk if you don't want to store the data? > This is why I made sure to mention that syslog-ng can use pipes. > > Really, I think you can get much of what you request by using your > syslogd in a new way. > > Maybe you NEED to store all data? Then you better make sure to always > have enough disk space.. > If things were just that easy :) >> In the imperfect world I'm now in, I have syslog as a single point >> of failure >> > > (as opposed to your new management software being the single point of > failure) > Nope, I'm not talking about a central be-all-and-log-all management software which is heavily influenced by lots of different programs running on the machine, just a single program that accomplishes a single task. >> and a constantly changing set of patterns that I have to monitor >> > > (do sshd log messages really change that often?) > Is there any reliable, change-tracked description of the log message format? >> The only place to change that seems to be in sshd, so for me the >> question is how, not if. >> > > You are requesting a new management interface without spec and > without a suggested implementation. I think that will be ignored. > If that was so, it would not shine a bright light on ssh development. Especially as I'm not requesting, but rather asking about general thoughts and the best way to go if I wanted to implement such a thing. > Now, the audit functionality you looked into is probably meant for > the very same purpose, so it seems like the best way forward might be > to find out how to make that work for you? I believe (small) > improvements there (with high impact) would be much better received. > I can do that, of course, but politeness and common sense made me ask generic questions before jumping onto a moving train :) Best Greetings Chris From bert at bertenselena.net Mon Sep 21 03:15:06 2009 From: bert at bertenselena.net (Bert Haverkamp) Date: Sun, 20 Sep 2009 19:15:06 +0200 Subject: Hardlink patches for sftp Message-ID: <1e68a10b0909201015kfe5a8bexe9ffd84791216ce1@mail.gmail.com> Dear all, I am looking for the status on the hardlink patches that were published on this list last february by Miklos Szeredi? I'd really like to have hardlink support in sftp. This would in turn enable hardlinks in sshfs and make incremental rsync backups to remote filesystems possible. can someone tell me if these patches will be incorporated in openssh? The patches can be found under https://bugzilla.mindrot.org/show_bug.cgi?id=1555 Regards, Bert Haverkamp -- ----------------------------------------------------- 38 is NOT a random number!!!! From alex at alex.org.uk Mon Sep 21 04:38:51 2009 From: alex at alex.org.uk (Alex Bligh) Date: Sun, 20 Sep 2009 19:38:51 +0100 Subject: openssh server and tun devices Message-ID: <34B4269C6B98D3264C0591A9@Ximines.local> If an ssh server receives a successful inbound ssh connection with 'ssh -w' without a tunnel number specified (i.e. in 'any' mode), it allocates the next tunnel device available on the server. The next thing the server needs to do is to set up the tunnel device. How does the server know which tunnel device was set up by the current connection? I'd really like something race-condition free here. Similarly (but less pressingly), if a client executes a ssh -w and uses the next available local tunnel device, is there some way of reading the tunnel device the child ssh process allocated? -- Alex Bligh From petfire85 at yahoo.fr Mon Sep 21 06:26:36 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Sun, 20 Sep 2009 22:26:36 +0200 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: Is there some OpenSSH developers or SSH experts who know what is the problem ? On Thu, Sep 17, 2009 at 11:31 PM, Douglas E. Engert wrote: > If you reword you question as to how to have RSA *or* DSA you might be a > response. > You may have found a bug, as I would not expect it to require RSA *and* > DSA. Is it a bug like says Douglas ? Have you ever had this problem ? From john.marshall at riverwillow.com.au Mon Sep 21 17:05:15 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Mon, 21 Sep 2009 17:05:15 +1000 Subject: How to generate additional debug messages for sshd gssapi failures? Message-ID: <20090921070514.GD1001@rwpc12.mby.riverwillow.net.au> I'm trying to troubleshoot gssapi_with_mic authentication with OpenSSH 5.2p1 on FreeBSD 8.0. If I run sshd with maximum debug "sshd -ddd" the most detail I get is: GSSAPI MIC check failed That comes from line 282 in auth2-gss.c 279 if (!GSS_ERROR(PRIVSEP(ssh_gssapi_checkmic(gssctxt, &gssbuf, &mic)))) 280 authenticated = PRIVSEP(ssh_gssapi_userok(authctxt->user)); 281 else 282 logit("GSSAPI MIC check failed"); 283 I think that's as much help as I can get from sshd. I'd like to add some printf's to that else clause so that I can see the reason codes returned by the gssapi routines. I'm not a programmer. Can anybody give me any hints as to what to put here? Is there any chance of enhancing the error reporting at that point in a future release so that debug logging produces useful output? Thank you for your help. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From vinschen at redhat.com Mon Sep 21 19:12:55 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 21 Sep 2009 11:12:55 +0200 Subject: Read buffer size in clientloop.c In-Reply-To: <4A973139.6060704@zip.com.au> References: <20090707105716.GN12258@calimero.vinschen.de> <20090707115337.GA22534@gate.dtucker.net> <20090710093345.GG12258@calimero.vinschen.de> <20090714093955.GE27613@calimero.vinschen.de> <4A973139.6060704@zip.com.au> Message-ID: <20090921091255.GA10541@calimero.vinschen.de> On Aug 28 11:22, Darren Tucker wrote: > Corinna Vinschen wrote: >> Hi Darren, >> >> On Jul 10 11:33, Corinna Vinschen wrote: >>> On Jul 7 21:53, Darren Tucker wrote: >>>> On Tue, Jul 07, 2009 at 12:57:16PM +0200, Corinna Vinschen wrote: >>>>> Would it be ok to raise the buffers in client_process_net_input() and >>>>> client_process_input() to 64K, maybe only on Cygwin? Or to make the >>>>> buffer sizes a configurable option? >>>> If there's a measureable performance gain (which it sounds like there is) >>>> then I personally have no objection to making it a compile time option. >>>> Damien? Maybe something like this? >>> I tested this patch and it works fine for Cygwin. >> >> Will this patch be checked in at one point? > > Yes, it was just committed and will be in 5.3p1. Thanks. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From cvela at csc.com Thu Sep 17 15:21:12 2009 From: cvela at csc.com (Chandra Prakash Vela) Date: Thu, 17 Sep 2009 10:51:12 +0530 Subject: Openssh 4.6p1 Error Message-ID: Hello Sir, Could provide the solution for the below error ? chan_read_failed for istate 3 Thanks and regards Chandra Prakash Vela Global Operations - Production Engineering Services Computer Sciences Corporation India Private Limited C-24 ,Sector 58,Noida -201301 USA: 1-302-781-1010 Extn. 1957 UK: +44 (0) 870 850 3512 Extn. 1957 Australia: 1800 137 784 Extn. 1957 India: +91-120-2582323 Extn. 1957 E-Mail: cvela at csc.com CSC ? This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose ? Computer Sciences Corporation India Pvt Ltd ? 7th,Floor, Block 1B, DLF IT Park, Sivaji Garden, Moonlight Stop, Nandambakkam Post, Ramapuram, Chennai-600 089. From alex at alex.org.uk Mon Sep 21 22:21:13 2009 From: alex at alex.org.uk (Alex Bligh) Date: Mon, 21 Sep 2009 13:21:13 +0100 Subject: [patch] RFC: put server tunnel name in environment Message-ID: <39CD35849A536C8FAEB1D71D@Ximines.local> If an ssh server receives a tun/tap tunnel request and sets up the tunnel concerned, as far as I can see there is currently no way for the server to configure the tunnel in a manner dependent upon (e.g) the key used to set up the ssh session. Whilst an id based on the key can be passed to the ssh child process, where the tunnel is dynamically allocated, its tunnel name is lost. This patch remedies this. It is very simple. All it does is put the tunnel name in the environment if one is set up. IE ssh to a server with "-w any" and the executed command will have (e.g.) SSH_TUNNEL=tun1 if tun1 was allocated. On *BSD, this will look more like '/dev/tun1'. I have tested this patch on Linux. It should work equally well on OpenBSD and FreeBSD (it's really very simple) but someone should test this. Patch is against 5.1p1. [this is my first patch against openssh so please go easy] -- Alex Bligh From peter at stuge.se Tue Sep 22 03:16:22 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 Sep 2009 19:16:22 +0200 Subject: Openssh 4.6p1 Error In-Reply-To: References: Message-ID: <20090921171622.18567.qmail@stuge.se> Hello, Chandra Prakash Vela wrote: > Could provide the solution for the below error ? > > chan_read_failed for istate 3 Can you reproduce this using the very latest version, 5.2p1 ? //Peter From alex at alex.org.uk Tue Sep 22 03:54:47 2009 From: alex at alex.org.uk (Alex Bligh) Date: Mon, 21 Sep 2009 18:54:47 +0100 Subject: [patch] RFC: put server tunnel name in environment In-Reply-To: <39CD35849A536C8FAEB1D71D@Ximines.local> References: <39CD35849A536C8FAEB1D71D@Ximines.local> Message-ID: <485F23059C446B1877047810@Ximines.local> --On 21 September 2009 13:21:13 +0100 Alex Bligh wrote: > If an ssh server receives a tun/tap tunnel request and sets up the tunnel > concerned, as far as I can see there is currently no way for the server > to configure the tunnel in a manner dependent upon (e.g) the key used to > set up the ssh session. Whilst an id based on the key can be passed to > the ssh child process, where the tunnel is dynamically allocated, its > tunnel name is lost. > > This patch remedies this. It is very simple. All it does is put the > tunnel name in the environment if one is set up. IE ssh to a server > with "-w any" and the executed command will have (e.g.) > SSH_TUNNEL=tun1 > if tun1 was allocated. On *BSD, this will look more like '/dev/tun1'. > > I have tested this patch on Linux. It should work equally well on OpenBSD > and FreeBSD (it's really very simple) but someone should test this. > > Patch is against 5.1p1. > > [this is my first patch against openssh so please go easy] Trying again, with the patch attached as text/plain (apologies for the extension) -- Alex Bligh -------------- next part -------------- diff -ur --exclude out ../openssh-5.1p1/misc.c ./misc.c --- ../openssh-5.1p1/misc.c 2008-06-13 05:48:59.000000000 +0100 +++ ./misc.c 2009-09-21 13:07:44.000000000 +0100 @@ -56,6 +56,8 @@ #include "log.h" #include "ssh.h" +static char *misc_tunname = 0; + /* remove newline at end of string */ char * chop(char *s) @@ -695,6 +697,9 @@ if (ioctl(sock, SIOCSIFFLAGS, &ifr) == -1) goto failed; + /* Preserve the name with the field the ioctl populated when tun=SSH_TUNID_ANY */ + tun_setname(ifr.ifr_name); + close(sock); return (fd); @@ -712,6 +717,28 @@ #endif } +/* + * Return the recorded name of the tunnel device + */ +char * +tun_getname() +{ + return (misc_tunname); +} + +/* + * Set the name of the recorded tunnel device, storing a copy (freeing + * any old version + */ +void +tun_setname(const char *tunname) +{ + if (misc_tunname) + xfree (misc_tunname); + + misc_tunname = xstrdup(tunname); +} + void sanitise_stdfd(void) { diff -ur --exclude out ../openssh-5.1p1/misc.h ./misc.h --- ../openssh-5.1p1/misc.h 2008-06-12 21:42:45.000000000 +0100 +++ ./misc.h 2009-09-21 12:22:56.000000000 +0100 @@ -52,6 +52,8 @@ void freeargs(arglist *); int tun_open(int, int); +char *tun_getname(); +void tun_setname(const char *); /* Common definitions for ssh tunnel device forwarding */ #define SSH_TUNMODE_NO 0x00 diff -ur --exclude out ../openssh-5.1p1/openbsd-compat/port-tun.c ./openbsd-compat/port-tun.c --- ../openssh-5.1p1/openbsd-compat/port-tun.c 2008-05-19 06:28:36.000000000 +0100 +++ ./openbsd-compat/port-tun.c 2009-09-21 12:59:09.000000000 +0100 @@ -93,6 +93,9 @@ goto failed; } + /* Preserve the name with the field the ioctl populated when tun=SSH_TUNID_ANY */ + tun_setname(ifr.ifr_name); + if (tun == SSH_TUNID_ANY) debug("%s: tunnel mode %d fd %d", __func__, mode, fd); else @@ -177,6 +180,9 @@ if (ioctl(sock, SIOCSIFFLAGS, &ifr) == -1) goto failed; + /* Preserve the name with the field the ioctl populated when tun=SSH_TUNID_ANY */ + tun_setname(ifr.ifr_name); + close(sock); return (fd); diff -ur --exclude out ../openssh-5.1p1/session.c ./session.c --- ../openssh-5.1p1/session.c 2008-06-16 14:29:18.000000000 +0100 +++ ./session.c 2009-09-21 12:45:19.000000000 +0100 @@ -1110,6 +1110,7 @@ u_int i, envsize; char **env, *laddr; struct passwd *pw = s->pw; + char * tunname; #ifndef HAVE_LOGIN_CAP char *path = NULL; #endif @@ -1216,6 +1217,10 @@ xfree(laddr); child_set_env(&env, &envsize, "SSH_CONNECTION", buf); + tunname = tun_getname(); + if (tunname) + child_set_env(&env, &envsize, "SSH_TUNNEL", tunname); + if (s->ttyfd != -1) child_set_env(&env, &envsize, "SSH_TTY", s->tty); if (s->term) From peter at stuge.se Tue Sep 22 03:58:56 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 Sep 2009 19:58:56 +0200 Subject: [patch] RFC: put server tunnel name in environment In-Reply-To: <485F23059C446B1877047810@Ximines.local> References: <39CD35849A536C8FAEB1D71D@Ximines.local> <485F23059C446B1877047810@Ximines.local> Message-ID: <20090921175856.28008.qmail@stuge.se> Alex Bligh wrote: > Trying again, with the patch attached as text/plain The patch seems racy. What if a second tunnel request comes in between the set_tunnel() and get_tunnel() for the first request? //Peter From rmartin at harvestproductionsinc.com Tue Sep 22 02:32:21 2009 From: rmartin at harvestproductionsinc.com (Reuben Martin) Date: Mon, 21 Sep 2009 11:32:21 -0500 Subject: Cannot rename across bind mounts Message-ID: <4AB764450200005A000021F5@harvestproductionsinc.com> Hello, I am having problems with renaming a file if the source or destination path is located on a bind mount. For instance if in the root directory, I have the directories "Files1" and "Files2" where one or both of the directories are created as the result of a bind mount, then when trying to do rename /Files1/a /Files2/b it produces an error saying it "Couldn't rename file". The ownership and permissions of files and directories have no bearing on this problem. Renaming the files without going outside of the bind mount doesn't cause problems, only when crossing the bind mount does the error occur. Is this a bug, or is this an intended behavior for some security reason? Thanks, -Reuben http://www.harvestproductionsinc.com From peter at stuge.se Tue Sep 22 04:28:29 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 Sep 2009 20:28:29 +0200 Subject: Cannot rename across bind mounts In-Reply-To: <4AB764450200005A000021F5@harvestproductionsinc.com> References: <4AB764450200005A000021F5@harvestproductionsinc.com> Message-ID: <20090921182829.1763.qmail@stuge.se> Reuben Martin wrote: > I am having problems with renaming a file if the source or > destination path is located on a bind mount. Are the two directories bound to different places within the same filesystem? //Peter From alex at alex.org.uk Tue Sep 22 05:44:56 2009 From: alex at alex.org.uk (Alex Bligh) Date: Mon, 21 Sep 2009 20:44:56 +0100 Subject: [patch] RFC: put server tunnel name in environment In-Reply-To: <20090921175856.28008.qmail@stuge.se> References: <39CD35849A536C8FAEB1D71D@Ximines.local> <485F23059C446B1877047810@Ximines.local> <20090921175856.28008.qmail@stuge.se> Message-ID: --On 21 September 2009 19:58:56 +0200 Peter Stuge wrote: > Alex Bligh wrote: >> Trying again, with the patch attached as text/plain > > The patch seems racy. What if a second tunnel request comes in > between the set_tunnel() and get_tunnel() for the first request? Is it possible to have more than one tunnel request per forked child? I may have misunderstood how the code works (in which case my apologies) but I thought what happened was that the ssh server forks on receiving a connection, and the tun_open is done by the child with the uid specified (in this case it has to be root for tun_open to work, but that's how I verified what was calling tun_open). My understanding was that each ssh connection could only receive one -w tun/tap request. The static char * is in effect local to the child (& thus connection) concerned. Have I missed something here? -- Alex Bligh From rmartin at harvestproductionsinc.com Tue Sep 22 06:43:20 2009 From: rmartin at harvestproductionsinc.com (Reuben Martin) Date: Mon, 21 Sep 2009 15:43:20 -0500 Subject: Cannot rename across bind mounts Message-ID: <4AB79F190200005A00002202@harvestproductionsinc.com> >Reuben Martin wrote: >> I am having problems with renaming a file if the source or >> destination path is located on a bind mount. > >Are the two directories bound to different places within the same >filesystem? > > >//Peter Yes. BTW: I'm currently using 5.2p1 from Gentoo portage, patched with sftpfilecontrol-v1.3 -Reuben http://www.harvestproductionsinc.com From ralf.hack at gmail.com Tue Sep 22 08:18:30 2009 From: ralf.hack at gmail.com (Ralf Hack) Date: Mon, 21 Sep 2009 23:18:30 +0100 Subject: openssh server and tun devices In-Reply-To: <34B4269C6B98D3264C0591A9@Ximines.local> References: <34B4269C6B98D3264C0591A9@Ximines.local> Message-ID: <2e9b14770909211518h6bfaeca5mf8152517e025773f@mail.gmail.com> Hi Alex, interesting question... looking at the code, the connection is handled within the server as the fd handle to the tunnel device, opened using sys_tun_open() then handed to the channel_new() function. The allocation of the tunnel with 'any' appear to be handled in sys_tun_open() by leaving the ifr.ifr_name empty. From there on it is kernel specific. The linux kernel module will eventually assign the interface id protected by a lock in drivers/net/tun.c (tun_chr_ioct->...->dev_alloc_name). My guess is that *BSD using open() will work similar to this. So the tunnel device should be available in ifr.ifr_name ( i.e. tun0, tun0, etc. ) in sys_tun_open(). At this point the struct is put on the stack and destroyed of course when leaving sys_tun_open() but not before it is printed for debugging purposes. The server does not appear to make use of this information any further than that and relies on open(/dev/net/tun) to be race condition free and to create a unique fd handle. Have you any reason to believe that this is not the case ? As to the latter question - for the above reason the tunnel device is probably not available anywhere to query. Would be nice though to see it in when probing the server with "~#". Hope this helps. Regards Ralf. On Sun, Sep 20, 2009 at 7:38 PM, Alex Bligh wrote: > If an ssh server receives a successful inbound ssh connection with 'ssh -w' > without a tunnel number specified (i.e. in 'any' mode), it allocates the > next tunnel device available on the server. The next thing the server > needs to do is to set up the tunnel device. How does the server know > which tunnel device was set up by the current connection? I'd really > like something race-condition free here. > > Similarly (but less pressingly), if a client executes a ssh -w and uses > the next available local tunnel device, is there some way of reading > the tunnel device the child ssh process allocated? > > -- > Alex Bligh > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From otubo at linux.vnet.ibm.com Tue Sep 22 14:44:54 2009 From: otubo at linux.vnet.ibm.com (Eduardo Otubo) Date: Tue, 22 Sep 2009 01:44:54 -0300 Subject: Problems using sftp on HMC IBM system Message-ID: <4AB85646.1070209@linux.vnet.ibm.com> Hello friends, I am having some problems using sftp to reach a HMC IBM system. The connection is suddenly closed and I don't why. Actually I don't know exactly how to read all these debug information. I would be very glad with any help on this topic. Here is the full debug output provided from the command execution: otubo at phoenix ~ $ sftp -vvv hscroot at skiper Connecting to skiper... OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/otubo/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to skiper [9.8.234.158] port 22. debug1: Connection established. debug3: Not a RSA1 key file /home/otubo/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/otubo/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/otubo/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH_4* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1 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-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,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 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: 145/256 debug2: bits set: 506/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/otubo/.ssh/known_hosts debug3: check_host_in_hostfile: match line 99 debug3: check_host_in_hostfile: filename /home/otubo/.ssh/known_hosts debug3: check_host_in_hostfile: match line 61 debug1: Host 'skiper' is known and matches the RSA host key. debug1: Found key in /home/otubo/.ssh/known_hosts:99 debug2: bits set: 511/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/otubo/.ssh/id_rsa (0xb960a030) debug2: key: /home/otubo/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-with-mic,gssapi,password,keyboard-interactive debug3: start over, passed a different list publickey,gssapi-with-mic,gssapi,password,keyboard-interactive debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found debug1: Unspecified GSS failure. Minor code may provide more information debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi debug1: Next authentication method: gssapi debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/otubo/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,gssapi,password,keyboard-interactive debug1: Trying private key: /home/otubo/.ssh/id_dsa debug3: no such identity: /home/otubo/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64) debug1: Authentication succeeded (keyboard-interactive). debug2: fd 4 setting O_NONBLOCK debug3: 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. debug2: callback start debug2: client_session2_setup: id 0 debug1: Sending environment. debug3: Ignored env SSH_AGENT_PID debug3: Ignored env TERM debug3: Ignored env SHELL debug3: Ignored env XDG_SESSION_COOKIE debug3: Ignored env WINDOWID debug3: Ignored env GTK_MODULES debug3: Ignored env XTERM_SHELL debug3: Ignored env USER debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env GNOME_KEYRING_SOCKET debug3: Ignored env USERNAME debug3: Ignored env PATH debug3: Ignored env DESKTOP_SESSION debug3: Ignored env GDM_XSERVER_LOCATION debug3: Ignored env PWD debug3: Ignored env EDITOR debug1: Sending env LANG = en_US.UTF-8 debug2: channel 0: request env confirm 0 debug3: Ignored env GNOME_KEYRING_PID debug3: Ignored env GDM_LANG debug3: Ignored env PS1 debug3: Ignored env GDMSESSION debug3: Ignored env XTERM_LOCALE debug3: Ignored env XTERM_VERSION debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env AWT_TOOLKIT debug3: Ignored env LOGNAME debug3: Ignored env XDG_DATA_DIRS debug3: Ignored env DBUS_SESSION_BUS_ADDRESS debug3: Ignored env ZZPATH debug3: Ignored env WINDOWPATH debug3: Ignored env DISPLAY debug3: Ignored env HISTTIMEFORMAT debug3: Ignored env XAUTHORITY debug3: Ignored env _ debug1: Sending subsystem: sftp debug2: channel 0: request subsystem confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: channel_input_confirm: type 99 id 0 debug2: subsystem request accepted on channel 0 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 6 c -1 debug1: fd 0 clearing O_NONBLOCK debug3: fd 1 is not O_NONBLOCK Transferred: sent 1808, received 1768 bytes, in 10.3 seconds Bytes per second: sent 175.7, received 171.8 debug1: Exit status 1 Connection closed []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 eotubo at linux.vnet.ibm.com From mouring at eviladmin.org Tue Sep 22 15:32:56 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 22 Sep 2009 00:32:56 -0500 Subject: Problems using sftp on HMC IBM system In-Reply-To: <4AB85646.1070209@linux.vnet.ibm.com> References: <4AB85646.1070209@linux.vnet.ibm.com> Message-ID: <1EF69051-1270-4506-BAEE-AFD4A5FF9787@eviladmin.org> A more useful thing to do is: $ ssh hscroot at skiper /bin/true ## Use where your true bin is located, on some it is /usr/bin/true If you see any output other than the "Banner" output (if you use one, which it doesn't look like it). You need to fix your shell to not output data on non-interactive shell connections. - Ben On Sep 21, 2009, at 11:44 PM, Eduardo Otubo wrote: > Hello friends, > > I am having some problems using sftp to reach a HMC IBM system. The > connection is suddenly closed and I don't why. Actually I don't know > exactly how to read all these debug information. I would be very > glad with any help on this topic. Here is the full debug output > provided from the command execution: > > otubo at phoenix ~ $ sftp -vvv hscroot at skiper > Connecting to skiper... > OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007 > debug1: Reading configuration data /home/otubo/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to skiper [9.8.234.158] port 22. > debug1: Connection established. > debug3: Not a RSA1 key file /home/otubo/.ssh/id_rsa. > debug2: key_type_from_name: unknown key type '-----BEGIN' > debug3: key_read: missing keytype > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug3: key_read: missing whitespace > debug2: key_type_from_name: unknown key type '-----END' > debug3: key_read: missing keytype > debug1: identity file /home/otubo/.ssh/id_rsa type 1 > debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 > debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 > debug1: identity file /home/otubo/.ssh/id_dsa type -1 > debug1: Remote protocol version 1.99, remote software version > OpenSSH_4.2 > debug1: match: OpenSSH_4.2 pat OpenSSH_4* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1 > 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-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,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 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: 145/256 > debug2: bits set: 506/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug3: check_host_in_hostfile: filename /home/otubo/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 99 > debug3: check_host_in_hostfile: filename /home/otubo/.ssh/known_hosts > debug3: check_host_in_hostfile: match line 61 > debug1: Host 'skiper' is known and matches the RSA host key. > debug1: Found key in /home/otubo/.ssh/known_hosts:99 > debug2: bits set: 511/1024 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /home/otubo/.ssh/id_rsa (0xb960a030) > debug2: key: /home/otubo/.ssh/id_dsa ((nil)) > debug1: Authentications that can continue: publickey,gssapi-with- > mic,gssapi,password,keyboard-interactive > debug3: start over, passed a different list publickey,gssapi-with- > mic,gssapi,password,keyboard-interactive > debug3: preferred gssapi-keyex,gssapi-with- > mic,gssapi,publickey,keyboard-interactive,password > debug3: authmethod_lookup gssapi-with-mic > debug3: remaining preferred: gssapi,publickey,keyboard- > interactive,password > debug3: authmethod_is_enabled gssapi-with-mic > debug1: Next authentication method: gssapi-with-mic > debug1: Unspecified GSS failure. Minor code may provide more > information > No credentials cache found > > debug1: Unspecified GSS failure. Minor code may provide more > information > No credentials cache found > > debug1: Unspecified GSS failure. Minor code may provide more > information > > > debug2: we did not send a packet, disable method > debug3: authmethod_lookup gssapi > debug3: remaining preferred: publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi > debug1: Next authentication method: gssapi > debug2: we did not send a packet, disable method > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering public key: /home/otubo/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: publickey,gssapi-with- > mic,gssapi,password,keyboard-interactive > debug1: Trying private key: /home/otubo/.ssh/id_dsa > debug3: no such identity: /home/otubo/.ssh/id_dsa > debug2: we did not send a packet, disable method > debug3: authmethod_lookup keyboard-interactive > debug3: remaining preferred: password > debug3: authmethod_is_enabled keyboard-interactive > debug1: Next authentication method: keyboard-interactive > debug2: userauth_kbdint > debug2: we sent a keyboard-interactive packet, wait for reply > debug2: input_userauth_info_req > debug2: input_userauth_info_req: num_prompts 1 > Password: > debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64) > debug2: input_userauth_info_req > debug2: input_userauth_info_req: num_prompts 0 > debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64) > debug1: Authentication succeeded (keyboard-interactive). > debug2: fd 4 setting O_NONBLOCK > debug3: 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. > debug2: callback start > debug2: client_session2_setup: id 0 > debug1: Sending environment. > debug3: Ignored env SSH_AGENT_PID > debug3: Ignored env TERM > debug3: Ignored env SHELL > debug3: Ignored env XDG_SESSION_COOKIE > debug3: Ignored env WINDOWID > debug3: Ignored env GTK_MODULES > debug3: Ignored env XTERM_SHELL > debug3: Ignored env USER > debug3: Ignored env SSH_AUTH_SOCK > debug3: Ignored env GNOME_KEYRING_SOCKET > debug3: Ignored env USERNAME > debug3: Ignored env PATH > debug3: Ignored env DESKTOP_SESSION > debug3: Ignored env GDM_XSERVER_LOCATION > debug3: Ignored env PWD > debug3: Ignored env EDITOR > debug1: Sending env LANG = en_US.UTF-8 > debug2: channel 0: request env confirm 0 > debug3: Ignored env GNOME_KEYRING_PID > debug3: Ignored env GDM_LANG > debug3: Ignored env PS1 > debug3: Ignored env GDMSESSION > debug3: Ignored env XTERM_LOCALE > debug3: Ignored env XTERM_VERSION > debug3: Ignored env SHLVL > debug3: Ignored env HOME > debug3: Ignored env AWT_TOOLKIT > debug3: Ignored env LOGNAME > debug3: Ignored env XDG_DATA_DIRS > debug3: Ignored env DBUS_SESSION_BUS_ADDRESS > debug3: Ignored env ZZPATH > debug3: Ignored env WINDOWPATH > debug3: Ignored env DISPLAY > debug3: Ignored env HISTTIMEFORMAT > debug3: Ignored env XAUTHORITY > debug3: Ignored env _ > debug1: Sending subsystem: sftp > debug2: channel 0: request subsystem confirm 1 > debug2: fd 3 setting TCP_NODELAY > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel 0: rcvd adjust 131072 > debug2: channel_input_confirm: type 99 id 0 > debug2: subsystem request accepted on channel 0 > debug2: channel 0: rcvd eof > debug2: channel 0: output open -> drain > debug2: channel 0: obuf empty > debug2: channel 0: close_write > debug2: channel 0: output drain -> closed > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > debug2: channel 0: rcvd close > debug2: channel 0: close_read > debug2: channel 0: input open -> closed > debug3: channel 0: will not send data after close > debug2: channel 0: almost dead > debug2: channel 0: gc: notify user > debug2: channel 0: gc: user detached > debug2: channel 0: send close > debug2: channel 0: is dead > debug2: channel 0: garbage collecting > debug1: channel 0: free: client-session, nchannels 1 > debug3: channel 0: status: The following connections are open: > #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) > > debug3: channel 0: close_fds r -1 w -1 e 6 c -1 > debug1: fd 0 clearing O_NONBLOCK > debug3: fd 1 is not O_NONBLOCK > Transferred: sent 1808, received 1768 bytes, in 10.3 seconds > Bytes per second: sent 175.7, received 171.8 > debug1: Exit status 1 > Connection closed > > > []'s > > -- > Eduardo Otubo > Software Engineer > Linux Technology Center > IBM Systems & Technology Group > Mobile: +55 19 8135 0885 eotubo at linux.vnet.ibm.com > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From wlarip at gmail.com Tue Sep 22 16:10:11 2009 From: wlarip at gmail.com (William Adams) Date: Tue, 22 Sep 2009 02:10:11 -0400 Subject: Problems using sftp on HMC IBM system In-Reply-To: <4AB85646.1070209@linux.vnet.ibm.com> References: <4AB85646.1070209@linux.vnet.ibm.com> Message-ID: <93e2f71e0909212310r4e135395kbe7ee437981c8629@mail.gmail.com> On Tue, Sep 22, 2009 at 12:44 AM, Eduardo Otubo wrote: > Hello friends, > > I am having some problems using sftp to reach a HMC IBM system. The > connection is suddenly closed and I don't why. Actually I don't know exactly > how to read all these debug information. I would be very glad with any help > on this topic. Here is the full debug output provided from the command > execution: > > otubo at phoenix ~ $ sftp -vvv hscroot at skiper > Connection closed > It might be useful to examine the account, hcsroot, and the IBM SSH configuration. In particular, if this account is root, is root logon permitted? Also, this IBM SSH installation appears to have the SFTP subsystem helper enabled. How is it configured? Generally, the IBM SSH daemon and its helpers will place their stdout and stderr in /tmp or the like. The SSH daemon can be configured to put out some verbose error messages (just as the client can) which will show you why the connection is being closed. From alex at alex.org.uk Tue Sep 22 16:29:53 2009 From: alex at alex.org.uk (Alex Bligh) Date: Tue, 22 Sep 2009 07:29:53 +0100 Subject: openssh server and tun devices In-Reply-To: <2e9b14770909211518h6bfaeca5mf8152517e025773f@mail.gmail.com> References: <34B4269C6B98D3264C0591A9@Ximines.local> <2e9b14770909211518h6bfaeca5mf8152517e025773f@mail.gmail.com> Message-ID: Ralf, (Hi - long time no speak) --On 21 September 2009 23:18:30 +0100 Ralf Hack wrote: > ? So the tunnel device should be available in ifr.ifr_name ( i.e. tun0, > tun0, etc. ) in sys_tun_open(). At this point the struct is put on the > stack and destroyed of course when leaving sys_tun_open() but not before > it is printed for debugging purposes. The server does not appear to make > use of this information any further than that and relies on > open(/dev/net/tun) to be race condition free and to create a unique fd > handle. Have you any reason to believe that this is not the case ? That, in the end, was my conclusion too. Combined with the assumption that there could be only one tun/tap tunnel per child, I think this is race free (see my patch). > ? As to the latter question - for the above reason the tunnel device is > probably not available anywhere to query. Would be nice though to see it > in when probing the server with "~#". I think the client also uses tun_open etc., in which case my patch could easily be adapted so that '~#' listed the /client/ tunnel name. It would simply need to call tun_getname(). Bringing the server tunnel name back to the client would be harder (I'm not sure how ~# etc work). -- Alex Bligh From mouring at eviladmin.org Wed Sep 23 02:08:01 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Tue, 22 Sep 2009 11:08:01 -0500 Subject: Problems using sftp on HMC IBM system In-Reply-To: <4AB8EBD6.3020209@linux.vnet.ibm.com> References: <4AB85646.1070209@linux.vnet.ibm.com> <1EF69051-1270-4506-BAEE-AFD4A5FF9787@eviladmin.org> <4AB8EBD6.3020209@linux.vnet.ibm.com> Message-ID: <9A0DC733-623A-416C-9323-3DE2A030B779@eviladmin.org> On Sep 22, 2009, at 10:23 AM, Eduardo Otubo wrote: > Ben Lindstrom wrote: >> >> A more useful thing to do is: >> >> $ ssh hscroot at skiper /bin/true ## Use where your true bin is >> located, on some it is /usr/bin/true >> >> If you see any output other than the "Banner" output (if you use >> one, which it doesn't look like it). You need to fix your shell to >> not output data on non-interactive shell connections. >> >> - Ben > > I think we're dealing with a very restricted shell, look what I got: > > otubo at phoenix ~ $ ssh hscroot at skiper /bin/true > Password: > /bin/bash: /bin/true: restricted: cannot specify `/' in command names > otubo at phoenix ~ $ ssh hscroot at skiper true > Password: > otubo at phoenix ~ $ > otubo at phoenix ~ $ ssh hscroot at skiper > Password: > Last login: Tue Sep 22 12:02:00 2009 from 9.18.200.68 > hscroot at hmc:~> > hscroot at hmc:~> which true > which: no true in (/hmcrbin/:/usr/hmcrbin) > > Any ideias? > []'s Make sure your sshd_config has: Subsystem sftp internal-sftp Otherwise I highly doubt it will work with a restricted shell. Since sshd is pretty much doing $SHELL -c /path/to/sftp-server - Ben From otubo at linux.vnet.ibm.com Wed Sep 23 01:23:02 2009 From: otubo at linux.vnet.ibm.com (Eduardo Otubo) Date: Tue, 22 Sep 2009 12:23:02 -0300 Subject: Problems using sftp on HMC IBM system In-Reply-To: <1EF69051-1270-4506-BAEE-AFD4A5FF9787@eviladmin.org> References: <4AB85646.1070209@linux.vnet.ibm.com> <1EF69051-1270-4506-BAEE-AFD4A5FF9787@eviladmin.org> Message-ID: <4AB8EBD6.3020209@linux.vnet.ibm.com> Ben Lindstrom wrote: > > A more useful thing to do is: > > $ ssh hscroot at skiper /bin/true ## Use where your true bin is located, > on some it is /usr/bin/true > > If you see any output other than the "Banner" output (if you use one, > which it doesn't look like it). You need to fix your shell to not > output data on non-interactive shell connections. > > - Ben I think we're dealing with a very restricted shell, look what I got: otubo at phoenix ~ $ ssh hscroot at skiper /bin/true Password: /bin/bash: /bin/true: restricted: cannot specify `/' in command names otubo at phoenix ~ $ ssh hscroot at skiper true Password: otubo at phoenix ~ $ otubo at phoenix ~ $ ssh hscroot at skiper Password: Last login: Tue Sep 22 12:02:00 2009 from 9.18.200.68 hscroot at hmc:~> hscroot at hmc:~> which true which: no true in (/hmcrbin/:/usr/hmcrbin) Any ideias? []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 eotubo at linux.vnet.ibm.com From otubo at linux.vnet.ibm.com Wed Sep 23 04:26:51 2009 From: otubo at linux.vnet.ibm.com (Eduardo Otubo) Date: Tue, 22 Sep 2009 15:26:51 -0300 Subject: Problems using sftp on HMC IBM system In-Reply-To: <9A0DC733-623A-416C-9323-3DE2A030B779@eviladmin.org> References: <4AB85646.1070209@linux.vnet.ibm.com> <1EF69051-1270-4506-BAEE-AFD4A5FF9787@eviladmin.org> <4AB8EBD6.3020209@linux.vnet.ibm.com> <9A0DC733-623A-416C-9323-3DE2A030B779@eviladmin.org> Message-ID: <4AB916EB.8000807@linux.vnet.ibm.com> Ben Lindstrom wrote: > > On Sep 22, 2009, at 10:23 AM, Eduardo Otubo wrote: > >> Ben Lindstrom wrote: >>> >>> A more useful thing to do is: >>> >>> $ ssh hscroot at skiper /bin/true ## Use where your true bin is >>> located, on some it is /usr/bin/true >>> >>> If you see any output other than the "Banner" output (if you use >>> one, which it doesn't look like it). You need to fix your shell to >>> not output data on non-interactive shell connections. >>> >>> - Ben >> >> I think we're dealing with a very restricted shell, look what I got: >> >> otubo at phoenix ~ $ ssh hscroot at skiper /bin/true >> Password: >> /bin/bash: /bin/true: restricted: cannot specify `/' in command names >> otubo at phoenix ~ $ ssh hscroot at skiper true >> Password: >> otubo at phoenix ~ $ >> otubo at phoenix ~ $ ssh hscroot at skiper >> Password: >> Last login: Tue Sep 22 12:02:00 2009 from 9.18.200.68 >> hscroot at hmc:~> >> hscroot at hmc:~> which true >> which: no true in (/hmcrbin/:/usr/hmcrbin) >> >> Any ideias? >> []'s > > Make sure your sshd_config has: > > Subsystem sftp internal-sftp > > Otherwise I highly doubt it will work with a restricted shell. Since > sshd is pretty much doing $SHELL -c /path/to/sftp-server > > - Ben As I said in the other email, I can't change this configuration, as soon as I solve I'll try this out too. Thanks for the help. []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 eotubo at linux.vnet.ibm.com From otubo at linux.vnet.ibm.com Wed Sep 23 04:25:16 2009 From: otubo at linux.vnet.ibm.com (Eduardo Otubo) Date: Tue, 22 Sep 2009 15:25:16 -0300 Subject: Problems using sftp on HMC IBM system In-Reply-To: <93e2f71e0909212310r4e135395kbe7ee437981c8629@mail.gmail.com> References: <4AB85646.1070209@linux.vnet.ibm.com> <93e2f71e0909212310r4e135395kbe7ee437981c8629@mail.gmail.com> Message-ID: <4AB9168C.1050609@linux.vnet.ibm.com> William Adams wrote: > > It might be useful to examine the account, hcsroot, and the IBM SSH > configuration. The hscroot user is a super user, but not necessarily root in the system: hscroot at hmc:~> cat /etc/passwd |grep hscroot hscroot:x:500:500:HMC Super User:/home/hscroot:/bin/hmcbash And the SSH configuration is here: # $OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials yes # Set this to 'yes' to enable support for the deprecated 'gssapi' authentication # mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included # in this release. The use of 'gssapi' is deprecated due to the presence of # potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to. GSSAPIEnableMITMAttack yes # Set this to 'yes' to enable PAM authentication (via challenge-response) # and session processing. Depending on your PAM configuration, this may # bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords' UsePAM yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes PermitUserEnvironment yes #Compression yes #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /usr/lib/ssh/sftp-server Banner /opt/hsc/data/ssh/ssh_banner LogLevel ERROR In the end of the configuration file, there is a Subsystem that points to a binary file that I could execute due to restrictions. And that Banner file does not exists. > In particular, if this account is root, is root logon permitted? > Also, this IBM SSH installation appears to have the SFTP subsystem > helper enabled. > How is it configured? This account is not root, then login is permitted. The configuration is right up above. > > Generally, the IBM SSH daemon and its helpers will place their stdout > and stderr in /tmp > or the like. The SSH daemon can be configured to put out some verbose > error messages > (just as the client can) which will show you why the connection is being closed. I just can't reconfigure the SSH daemon due to hscroot permissions, I'll talk to the server owner to give me root's password to try those out. Thanks for the help :) -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 eotubo at linux.vnet.ibm.com From jbasney at ncsa.uiuc.edu Wed Sep 23 06:21:06 2009 From: jbasney at ncsa.uiuc.edu (Jim Basney) Date: Tue, 22 Sep 2009 15:21:06 -0500 Subject: How to generate additional debug messages for sshd gssapi failures? In-Reply-To: <20090921070514.GD1001@rwpc12.mby.riverwillow.net.au> References: <20090921070514.GD1001@rwpc12.mby.riverwillow.net.au> Message-ID: <4AB931B2.4060105@ncsa.uiuc.edu> Maybe this will help with troubleshooting. It may require setting UsePrivilegeSeparation no in sshd_config to get a useful error message. Index: auth2-gss.c =================================================================== RCS file: /cvs/openssh/auth2-gss.c,v retrieving revision 1.19 diff -u -r1.19 auth2-gss.c --- auth2-gss.c 2 Dec 2007 11:59:45 -0000 1.19 +++ auth2-gss.c 22 Sep 2009 20:17:11 -0000 @@ -278,8 +278,17 @@ if (!GSS_ERROR(PRIVSEP(ssh_gssapi_checkmic(gssctxt, &gssbuf, &mic)))) authenticated = PRIVSEP(ssh_gssapi_userok(authctxt->user)); - else + else { + char *errstr; + OM_uint32 maj,min; + logit("GSSAPI MIC check failed"); + errstr=ssh_gssapi_last_error(gssctxt,&maj,&min); + if (errstr) { + debug("GSSAPI ERROR maj=%u, min=%u\n%s", maj, min, errstr); + xfree(errstr); + } + } buffer_free(&b); xfree(mic.value); John Marshall wrote: > I'm trying to troubleshoot gssapi_with_mic authentication with OpenSSH > 5.2p1 on FreeBSD 8.0. > > If I run sshd with maximum debug "sshd -ddd" the most detail I get is: > > GSSAPI MIC check failed > > That comes from line 282 in auth2-gss.c > > 279 if (!GSS_ERROR(PRIVSEP(ssh_gssapi_checkmic(gssctxt, &gssbuf, &mic)))) > 280 authenticated = PRIVSEP(ssh_gssapi_userok(authctxt->user)); > 281 else > 282 logit("GSSAPI MIC check failed"); > 283 > > I think that's as much help as I can get from sshd. I'd like to add > some printf's to that else clause so that I can see the reason codes > returned by the gssapi routines. I'm not a programmer. Can anybody > give me any hints as to what to put here? > > Is there any chance of enhancing the error reporting at that point in a > future release so that debug logging produces useful output? > > Thank you for your help. From alex at alex.org.uk Wed Sep 23 07:07:31 2009 From: alex at alex.org.uk (Alex Bligh) Date: Tue, 22 Sep 2009 22:07:31 +0100 Subject: [patch] RFC: put server tunnel name in environment In-Reply-To: References: <39CD35849A536C8FAEB1D71D@Ximines.local> <485F23059C446B1877047810@Ximines.local> <20090921175856.28008.qmail@stuge.se> Message-ID: <7C6C2E53FCD84013E594401B@nimrod.local> Peter, --On 21 September 2009 20:44:56 +0100 Alex Bligh wrote: >> Alex Bligh wrote: >>> Trying again, with the patch attached as text/plain >> >> The patch seems racy. What if a second tunnel request comes in >> between the set_tunnel() and get_tunnel() for the first request? > > Is it possible to have more than one tunnel request per forked > child? I've been thinking some more about this. I think it depends what you mean by "racy". There is no traditional code race whereby the allocated string can be freed, as the code concerned is one single-threaded process (as per the reasons I explained before). What can happen is the string could have the wrong content if the following code flows were to happen: 1. Environment is set up (and interactive / non-interactive setup launched) before SSH_MSG_CHANNEL_OPEN / tun at openssh.com is received. Here do_setup_env() is called before server_request_tun(), and the environment string will be empty. Firstly, this doesn't happen in practice, at least when openssh is the client (and the tunnel extension seems to be openssh only), because the sessions are first sent up, then no-more-sessions comes in, then the interactive session / whatever launches. Secondly, once the interactive session is running, clearly its environment can't be altered by its parent anyway. So if SSH_TUNNEL is documented as "the tunnel opened prior to the / at the time of the start of the session", this would be accurate. 2. Multiple calls to server_request_tun() before the call to do_setup_env() call (i.e. requests to open multiple tunnels). This can't happen with an openssh client because the client does not support opening multiple tunnels, even when their IDs are specified. EG machine1# ssh -w 0:0 -w 1:1 machine2 will not do what you might have thought. It will in fact only set up tun1 devices at either end (and not tun0 devices). Now the protocol definition says: OpenSSH supports layer 2 and layer 3 tunnelling via the "tun at openssh.com" channel type. This channel type supports forwarding of network packets with datagram boundaries intact between endpoints equipped with interfaces like the BSD tun(4) device. Tunnel forwarding channels are requested by the client with the following packet: It's unclear to me whether that last plural is implying more than one tunnel can be set up (in theory), or is merely talking in generic terms. My reading of the code suggests that the server would seem to support this, but the client doesn't. One fix for this problem would be merely to describe the environment variable as "the last tunnel set up prior to the interactive session". A better approach, I think, would be simply to concatenate tunnel names onto the string. This would also handle closures, as the client knows exactly how many tunnels it has successfully opened and closed, and if the server never removes any from the string, the client can simply count through open requests to reliably get the ID of the n'th tunnel that it opened. This would would be a simple change to tun_setname() in the patch to concatenate, rather than free. Does that address your raciness concerns? -- Alex Bligh From wlarip at gmail.com Wed Sep 23 07:50:22 2009 From: wlarip at gmail.com (William Adams) Date: Tue, 22 Sep 2009 17:50:22 -0400 Subject: Problems using sftp on HMC IBM system In-Reply-To: <4AB9168C.1050609@linux.vnet.ibm.com> References: <4AB85646.1070209@linux.vnet.ibm.com> <93e2f71e0909212310r4e135395kbe7ee437981c8629@mail.gmail.com> <4AB9168C.1050609@linux.vnet.ibm.com> Message-ID: <93e2f71e0909221450u17226809l1200b5c64c679cb6@mail.gmail.com> On Tue, Sep 22, 2009 at 2:25 PM, Eduardo Otubo wrote: > LogLevel ERROR This should be enough. Depending on how syslogd on the IBM system is configured, these three files should be of interest. /tmp/sshd?.stdout. /tmp/sshd?.stderr and /tmp/log The name of the last can be gleaned from the parameters passed to the STC which starts syslogd. the name of the first two should be in the STC which starts SSHD. Not sure why your sshd_config has a BSD reference in it. perhaps a hold over from the port of SSH to MVS(which I'm assuming this is). the answer should be in the log created by syslogd. From peter at stuge.se Wed Sep 23 08:10:14 2009 From: peter at stuge.se (Peter Stuge) Date: Wed, 23 Sep 2009 00:10:14 +0200 Subject: Problems using sftp on HMC IBM system In-Reply-To: <4AB9168C.1050609@linux.vnet.ibm.com> References: <4AB85646.1070209@linux.vnet.ibm.com> <93e2f71e0909212310r4e135395kbe7ee437981c8629@mail.gmail.com> <4AB9168C.1050609@linux.vnet.ibm.com> Message-ID: <20090922221015.10856.qmail@stuge.se> Eduardo Otubo wrote: > # override default of no subsystems > Subsystem sftp /usr/lib/ssh/sftp-server > Banner /opt/hsc/data/ssh/ssh_banner > LogLevel ERROR > > In the end of the configuration file, there is a Subsystem that > points to a binary file that I could execute due to restrictions. If this sentence refers to /usr/lib/ssh/sftp-server then that explains why you are unable to use sftp. In order to use sftp, the user must have permission to execute sftp-server as specified by the subsystem line, or the server configuration must be changed, and /usr/lib/ssh/sftp-server above replaced with internal-sftp //Peter From molnarb81 at hotmail.com Fri Sep 25 18:24:43 2009 From: molnarb81 at hotmail.com (=?iso-8859-2?B?QmFs4XpzIE1vbG7hcg==?=) Date: Fri, 25 Sep 2009 10:24:43 +0200 Subject: ssh keyforwarding Message-ID: Dear All, I have a problem with the ssh keyforwarding. I use this command: ssh -t -A uid at hostname 'ssh hostname' Through the mans this is the right command. In the config file the keyforwarding is accept. ssh-agent is runnig with my key ... I do not know where I miss something ... or what do I wrong In the servers the .ssh dir exist with the permissions: drwxr-xr-x the authorized_keys as well -rwx------- I tried the permission varians as well without success. for both the owner is uid and group staff on both server for the first it is working but for the second one ... it is asking my passwd .profile file not contains any su or sudo command ... Can you help me? Many thanks for your help and time in advance. RegardsBal?zs Moln?re-Mail:molnarb81 at hotmail.com _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx From bert at bertenselena.net Mon Sep 28 21:29:24 2009 From: bert at bertenselena.net (Bert Haverkamp) Date: Mon, 28 Sep 2009 13:29:24 +0200 Subject: Hardlink patches for sftp In-Reply-To: <1e68a10b0909201015kfe5a8bexe9ffd84791216ce1@mail.gmail.com> References: <1e68a10b0909201015kfe5a8bexe9ffd84791216ce1@mail.gmail.com> Message-ID: <1e68a10b0909280429s7ae24be0uf1e24d821f8f5b68@mail.gmail.com> Hello, Sorry for the repeat, but I didn't see any response yet. Damien, could you maybe let us know the status? You were the one reacting to Miklos patches. (positively, it seemed) What are your plans with it? Regards, Bert Haverkamp On Sun, Sep 20, 2009 at 7:15 PM, Bert Haverkamp wrote: > Dear all, > > I am looking for the status on the hardlink patches that were > published on this list last february by Miklos Szeredi? > I'd really like to have hardlink support in sftp. This would in turn > enable hardlinks in sshfs and make incremental rsync backups to remote > filesystems possible. > > can someone tell me if these patches will be incorporated in openssh? > The patches can be found under > https://bugzilla.mindrot.org/show_bug.cgi?id=1555 > > Regards, > > Bert Haverkamp > > -- > ----------------------------------------------------- > 38 is NOT a random number!!!! > -- ----------------------------------------------------- 38 is NOT a random number!!!! From petfire85 at yahoo.fr Wed Sep 30 08:01:27 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Wed, 30 Sep 2009 00:01:27 +0200 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: Please help me ... . I suppose that OpenSSH developers know how it works because they have implement it. Is this in a RFC ? if yes, which RFC ? Thanks From dan at doxpara.com Wed Sep 30 08:13:37 2009 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 30 Sep 2009 00:13:37 +0200 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: Sounds like a bug...is this causing severe problems for you? On Wed, Sep 30, 2009 at 12:01 AM, Steeve BARBEAU wrote: > Please help me ... . I suppose that OpenSSH developers know how it works > because they have implement it. > > Is this in a RFC ? if yes, which RFC ? > > Thanks > _______________________________________________ > 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 Wed Sep 30 10:05:15 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Sep 2009 10:05:15 +1000 (EST) Subject: Question about Server Authentication In-Reply-To: <324763.44539.qm@web24710.mail.ird.yahoo.com> References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: On Mon, 7 Sep 2009, Steeve BARBEAU wrote: > > Hi guys, > > I'm working on a project which concern SSH and there is something i >don't understand about server authentication. So I explain my problem: > > - When you authorize only RSA keys in the sshd_config on the server, >you need to have the RSA public key of this server in the known_hosts >file of the client. This is absolutely normal. > > - When you authorize only DSA keys in the sshd_config on the server, >you need to have the DSA public key of this server in the known_hosts >file of the client. This is also absolutely normal. > > - But when you authorize both RSA and DSA keys, you are obliged to >have the RSA public key in the known_hosts file, without it fails. If >there is only DSA in the known_hosts file it fails, and this is that I >don't understand. Why the server authentication doesn't work with the >DSA key when both DSA and RSA are authorize. (Of course if both are >present in the known_host file, it works). So if somebody can help me >about this, it will be nice ;) When the server offers both ssh-rsa and ssh-dss server key types, the client's preference determines what is acutally used. Since the client offers ssh-rsa,ssh-dss by default (controllable via HostKeyAlgorithms), RSA will always win if the server supports it. It might be possible to look for a DSA key in known_hosts and change the order if one is found without a corresponding RSA key, but I don't really see much point. -d