From accountlostin at gmx.com Thu Jan 1 03:31:42 2015 From: accountlostin at gmx.com (account lost) Date: Wed, 31 Dec 2014 17:31:42 +0100 Subject: Keystroke dynamics countermeasures? Message-ID: Jacob Appelbaum and Laura Potrais recently gave a talk titled " Reconstructing narratives" at 31C3. http://media.ccc.de/browse/congress/2014/31c3_-_6258_-_en_-_saal_1_-_201412282030_-_reconstructing_narratives_-_jacob_-_laura_poitras.html#video They endorsed some technologies which are known to have not been broken by the five eyes at the time the documents were written, such as OTR, PGP, TOR, while discouraging people from using known-broken protocols such as PPTP vpn's and IPSEC vpn's "secured" by a preshared key, often common to all users and publicized on the isp's website, with L2TP only providing client authentication to the isp for accounting purposes (ok, that's a little off topic). They also stated that the NSA has, somehow, partially compromised SSH, but they couldn't figure out how. Jacob made some confused statement about elliptic curves, but the referenced document is more clear: http://www.spiegel.de/media/media-35515.pdf The slide about ssh is on page 19. The NSA states to be able to potentially recover usernames and passwords sent over SSH. This is a wild guess, but to me this seems more pertaining to keystroke dynamics, and has been known to be possible for a while: http://users.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf Text entered interactively in ssh (eg, invoking sudo post login) may leak credentials useful at escalating privileges through other services. Would it be possible to use ssh in canonical mode to avoid this? I think that would make text editing impossibile, but, couldn't a mechanism be provided to send keystroke all at once, simulating locally the expected result meanwhile? I think MOSH already does that, and this is probably out of ssh scope. But, could it be possible to have an option allowing the user to artificially add lag before sending the keystroke? EG, SSH will send the keystrokes at a regular interval of 500ms, adjusting the added lag in order to maintain a fixed latency between keystrokes, making it harder or impossible to gain insight of the entered text from traffic analysis. Does this last idea make any sense? From milosz at milosz.ca Thu Jan 1 10:40:35 2015 From: milosz at milosz.ca (Milosz Kosmider) Date: Wed, 31 Dec 2014 18:40:35 -0500 Subject: Using %n and other options in ssh_config IdentityFile Message-ID: Hi folks, The ssh_config man page specifies that the IdentityFile directive can expand a number of special character sequences into useful values, for example %h into the value of the HostName directive. This is great, but I am finding that the ability to expand these variables under various directives is quite spotty: http://www.dtucker.net/openssh/percent_expand_opts.html This chart possibly no longer reflects the status quo, but it paints the intended picture. In particular, one feature I find is missing is the ability to use %n (host name as specified on command line) in my IdentityFile and User directives. That is the naming scheme I have been using for my identity files and users for years now, and it has resulted in a rather repetitive .ssh/config file that I would like to DRY up a little. Allowing %n in the above directives would allow me to replace this: Host * IdentitiesOnly yes PreferredAuthentications publickey Host superduper HostName superduper.com User superduper IdentityFile ~/.ssh/supersuper.id_rsa Host ultramega HostName ultramega.com User ultramega IdentityFile ~/.ssh/ultramega.id_rsa Host differentuser HostName differentuser.com User someonelse IdentityFile ~/.ssh/differentuser.id_rsa with this: Host * IdentitiesOnly yes PreferredAuthentications publickey IdentityFile ~/.ssh/%n.id_rsa User %n Host superduper HostName superduper.com Host ultramega HostName ultramega.com Host differentuser HostName differentuser.com User someonelse Thoughts? Is it reasonable? Is it feasible? If you folks think it's a good idea, but no one on the inside has the bandwidth to do it, I am willing to learn the ropes and submit a code change, but I cannot find the process for this on the http://www.openssh.com/ website. Cheers, Milosz System details: - OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 - Ubuntu 14.04.1 LTS From seroland86 at gmail.com Fri Jan 2 09:43:16 2015 From: seroland86 at gmail.com (Sebastian Roland) Date: Thu, 1 Jan 2015 23:43:16 +0100 Subject: pam_end() wont get called Message-ID: Version: OpenSSH 6.7p1 Platform: ARM and x86_64 (both using offical ArchLinux packages) I am writing a PAM module for OpenSSH where I register a cleanup function as follows: int rc = pam_set_data(pamh, "x509_info", x509_info, &cleanup_x509_info); The cleanup function so far is only there for testing purposes: static void cleanup_x509_info(pam_handle_t *pamh, void *data, int error_status) { FILE *foo = fopen("/tmp/THIS_IS_A_TEST", "a"); close(foo); LOG_MSG("Cleanup called"); } Whether the file nor the log entry is there. So I suppose the function will never be called. This is not optimal as datastructures should be freed here currently leading to memory leaks. The sshd_config can be find attached. Sebastian From grarpamp at gmail.com Mon Jan 5 19:38:41 2015 From: grarpamp at gmail.com (grarpamp) Date: Mon, 5 Jan 2015 03:38:41 -0500 Subject: =?UTF-8?Q?Fwd=3A_=5BCryptography=5D_Why_aren=E2=80=99t_we_using_SSH_for_ev?= =?UTF-8?Q?erything=3F?= In-Reply-To: References: <1420354302.25833.100.camel@scientia.net> Message-ID: There were a few notes in this thread that may indicate open areas for development. I forward merely as FYI. http://www.metzdowd.com/pipermail/cryptography/2015-January/024231.html ---------- Forwarded message ---------- From: Peter Gutmann Date: Sun, Jan 4, 2015 at 9:29 PM Subject: Re: [Cryptography] Why aren?t we using SSH for everything? To: calestyo at scientia.net, pgut001 at cs.auckland.ac.nz Cc: cryptography at metzdowd.com Christoph Anton Mitterer writes: >On Sun, 2015-01-04 at 18:54 +1300, Peter Gutmann wrote: >> TLS finally fixed this after a year-long battle to get the change accepted. I >> also suggested it to the SSH folks but they weren't interested, and after the >> fight it took to get it into TLS I just didn't have the energy to go through >> the same thing for SSH. > >$ ssh -Q mac | grep etm >hmac-sha1-etm at openssh.com >hmac-sha1-96-etm at openssh.com >hmac-sha2-256-etm at openssh.com >hmac-sha2-512-etm at openssh.com >hmac-md5-etm at openssh.com >hmac-md5-96-etm at openssh.com >hmac-ripemd160-etm at openssh.com >umac-64-etm at openssh.com >umac-128-etm at openssh.com I've done the same thing, but the problem is that a bunch of (probably) incompatible vendor-specific extensions doesn't profit the community as a whole. If anyone from OpenSSH would like to get in touch, we can (a) see if what we're doing is interoperable and (b) document it in an RFC for general adoption. Peter. _______________________________________________ The cryptography mailing list cryptography at metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography From djm at mindrot.org Tue Jan 6 10:58:14 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Jan 2015 10:58:14 +1100 (EST) Subject: =?ISO-8859-7?Q?Re=3A_Fwd=3A_=5BCryptography=5D_Why_aren=A2t_we_using_SSH_for_everything=3F?= In-Reply-To: References: <1420354302.25833.100.camel@scientia.net> Message-ID: All our protocol extensions are documented in PROTOCOL.* in our source. Other open-source implementations have adopted some of our extensions (e.g. OpenSSH certificates in Go's x/crypto/ssh, chacha20-poly1305 in tinyssh) and we have adopted extensions from other open-source implementations (e.g. curve25519-sha256 at libssh.org). I've kinda given up trying to write things up for the IETF. It's dominated by commerical vendors and people with more inclination to argue on mailing lists than write good software (cf. the sftp process). -d On Mon, 5 Jan 2015, grarpamp wrote: > There were a few notes in this thread that may indicate > open areas for development. I forward merely as FYI. > > http://www.metzdowd.com/pipermail/cryptography/2015-January/024231.html > > ---------- Forwarded message ---------- > From: Peter Gutmann > Date: Sun, Jan 4, 2015 at 9:29 PM > Subject: Re: [Cryptography] Why aren?t we using SSH for everything? > To: calestyo at scientia.net, pgut001 at cs.auckland.ac.nz > Cc: cryptography at metzdowd.com > > Christoph Anton Mitterer writes: > >On Sun, 2015-01-04 at 18:54 +1300, Peter Gutmann wrote: > >> TLS finally fixed this after a year-long battle to get the change accepted. I > >> also suggested it to the SSH folks but they weren't interested, and after the > >> fight it took to get it into TLS I just didn't have the energy to go through > >> the same thing for SSH. > > > >$ ssh -Q mac | grep etm > >hmac-sha1-etm at openssh.com > >hmac-sha1-96-etm at openssh.com > >hmac-sha2-256-etm at openssh.com > >hmac-sha2-512-etm at openssh.com > >hmac-md5-etm at openssh.com > >hmac-md5-96-etm at openssh.com > >hmac-ripemd160-etm at openssh.com > >umac-64-etm at openssh.com > >umac-128-etm at openssh.com > > I've done the same thing, but the problem is that a bunch of (probably) > incompatible vendor-specific extensions doesn't profit the community as a > whole. If anyone from OpenSSH would like to get in touch, we can (a) see if > what we're doing is interoperable and (b) document it in an RFC for general > adoption. > > Peter. > _______________________________________________ > The cryptography mailing list > cryptography at metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From scott_n at xypro.com Tue Jan 6 11:29:08 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 6 Jan 2015 00:29:08 +0000 Subject: =?iso-8859-7?Q?RE:_Fwd:_[Cryptography]_Why_aren=A2t_we_using_SSH_for_ever?= =?iso-8859-7?Q?ything=3F?= In-Reply-To: References: <1420354302.25833.100.camel@scientia.net> Message-ID: Damien, What is the best document to use for documentation on SFTP? In other words, if I want to build an SFTP client library based on libssh.a, is there documentation about the series of messages I need to send over the wire? Thanks, ScottN -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Damien Miller Sent: Monday, January 05, 2015 3:58 PM To: grarpamp Cc: openssh-unix-dev at mindrot.org Subject: Re: Fwd: [Cryptography] Why aren?t we using SSH for everything? All our protocol extensions are documented in PROTOCOL.* in our source. Other open-source implementations have adopted some of our extensions (e.g. OpenSSH certificates in Go's x/crypto/ssh, chacha20-poly1305 in tinyssh) and we have adopted extensions from other open-source implementations (e.g. curve25519-sha256 at libssh.org). I've kinda given up trying to write things up for the IETF. It's dominated by commerical vendors and people with more inclination to argue on mailing lists than write good software (cf. the sftp process). -d On Mon, 5 Jan 2015, grarpamp wrote: > There were a few notes in this thread that may indicate open areas for > development. I forward merely as FYI. > > http://www.metzdowd.com/pipermail/cryptography/2015-January/024231.htm > l > > ---------- Forwarded message ---------- > From: Peter Gutmann > Date: Sun, Jan 4, 2015 at 9:29 PM > Subject: Re: [Cryptography] Why aren?t we using SSH for everything? > To: calestyo at scientia.net, pgut001 at cs.auckland.ac.nz > Cc: cryptography at metzdowd.com > > Christoph Anton Mitterer writes: > >On Sun, 2015-01-04 at 18:54 +1300, Peter Gutmann wrote: > >> TLS finally fixed this after a year-long battle to get the change > >> accepted. I also suggested it to the SSH folks but they weren't > >> interested, and after the fight it took to get it into TLS I just > >> didn't have the energy to go through the same thing for SSH. > > > >$ ssh -Q mac | grep etm > >hmac-sha1-etm at openssh.com > >hmac-sha1-96-etm at openssh.com > >hmac-sha2-256-etm at openssh.com > >hmac-sha2-512-etm at openssh.com > >hmac-md5-etm at openssh.com > >hmac-md5-96-etm at openssh.com > >hmac-ripemd160-etm at openssh.com > >umac-64-etm at openssh.com > >umac-128-etm at openssh.com > > I've done the same thing, but the problem is that a bunch of > (probably) incompatible vendor-specific extensions doesn't profit the > community as a whole. If anyone from OpenSSH would like to get in > touch, we can (a) see if what we're doing is interoperable and (b) > document it in an RFC for general adoption. > > Peter. > _______________________________________________ > The cryptography mailing list > cryptography at metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography > _______________________________________________ > 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 Tue Jan 6 15:54:22 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Jan 2015 15:54:22 +1100 (EST) Subject: =?ISO-8859-7?Q?RE=3A_Fwd=3A_=5BCryptography=5D_Why_aren=A2t_we_using_SSH_for_everything=3F?= In-Reply-To: References: <1420354302.25833.100.camel@scientia.net> Message-ID: On Tue, 6 Jan 2015, Scott Neugroschl wrote: > Damien, > > What is the best document to use for documentation on SFTP? In other > words, if I want to build an SFTP client library based on libssh.a, is > there documentation about the series of messages I need to send over > the wire? http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt plus the mistakes and extensions documented in the PROTOCOL file in the source tree. -d From wooozdoook at gmail.com Tue Jan 6 22:51:39 2015 From: wooozdoook at gmail.com (Kai Cui) Date: Tue, 6 Jan 2015 19:51:39 +0800 Subject: Latest 6.7p1 building failed on AIX 5.3 Message-ID: Hi! I try to build latest openssh 6.7p1 on AIX 5.3, but failed with the following error msg: # make echo (cd openbsd-compat && make) Target "all" is up to date. cc -qlanglvl=extc89 -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -blibpath:/usr/lib:/lib -lssh -lopenbsd-compat -lcrypto -lz ld: 0711-317 ERROR: Undefined symbol: .va_copy ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: The error code from the last command is 8. Any help is appreciated. From dtucker at zip.com.au Wed Jan 7 04:04:18 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 6 Jan 2015 12:04:18 -0500 Subject: Latest 6.7p1 building failed on AIX 5.3 In-Reply-To: References: Message-ID: On Tue, Jan 6, 2015 at 6:51 AM, Kai Cui wrote: > Hi! > > I try to build latest openssh 6.7p1 on AIX 5.3, but failed with the > following error msg: > > # make > echo > > (cd openbsd-compat && make) > Target "all" is up to date. > cc -qlanglvl=extc89 -o ssh ssh.o readconf.o clientloop.o sshtty.o > sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o > roaming_client.o -L. -Lopenbsd-compat/ -blibpath:/usr/lib:/lib -lssh > -lopenbsd-compat -lcrypto -lz > ld: 0711-317 ERROR: Undefined symbol: .va_copy > ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more > That should have picked up the definition from defines.h: #ifndef HAVE_VA_COPY # ifdef HAVE___VA_COPY # define va_copy(dest, src) __va_copy(dest, src) # else # define va_copy(dest, src) (dest) = (src) # endif #endif What is HAVE_VA_COPY set to in config.h ? Also, which object file has va_copy (I think it'll be sshbuf-getput-basic.o but I could be wrong). -- 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 aris at 0xbadc0de.be Wed Jan 7 08:27:22 2015 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Tue, 06 Jan 2015 22:27:22 +0100 Subject: Fwd: [Cryptography] Why =?windows-1252?Q?aren=92t_we_usi?= =?windows-1252?Q?ng_SSH_for_everything=3F?= In-Reply-To: References: <1420354302.25833.100.camel@scientia.net> Message-ID: <54AC533A.7040200@0xbadc0de.be> Le 6/01/15 05:54, Damien Miller a ?crit : > On Tue, 6 Jan 2015, Scott Neugroschl wrote: > >> Damien, >> >> What is the best document to use for documentation on SFTP? In other >> words, if I want to build an SFTP client library based on libssh.a, is >> there documentation about the series of messages I need to send over >> the wire? > http://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt plus the > mistakes and extensions documented in the PROTOCOL file in the source > tree. > > -d It's a shame there is no final version of the SFTP protocol, but more than 7 (IIRC) incompatible versions. It's understandable that OpenSSH ended up with sftpv3 + custom messages. use libssh from libssh.org if you want an sftp client lib :) Aris From docbook.xml at gmail.com Wed Jan 7 10:24:40 2015 From: docbook.xml at gmail.com (Ali, Saqib) Date: Tue, 06 Jan 2015 23:24:40 +0000 Subject: [PATCH] Early request for comments: U2F authentication Message-ID: Greetings Michael, Where is the latest patch available? I would like to start testing it. Thanks! :) From peter at stuge.se Wed Jan 7 14:30:34 2015 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 Jan 2015 04:30:34 +0100 Subject: Fwd: [Cryptography] Why =?utf-8?Q?aren?= =?utf-8?B?4oCZdA==?= we using SSH for everything? In-Reply-To: <54AC533A.7040200@0xbadc0de.be> References: <1420354302.25833.100.camel@scientia.net> <54AC533A.7040200@0xbadc0de.be> Message-ID: <20150107033034.26366.qmail@stuge.se> Aris Adamantiadis wrote: > use libssh from libssh.org if you want an sftp client lib :) or libssh2 from libssh2.org Let's be fair. //Peter From stapelberg+openssh at google.com Wed Jan 7 21:07:00 2015 From: stapelberg+openssh at google.com (Michael Stapelberg) Date: Wed, 7 Jan 2015 02:07:00 -0800 Subject: [PATCH] Early request for comments: U2F authentication In-Reply-To: References: Message-ID: In addition to the thread where you?re currently posting in, you can also find the latest patch at https://bugzilla.mindrot.org/show_bug.cgi?id=2319 I haven?t had a chance to reply to Thomas?s comments yet. On Tue, Jan 6, 2015 at 3:24 PM, Ali, Saqib wrote: > Greetings Michael, > > Where is the latest patch available? I would like to start testing it. > > Thanks! :) > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From calestyo at scientia.net Thu Jan 8 07:30:57 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 07 Jan 2015 21:30:57 +0100 Subject: discussion about keystroke timing attacks against SSH on the cryptography ML Message-ID: <1420662657.4847.69.camel@scientia.net> Hi folks. FYI: There's a discussion[0] about keystroke timing attacks against SSH going on on the cryptography mailing list. Would be interesting to hear the opinion of some OpenSSH folks what SSH/OpenSSH is doing against this and what could maybe be don in addition. Especially since the main idea behind the attack is obviously not limited to the initial authentication phase when a password is entered and characters would be sent one-by-one... but applicable more generally to any interactive sessions. Cheers, Chris. [0] http://www.metzdowd.com/pipermail/cryptography/2015-January/024284.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From calestyo at scientia.net Thu Jan 8 07:51:00 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 07 Jan 2015 21:51:00 +0100 Subject: Debian bugs requesting "safer" default algos/etc. Message-ID: <1420663860.4847.88.camel@scientia.net> Hi. Another FYI: Along with the recent publications about alleged NSA attacks against SSH, we got some bug[0][1] reports in Debian about "please use more secure algos" (i.e. disable all others). Perhaps something you might want to look at. - With respect to the DH group sizes, which is requested there to be increased... well I've already opened #2302 and #2303, but these are more related around DH-GEX, not about disabling e.g. diffie-hellman-group1-sha1, diffie-hellman-group14-sha1 and possibly even diffie-hellman-group-exchange-sha1 nor do they deal with the request from the submitters of the bugs in Debian to no longer generate small moduli by default. - With respect to those submitters request to drop many "legacy" alogs from the default lists... well it's difficult because of interoperability, but I'd basically agree with that request... people in need for those algos can still enable them manually or (for the client side) even just on a per host basis. I for example allow on my systems only these per default (in ssh_config and sshd_config: HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ssh-rsa,ssh-rsa-cert-v01 at openssh.com KexAlgorithms curve25519-sha256 at libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256 Ciphers chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com,umac-128-etm at openssh.com I.e. everything that matches: - dss, v00 - diffie-hellman => in principle I woluld allow diffie-hellman-group-exchange-sha256, but not as long as #2302 and #2303 are issues. - arcfour, cbc - sha1, md5, ripemd, umac-64 or that not matches etm => I have no real reason to believe that umac-64-etm at openssh.com isn't secure enough... I just thought better more bits, it doesn't hurt. And I'm still thinking about removing all nist curves algos. Also I'm well aware that the algos I've decided to drop are not necessarily fully broken... but again,... better safe than sorry. I'm not sure how much upstream is willing here to "harden" defaults, since this usually goes on out-of-the-box interoperability... but I think it would be better if any such hardening takes place on the upstream side, than every distro cooking it's own stuff. Cheers, Chris. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774711 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774793 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From hyc at symas.com Thu Jan 8 07:57:11 2015 From: hyc at symas.com (Howard Chu) Date: Wed, 07 Jan 2015 20:57:11 +0000 Subject: discussion about keystroke timing attacks against SSH on the cryptography ML In-Reply-To: <1420662657.4847.69.camel@scientia.net> References: <1420662657.4847.69.camel@scientia.net> Message-ID: <54AD9DA7.4000600@symas.com> Christoph Anton Mitterer wrote: > Hi folks. > > FYI: > There's a discussion[0] about keystroke timing attacks against SSH going > on on the cryptography mailing list. > > Would be interesting to hear the opinion of some OpenSSH folks what > SSH/OpenSSH is doing against this and what could maybe be don in > addition. > Especially since the main idea behind the attack is obviously not > limited to the initial authentication phase when a password is entered > and characters would be sent one-by-one... but applicable more generally > to any interactive sessions. > This is why I use LINEMODE/EXTPROC... https://github.com/hyc/OpenSSH-LINEMODE > Cheers, > Chris. > > > [0] http://www.metzdowd.com/pipermail/cryptography/2015-January/024284.html > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- -- 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 calestyo at scientia.net Thu Jan 8 08:00:21 2015 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 07 Jan 2015 22:00:21 +0100 Subject: discussion about keystroke timing attacks against SSH on the cryptography ML In-Reply-To: <54AD9DA7.4000600@symas.com> References: <1420662657.4847.69.camel@scientia.net> <54AD9DA7.4000600@symas.com> Message-ID: <1420664421.4847.97.camel@scientia.net> I guess it would be nice if you and other people could perhaps post (or cross post) further stuff on this thread to the cryptography mailing list (cryptography at metzdowd.com). Cheers, Chris :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From johannes at kyriasis.com Thu Jan 8 21:08:04 2015 From: johannes at kyriasis.com (Johannes =?utf-8?B?TMO2dGhiZXJn?=) Date: Thu, 8 Jan 2015 11:08:04 +0100 Subject: pubkey fingerprint and krb princ name in environment In-Reply-To: References: <20141228141251.GA9815@leeloo.kyriasis.com> Message-ID: <20150108100804.GA24422@leeloo.kyriasis.com> [Accidentally replied directly instead of to the list, sorry ?bout that] On 30/12, Damien Miller wrote: > As of last week, sshd keeps a list of the user public keys that were > used in authentication. This should make implementing the pubkey bit > of this easier... > Does it store the whole key, the fp or both? Because just the fingerprint is just a single line. Anyway, that?s awesome! -- Sincerely, Johannes L?thberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 1495 bytes Desc: not available URL: From djm at mindrot.org Fri Jan 9 00:05:34 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Jan 2015 00:05:34 +1100 (EST) Subject: pubkey fingerprint and krb princ name in environment In-Reply-To: <20150108100804.GA24422@leeloo.kyriasis.com> References: <20141228141251.GA9815@leeloo.kyriasis.com> <20150108100804.GA24422@leeloo.kyriasis.com> Message-ID: On Thu, 8 Jan 2015, Johannes L?thberg wrote: > [Accidentally replied directly instead of to the list, sorry ?bout that] > > On 30/12, Damien Miller wrote: > > As of last week, sshd keeps a list of the user public keys that were > > used in authentication. This should make implementing the pubkey bit > > of this easier... > > > > Does it store the whole key, the fp or both? Because just the fingerprint is > just a single line. It stores the whole key (it needs to, so it can compare them with subsequent attempts). I might need to generalise it for krb credentials though. -d From fedor.brunner at azet.sk Fri Jan 9 01:15:20 2015 From: fedor.brunner at azet.sk (Fedor Brunner) Date: Thu, 08 Jan 2015 15:15:20 +0100 Subject: Factorization of a 768-bit RSA modulus Message-ID: <54AE90F8.6020201@azet.sk> ssh-keygen.c contains condition else if (type != KEY_ECDSA && type != KEY_ED25519 && *bitsp < 768) fatal("Key must at least be 768 bits"); Please increase the minimal RSA key length. https://eprint.iacr.org/2010/006 This paper reports on the factorization of the 768-bit number RSA-768 by the number field sieve factoring method From jjelen at redhat.com Fri Jan 9 03:44:57 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Thu, 08 Jan 2015 17:44:57 +0100 Subject: [PATCH] Improve error message in scp (bz1768) Message-ID: <54AEB409.1090706@redhat.com> Hello, I started digging in some problems and problems and bugzillas and this was one problem I found and managed to solve so I'm letting you know about this with patch. Severity is not critical, but according to other users and bugzillas, it can mislead someone (during at almost 10 years of existence according to Ubuntu). To get to the point, there is problem in current version, that you are getting strange error message if you try to scp existing local file to non-existing remote directory (ending with slash). The most we can say by example: $ scp file host:new_dir/ This example ends up with quite strange error message: > scp: new_dir/: Is a directory Which doesn't make sense from the beginning, but after some digging in code, you see that this error message is coming from place where scp is trying to write the received data into file ending with slash (which can't end other way than this). My patch is trying to fix this specific issue and not to break any other functionality, not like the previous attempt mentioned in bugzilla. As I'm mentioning in bugzilla, all tests in regress passed and I also added one more to verify that this edge condition is covered with reasonable error message. Once more, link to bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=1768 TL;DR: Can someone approve this patch for and include it in openssh? Best regards, Jakub Jelen From jjelen at redhat.com Fri Jan 9 22:19:50 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Fri, 09 Jan 2015 12:19:50 +0100 Subject: [PATCH] Make config parser more strict to ip:port values (bz2335) Message-ID: <54AFB956.7070806@redhat.com> Hello, I have there another small contribution for openssh project and since I don't have any other responses for the previous I will not be such verbose like last time. In short, openssh config parser doesn't do what it is supposed to do (based on man pages) and this behaviour is quite confusing so I would like to push this modification into upstream. Finally, link to bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=2335 I hope everything is clear and if not, I'm open to discussion. Best regards, Jakub Jelen From grantksupport at operamail.com Sat Jan 10 03:05:07 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 08:05:07 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? Message-ID: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> I run OpenSSH on linux @ client which ssh /usr/local/bin/ssh ssh -v OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014 @ server which sshd /usr/local/bin/sshd sshd -v unknown option -- V OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014 usage: sshd [-46DdeiqTt] [-b bits] [-C connection_spec] [-c host_cert_file] [-E log_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-k key_gen_time] [-o option] [-p port] I have configured for hostbased authentication client ssh_config ... PreferredAuthentications hostbased,publickey HostbasedAuthentication yes PubkeyAuthentication yes PasswordAuthentication no ... server sshd_config ... AuthenticationMethods hostbased,publickey HostbasedAuthentication yes HostbasedUsesNameFromPacketOnly yes PubkeyAuthentication yes PasswordAuthentication no ... on the server, because I'm not entirely sure where to put it yet echo "client.DOMAIN.COM" > /etc/shosts.equiv echo "client.DOMAIN.COM" > /usr/local/etc/shosts.equiv when I try to connect ssh -vvv server.DOMAIN.COM hostname auth fails ... Permission denied (hostbased). debug logs return client log ... debug1: Authentications that can continue: hostbased debug3: start over, passed a different list hostbased debug3: preferred hostbased,publickey debug3: authmethod_lookup hostbased debug3: remaining preferred: publickey,password debug3: authmethod_is_enabled hostbased debug1: Next authentication method: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug1: No more client hostkeys for hostbased authentication. debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (hostbased). server log ... Jan 9 07:37:31 server sshd[19835]: debug2: input_userauth_request: try method hostbased [preauth] Jan 9 07:37:31 server sshd[19835]: debug1: userauth_hostbased: cuser root chost client.DOMAIN.COM. pkalg ssh-ed25519 slen 83 [preauth] Jan 9 07:37:31 server sshd[19835]: debug3: mm_key_allowed entering [preauth] Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_send entering: type 22 [preauth] Jan 9 07:37:31 server sshd[19835]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_receive_expect entering: type 23 [preauth] Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_receive entering [preauth] Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_receive entering Jan 9 07:37:31 server sshd[19835]: debug3: monitor_read: checking request 22 Jan 9 07:37:31 server sshd[19835]: debug3: mm_answer_keyallowed entering Jan 9 07:37:31 server sshd[19835]: debug3: mm_answer_keyallowed: key_from_blob: 0x7cd1262cbc76 Jan 9 07:37:31 server sshd[19835]: debug2: userauth_hostbased: chost client.DOMAIN.COM. resolvedname xxxx:xxx:xxxx:xxx::10 ipaddr xxxx:xxx:xxxx:xxx::10 Jan 9 07:37:31 server sshd[19835]: debug2: stripping trailing dot from chost client.DOMAIN.COM. Jan 9 07:37:31 server sshd[19835]: debug2: auth_rhosts2: clientuser root hostname client.DOMAIN.COM ipaddr client.DOMAIN.COM Jan 9 07:37:31 server sshd[19835]: debug1: temporarily_use_uid: 0/0 (e=0/0) Jan 9 07:37:31 server sshd[19835]: debug1: restore_uid: 0/0 Jan 9 07:37:31 server sshd[19835]: debug1: temporarily_use_uid: 0/0 (e=0/0) Jan 9 07:37:31 server sshd[19835]: debug1: restore_uid: 0/0 Jan 9 07:37:31 server sshd[19835]: Failed hostbased for root from xxxx:xxx:xxxx:xxx::10 port 40452 ssh2: ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx, client user "root", client host "client.DOMAIN.COM" Jan 9 07:37:31 server sshd[19835]: debug3: mm_answer_keyallowed: key 0x7cd1262cbc76 is not allowed Jan 9 07:37:31 server sshd[19835]: debug3: mm_request_send entering: type 23 Jan 9 07:37:31 server sshd[19835]: debug2: userauth_hostbased: authenticated 0 [preauth] Jan 9 07:37:31 server sshd[19835]: debug3: userauth_finish: failure partial=0 next methods="hostbased" [preauth] ... I see that mm_answer_keyallowed: key 0x7cd1262cbc76 is not allowed but am not clear what key that is. grep'ing for '7cd1262cbc76' turns up nothing. What's wrong or missing in my config? From tim at multitalents.net Sat Jan 10 05:48:32 2015 From: tim at multitalents.net (Tim Rice) Date: Fri, 9 Jan 2015 10:48:32 -0800 (PST) Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> Message-ID: On Fri, 9 Jan 2015, grantksupport at operamail.com wrote: | OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014 | I have configured for hostbased authentication | | client ssh_config | ... | PreferredAuthentications hostbased,publickey | HostbasedAuthentication yes | PubkeyAuthentication yes | PasswordAuthentication no | ... | | server sshd_config | ... | AuthenticationMethods hostbased,publickey | HostbasedAuthentication yes | HostbasedUsesNameFromPacketOnly yes | PubkeyAuthentication yes | PasswordAuthentication no | ... | | on the server, because I'm not entirely sure where to put it yet | | echo "client.DOMAIN.COM" > /etc/shosts.equiv | echo "client.DOMAIN.COM" > /usr/local/etc/shosts.equiv | What's wrong or missing in my config? My ssh_config has Host * HostbasedAuthentication yes EnableSSHKeysign yes NoHostAuthenticationForLocalhost yes NoHostAuthenticationForLocalhost is not necessary. The one you are missing is EnableSSHKeysign. Additionally, you made no mention of your ssh_known_hosts files. Make sure the client's public keys are in the server's ssh_known_hosts file. -- Tim Rice Multitalents tim at multitalents.net From imorgan at nas.nasa.gov Sat Jan 10 06:40:14 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 9 Jan 2015 11:40:14 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> Message-ID: <20150109193527.GA29822@linux124.nas.nasa.gov> To begin with, don't complicate the situation by requiring two forms of authentication before you've gotten a single form of authentication working. In addition, root is too much of a special case for useful debugging; try your tests as a regular user. As Tim Rice noted, you will need to set EnableSSHKeysign in the system--wide client configuration for hostbased authentication to work for non-root users. -- Iain Morgan From grantksupport at operamail.com Sat Jan 10 07:07:38 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 12:07:38 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <20150109193527.GA29822@linux124.nas.nasa.gov> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> Message-ID: <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> Hi, On Fri, Jan 9, 2015, at 10:48 AM, Tim Rice wrote: > My ssh_config has > Host * > HostbasedAuthentication yes > EnableSSHKeysign yes > NoHostAuthenticationForLocalhost yes > > NoHostAuthenticationForLocalhost is not necessary. > The one you are missing is EnableSSHKeysign. > > Additionally, you made no mention of your ssh_known_hosts files. Make > sure the client's public keys are in the server's ssh_known_hosts file. On Fri, Jan 9, 2015, at 11:40 AM, Iain Morgan wrote: > To begin with, don't complicate the situation by requiring two forms of > authentication before you've gotten a single form of authentication > working. In addition, root is too much of a special case for useful > debugging; try your tests as a regular user. > > As Tim Rice noted, you will need to set EnableSSHKeysign in the > system--wide client configuration for hostbased authentication to work > for non-root users. I edited configs to client ssh_config ... - PreferredAuthentications hostbased,publickey + PreferredAuthentications hostbased HostbasedAuthentication yes PubkeyAuthentication yes + PubkeyAuthentication no PasswordAuthentication no ... EnableSSHKeysign yes (note: this had already been 'in there' --- just further down in the config) ... server sshd_config ... - AuthenticationMethods hostbased,publickey + AuthenticationMethods hostbased HostbasedAuthentication yes - HostbasedUsesNameFromPacketOnly yes + #HostbasedUsesNameFromPacketOnly yes - PubkeyAuthentication yes + PubkeyAuthentication no PasswordAuthentication no ... I already have the server's key in the known hosts file on the client. @ client cat ssh_config ... GlobalKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts UserKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts ... ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts and @server ssh-keyscan -t ed25519 client.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts with all of the above, the hostbased auth connnect still fails just as before, ssh server.DOMAIN.COM ... Permission denied (hostbased). From grantksupport at operamail.com Sat Jan 10 07:22:00 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 12:22:00 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> Message-ID: <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> @client as root (as before) ssh server.DOMAIN.COM Permission denied (hostbased). instead, as my user, fails differently for some reason, ssh server.DOMAIN.COM ... no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx ssh_keysign: no reply key_sign failed Permission denied (hostbased). and verbose ssh server.DOMAIN.COM -vvv ... debug1: Authentications that can continue: hostbased debug3: start over, passed a different list hostbased debug3: preferred hostbased debug3: authmethod_lookup hostbased debug3: authmethod_is_enabled hostbased debug1: Next authentication method: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 1000 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 1000 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 1000 debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: hostbased debug2: userauth_hostbased: chost client.DOMAIN.COM. debug2: ssh_keysign called debug3: ssh_msg_send: type 2 debug3: ssh_msg_recv entering debug1: permanently_drop_suid: 1000 no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx ssh_keysign: no reply key_sign failed debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (hostbased). From imorgan at nas.nasa.gov Sat Jan 10 08:02:55 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 9 Jan 2015 13:02:55 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> Message-ID: <20150109210255.GF5808@linux124.nas.nasa.gov> On Fri, Jan 09, 2015 at 12:07:38 -0800, grantksupport at operamail.com wrote: > Hi, > > On Fri, Jan 9, 2015, at 10:48 AM, Tim Rice wrote: > > My ssh_config has > > Host * > > HostbasedAuthentication yes > > EnableSSHKeysign yes > > NoHostAuthenticationForLocalhost yes > > > > NoHostAuthenticationForLocalhost is not necessary. > > The one you are missing is EnableSSHKeysign. > > > > Additionally, you made no mention of your ssh_known_hosts files. Make > > sure the client's public keys are in the server's ssh_known_hosts file. > > > On Fri, Jan 9, 2015, at 11:40 AM, Iain Morgan wrote: > > To begin with, don't complicate the situation by requiring two forms of > > authentication before you've gotten a single form of authentication > > working. In addition, root is too much of a special case for useful > > debugging; try your tests as a regular user. > > > > As Tim Rice noted, you will need to set EnableSSHKeysign in the > > system--wide client configuration for hostbased authentication to work > > for non-root users. > > I edited configs to > > client ssh_config > ... > - PreferredAuthentications hostbased,publickey > + PreferredAuthentications hostbased > HostbasedAuthentication yes > PubkeyAuthentication yes > + PubkeyAuthentication no > PasswordAuthentication no > ... I suppose I wan't specific enough; I was recommending that you should first get each of the two authentication methods working separately before you set AuthenticationMethods in sshd_config to require both hostbased and public-key authentication. While you are debugging your issue, I would recommend leaving PreferredAuthentications at the default and leaving the various authentication methods enabled. When you invoke ssh with the -v option and an authentication method (such as hostbased authentication) fails, the client can display some diagnostic information from the server -- provided that you are able to successfully authenticate by some other method, such as public-key authentication. > EnableSSHKeysign yes (note: this had already been 'in there' --- just further down in the config) > ... > > server sshd_config > ... > - AuthenticationMethods hostbased,publickey > + AuthenticationMethods hostbased > HostbasedAuthentication yes > - HostbasedUsesNameFromPacketOnly yes > + #HostbasedUsesNameFromPacketOnly yes > - PubkeyAuthentication yes > + PubkeyAuthentication no > PasswordAuthentication no > ... > > I already have the server's key in the known hosts file on the client. > But, for hostbased authentication, the _server_ must have the key for the _client_ in the ssh_known_hosts file (or potentially in the user's ~/.ssh/known_hosts file). > @ client > > cat ssh_config > ... > GlobalKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts > UserKnownHostsFile /usr/local/etc/ssh/ssh_known_hosts > ... > > ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts > > and @server > > ssh-keyscan -t ed25519 client.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts > > with all of the above, the hostbased auth connnect still fails just as before, > > ssh server.DOMAIN.COM > ... > Permission denied (hostbased). You may want to check that you are using the right location for your shosts.equiv and that the ssh-keysign binary is setuid root (assuming that you are now trying as a regular user). Damien recently added some additional debugging messages for hostbased authentication, so if you continue to have problems you could try building a recent snapshot for the server. Hostbased authentication can be a bit thorny to get right since it depends upon multiple files being correct. Try to keep things simple initially to avoid unnecessary complications: Only change those options in the client and server that are necessary to enable hostbased authentication. make sure that you are using the right location for the shosts.equiv file and that the entry in the file matches the hostname (ususally teh fully-qualified hostname) that the client uses. The server must have the clients public-key in the ssh_known_hosts file, and the name must also match the client. In most cases, problems with hostbased authentication end up being due to either a typo or an inconsistency between the name claimed by the client and the name that the server associates with the client's IP address. -- Iain Morgan From grantksupport at operamail.com Sat Jan 10 08:00:10 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 13:00:10 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> Message-ID: <1420837210.2161618.211987621.0D6709E1@webmail.messagingengine.com> Hi On Fri, Jan 9, 2015, at 12:34 PM, Mark Hahn wrote: > >> The one you are missing is EnableSSHKeysign. > > I suppose it's worth asking: is your ssh-keysign suid root > (and are the permissions on your host keys sufficiently tight)? Note that everything works correctly with other auth methods: pubkey, password, ... I suspect key perms issues would've come up there. Here's also the ssk-keysign perms client ls -al /usr/local/libexec/ssh-keysign -rwsr-xr-x+ 1 root root 459K Oct 11 06:51 /usr/local/libexec/ssh-keysign* ls -al /usr/local/etc/ssh/ssh.client.ed25519* -rw-------+ 1 root root 517 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519 -rw-r--r--+ 1 root root 107 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519.pub server ls -al /usr/local/libexec/ssh-keysign -rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign* ls -al /usr/local/etc/ssh/ssh.server.ed25519* -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519 -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub > > ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts > > fine, though it's worth verifying that these are the files being used > by the (non-default, right) sshd and ssh (client) that you're using. i have @ server which sshd /usr/local/sbin/sshd systemctl status sshd sshd.service - OpenSSH Daemon Loaded: loaded (/etc/systemd/system/sshd.service; enabled) Active: active (running) since Fri 2015-01-09 12:57:12 PST; 2s ago Main PID: 21534 (sshd) CGroup: /system.slice/sshd.service ?? 4662 sshd: root at pts/0 ?? 4664 -bash ??21534 /usr/local/sbin/sshd -D -f /usr/local/etc/ssh/sshd_config ??21541 systemctl status sshd ps ax | grep sshd_config 20989 ? Ss 0:00 /usr/local/sbin/sshd -D -f /usr/local/etc/ssh/sshd_config and @ client which ssh /usr/local/bin/ssh ssh server.DOMAIN.COM -vvv ... debug3: load_hostkeys: loading entries for host "server.DOMAIN.COM" from file "/usr/local/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type ED25519 in file /usr/local/etc/ssh/ssh_known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "server.DOMAIN.COM" from file "/usr/local/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found key type ED25519 in file /usr/local/etc/ssh/ssh_known_hosts:2 debug3: load_hostkeys: loaded 1 keys ... > > Permission denied (hostbased). From imorgan at nas.nasa.gov Sat Jan 10 08:40:48 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 9 Jan 2015 13:40:48 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> Message-ID: <20150109214048.GG5808@linux124.nas.nasa.gov> On Fri, Jan 09, 2015 at 12:22:00 -0800, grantksupport at operamail.com wrote: > @client > > as root (as before) > > ssh server.DOMAIN.COM > Permission denied (hostbased). > > instead, as my user, fails differently for some reason, > > ssh server.DOMAIN.COM > ... > no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx > ssh_keysign: no reply > key_sign failed > Permission denied (hostbased). > So, that indicates that you have a problem with your client setup. Since you are trying to use ssh from /usr/local/bin, I take it that it is a local build. As such, some of the files may not be properly located. You can check the location of the ssh-keysign binary by running strings on the ssh executable and grep'ing for ssh-keysign. I expect that it will be /usr/local/libexec/ssh-keysign. Make sure that it is setuid root. You can then run strings on the ssh-keysign executable and grep for ssh_host ed25519 to confirm the expected location for the host key. Make sure that the key can be found in the expected location, and that the public key is world-readable, but that the private key is readable only by root. Note, if you do not see a reference to ssh_host_ed25519 in the above strings output, the ssh-keysign executable is from an older distribution that does not support ED25519. Given that possibility, you might try adding the ECDSA key for the client to the ssh_known_hosts file on the server. -- Iain Morgan From grantksupport at operamail.com Sat Jan 10 08:50:25 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 13:50:25 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <20150109210255.GF5808@linux124.nas.nasa.gov> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <20150109210255.GF5808@linux124.nas.nasa.gov> Message-ID: <1420840225.2174102.211996381.12C3AF48@webmail.messagingengine.com> Hi, On Fri, Jan 9, 2015, at 01:02 PM, Iain Morgan wrote: > I suppose I wan't specific enough; I was recommending that you should > first get each of the two authentication methods working separately > before you set AuthenticationMethods in sshd_config to require both > hostbased and public-key authentication. While you are debugging your > issue, I would recommend leaving PreferredAuthentications at the default > and leaving the various authentication methods enabled. Sorry, perhaps I'm being thick. I don't get it. pubkey auth works fine. password auth works fine. pubkey,password works fine hostbased &/or hostbased,anything_else does not. What config would you like me to try? > When you invoke ssh with the -v option and an authentication method > (such as hostbased authentication) fails, the client can display some > diagnostic information from the server -- provided that you are able to > successfully authenticate by some other method, such as public-key > authentication. As above, if hostbased is enabled, NOTHING works. > > I already have the server's key in the known hosts file on the client. > > > > But, for hostbased authentication, the _server_ must have the key for > the _client_ in the ssh_known_hosts file (or potentially in the user's > ~/.ssh/known_hosts file). I've now done @ both server & @client ssh-keyscan -t ed25519 client.DOMAIN.COM > /usr/local/etc/ssh/ssh_known_hosts ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts It makes no difference; failure as reported. > You may want to check that you are using the right location for your > shosts.equiv and that the ssh-keysign binary is setuid root (assuming > that you are now trying as a regular user). already done man 5 sshd_config | grep shosts Specifies whether or not the server will attempt to perform a reverse name lookup when matching the name in the ~/.shosts, ~/.rhosts, and /etc/hosts.equiv files during HostbasedAuthentication. A setting of ?yes? means Specifies that .rhosts and .shosts files will not be used in RhostsRSAAuthentication or HostbasedAuthentication. ---> /etc/hosts.equiv and /usr/local/etc/ssh/shosts.equiv are still used. The default is ?yes?. @ both server & client cat /usr/local/etc/ssh/shosts.equiv client.DOMAIN.COM server.DOMAIN.COM > Damien recently added some additional debugging messages for hostbased > authentication, so if you continue to have problems you could try > building a recent snapshot for the server. how recently? these are tarball builds -rw-rwxr--+ 1 root root 1.3M Oct 6 15:34 openssh-6.7p1.tar.gz* newer that the release, I presume? > Hostbased authentication can be a bit thorny to get right since it > depends upon multiple files being correct. Try to keep things simple > initially to avoid unnecessary complications: Only change those options > in the client and server that are necessary to enable hostbased > authentication. I start with a KNOWN TO WORK pubkey,password config, then ONLY change to add the hostbased auth. And then it fails. Reverse JUST those changes, and it succeeds. > make sure that you are using the right location for the > shosts.equiv file and that the entry in the file matches the hostname > (ususally teh fully-qualified hostname) that the client uses. The server > must have the clients public-key in the ssh_known_hosts file, and the > name must also match the client. all hostnames a FQDNs. all have correct/verified forward & reverse DNS entries. both IPv4 & IPv6 ssh, from any to all machines works using pubkey/password auth. In all cases, on alll machines, hostbased auth fails, as above. > In most cases, problems with hostbased authentication end up being due > to either a typo or an inconsistency between the name claimed by the > client and the name that the server associates with the client's IP > address. everything matches afaict @ client hostname client.DOMAIN.COM hostname -s client hostname -f client.DOMAIN.COM dig A `hostname` +short 192.168.1.65 dig AAAA `hostname` +short xxxx:xxx:xxxx:xxx::65 host 192.168.1.65 65.1.168.192.in-addr.arpa domain name pointer client.DOMAIN.COM. host xxxx:xxx:xxxx:xxx::65 65.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer client.DOMAIN.COM. dig A server.DOMAIN.COM +short 192.168.1.68 dig AAAA server.DOMAIN.COM +short xxxx:xxx:xxxx:xxx::68 host 192.168.1.68 68.1.168.192.in-addr.arpa domain name pointer server.DOMAIN.COM. host xxxx:xxx:xxxx:xxx::68 68.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer server.DOMAIN.COM. host client.DOMAIN.COM client.DOMAIN.COM has address 192.168.1.65 client.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::65 host server.DOMAIN.COM server.DOMAIN.COM has address 192.168.1.68 server.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::68 ssh-keyscan -t ed25519 client.DOMAIN.COM # client.DOMAIN.COM SSH-2.0-OpenSSH_6.7 client.DOMAIN.COM ssh-ed25519 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ssh-keyscan -t ed25519 server.DOMAIN.COM # server.DOMAIN.COM SSH-2.0-OpenSSH_6.7 server.DOMAIN.COM ssh-ed25519 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB @ server hostname server.DOMAIN.COM hostname -s server hostname -f server.DOMAIN.COM dig A `hostname` +short 192.168.1.68 dig AAAA `hostname` +short xxxx:xxx:xxxx:xxx::68 host 192.168.1.68 68.1.168.192.in-addr.arpa domain name pointer server.DOMAIN.COM. host xxxx:xxx:xxxx:xxx::68 68.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer server.DOMAIN.COM. dig A client.DOMAIN.COM +short 192.168.1.65 dig AAAA client.DOMAIN.COM +short xxxx:xxx:xxxx:xxx::65 host 192.168.1.65 65.1.168.192.in-addr.arpa domain name pointer client.DOMAIN.COM. host xxxx:xxx:xxxx:xxx::65 65.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa domain name pointer desk.DOMAIN.COM. host client.DOMAIN.COM client.DOMAIN.COM has address 192.168.1.65 client.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::65 host server.DOMAIN.COM server.DOMAIN.COM has address 192.168.1.68 server.DOMAIN.COM has IPv6 address xxxx:xxx:xxxx:xxx::68 ssh-keyscan -t ed25519 client.DOMAIN.COM # client.DOMAIN.COM SSH-2.0-OpenSSH_6.7 client.DOMAIN.COM ssh-ed25519 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ssh-keyscan -t ed25519 server.DOMAIN.COM # server.DOMAIN.COM SSH-2.0-OpenSSH_6.7 server.DOMAIN.COM ssh-ed25519 BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB From grantksupport at operamail.com Sat Jan 10 09:03:02 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 14:03:02 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <20150109214048.GG5808@linux124.nas.nasa.gov> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> <20150109214048.GG5808@linux124.nas.nasa.gov> Message-ID: <1420840982.2177131.212007993.15D021A2@webmail.messagingengine.com> Hi, On Fri, Jan 9, 2015, at 01:40 PM, Iain Morgan wrote: > So, that indicates that you have a problem with your client setup. Since > you are trying to use ssh from /usr/local/bin, I take it that it is a > local build. As such, some of the files may not be properly located. Yes. Built as ./configure \ --prefix="/usr/local" \ --sysconfdir="/usr/local/etc/ssh" \ --libdir="/usr/local/lib64" \ --with-ssl-dir="/usr/local/ssl" \ --with-md5-passwords \ --with-xauth=/usr/bin/xauth \ --with-pam > You can check the location of the ssh-keysign binary by running strings > on the ssh executable and grep'ing for ssh-keysign. I expect that it > will be /usr/local/libexec/ssh-keysign. Make sure that it is setuid > root. ls -al $( strings `which ssh` | grep ssh-keysign ) -rwsr-xr-x+ 1 root root 459K Oct 11 06:51 /usr/local/libexec/ssh-keysign* > You can then run strings on the ssh-keysign executable and grep for > ssh_host ed25519 to confirm the expected location for the host key. Make > sure that the key can be found in the expected location, and that the > public key is world-readable, but that the private key is readable only > by root. strings /usr/local/libexec/ssh-keysign | grep ssh_host | grep ed25519 /usr/local/etc/ssh/ssh_host_ed25519_key That's NOT the name/location of the key. On the client grep Identity /usr/local/etc/ssh/ssh_config IdentityFile /usr/local/etc/ssh/ssh.client.ed25519 and on the server grep HostKey /usr/local/etc/ssh/sshd_config HostKey /usr/local/etc/ssh/ssh.server.ed25519 As reported above client ls -al /usr/local/etc/ssh/ssh.client.ed25519* -rw-------+ 1 root root 517 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519 -rw-r--r--+ 1 root root 107 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519.pub server ls -al /usr/local/etc/ssh/ssh.server.ed25519* -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519 -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub With pubkey/password these keys work as expected. > Note, if you do not see a reference to ssh_host_ed25519 in the above > strings output, the ssh-keysign executable is from an older distribution > that does not support ED25519. My 'locally installed' openssh is ssh -V OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014 the distro's ssh -- not used by me, but not removable is /usr/bin/ssh -V OpenSSH_6.6.1p1, OpenSSL 1.0.1j-fips 15 Oct 2014 > Given that possibility, you might try adding the ECDSA key for the > client to the ssh_known_hosts file on the server. It already is. From imorgan at nas.nasa.gov Sat Jan 10 09:26:41 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 9 Jan 2015 14:26:41 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420837210.2161618.211987621.0D6709E1@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420837210.2161618.211987621.0D6709E1@webmail.messagingengine.com> Message-ID: <20150109222641.GB29822@linux124.nas.nasa.gov> On Fri, Jan 09, 2015 at 13:00:10 -0800, grantksupport at operamail.com wrote: > Hi > > On Fri, Jan 9, 2015, at 12:34 PM, Mark Hahn wrote: > > >> The one you are missing is EnableSSHKeysign. > > > > I suppose it's worth asking: is your ssh-keysign suid root > > (and are the permissions on your host keys sufficiently tight)? > > Note that everything works correctly with other auth methods: pubkey, password, ... > I suspect key perms issues would've come up there. Not so, only hostbased authentication uses the client's host keys, and it is likewise the only method that uses ssh-keysign. Further, ssh-keysign is only used for non-root users. > > Here's also the ssk-keysign perms > > client > > ls -al /usr/local/libexec/ssh-keysign > -rwsr-xr-x+ 1 root root 459K Oct 11 06:51 /usr/local/libexec/ssh-keysign* > > ls -al /usr/local/etc/ssh/ssh.client.ed25519* > -rw-------+ 1 root root 517 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519 > -rw-r--r--+ 1 root root 107 May 9 2014 /usr/local/etc/ssh/ssh.client.ed25519.pub > Err, those _should_ be ssh_host_ed25519 and ssh_host_ed25519.pub. > > server > > ls -al /usr/local/libexec/ssh-keysign > -rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign* > > ls -al /usr/local/etc/ssh/ssh.server.ed25519* > -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519 > -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub > Renaming the keys in your output only serves to complicate matters for those who are taking time to try to help you. Further, ssh-keysign plays no role on the server and the server's keys are not a factor in the problem you are facing. > > > > ssh-keyscan -t ed25519 server.DOMAIN.COM >> /usr/local/etc/ssh/ssh_known_hosts > > > > fine, though it's worth verifying that these are the files being used > > by the (non-default, right) sshd and ssh (client) that you're using. > > i have > > @ server > > which sshd > /usr/local/sbin/sshd > > systemctl status sshd > sshd.service - OpenSSH Daemon > Loaded: loaded (/etc/systemd/system/sshd.service; enabled) > Active: active (running) since Fri 2015-01-09 12:57:12 PST; 2s ago > Main PID: 21534 (sshd) > CGroup: /system.slice/sshd.service > ?? 4662 sshd: root at pts/0 > ?? 4664 -bash > ??21534 /usr/local/sbin/sshd -D -f /usr/local/etc/ssh/sshd_config > ??21541 systemctl status sshd > > ps ax | grep sshd_config > 20989 ? Ss 0:00 /usr/local/sbin/sshd -D -f /usr/local/etc/ssh/sshd_config > > and > > @ client > > which ssh > /usr/local/bin/ssh > > ssh server.DOMAIN.COM -vvv > ... > debug3: load_hostkeys: loading entries for host "server.DOMAIN.COM" from file "/usr/local/etc/ssh/ssh_known_hosts" > debug3: load_hostkeys: found key type ED25519 in file /usr/local/etc/ssh/ssh_known_hosts:2 > debug3: load_hostkeys: loaded 1 keys > debug3: load_hostkeys: loading entries for host "server.DOMAIN.COM" from file "/usr/local/etc/ssh/ssh_known_hosts" > debug3: load_hostkeys: found key type ED25519 in file /usr/local/etc/ssh/ssh_known_hosts:2 > debug3: load_hostkeys: loaded 1 keys > ... > > > > Permission denied (hostbased). > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From grantksupport at operamail.com Sat Jan 10 09:42:59 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 14:42:59 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <20150109222641.GB29822@linux124.nas.nasa.gov> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420837210.2161618.211987621.0D6709E1@webmail.messagingengine.com> <20150109222641.GB29822@linux124.nas.nasa.gov> Message-ID: <1420843379.2185781.212022017.3202626E@webmail.messagingengine.com> On Fri, Jan 9, 2015, at 02:26 PM, Iain Morgan wrote: > > server > > > > ls -al /usr/local/libexec/ssh-keysign > > -rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign* > > > > ls -al /usr/local/etc/ssh/ssh.server.ed25519* > > -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519 > > -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub > > > > Renaming the keys in your output only serves to complicate matters for > those who are taking time to try to help you. How so? What's being complicated? I haven't renamed anything "in my output". Those are the actual keynames, and locations, that I've been using for years, renewed, as you can see by the date, just last May From grantksupport at operamail.com Sat Jan 10 10:11:58 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 15:11:58 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> <20150109214048.GG5808@linux124.nas.nasa.gov> <1420840982.2177131.212007993.15D021A2@webmail.messagingengine.com> Message-ID: <1420845118.2192508.212030153.53A91C9B@webmail.messagingengine.com> On Fri, Jan 9, 2015, at 03:06 PM, Mark Hahn wrote: > > On the client > > > > grep Identity /usr/local/etc/ssh/ssh_config > > IdentityFile /usr/local/etc/ssh/ssh.client.ed25519 > > shouldn't this be HostKey in sshd_config? > presumably that's what ssh-keysign is looking for, > not a *user* key. That's on the *client*. note that it's in ssh_config cat /usr/local/etc/ssh/ssh_config ... Host * IdentityFile /usr/local/etc/ssh/ssh.client.ed25519 ... On the *server*, in sshd_config it's cat /usr/local/etc/ssh/sshd_config ... HostKey /usr/local/etc/ssh/ssh.server.ed25519 ... From imorgan at nas.nasa.gov Sat Jan 10 10:13:00 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 9 Jan 2015 15:13:00 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420843379.2185781.212022017.3202626E@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420837210.2161618.211987621.0D6709E1@webmail.messagingengine.com> <20150109222641.GB29822@linux124.nas.nasa.gov> <1420843379.2185781.212022017.3202626E@webmail.messagingengine.com> Message-ID: <20150109231300.GH5808@linux124.nas.nasa.gov> On Fri, Jan 09, 2015 at 14:42:59 -0800, grantksupport at operamail.com wrote: > > > On Fri, Jan 9, 2015, at 02:26 PM, Iain Morgan wrote: > > > server > > > > > > ls -al /usr/local/libexec/ssh-keysign > > > -rwsr-xr-x+ 1 root root 455K Oct 11 06:51 /usr/local/libexec/ssh-keysign* > > > > > > ls -al /usr/local/etc/ssh/ssh.server.ed25519* > > > -rw-------+ 1 root root 464 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519 > > > -rw-r--r--+ 1 root root 107 May 10 2014 /usr/local/etc/ssh/ssh.server.ed25519.pub > > > > > > > Renaming the keys in your output only serves to complicate matters for > > those who are taking time to try to help you. > > How so? What's being complicated? I haven't renamed anything "in my output". > > Those are the actual keynames, and locations, that I've been using for years, renewed, as you can see by the date, just last May So, how many barrels do you have in that shotgun pointed at your foot? It looks like you need to read the manual files. While the server permits you to specify the names and locations of the host keys, the client does NOT. The locations are hard-coded into ssh and ssh-keysign at build time; using IdentitryFile does not alter this. As noted before, only hostbased authentication uses the client's host keys, so renaming the keys would not have impacted other authentication methods. -- Iain Morgan From hahn at mcmaster.ca Sat Jan 10 10:15:36 2015 From: hahn at mcmaster.ca (Mark Hahn) Date: Fri, 9 Jan 2015 18:15:36 -0500 (EST) Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420845118.2192508.212030153.53A91C9B@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> <20150109214048.GG5808@linux124.nas.nasa.gov> <1420840982.2177131.212007993.15D021A2@webmail.messagingengine.com> <1420845118.2192508.212030153.53A91C9B@webmail.messagingengine.com> Message-ID: >>> On the client >>> grep Identity /usr/local/etc/ssh/ssh_config >>> IdentityFile /usr/local/etc/ssh/ssh.client.ed25519 >> >> shouldn't this be HostKey in sshd_config? >> presumably that's what ssh-keysign is looking for, >> not a *user* key. > > That's on the *client*. note that it's in ssh_config exactly. how else is ssh-keysign going to know about your non-default (client) host key's location? > cat /usr/local/etc/ssh/ssh_config > ... > Host * > IdentityFile /usr/local/etc/ssh/ssh.client.ed25519 again, IdentityFile is a user key. > On the *server*, in sshd_config it's > > cat /usr/local/etc/ssh/sshd_config > ... > HostKey /usr/local/etc/ssh/ssh.server.ed25519 sure, that's great. the problem is on the client side... regards, mark hahn From grantksupport at operamail.com Sat Jan 10 10:19:52 2015 From: grantksupport at operamail.com (grantksupport at operamail.com) Date: Fri, 09 Jan 2015 15:19:52 -0800 Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <20150109231300.GH5808@linux124.nas.nasa.gov> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420837210.2161618.211987621.0D6709E1@webmail.messagingengine.com> <20150109222641.GB29822@linux124.nas.nasa.gov> <1420843379.2185781.212022017.3202626E@webmail.messagingengine.com> <20150109231300.GH5808@linux124.nas.nasa.gov> Message-ID: <1420845592.2193509.212032525.2CBF1FE8@webmail.messagingengine.com> On Fri, Jan 9, 2015, at 03:13 PM, Iain Morgan wrote: > So, how many barrels do you have in that shotgun pointed at your foot? > > It looks like you need to read the manual files. Well, I'll grant you the onset of the sarcasm and RTFM'ing, and the tired presumption that we didn't, took longer than typical to get to, but like death and taxes, it's a sure thing. Thanks anayway. Moving on. From tim at multitalents.net Sat Jan 10 10:20:35 2015 From: tim at multitalents.net (Tim Rice) Date: Fri, 9 Jan 2015 15:20:35 -0800 (PST) Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> Message-ID: On Fri, 9 Jan 2015, grantksupport at operamail.com wrote: | @client | | as root (as before) | | ssh server.DOMAIN.COM | Permission denied (hostbased). | | instead, as my user, fails differently for some reason, | | ssh server.DOMAIN.COM | ... | no matching hostkey found for key ED25519 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx | ssh_keysign: no reply | key_sign failed | Permission denied (hostbased). I use hostbased auth here extensively and have for years. On my machines here, hostbased does not work as root but does as a regular user. Another thing that has not been mentioned in the thread so far is the need for properly configured DNS when using hostbased. If you nslookup the client does it show a single IP? If you nslookup the IP, does it return the client name? Does the name and IP match what is in ssh_known_hosts on the server? Does the client's entry in the server's ssh_known_hosts file have both the hostname and the FQDN? If you nslookup the server does it show a single IP? If you nslookup the IP, does it return the server name? -- Tim Rice Multitalents tim at multitalents.net From hahn at mcmaster.ca Sat Jan 10 10:25:59 2015 From: hahn at mcmaster.ca (Mark Hahn) Date: Fri, 9 Jan 2015 18:25:59 -0500 (EST) Subject: OpenSSH_6.7p1 hostbased authentication failing on linux->linux connection. what's wrong with my config? In-Reply-To: <2013_1420845394_t09NGXZG012205_alpine.LFD.2.02.1501091813000.10351@coffee.psychology.mcmaster.ca> References: <1420819507.2074118.211863789.0DD4FD38@webmail.messagingengine.com> <20150109193527.GA29822@linux124.nas.nasa.gov> <1420834058.2149303.211963733.3005EA0F@webmail.messagingengine.com> <1420834920.2152656.211976981.35590A13@webmail.messagingengine.com> <20150109214048.GG5808@linux124.nas.nasa.gov> <1420840982.2177131.212007993.15D021A2@webmail.messagingengine.com> <1420845118.2192508.212030153.53A91C9B@webmail.messagingengine.com> <2013_1420845394_t09NGXZG012205_alpine.LFD.2.02.1501091813000.10351@coffee.psychology.mcmaster.ca> Message-ID: >>> shouldn't this be HostKey in sshd_config? apologies, I didn't check the source, and indeed ssh-keysign has the hostkey paths hardcoded. would it be bad if this were runtime-configurable? From dma_k at mail.ru Sun Jan 11 01:10:38 2015 From: dma_k at mail.ru (Dmitry Katsubo) Date: Sat, 10 Jan 2015 15:10:38 +0100 Subject: Variable substitution in UserKnownHostsFile configuration option Message-ID: <54B132DE.4080403@mail.ru> Dear OpenSSH developers, Do you find it a good idea if variable substitution is implemented in UserKnownHostsFile the same way it is done for IdentityFile? In ssh_config I would like to write something like UserKnownHostsFile ~/keys/%r/known_hosts Thanks! -- With best regards, Dmitry From 7cbita+zq3djk at guerrillamail.com Mon Jan 12 19:26:14 2015 From: 7cbita+zq3djk at guerrillamail.com (7cbita+zq3djk at guerrillamail.com) Date: Mon, 12 Jan 2015 08:26:14 +0000 Subject: Passwd vuln, TIOCPKT EXTPROC LINEMODE Readline rlwrap Message-ID: <5562c78f7fae63edc21c3a2901e321b8fc7@guerrillamail.com> http://www.metzdowd.com/pipermail/cryptography/2015-January/024309.html http://lists.gnu.org/archive/html/bug-readline/2011-01/msg00006.html ---- Sent using GuerrillaMail.com Block or report abuse: https://www.guerrillamail.com/abuse/?a=TlFxCx4TS%2FkAhgesvXoaZDTKRMSUwNhEiatQew%3D%3D From openssh at contactdaniel.net Mon Jan 12 20:05:53 2015 From: openssh at contactdaniel.net (Daniel Dent) Date: Mon, 12 Jan 2015 01:05:53 -0800 Subject: questions regarding session establishment in SSH Message-ID: <254C6C6B-D572-41D4-8CD1-A73A17D165EA@contactdaniel.net> Hello, I spent some time today with RFC4253, RFC5056 and the OpenSSH source code and I have a few questions. 1) For authentication methods such as "publickey" that work by providing a signature over a session identifier, is it fair to say that a MITM attacker is unable to use a MITM attack to log in to the server the client meant to log into? The reason I believe that to be the case is that the SSH protocol appears to have both end point and unique channel bindings through its session identifier mechanisms. If that holds true, then if: * publickey authentication is used on a connection, and * a shared secret is available on both the SSH server and the SSH client, which the server will only provide after a user authenticates, and * the SSH server is able to provide the SSH client with the secret, then An SSH client can safely conclude that no MITM attack has occurred. Per my blog post at https://www.danieldent.com/blog/ssh-requires-a-chain-of-trust/, I am looking for an easy way to bring new hosts online and know that the initial connection to them has not been subject to a MITM. I proposed a more complicated approach that could work for any authentication method, but with further analysis I believe that if the authentication method is restricted to ones which leverages channel bindings, then all that is needed is to have a way to load a shared secret onto servers. 2) How was the 16 byte/128 bit size of the cookie in SSH_MSG_KEXINIT chosen? In earlier versions of the protocol, a 16 byte cookie would have had both the client and the server contributing at least as much entropy as the output of the hash function it contributed entropy towards (MD5). But that no longer holds true. Has there been any analysis done on the adequacy of a 16 byte cookie? 3) Regarding section 7.2 of RFC4253: An explanation of how keys are chosen is given, ending with "This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH." The keys described in 7.2 are chosen using the output of hash functions; there is only so much entropy available in the output of those hash functions. If the amount of entropy is less than the key size of the encryption functions, does that not mean that the higher key size is only a dangerous illusion? Thanks, Daniel --- Daniel Dent https://www.danieldent.com/ https://twitter.com/DanielDent https://www.linkedin.com/in/danieldent From hyc at symas.com Mon Jan 12 21:20:10 2015 From: hyc at symas.com (Howard Chu) Date: Mon, 12 Jan 2015 10:20:10 +0000 Subject: Passwd vuln, TIOCPKT EXTPROC LINEMODE Readline rlwrap In-Reply-To: <5562c78f7fae63edc21c3a2901e321b8fc7@guerrillamail.com> References: <5562c78f7fae63edc21c3a2901e321b8fc7@guerrillamail.com> Message-ID: <54B39FDA.7060800@symas.com> 7cbita+zq3djk at guerrillamail.com wrote: > http://www.metzdowd.com/pipermail/cryptography/2015-January/024309.html > http://lists.gnu.org/archive/html/bug-readline/2011-01/msg00006.html Previously mentioned on this list 4-1/2 years ago http://lists.mindrot.org/pipermail/openssh-unix-dev/2010-June/028732.html -- -- 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 Tue Jan 13 06:24:17 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Jan 2015 06:24:17 +1100 (EST) Subject: questions regarding session establishment in SSH In-Reply-To: <254C6C6B-D572-41D4-8CD1-A73A17D165EA@contactdaniel.net> References: <254C6C6B-D572-41D4-8CD1-A73A17D165EA@contactdaniel.net> Message-ID: On Mon, 12 Jan 2015, Daniel Dent wrote: > Hello, > > I spent some time today with RFC4253, RFC5056 and the OpenSSH source > code and I have a few questions. > > 1) For authentication methods such as "publickey" that work by > providing a signature over a session identifier, is it fair to say > that a MITM attacker is unable to use a MITM attack to log in to the > server the client meant to log into? The reason I believe that to be > the case is that the SSH protocol appears to have both end point and > unique channel bindings through its session identifier mechanisms. > > If that holds true, then if: > * publickey authentication is used on a connection, and > * a shared secret is available on both the SSH server and the SSH client, > which the server will only provide after a user authenticates, and > * the SSH server is able to provide the SSH client with the secret, then > > An SSH client can safely conclude that no MITM attack has occurred. Are you talking about a MITM that has a copy of the real target's host key? If not, then the connection is already protected by the server's signature using the hostkey over the session ID. If you are talking about an active MITM with the host key, then they can still succeed by just accepting any host key that the client presents without bothering to check the signature it generated. The channel binding in pubkey auth prevents a MITM from using the client's public key to authenticate to the real host on their behalf. It doesn't provide any guarantee that the host is what they expect, because the client has already accepted that they trust the server by that point in the protocol. > 2) How was the 16 byte/128 bit size of the cookie in SSH_MSG_KEXINIT chosen? You'd have to search the ancient ietf-ssh archives and/or early versions of the internet-drafts for that. > In earlier versions of the protocol, a 16 byte cookie would have had > both the client and the server contributing at least as much entropy > as the output of the hash function it contributed entropy towards > (MD5). But that no longer holds true. Has there been any analysis done > on the adequacy of a 16 byte cookie? Not that I'm aware of, but I don't think it matters. Even 2^128 is infeasible assuming the hash algorithm is sound. > 3) Regarding section 7.2 of RFC4253: > > An explanation of how keys are chosen is given, ending with "This > process will lose entropy if the amount of entropy in K is larger than > the internal state size of HASH." > > The keys described in 7.2 are chosen using the output of hash > functions; there is only so much entropy available in the output of > those hash functions. If the amount of entropy is less than the key > size of the encryption functions, does that not mean that the higher > key size is only a dangerous illusion? It's an illusion but with the smallest hash used being 160 bits and the stretching being performed using a good hash function, it's hardly a dangerous one. -d From sjcjonker at sjc.nl Tue Jan 13 06:39:11 2015 From: sjcjonker at sjc.nl (Stijn Jonker) Date: Mon, 12 Jan 2015 20:39:11 +0100 Subject: Source IP missing in log when no suitable key exchange method found. Message-ID: <64C7CEE6-8DF8-4E5F-A0FB-B3BC1A1D0B7F@sjc.nl> Dear SSH Guru's, Whilst reading the recent "Stribika" article [1] on tweaking the ssh algorithms I decided to mimic this and some other tweaks to my sshd config. Well it did one thing for sure, stopping most SSH brute force / scanners. Besides the normal User xxx from yyy not allowed because not in AllowUsers, or the failures due to public key only the logs are now filled with: Jan 12 20:17:28 <> sshd[8888]: fatal: Unable to negotiate a key exchange method [preauth] Jan 12 20:19:16 <> sshd[8890]: fatal: Unable to negotiate a key exchange method [preauth] So the scanners don't support my selections of algorithms. Which is fine as well, but there is no source IP logged. Now I'm far from proficient in C, but reading correctly this is triggered from kex.c in the function choose_kex, which reading the various calls to this doesn't pass the source IP. This is assumed to be the reason why the IP is not logged, but maybe a good addition nevertheless? Based on my lack of C skills, no patch from myside apologies. Stijn P.S. whether below algorithms make things more secure depends on each persons view / the goals to be achieved. But the lack of source IP is hindering detection and fail2ban like protection. [maint@<> ~]$ sshd -v unknown option -- v OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014 usage: sshd [-46DdeiqTt] [-b bits] [-C connection_spec] [-c host_cert_file] [-E log_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len] [maint@<> ~]$ grep -v -e ^# -e ^$ /etc/ssh/sshd_config Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ed25519_key UsePrivilegeSeparation yes KeyRegenerationInterval 600 ServerKeyBits 2048 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin no StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no PasswordAuthentication no X11Forwarding no X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes MaxStartups 10:30:60 Banner /etc/issue.net DebianBanner no UseDNS no AllowTcpForwarding no GatewayPorts no AllowUsers <> AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes AuthenticationMethods publickey KexAlgorithms curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-ripemd160-etm at openssh.com,umac-128-etm at openssh.com [1] https://stribika.github.io/2015/01/04/secure-secure-shell.html -- Yours Sincerely / Met Vriendelijke groet, Stijn Jonker SJCJonker at SJC.nl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1495 bytes Desc: OpenPGP digital signature URL: From trey.henefield at ultra-ats.com Fri Jan 16 02:29:18 2015 From: trey.henefield at ultra-ats.com (Trey Henefield) Date: Thu, 15 Jan 2015 15:29:18 +0000 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... Message-ID: Greetings, I discovered an issue in the latest version of SSH, where the number of password prompts are doubled. If I specify 1, I get 2, and so on. Best regards, Trey Henefield, CISSP Senior IAVA Engineer Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA Trey.Henefield at ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450 www.ultra-ats.com Disclaimer The information contained in this communication from trey.henefield at ultra-ats.com sent at 2015-01-15 10:29:26 is confidential and may be legally privileged. It is intended solely for use by openssh-unix-dev at mindrot.org and others authorized to receive it. If you are not openssh-unix-dev at mindrot.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. From imorgan at nas.nasa.gov Fri Jan 16 05:53:29 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 15 Jan 2015 10:53:29 -0800 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: Message-ID: <20150115185329.GC29822@linux124.nas.nasa.gov> On Thu, Jan 15, 2015 at 15:29:18 +0000, Trey Henefield wrote: > Greetings, > > I discovered an issue in the latest version of SSH, where the number of password prompts are doubled. If I specify 1, I get 2, and so on. > Could you give a bit more detail? I just tried with 6.7p1 and got the expected number of password prompts. Are the prompts all identical? Perhaps you have both PasswordAuthentication and ChallengeResponseAuthentication enabled, or perhaps the multiple prompts are due to your PAM configuration if you are using ChallengeResponseAuthentication? -- Iain Morgan From keisial at gmail.com Fri Jan 16 06:27:39 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 15 Jan 2015 20:27:39 +0100 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: Message-ID: <54B814AB.2050303@gmail.com> On 15/01/15 16:29, Trey Henefield wrote: > Greetings, > > I discovered an issue in the latest version of SSH, where the number of password prompts are doubled. If I specify 1, I get 2, and so on. NumberOfPasswordPrompts is a client option. And it is working fine here on 6.7p1: Running ssh -vvv -o NumberOfPasswordPrompts=1 testmachine, I only get asked for a password once, then disconnect. Could you send us the output of such command on your tests? (there isn't anything specially sensitive there, but feel free to obscure any data you son't feel comfortable sharing, such as your username, host name or key ids...) Note that at the server side, the option is called MaxAuthTries, and works differently, counting authentication attempts of any kind. > For OpenSSH, the server does not specifically constrain the number of > pasword authentication attempts. MaxAuthTries (default is 6) is the > maximum number of authentication attempts (of any sort) per connection. -- Ian Morgan last February on "Issue With SSHD Password Guesses" thread From trey.henefield at ultra-ats.com Fri Jan 16 07:47:33 2015 From: trey.henefield at ultra-ats.com (Trey Henefield) Date: Thu, 15 Jan 2015 20:47:33 +0000 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: <54B814AB.2050303@gmail.com> References: <54B814AB.2050303@gmail.com> Message-ID: So it appears that I am getting a keyboard-interactive prompt and then a password prompt. Here is the output of the requested command: ssh -vvv -o NumberOfPasswordPrompts=1 -t root at 10.10.2.51 OpenSSH_6.7p1, OpenSSL 1.0.1k-fips 8 Jan 2015 debug1: Reading configuration data /cygdrive/c/progra~1/OpenSSH/etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 10.10.2.51 [10.10.2.51] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7 debug1: match: OpenSSH_6.7 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "10.10.2.51" from file "/.ssh/kn own_hosts" debug3: load_hostkeys: found key type ED25519 in file /.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-ed25519-cert-v01 at openssh.com, ssh-ed25519 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh- sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hel lman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sh a2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa- sha2-nistp521-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 @openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ecdsa-sha 2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.c om,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,arcfour256,arcfour128,ae s128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndae l-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.c om,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,arcfour256,arcfour128,ae s128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndae l-cbc at lysator.liu.se debug2: kex_parse_kexinit: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac -sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.co m,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 ,hmac-md5-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openss h.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh .com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac -sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.co m,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 ,hmac-md5-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openss h.com,hmac-md5-96-etm at openssh.com,hmac-md5,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: curve25519-sha256 at libssh.org,diffie-hellman-group-exc hange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ssh-ed25519 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-sha1 debug2: kex_parse_kexinit: hmac-sha1 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: setup hmac-sha1 debug1: kex: server->client aes128-ctr hmac-sha1 none debug2: mac_setup: setup hmac-sha1 debug1: kex: client->server aes128-ctr hmac-sha1 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ED25519 17:99:91:c2:9d:f4:9a:6c:b3:ab:50:c5:e8:eb:a3:70 debug3: load_hostkeys: loading entries for host "10.10.2.51" from file "/.ssh/kn own_hosts" debug3: load_hostkeys: found key type ED25519 in file /.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host '10.10.2.51' is known and matches the ED25519 host key. debug1: Found key in /.ssh/known_hosts:1 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: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/id_rsa (0x0), debug2: key: /.ssh/id_dsa (0x0), debug2: key: /.ssh/id_ecdsa (0x0), debug2: key: /.ssh/id_ed25519 (0x0), debug3: input_userauth_banner You are accessing a U.S. Government (USG) Information System (IS) that is provid ed for USG-authorized use only. By using this IS (which includes any device atta ched to this IS), you consent to the following conditions: - The USG routinely intercepts and monitors communications on this IS for purpos es including, but not limited to, penetration testing, COMSEC monitoring, networ k operations and defense, personnel misconduct (PM), law enforcement (LE), and c ounterintelligence (CI) investigations. - At any time, the USG may inspect and seize data stored on this IS. - Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used fo r any USG-authorized purpose. - This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. - Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged commun ications, or work product, related to personal representation or services by att orneys, psychotherapists, or clergy, and their assistants. Such communications a nd work product are private and confidential. See User Agreement for details. debug1: Authentications that can continue: publickey,password,keyboard-interacti ve debug3: start over, passed a different list publickey,password,keyboard-interact ive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/id_rsa debug3: no such identity: /.ssh/id_rsa: No such file or directory debug1: Trying private key: /.ssh/id_dsa debug3: no such identity: /.ssh/id_dsa: No such file or directory debug1: Trying private key: /.ssh/id_ecdsa debug3: no such identity: /.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /.ssh/id_ed25519 debug3: no such identity: /.ssh/id_ed25519: No such file or directory 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: debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password root at 10.10.2.51's password: debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,password,keyboard-interactive). In the above output, the first prompt is "Password:". The second prompt is "root at 10.10.2.51's password:" Best regards, Trey Henefield, CISSP Senior IAVA Engineer Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA Trey.Henefield at ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450 www.ultra-ats.com -----Original Message----- From: ?ngel Gonz?lez [mailto:keisial at gmail.com] Sent: Thursday, January 15, 2015 1:28 PM To: Trey Henefield Cc: openssh-unix-dev at mindrot.org Subject: Re: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... On 15/01/15 16:29, Trey Henefield wrote: > Greetings, > > I discovered an issue in the latest version of SSH, where the number of password prompts are doubled. If I specify 1, I get 2, and so on. NumberOfPasswordPrompts is a client option. And it is working fine here on 6.7p1: Running ssh -vvv -o NumberOfPasswordPrompts=1 testmachine, I only get asked for a password once, then disconnect. Could you send us the output of such command on your tests? (there isn't anything specially sensitive there, but feel free to obscure any data you son't feel comfortable sharing, such as your username, host name or key ids...) Note that at the server side, the option is called MaxAuthTries, and works differently, counting authentication attempts of any kind. > For OpenSSH, the server does not specifically constrain the number of > pasword authentication attempts. MaxAuthTries (default is 6) is the > maximum number of authentication attempts (of any sort) per connection. -- Ian Morgan last February on "Issue With SSHD Password Guesses" thread Disclaimer The information contained in this communication from trey.henefield at ultra-ats.com sent at 2015-01-15 15:47:41 is confidential and may be legally privileged. It is intended solely for use by openssh-unix-dev at mindrot.org and others authorized to receive it. If you are not openssh-unix-dev at mindrot.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. From trey.henefield at ultra-ats.com Fri Jan 16 07:53:39 2015 From: trey.henefield at ultra-ats.com (Trey Henefield) Date: Thu, 15 Jan 2015 20:53:39 +0000 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: <20150115185329.GC29822@linux124.nas.nasa.gov> References: <20150115185329.GC29822@linux124.nas.nasa.gov> Message-ID: I have tried giving the options " ChallengeResponseAuthentication=no" and "KbdInteractiveAuthentication=no", with no change in behavior. I did try " PasswordAuthentication=no" and that did remove the second prompt, but password authentication is what I am trying to achieve. I am also using PAM via "UsePAM=yes" option. Best regards, Trey Henefield, CISSP Senior IAVA Engineer Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA Trey.Henefield at ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450 www.ultra-ats.com -----Original Message----- From: Iain Morgan [mailto:imorgan at nas.nasa.gov] Sent: Thursday, January 15, 2015 12:53 PM To: Trey Henefield Cc: openssh-unix-dev at mindrot.org Subject: Re: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... On Thu, Jan 15, 2015 at 15:29:18 +0000, Trey Henefield wrote: > Greetings, > > I discovered an issue in the latest version of SSH, where the number of password prompts are doubled. If I specify 1, I get 2, and so on. > Could you give a bit more detail? I just tried with 6.7p1 and got the expected number of password prompts. Are the prompts all identical? Perhaps you have both PasswordAuthentication and ChallengeResponseAuthentication enabled, or perhaps the multiple prompts are due to your PAM configuration if you are using ChallengeResponseAuthentication? -- Iain Morgan Disclaimer The information contained in this communication from trey.henefield at ultra-ats.com sent at 2015-01-15 15:53:46 is confidential and may be legally privileged. It is intended solely for use by openssh-unix-dev at mindrot.org and others authorized to receive it. If you are not openssh-unix-dev at mindrot.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. From dkg at fifthhorseman.net Fri Jan 16 08:57:59 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 15 Jan 2015 16:57:59 -0500 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: <54B814AB.2050303@gmail.com> Message-ID: <87sifb1zbs.fsf@alice.fifthhorseman.net> On Thu 2015-01-15 15:47:33 -0500, Trey Henefield wrote: > 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: > debug1: Authentications that can continue: publickey,password,keyboard-interactive > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > root at 10.10.2.51's password: > debug2: we sent a password packet, wait for reply > debug1: Authentications that can continue: publickey,password,keyboard-interactive > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey,password,keyboard-interactive). > > > In the above output, the first prompt is "Password:". The second prompt is "root at 10.10.2.51's password:" The first prompt is a keyboard-interactive prompt; the second prompt is the password prompt. please try again with -oKbdInteractiveAuthentication=no Regards, --dkg PS if possible, you should probably avoid using password authentication for the root account anyway, but that's a sideline to the issue you're seeing here. From imorgan at nas.nasa.gov Fri Jan 16 09:26:07 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 15 Jan 2015 14:26:07 -0800 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: <20150115185329.GC29822@linux124.nas.nasa.gov> Message-ID: <20150115222607.GS5808@linux124.nas.nasa.gov> On Thu, Jan 15, 2015 at 20:53:39 +0000, Trey Henefield wrote: > I have tried giving the options " ChallengeResponseAuthentication=no" and "KbdInteractiveAuthentication=no", with no change in behavior. > > I did try " PasswordAuthentication=no" and that did remove the second prompt, but password authentication is what I am trying to achieve. I am also using PAM via "UsePAM=yes" option. > As already noted on the list, the "Password:" prompt is due to keyboard-interactive authentication, whereas the '@'s password:' prompt is due to password authentication. In most cases, you only want to have one of these authentication methods enabled. So, using "-oKbdInteractiveAuthentication=no" should have addressed your issue. What pormpts did you get in that case? -- Iain Morgan From trey.henefield at ultra-ats.com Fri Jan 16 09:54:20 2015 From: trey.henefield at ultra-ats.com (Trey Henefield) Date: Thu, 15 Jan 2015 22:54:20 +0000 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: <87sifb1zbs.fsf@alice.fifthhorseman.net> References: <54B814AB.2050303@gmail.com> , <87sifb1zbs.fsf@alice.fifthhorseman.net> Message-ID: Yes, I have tried that option with no difference in behavior. It seems it ignores that option when provided. Just for reference, I am building it on RedHat 5. I have never had this issue on any previous version of OpenSSH. I use the default configuration with only the changes specified in the RHEL 5 STIG applied. I appreciate the security advice. The root account was indicated simply as an anonymous indicator. I do have PermitRootLogin=no applied. But this same issue is present regardless of the account provided. Best regards, Trey Henefield, CISSP Senior IAVA Engineer Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA Trey.Henefield at ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450 www.ultra-ats.com -----Original Message----- From: Daniel Kahn Gillmor [dkg at fifthhorseman.net] Received: Thursday, 15 Jan 2015, 4:03PM To: Trey Henefield [trey.henefield at ultra-ats.com]; ?ngel Gonz?lez [keisial at gmail.com] CC: openssh-unix-dev at mindrot.org [openssh-unix-dev at mindrot.org] Subject: RE: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... On Thu 2015-01-15 15:47:33 -0500, Trey Henefield wrote: > 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: > debug1: Authentications that can continue: publickey,password,keyboard-interactive > debug2: we did not send a packet, disable method > debug3: authmethod_lookup password > debug3: remaining preferred: > debug3: authmethod_is_enabled password > debug1: Next authentication method: password > root at 10.10.2.51's password: > debug2: we sent a password packet, wait for reply > debug1: Authentications that can continue: publickey,password,keyboard-interactive > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey,password,keyboard-interactive). > > > In the above output, the first prompt is "Password:". The second prompt is "root at 10.10.2.51's password:" The first prompt is a keyboard-interactive prompt; the second prompt is the password prompt. please try again with -oKbdInteractiveAuthentication=no Regards, --dkg PS if possible, you should probably avoid using password authentication for the root account anyway, but that's a sideline to the issue you're seeing here. Disclaimer The information contained in this communication from trey.henefield at ultra-ats.com sent at 2015-01-15 17:54:25 is confidential and may be legally privileged. It is intended solely for use by openssh-unix-dev at mindrot.org and others authorized to receive it. If you are not openssh-unix-dev at mindrot.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. From dkg at fifthhorseman.net Fri Jan 16 11:46:44 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 15 Jan 2015 19:46:44 -0500 Subject: Variable substitution in UserKnownHostsFile configuration option In-Reply-To: <54B132DE.4080403@mail.ru> References: <54B132DE.4080403@mail.ru> Message-ID: <87zj9jzh57.fsf@alice.fifthhorseman.net> On Sat 2015-01-10 09:10:38 -0500, Dmitry Katsubo wrote: > Do you find it a good idea if variable substitution is implemented in > UserKnownHostsFile the same way it is done for IdentityFile? In > ssh_config I would like to write something like > > UserKnownHostsFile ~/keys/%r/known_hosts %r is the remote username, right? so this would be useful if you wanted a different known_hosts file for example.net depending on whether you were logging in as foo at example.net or bar at example.net. is that right? if so, it seems like a pretty strange use case. can you come up with a better rationale for the variable substitution? In the abstract, it seems like a reasonable suggestion, but the specific example you're offering isn't particularly compelling. --dkg From nkadel at gmail.com Fri Jan 16 17:21:42 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 16 Jan 2015 01:21:42 -0500 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: <54B814AB.2050303@gmail.com> <87sifb1zbs.fsf@alice.fifthhorseman.net> Message-ID: On Thu, Jan 15, 2015 at 5:54 PM, Trey Henefield wrote: > Yes, I have tried that option with no difference in behavior. It seems it ignores that option when provided. Just for reference, I am building it on RedHat 5. I have never had this issue on any previous version of OpenSSH. I use the default configuration with only the changes specified in the RHEL 5 STIG applied. RHEL 5 is now 2 major releases behind and was released roughly 7 years ago. Time to update, I think, there have been a *lot* of significant security and architecture changes that can affect the toolchain used to build recent versions of OpenSSH. > I appreciate the security advice. The root account was indicated simply as an anonymous indicator. I do have PermitRootLogin=no applied. But this same issue is present regardless of the account provided. > > > Best regards, > > > Trey Henefield, CISSP > Senior IAVA Engineer > > Ultra Electronics > Advanced Tactical Systems, Inc. > 4101 Smith School Road > Building IV, Suite 100 > Austin, TX 78744 USA > > Trey.Henefield at ultra-ats.com > Tel: +1 512 327 6795 ext. 647 > Fax: +1 512 327 8043 > Mobile: +1 512 541 6450 > > www.ultra-ats.com > > -----Original Message----- > From: Daniel Kahn Gillmor [dkg at fifthhorseman.net] > Received: Thursday, 15 Jan 2015, 4:03PM > To: Trey Henefield [trey.henefield at ultra-ats.com]; ?ngel Gonz?lez [keisial at gmail.com] > CC: openssh-unix-dev at mindrot.org [openssh-unix-dev at mindrot.org] > Subject: RE: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... > > On Thu 2015-01-15 15:47:33 -0500, Trey Henefield wrote: >> 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: >> debug1: Authentications that can continue: publickey,password,keyboard-interactive >> debug2: we did not send a packet, disable method >> debug3: authmethod_lookup password >> debug3: remaining preferred: >> debug3: authmethod_is_enabled password >> debug1: Next authentication method: password >> root at 10.10.2.51's password: >> debug2: we sent a password packet, wait for reply >> debug1: Authentications that can continue: publickey,password,keyboard-interactive >> debug2: we did not send a packet, disable method >> debug1: No more authentication methods to try. >> Permission denied (publickey,password,keyboard-interactive). >> >> >> In the above output, the first prompt is "Password:". The second prompt is "root at 10.10.2.51's password:" > > The first prompt is a keyboard-interactive prompt; the second prompt is > the password prompt. please try again with > -oKbdInteractiveAuthentication=no > > Regards, > > --dkg > > PS if possible, you should probably avoid using password authentication > for the root account anyway, but that's a sideline to the issue you're > seeing here. > > Disclaimer > The information contained in this communication from trey.henefield at ultra-ats.com sent at 2015-01-15 17:54:25 is confidential and may be legally privileged. > It is intended solely for use by openssh-unix-dev at mindrot.org and others authorized to receive it. If you are not openssh-unix-dev at mindrot.org you are hereby notified that > any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From david6666666 at hotmail.com Fri Jan 16 17:51:28 2015 From: david6666666 at hotmail.com (David .) Date: Fri, 16 Jan 2015 17:51:28 +1100 Subject: Solaris 10 + OpenSSH locale settings Message-ID: Hi, I am using OpenSSH 6.6p1 on Solaris 10. My question is in regards to locale setup. It doesn't appear to be acknowledging the locale variables located in /etc/default/init Besides user profiles, where does OpenSSH obtain the default LANG/LC* variables from by default? and does it acknowledge the locale settings we placed into /etc/default/init file? Regards From martin at oneiros.de Sat Jan 17 05:06:35 2015 From: martin at oneiros.de (=?UTF-8?Q?Martin_Schr=C3=B6der?=) Date: Fri, 16 Jan 2015 19:06:35 +0100 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: <54B814AB.2050303@gmail.com> <87sifb1zbs.fsf@alice.fifthhorseman.net> Message-ID: 2015-01-16 7:21 GMT+01:00 Nico Kadel-Garcia : > RHEL 5 is now 2 major releases behind and was released roughly 7 years > ago. Time to update, I think, there have been a *lot* of significant > security and architecture changes that can affect the toolchain used > to build recent versions of OpenSSH. 5.11 was release last September. :-) But: When you pay for RHEL, you should use the RH packages. Best Martin From scott_n at xypro.com Sat Jan 17 06:33:05 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 16 Jan 2015 19:33:05 +0000 Subject: "make tests" in a cross-compile build? Message-ID: How is "make tests" handled in a cross compilation build? Assuming that make exists on the target (but not the compilers), can we just bring over the test subdirectory, makefiles, and executables and run "make tests" there? Does anyone have suggestions? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | From nkadel at gmail.com Sat Jan 17 10:58:22 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 16 Jan 2015 18:58:22 -0500 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: <54B814AB.2050303@gmail.com> <87sifb1zbs.fsf@alice.fifthhorseman.net> Message-ID: On Fri, Jan 16, 2015 at 1:06 PM, Martin Schr?der wrote: > 2015-01-16 7:21 GMT+01:00 Nico Kadel-Garcia : >> RHEL 5 is now 2 major releases behind and was released roughly 7 years >> ago. Time to update, I think, there have been a *lot* of significant >> security and architecture changes that can affect the toolchain used >> to build recent versions of OpenSSH. > > 5.11 was release last September. :-) Yeah, but I'd call that a minor release. RHEL 7 has been out since June of 2014. > But: When you pay for RHEL, you should use the RH packages. And if you need major feature updates, like those between OpenSSH 4.3 (the RHEL 5 standard) and OpenSSH 5.3 (the RHEL 6 standard version) and OpenSSH 6.4 (the RHEL 7 version), well, eventually, backporting becomes infeasible. The big problem with the current OpenSSH 6.7p1 release and RHEL 5 is the out of date OpenSSL library. There are some fascinating checks for the version number that reject the OpenSSL in RHEL 5, even if it's the RHEL version with various useful patches backported by Red Hat. The work of resolving that sort of dependency accumulates, and eventually become *much* easier just to update the OS rather than maintain the patches and build trees. Been there, done that, publish at https://github.com/nkadel/. From dma_k at mail.ru Sun Jan 18 12:24:38 2015 From: dma_k at mail.ru (Dmitry Katsubo) Date: Sun, 18 Jan 2015 02:24:38 +0100 Subject: Variable substitution in UserKnownHostsFile configuration option In-Reply-To: <87zj9jzh57.fsf@alice.fifthhorseman.net> References: <54B132DE.4080403@mail.ru> <87zj9jzh57.fsf@alice.fifthhorseman.net> Message-ID: <54BB0B56.1000307@mail.ru> On 16/01/2015 01:46, Daniel Kahn Gillmor wrote: > %r is the remote username, right? so this would be useful if you wanted > a different known_hosts file for example.net depending on whether you > were logging in as foo at example.net or bar at example.net. is that right? > if so, it seems like a pretty strange use case. can you come up with a > better rationale for the variable substitution? > > In the abstract, it seems like a reasonable suggestion, but the specific > example you're offering isn't particularly compelling. I agree, this feature usecase sounds a bit weird. In my case I am using OpenSSH compiled with Cygwin for Win32 and I need to specify in etc/ssh_config something like this: UserKnownHostsFile /cygdrive/c/Users/%u/.ssh/known_hosts Currently I can only specify the location of IdentityFile. -- With best regards, Dmitry From djm at mindrot.org Mon Jan 19 01:31:37 2015 From: djm at mindrot.org (Damien Miller) Date: Mon, 19 Jan 2015 01:31:37 +1100 (EST) Subject: Variable substitution in UserKnownHostsFile configuration option In-Reply-To: <54BB0B56.1000307@mail.ru> References: <54B132DE.4080403@mail.ru> <87zj9jzh57.fsf@alice.fifthhorseman.net> <54BB0B56.1000307@mail.ru> Message-ID: On Sun, 18 Jan 2015, Dmitry Katsubo wrote: > I agree, this feature usecase sounds a bit weird. In my case I am using > OpenSSH compiled with Cygwin for Win32 and I need to specify in > etc/ssh_config something like this: > > UserKnownHostsFile /cygdrive/c/Users/%u/.ssh/known_hosts Is that not what cygwin already considers your home directory? -d From trey.henefield at ultra-ats.com Wed Jan 21 00:04:40 2015 From: trey.henefield at ultra-ats.com (Trey Henefield) Date: Tue, 20 Jan 2015 13:04:40 +0000 Subject: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... In-Reply-To: References: <54B814AB.2050303@gmail.com> <87sifb1zbs.fsf@alice.fifthhorseman.net> Message-ID: So I have sorted it out now. It turns out that defining "UsePAM yes" was causing the keyboard-interactive mode to occur. The odd thing was that defining "-o KbdInteractiveAuthentication=no" had no effect, although it did not produce an error either meaning it accepted the parameter provided. In the end, I was able to keep the UsePAM option and remove the keyboard-interactive prompt by explicitly defining the authentication methods with "-o PreferredAuthentications=password". Best regards, Trey Henefield, CISSP Senior IAVA Engineer Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA Trey.Henefield at ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450 www.ultra-ats.com -----Original Message----- From: Nico Kadel-Garcia [mailto:nkadel at gmail.com] Sent: Friday, January 16, 2015 12:22 AM To: Trey Henefield Cc: keisial at gmail.com; dkg at fifthhorseman.net; openssh-unix-dev at mindrot.org Subject: Re: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... On Thu, Jan 15, 2015 at 5:54 PM, Trey Henefield wrote: > Yes, I have tried that option with no difference in behavior. It seems it ignores that option when provided. Just for reference, I am building it on RedHat 5. I have never had this issue on any previous version of OpenSSH. I use the default configuration with only the changes specified in the RHEL 5 STIG applied. RHEL 5 is now 2 major releases behind and was released roughly 7 years ago. Time to update, I think, there have been a *lot* of significant security and architecture changes that can affect the toolchain used to build recent versions of OpenSSH. > I appreciate the security advice. The root account was indicated simply as an anonymous indicator. I do have PermitRootLogin=no applied. But this same issue is present regardless of the account provided. > > > Best regards, > > > Trey Henefield, CISSP > Senior IAVA Engineer > > Ultra Electronics > Advanced Tactical Systems, Inc. > 4101 Smith School Road > Building IV, Suite 100 > Austin, TX 78744 USA > > Trey.Henefield at ultra-ats.com > Tel: +1 512 327 6795 ext. 647 > Fax: +1 512 327 8043 > Mobile: +1 512 541 6450 > > www.ultra-ats.com > > -----Original Message----- > From: Daniel Kahn Gillmor [dkg at fifthhorseman.net] > Received: Thursday, 15 Jan 2015, 4:03PM > To: Trey Henefield [trey.henefield at ultra-ats.com]; ?ngel Gonz?lez > [keisial at gmail.com] > CC: openssh-unix-dev at mindrot.org [openssh-unix-dev at mindrot.org] > Subject: RE: OpenSSH v6.7 & NumberOfPasswordPrompts Option ... > > On Thu 2015-01-15 15:47:33 -0500, Trey Henefield wrote: >> 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: >> debug1: Authentications that can continue: >> publickey,password,keyboard-interactive >> debug2: we did not send a packet, disable method >> debug3: authmethod_lookup password >> debug3: remaining preferred: >> debug3: authmethod_is_enabled password >> debug1: Next authentication method: password root at 10.10.2.51's >> password: >> debug2: we sent a password packet, wait for reply >> debug1: Authentications that can continue: >> publickey,password,keyboard-interactive >> debug2: we did not send a packet, disable method >> debug1: No more authentication methods to try. >> Permission denied (publickey,password,keyboard-interactive). >> >> >> In the above output, the first prompt is "Password:". The second prompt is "root at 10.10.2.51's password:" > > The first prompt is a keyboard-interactive prompt; the second prompt > is the password prompt. please try again with > -oKbdInteractiveAuthentication=no > > Regards, > > --dkg > > PS if possible, you should probably avoid using password > authentication for the root account anyway, but that's a sideline to > the issue you're seeing here. > > Disclaimer > The information contained in this communication from trey.henefield at ultra-ats.com sent at 2015-01-15 17:54:25 is confidential and may be legally privileged. > It is intended solely for use by openssh-unix-dev at mindrot.org and > others authorized to receive it. If you are not openssh-unix-dev at mindrot.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From imorgan at nas.nasa.gov Wed Jan 21 08:42:15 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 20 Jan 2015 13:42:15 -0800 Subject: out-of-date snapshots Message-ID: <20150120214215.GD29822@linux124.nas.nasa.gov> Hi, The snapshots at: http://www.mindrot.org/openssh_snap/ appear to be quite out of date. Recent additions, such as FingerprintHash and HostbasedAcceptedKeyTypes, are completely missing. I suspect that the snapshots have not been updating correctly since the transition to using git. -- Iain Morgan From djm at mindrot.org Wed Jan 21 12:33:43 2015 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 Jan 2015 12:33:43 +1100 (EST) Subject: out-of-date snapshots In-Reply-To: <20150120214215.GD29822@linux124.nas.nasa.gov> References: <20150120214215.GD29822@linux124.nas.nasa.gov> Message-ID: On Tue, 20 Jan 2015, Iain Morgan wrote: > Hi, > > The snapshots at: > > http://www.mindrot.org/openssh_snap/ > > appear to be quite out of date. Recent additions, such as > FingerprintHash and HostbasedAcceptedKeyTypes, are completely missing. I > suspect that the snapshots have not been updating correctly since the > transition to using git. oops - thanks. Should be fixed now. -d From dkg at fifthhorseman.net Wed Jan 21 15:05:46 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Jan 2015 23:05:46 -0500 Subject: Factorization of a 768-bit RSA modulus In-Reply-To: <54AE90F8.6020201@azet.sk> References: <54AE90F8.6020201@azet.sk> Message-ID: <87iog0u6at.fsf@alice.fifthhorseman.net> On Thu 2015-01-08 09:15:20 -0500, Fedor Brunner wrote: > ssh-keygen.c contains condition > > else if (type != KEY_ECDSA && type != KEY_ED25519 && *bitsp < 768) > fatal("Key must at least be 768 bits"); > > Please increase the minimal RSA key length. > > > https://eprint.iacr.org/2010/006 > This paper reports on the factorization of the 768-bit number RSA-768 by > the number field sieve factoring method This seems to still be the case: https://anongit.mindrot.org/openssh.git/tree/ssh-keygen.c#n216 a minimum of 1024 bits would still be low, but it would be better than 768. Arguably, modern SSH clients and servers shouldn't even accept 768-bit keys, let alone generate them. Is there interest upstream in raising this floor? --dkg From jason.vas.dias at gmail.com Thu Jan 22 02:36:05 2015 From: jason.vas.dias at gmail.com (Jason Vas Dias) Date: Wed, 21 Jan 2015 15:36:05 +0000 Subject: way to set shell used for remote commands? Message-ID: Good day - Please can OpenSSH provide some way of specifying which shell to use to execute commands on a host. For the account I need to use, the user's password shell is not acceptable, (a ten year old version of bash 3.0) and cannot be changed without weeks or months of burocracy , if at all. I built & installed the latest bash under that account, in the ~/bin directory, but SSH will not use it. Using the client OpenSSH version : 1:6.6p1-2ubuntu2 on a linux x86_64 Ubuntu 14.04.1 host, if I try to specify which bash to use for an SSH command like : $ ssh $account /home/${user}/bin/bash -c 'echo $BASH_VERSION; echo $BASH_VERSION'; something very weird happens - only the second statement produces any output . If this is changed, we see only the first statement is run by the new shell, and the second is run by the old shell: $ ssh $account /home/${user}/bin/bash -c \ 'set | grep BASH_VERSION; echo $BASH_VERSION' Produces the output: BASH_VERSION='4.3.30(1)-release' 3.0.0(1)-release So the first statement is run by the new shell, and the second by the old shell. This appears to be a major bug in OpenSSH - should I report it ? Since OpenSSH provides no way to run commands with anything other than the user's password shell, it really needs to do so. A simple patch would be to session.c, @ line 1746 : /* * Get the shell from the password data. An empty shell field is * legal, and means /bin/sh. */ shell = (pw->pw_shell[0] == 0) ? _PATH_BSHELL : pw->pw_shell; One could do something like: char *sh; if ( (sh=getenv("SSH_SHELL") )!= NULL ) shell = sh; else shell = (pw->pw_shell[0] == 0) ? _PATH_BSHELL : pw->pw_shell; Or provide some configuration option - this would probably have to be per-server . Is there any hope of getting the ability to specify which shell to run remote commands with in a forthcoming OpenSSH release, or do I need to apply my patch and maintain my own OpenSSH branch ? Thanks & Regards, Jason From naddy at mips.inka.de Thu Jan 22 04:19:02 2015 From: naddy at mips.inka.de (Christian Weisgerber) Date: Wed, 21 Jan 2015 17:19:02 +0000 (UTC) Subject: way to set shell used for remote commands? References: Message-ID: On 2015-01-21, Jason Vas Dias wrote: > Please can OpenSSH provide some way of specifying which shell to use to > execute commands on a host. No way. The security fallout is staggering. > For the account I need to use, the user's password shell is not acceptable, > (a ten year old version of bash 3.0) > and cannot be changed without weeks or months of burocracy , if at all. Oh, but you could install a new sshd there? > I built & installed the latest bash under that account, in the ~/bin directory, > but SSH will not use it. ---- ~/.profile ---> case $BASH_VERSION in 3.*) exec ~/bin/bash -l ;; esac <------------------- You can build something similar with ~/.bashrc for non-login shells. > Using the client OpenSSH version : 1:6.6p1-2ubuntu2 on a linux x86_64 > Ubuntu 14.04.1 host, > if I try to specify which bash to use for an SSH command like : > $ ssh $account /home/${user}/bin/bash -c 'echo $BASH_VERSION; echo > $BASH_VERSION'; > something very weird happens - only the second statement produces any > output . Insufficient quoting. $ ssh $account "/home/${user}/bin/bash -c 'echo \$BASH_VERSION; echo \$BASH_VERSION'" -- Christian "naddy" Weisgerber naddy at mips.inka.de From alex at alex.org.uk Thu Jan 22 04:29:00 2015 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 21 Jan 2015 17:29:00 +0000 Subject: way to set shell used for remote commands? In-Reply-To: References: Message-ID: On 21 Jan 2015, at 15:36, Jason Vas Dias wrote: > Please can OpenSSH provide some way of specifying which shell to use to > execute commands on a host. Using dash as an example of another shell: ssh 127.0.0.1 -t dash and ssh 127.0.0.1 dash -c env appear to do the expected for me. -- Alex Bligh From imorgan at nas.nasa.gov Thu Jan 22 06:26:52 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 21 Jan 2015 11:26:52 -0800 Subject: way to set shell used for remote commands? In-Reply-To: References: Message-ID: <20150121192652.GE29822@linux124.nas.nasa.gov> On Wed, Jan 21, 2015 at 17:29:00 +0000, Alex Bligh wrote: > > On 21 Jan 2015, at 15:36, Jason Vas Dias wrote: > > > Please can OpenSSH provide some way of specifying which shell to use to > > execute commands on a host. > > Using dash as an example of another shell: > > ssh 127.0.0.1 -t dash > > and > > ssh 127.0.0.1 dash -c env > > appear to do the expected for me. > Two years ago, I opened a bug to add support for a ForceShell option to sshd that would provide the ability to override users shells. There doesn't seem to have been much interest in it, and I never received any feedback. I haven't updated the patch since the original submission, and it may need some further work, but it might be worth a try. I don't recall it it overrides the user's shell during forced password changes, so that may be one area that needs to be addressed. -- Iain Morgan From deengert at gmail.com Thu Jan 22 07:33:43 2015 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 21 Jan 2015 14:33:43 -0600 Subject: way to set shell used for remote commands? In-Reply-To: References: Message-ID: <54C00D27.2030004@gmail.com> On 1/21/2015 9:36 AM, Jason Vas Dias wrote: > Good day - > > Please can OpenSSH provide some way of specifying which shell to use to > execute commands on a host. > > For the account I need to use, the user's password shell is not acceptable, > (a ten year old version of bash 3.0) > and cannot be changed without weeks or months of burocracy , if at all. > > I built & installed the latest bash under that account, in the ~/bin directory, > but SSH will not use it. > > Using the client OpenSSH version : 1:6.6p1-2ubuntu2 on a linux x86_64 > Ubuntu 14.04.1 host, > if I try to specify which bash to use for an SSH command like : > $ ssh $account /home/${user}/bin/bash -c 'echo $BASH_VERSION; echo > $BASH_VERSION'; looks like escape problem and not clear if $user should be $USER and is being done on local system... Try something like: ssh $account /home/${USER}/bin/bash -c \'echo \$BASH_VERSION\; echo \$BASH_VERSION\'; > something very weird happens - only the second statement produces any > output . > If this is changed, we see only the first statement is run by the new shell, > and the second is run by the old shell: > $ ssh $account /home/${user}/bin/bash -c \ > 'set | grep BASH_VERSION; echo $BASH_VERSION' > Produces the output: > BASH_VERSION='4.3.30(1)-release' > 3.0.0(1)-release > So the first statement is run by the new shell, and the second by the old > shell. > > This appears to be a major bug in OpenSSH - should I report it ? > > Since OpenSSH provides no way to run commands with anything other > than the user's password shell, it really needs to do so. > > A simple patch would be to session.c, @ line 1746 : > > /* > * Get the shell from the password data. An empty shell field is > * legal, and means /bin/sh. > */ > shell = (pw->pw_shell[0] == 0) ? _PATH_BSHELL : pw->pw_shell; > > > One could do something like: > > char *sh; > if ( (sh=getenv("SSH_SHELL") )!= NULL ) > shell = sh; > else > shell = (pw->pw_shell[0] == 0) ? _PATH_BSHELL : pw->pw_shell; > > > Or provide some configuration option - this would probably have to > be per-server . > > Is there any hope of getting the ability to specify which shell to run > remote commands with in a forthcoming OpenSSH release, or do > I need to apply my patch and maintain my own OpenSSH branch ? > > Thanks & Regards, > Jason > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Douglas E. Engert From jason.vas.dias at gmail.com Fri Jan 23 01:17:13 2015 From: jason.vas.dias at gmail.com (Jason Vas Dias) Date: Thu, 22 Jan 2015 14:17:13 +0000 Subject: way to set shell used for remote commands? In-Reply-To: <20150121192652.GE29822@linux124.nas.nasa.gov> References: <20150121192652.GE29822@linux124.nas.nasa.gov> Message-ID: Thanks Alan & Iain for your replies. RE: >> ssh 127.0.0.1 dash -c env >> >> appear to do the expected for me. >> Yes, it is easy enough to run any program on the remote host to read commands from stdin and write results to stdout ; but that means you have to send the script to execute separately: $ echo "$script" | ssh $remote_host $remote_shell and that means you must be aware on the origin host exactly what the path of $remote_shell is on the remote host. Also using $SHELL -c "$SCRIPT" on the origin host does not work if $SCRIPT contains semi-colons; only the first line terminated by a semi-colon will be run by $SHELL; remaining lines are run by the user's default shell. And that introduces a new level of quoting hell . What I'd like is an option I could put into a configuration file on $remote_host to say "sshd should use SHELL=$X for all commands", or maybe it might be nicer to be able to say: "use SHELL=$X for commands coming from host $Y or network $N" or "use SHELL=$X for commands that match the regular expression $Y" or a combination of both. The problem is of course, there appears to be no user-specific configuration file for sshd beyound ~/.ssh/rc - and I don't think that is the right file . AFAICS, sshd does not parse the user's ~/.ssh/config - this is used only by the 'ssh' client for OUTGOING commands. It appears sshd needs a per-user config file for INCOMING commands. So the patch would need to add a new "~/.ssh/sshd_config' file, which could contain lines like : # for commands coming from hosts on subnet 192.168/16, use this shell: Host 192.168/16 Shell /path/to/my/subnet.192.168/shell # for commands coming from hosts on subnet 172.16/16, use this shell: Host 172.16/16 Shell /path/to/my/subnet.172.16/shell # for commands which start with 'new_shell', use specified shell and # remove prefixing 'new_shell' : Match ^(new_shell)\ (.*) = \2 Shell /path/to/my/latest/shell If I develop such a patch, would there be any interest in it / likelihood of it being incorporated in a future OpenSSH release ? Iain, I'd be most interested to see your 'ForceShell' patch. Please could you post it ? Does it apply to commands from particular hosts, or all incoming commands ? Thanks & Regards, Jason On 21/01/2015, Iain Morgan wrote: > On Wed, Jan 21, 2015 at 17:29:00 +0000, Alex Bligh wrote: >> >> On 21 Jan 2015, at 15:36, Jason Vas Dias >> wrote: >> >> > Please can OpenSSH provide some way of specifying which shell to use to >> > execute commands on a host. >> >> Using dash as an example of another shell: >> >> ssh 127.0.0.1 -t dash >> >> and >> >> ssh 127.0.0.1 dash -c env >> >> appear to do the expected for me. >> > > Two years ago, I opened a bug to add support for a ForceShell option > to sshd that would provide the ability to override users shells. There > doesn't seem to have been much interest in it, and I never received any > feedback. > > I haven't updated the patch since the original submission, and it may > need some further work, but it might be worth a try. I don't recall it > it overrides the user's shell during forced password changes, so that > may be one area that needs to be addressed. > > -- > Iain Morgan > From imorgan at nas.nasa.gov Fri Jan 23 06:40:59 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 22 Jan 2015 11:40:59 -0800 Subject: way to set shell used for remote commands? In-Reply-To: References: <20150121192652.GE29822@linux124.nas.nasa.gov> Message-ID: <20150122194059.GA8538@linux124.nas.nasa.gov> On Thu, Jan 22, 2015 at 14:17:13 +0000, Jason Vas Dias wrote: > Thanks Alan & Iain for your replies. > RE: > >> ssh 127.0.0.1 dash -c env > >> > >> appear to do the expected for me. > >> > Yes, it is easy enough to run any program on the remote host > to read commands from stdin and write results to stdout ; > but that means you have to send the script to execute separately: > $ echo "$script" | ssh $remote_host $remote_shell > and that means you must be aware on the origin host > exactly what the path of $remote_shell is on the remote host. > Also using $SHELL -c "$SCRIPT" on the origin host does not work if > $SCRIPT contains semi-colons; only the first line terminated by > a semi-colon will be run by $SHELL; remaining lines are run > by the user's default shell. And that introduces a new level > of quoting hell . > > What I'd like is an option I could put into a configuration file on > $remote_host to say "sshd should use SHELL=$X for all commands", or > maybe it might be nicer to be able to say: > "use SHELL=$X for commands coming from host $Y or network $N" > or "use SHELL=$X for commands that match the regular expression $Y" > or a combination of both. > > The problem is of course, there appears to be no user-specific > configuration file for sshd beyound ~/.ssh/rc - and I don't think > that is the right file . AFAICS, sshd does not parse the user's > ~/.ssh/config - this is used only by the 'ssh' client for OUTGOING commands. > > It appears sshd needs a per-user config file for INCOMING commands. > > So the patch would need to add a new "~/.ssh/sshd_config' file, which > could contain lines like : > # for commands coming from hosts on subnet 192.168/16, use this shell: > Host 192.168/16 > Shell /path/to/my/subnet.192.168/shell > # for commands coming from hosts on subnet 172.16/16, use this shell: > Host 172.16/16 > Shell /path/to/my/subnet.172.16/shell > # for commands which start with 'new_shell', use specified shell and > # remove prefixing 'new_shell' : > Match ^(new_shell)\ (.*) = \2 > Shell /path/to/my/latest/shell > > If I develop such a patch, would there be any interest in it / likelihood > of it being incorporated in a future OpenSSH release ? > > Iain, I'd be most interested to see your 'ForceShell' patch. > Please could you post it ? Does it apply to commands from > particular hosts, or all incoming commands ? > > Thanks & Regards, > Jason > First, my apologies for not including the URL or bugzilla ID. The bug (and patch) can be found at: https://bugzilla.mindrot.org/show_bug.cgi?id=2062 The patch adds a ForceShell option to sshd_config, similar to ForceCommand, except that it overrides the shell used to invoke remote commands or for interactive sessions. With such an option, you could use a Match block to override the shell for particular users, and could do so based on the client host or any other criteria supported by the match directive. For example: Match User sombody Host foo.example.com ForceShell /bin/dash As noted above, it is an sshd_config option, and thus cannot be set directly by the user. From a policy enforcement standpoint, this seems the better way to approach things. Unfortunately, I haven't touched the patch in two years, so I'm not sure if it still applies cleanly. I'll see if I can set aside some time to update the patch, but that may be a week or two away. Feel free to give it a try in the meantime. -- Iain Morgan From philipp.marek at linbit.com Fri Jan 23 18:00:12 2015 From: philipp.marek at linbit.com (Philipp Marek) Date: Fri, 23 Jan 2015 08:00:12 +0100 Subject: way to set shell used for remote commands? In-Reply-To: References: <20150121192652.GE29822@linux124.nas.nasa.gov> Message-ID: <20150123070012.GM24843@cacao.linbit> > What I'd like is an option I could put into a configuration file on > $remote_host to say "sshd should use SHELL=$X for all commands", or > maybe it might be nicer to be able to say: > "use SHELL=$X for commands coming from host $Y or network $N" > or "use SHELL=$X for commands that match the regular expression $Y" > or a combination of both. Why not create an additional user on $remote, reusing the same UID and groups, and giving that user the "right" shell? From nkadel at gmail.com Fri Jan 23 18:15:20 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 23 Jan 2015 02:15:20 -0500 Subject: way to set shell used for remote commands? In-Reply-To: <20150123070012.GM24843@cacao.linbit> References: <20150121192652.GE29822@linux124.nas.nasa.gov> <20150123070012.GM24843@cacao.linbit> Message-ID: On Fri, Jan 23, 2015 at 2:00 AM, Philipp Marek wrote: > >> What I'd like is an option I could put into a configuration file on >> $remote_host to say "sshd should use SHELL=$X for all commands", or >> maybe it might be nicer to be able to say: >> "use SHELL=$X for commands coming from host $Y or network $N" >> or "use SHELL=$X for commands that match the regular expression $Y" >> or a combination of both. > Why not create an additional user on $remote, reusing the same UID and > groups, and giving that user the "right" shell? Because it screws up commands like 'ls -l' inconsistently, confuses logging, and generally makes file and process ownership difficult to track. If you want to do this on your own personal system and accept the consequences, so be it.Multiple users with the same uid are like bind-mounting directories. It works great, until it doesn't. From john.m.olsson at ericsson.com Fri Jan 23 21:52:13 2015 From: john.m.olsson at ericsson.com (John Olsson M) Date: Fri, 23 Jan 2015 11:52:13 +0100 Subject: Usability issue when forced to change password when logging in to a system Message-ID: <54C227DD.8020708@ericsson.com> Hi, What I am about to describe is something that has existed for a very long time, but it is still a usability issue. :) When logging in to a system and the system detects that the password has expired and needs to change this happens Login As: Foobar Password: Your password has expired. Choose a new password. Old Pasword: Now the user has just read the text "Your password has expired. Choose a new password.". This means that the user has already started thinking about what password to change to. The mind is set on the new password. And almost always (consistently) the "Old " prefix is lost. You just start typing the new password. And *bam* you are in password change hell and get extremely frustrated as a result. This has been observed with numerous people. If you combine this with draconian password policies you are very close to snapping. ;) In the OpenSSH source code it looks like OpenSSH does not cache and copy the authentication password back to the PAM stack when password change is invoked. Instead OpenSSH gets it again from the tty leading to the above usability issue. So I am wondering if there is any reason for doing like this? And if not, could this please be fixed in an upcoming release of OpenSSH? Or prehaps there is already a configuration setting for tweaking this behavior? /John -- John Olsson Ericsson AB GSM BSC/BSS System Management From peter at stuge.se Sat Jan 24 02:50:37 2015 From: peter at stuge.se (Peter Stuge) Date: Fri, 23 Jan 2015 16:50:37 +0100 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <54C227DD.8020708@ericsson.com> References: <54C227DD.8020708@ericsson.com> Message-ID: <20150123155038.2007.qmail@stuge.se> John Olsson M wrote: > it looks like OpenSSH does not cache and copy the authentication password .. > So I am wondering if there is any reason for doing like this? Data hygiene is one. //Peter From imorgan at nas.nasa.gov Sat Jan 24 05:59:22 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 23 Jan 2015 10:59:22 -0800 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <54C227DD.8020708@ericsson.com> References: <54C227DD.8020708@ericsson.com> Message-ID: <20150123185921.GF29822@linux124.nas.nasa.gov> On Fri, Jan 23, 2015 at 11:52:13 +0100, John Olsson M wrote: > In the OpenSSH source code it looks like OpenSSH does not cache and > copy the authentication password back to the PAM stack when password > change is invoked. Instead OpenSSH gets it again from the tty > leading to the above usability issue. > As I recall, OpenSSH does not use PAM to implement password changes; instead, it executes the system's passwd binary. This was done to avoid a variety of problems. This allows password expiration to work on platforms that do not have PAM support, and it probably also simplifies the handling of password expiration when public-key or hostbased authentication is used. In short, executing passwd is simpler and much more portable. -- Iain Morgan From dtucker at zip.com.au Sat Jan 24 09:27:58 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 23 Jan 2015 14:27:58 -0800 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <20150123185921.GF29822@linux124.nas.nasa.gov> References: <54C227DD.8020708@ericsson.com> <20150123185921.GF29822@linux124.nas.nasa.gov> Message-ID: On Fri, Jan 23, 2015 at 10:59 AM, Iain Morgan wrote: > > As I recall, OpenSSH does not use PAM to implement password changes; > Actually it does (via pam_chauthtok() but only when you are using keyboard-interactive and it has a reliable way to talk to to the user. > instead, it executes the system's passwd binary. It does that when you are not using PAM, or when you are using PAM with "password" authentication (it can't call pam_chauthtok() in the latter case because by the time it can talk to the user via a tty, it has long since dropped the privilege required to actually change the password. -- 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 nkadel at gmail.com Sat Jan 24 13:46:11 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 23 Jan 2015 21:46:11 -0500 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <20150123155038.2007.qmail@stuge.se> References: <54C227DD.8020708@ericsson.com> <20150123155038.2007.qmail@stuge.se> Message-ID: On Fri, Jan 23, 2015 at 10:50 AM, Peter Stuge wrote: > John Olsson M wrote: >> it looks like OpenSSH does not cache and copy the authentication password > .. >> So I am wondering if there is any reason for doing like this? > > Data hygiene is one. Also, in my opinion as more of an admin than a developer, any bug in a routine that stores psswords temporary in plain text is *begging* to have a bug or get an unexpected modification that publishes the passwords somewhere else. Basically, never handle or store dangerous information that you don't *have* to store. From keisial at gmail.com Mon Jan 26 07:27:09 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 25 Jan 2015 21:27:09 +0100 Subject: way to set shell used for remote commands? In-Reply-To: References: <20150121192652.GE29822@linux124.nas.nasa.gov> Message-ID: <54C5519D.4090402@gmail.com> On 22/01/15 15:17, Jason Vas Dias wrote: > Thanks Alan& Iain for your replies. > RE: >>> ssh 127.0.0.1 dash -c env >>> >>> appear to do the expected for me. >>> > Yes, it is easy enough to run any program on the remote host > to read commands from stdin and write results to stdout ; > but that means you have to send the script to execute separately: > $ echo "$script" | ssh $remote_host $remote_shell > and that means you must be aware on the origin host > exactly what the path of $remote_shell is on the remote host. > Also using $SHELL -c "$SCRIPT" on the origin host does not work if > $SCRIPT contains semi-colons; only the first line terminated by > a semi-colon will be run by $SHELL; remaining lines are run > by the user's default shell. And that introduces a new level > of quoting hell . > > What I'd like is an option I could put into a configuration file on > $remote_host to say "sshd should use SHELL=$X for all commands", or > maybe it might be nicer to be able to say: > "use SHELL=$X for commands coming from host $Y or network $N" > or "use SHELL=$X for commands that match the regular expression $Y" > or a combination of both. (...) Edit ~/.ssh/authorized_keys in the remote host and set for your key:? command="/bin/bash -c 'if [ -z \"$SSH_ORIGINAL_COMMAND\" ]; then exec /bin/good-shell \"$@\"; else exec /bin/good-shell -c \"$SSH_ORIGINAL_COMMAND\"; fi'" The "choose shell based on subnet" can be implemented by pointing to a shell script that parses $SSH_CONNECTION. ?This will only work when you authenticate with public key, but if you were routinely executing remote commands like that and entering the key manually each time, you would already be doing things the Wrong Way. Regards From john.m.olsson at ericsson.com Mon Jan 26 18:34:48 2015 From: john.m.olsson at ericsson.com (John Olsson M) Date: Mon, 26 Jan 2015 08:34:48 +0100 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: References: <54C227DD.8020708@ericsson.com> <20150123155038.2007.qmail@stuge.se> Message-ID: <54C5EE18.4030808@ericsson.com> On 2015-01-24 03:46, Nico Kadel-Garcia wrote: > On Fri, Jan 23, 2015 at 10:50 AM, Peter Stuge wrote: >> ... >> So I am wondering if there is any reason for doing like this? >> Data hygiene is one. > Also, in my opinion as more of an admin than a developer, any bug in a > routine that stores psswords temporary in plain text is *begging* to > have a bug or get an unexpected modification that publishes the > passwords somewhere else. Basically, never handle or store dangerous > information that you don't *have* to store. > There is always a need to strike a balance between security and usability. Sometimes it is missed that good usability also gives good security... What about changing the dialog like this? (The instructions matches better what it is the system wants to user to actually do, that is first enter the old password and then start thinking about the new password.) Login As: Foobar Password: Your password has expired. Retype your old password. Old Password: Choose a new password. New Password: Retype your new password New Password: Could this be implemented without the need for caching any password (old or new) in clear text? /John From peter at stuge.se Mon Jan 26 22:33:06 2015 From: peter at stuge.se (Peter Stuge) Date: Mon, 26 Jan 2015 12:33:06 +0100 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <54C5EE18.4030808@ericsson.com> References: <54C227DD.8020708@ericsson.com> <20150123155038.2007.qmail@stuge.se> <54C5EE18.4030808@ericsson.com> Message-ID: <20150126113306.5999.qmail@stuge.se> John Olsson M wrote: > What about changing the dialog like this? (The instructions matches better I think there's a good case to be made for OpenSSH to not provide any instructions at all unless it is in charge of the dialog itself. Have you checked that the current instructions are actually output by OpenSSH? The string seems to be in openbsd-compat/bsd-cray.c inside #ifdef _UNICOS > Login As: Foobar > Password: > Your password has expired. Retype your old password. I'd argue simply for "Your password has expired." > Old Password: > Choose a new password. > New Password: > Retype your new password > New Password: > Could this be implemented without the need for caching any password Why don't you try? All arguments are better received with a patch. //Peter From imorgan at nas.nasa.gov Tue Jan 27 11:54:19 2015 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 26 Jan 2015 16:54:19 -0800 Subject: way to set shell used for remote commands? In-Reply-To: <20150122194059.GA8538@linux124.nas.nasa.gov> References: <20150121192652.GE29822@linux124.nas.nasa.gov> <20150122194059.GA8538@linux124.nas.nasa.gov> Message-ID: <20150127005419.GG29822@linux124.nas.nasa.gov> On Thu, Jan 22, 2015 at 11:40:59 -0800, Iain Morgan wrote: > Unfortunately, I haven't touched the patch in two years, so I'm not sure > if it still applies cleanly. I'll see if I can set aside some time to > update the patch, but that may be a week or two away. Feel free to give > it a try in the meantime. > Here's an update of the patch versus 6.7p1. -- Iain Morgan diff -ur V_6_7_P1/auth.c V_6_7_P1.force-shell/auth.c --- V_6_7_P1/auth.c 2014-07-17 21:11:25.000000000 -0700 +++ V_6_7_P1.force-shell/auth.c 2015-01-26 14:00:55.687638002 -0800 @@ -158,8 +158,9 @@ * Deny if shell does not exist or is not executable unless we * are chrooting. */ - if (options.chroot_directory == NULL || - strcasecmp(options.chroot_directory, "none") == 0) { + if (options.adm_forced_shell == NULL && + (options.chroot_directory == NULL || + strcasecmp(options.chroot_directory, "none") == 0)) { char *shell = xstrdup((pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell); /* empty = /bin/sh */ diff -ur V_6_7_P1/servconf.c V_6_7_P1.force-shell/servconf.c --- V_6_7_P1/servconf.c 2014-07-17 21:11:26.000000000 -0700 +++ V_6_7_P1.force-shell/servconf.c 2015-01-26 14:27:11.927378483 -0800 @@ -157,6 +157,7 @@ options->ip_qos_interactive = -1; options->ip_qos_bulk = -1; options->version_addendum = NULL; + options->adm_forced_shell = NULL; } void @@ -361,7 +362,7 @@ sAuthorizedKeysCommand, sAuthorizedKeysCommandUser, sAuthenticationMethods, sHostKeyAgent, sPermitUserRC, sStreamLocalBindMask, sStreamLocalBindUnlink, - sAllowStreamLocalForwarding, + sAllowStreamLocalForwarding, sForceShell, sDeprecated, sUnsupported } ServerOpCodes; @@ -492,6 +493,7 @@ { "streamlocalbindmask", sStreamLocalBindMask, SSHCFG_ALL }, { "streamlocalbindunlink", sStreamLocalBindUnlink, SSHCFG_ALL }, { "allowstreamlocalforwarding", sAllowStreamLocalForwarding, SSHCFG_ALL }, + { "forceshell", sForceShell, SSHCFG_ALL }, { NULL, sBadOption, 0 } }; @@ -1663,6 +1665,15 @@ intptr = &options->fwd_opts.streamlocal_bind_unlink; goto parse_flag; + case sForceShell: + if (cp == NULL) + fatal("%.200s line %d: Missing argument.", filename, + linenum); + len = strspn(cp, WHITESPACE); + if (*activep && options->adm_forced_shell == NULL) + options->adm_forced_shell = xstrdup(cp + len); + return 0; + case sDeprecated: logit("%s line %d: Deprecated option %s", filename, linenum, arg); @@ -1844,6 +1855,7 @@ M_CP_STROPT(adm_forced_command); M_CP_STROPT(chroot_directory); + M_CP_STROPT(adm_forced_shell); } #undef M_CP_INTOPT @@ -2086,6 +2098,7 @@ dump_cfg_string(sHostKeyAgent, o->host_key_agent); dump_cfg_string(sKexAlgorithms, o->kex_algorithms ? o->kex_algorithms : kex_alg_list(',')); + dump_cfg_string(sForceShell, o->adm_forced_shell); /* string arguments requiring a lookup */ dump_cfg_string(sLogLevel, log_level_name(o->log_level)); diff -ur V_6_7_P1/servconf.h V_6_7_P1.force-shell/servconf.h --- V_6_7_P1/servconf.h 2014-07-17 21:11:26.000000000 -0700 +++ V_6_7_P1.force-shell/servconf.h 2015-01-26 14:00:55.696637887 -0800 @@ -185,6 +185,7 @@ u_int num_auth_methods; char *auth_methods[MAX_AUTH_METHODS]; + char *adm_forced_shell; } ServerOptions; /* Information about the incoming connection as used by Match */ diff -ur V_6_7_P1/session.c V_6_7_P1.force-shell/session.c --- V_6_7_P1/session.c 2014-07-17 21:11:26.000000000 -0700 +++ V_6_7_P1.force-shell/session.c 2015-01-26 14:00:55.698637830 -0800 @@ -827,7 +827,9 @@ else if (s->ttyfd == -1) { char *shell = s->pw->pw_shell; - if (shell[0] == '\0') /* empty shell means /bin/sh */ + if (options.adm_forced_shell) + shell = options.adm_forced_shell; + else if (shell[0] == '\0') /* empty shell means /bin/sh */ shell =_PATH_BSHELL; PRIVSEP(audit_run_command(shell)); } @@ -1727,6 +1729,8 @@ * legal, and means /bin/sh. */ shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell; + if (options.adm_forced_shell) + shell = options.adm_forced_shell; /* * Make sure $SHELL points to the shell from the password file, diff -ur V_6_7_P1/sshd_config.5 V_6_7_P1.force-shell/sshd_config.5 --- V_6_7_P1/sshd_config.5 2014-10-02 16:24:57.000000000 -0700 +++ V_6_7_P1.force-shell/sshd_config.5 2015-01-26 14:00:55.700637767 -0800 @@ -502,6 +502,14 @@ will force the use of an in-process sftp server that requires no support files when used with .Cm ChrootDirectory . +.It Cm ForceShell +Executes the command specified by +.Cm ForceShell +in place of the user's normal login shell. +This applies to shell, command, or subsystem execution. +It is most useful inside a +.Cm Match +block. .It Cm GatewayPorts Specifies whether remote hosts are allowed to connect to ports forwarded for the client. @@ -918,6 +926,7 @@ .Cm DenyGroups , .Cm DenyUsers , .Cm ForceCommand , +.Cm ForceShell , .Cm GatewayPorts , .Cm GSSAPIAuthentication , .Cm HostbasedAuthentication , From john.m.olsson at ericsson.com Tue Jan 27 22:40:30 2015 From: john.m.olsson at ericsson.com (John Olsson M) Date: Tue, 27 Jan 2015 12:40:30 +0100 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <20150126113306.5999.qmail@stuge.se> References: <54C227DD.8020708@ericsson.com> <20150123155038.2007.qmail@stuge.se> <54C5EE18.4030808@ericsson.com> <20150126113306.5999.qmail@stuge.se> Message-ID: <54C7792E.8090207@ericsson.com> Why don't you try? All arguments are better received with a patch. Sure! :) Where can I find instructions on how to setup my own build and test environment for OpenSSH development on Ubuntu 14.04? Any official OpenSSH design rules I should consider (apart from following the style already used in the source code)? The initial dialog example (that motivated me to send the initial email to the list) comes from a system based on SLED 11 SP3. When checking, the actual dialog presented at login is identical to what happens when you run the passwd command in the shell to change your password. Thus it seems like the dialog texts does not originate from OpenSSH itself. So the "culprit" might actually be PAM... /John On 2015-01-26 12:33, Peter Stuge wrote: > John Olsson M wrote: >> What about changing the dialog like this? (The instructions matches better > I think there's a good case to be made for OpenSSH to not provide any > instructions at all unless it is in charge of the dialog itself. > > Have you checked that the current instructions are actually output by > OpenSSH? The string seems to be in openbsd-compat/bsd-cray.c inside > #ifdef _UNICOS > > >> Login As: Foobar >> Password: >> Your password has expired. Retype your old password. > I'd argue simply for "Your password has expired." > >> Old Password: >> Choose a new password. >> New Password: >> Retype your new password >> New Password: > >> Could this be implemented without the need for caching any password > Why don't you try? All arguments are better received with a patch. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Tue Jan 27 23:02:19 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 27 Jan 2015 07:02:19 -0500 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <54C7792E.8090207@ericsson.com> References: <54C227DD.8020708@ericsson.com> <20150123155038.2007.qmail@stuge.se> <54C5EE18.4030808@ericsson.com> <20150126113306.5999.qmail@stuge.se> <54C7792E.8090207@ericsson.com> Message-ID: On Tue, Jan 27, 2015 at 6:40 AM, John Olsson M wrote: > Why don't you try? All arguments are better received with a patch. > > Sure! :) > > Where can I find instructions on how to setup my own build and test > environment for OpenSSH development on Ubuntu 14.04? The general requirements and build instructions are in the INSTALL file. The -dev packages you need for Debian based distros like Ubuntu are listed in README.platform. > Any official OpenSSH design rules I should consider (apart from following > the style already used in the source code)? > OpenSSH follows the OpenBSD style: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9 > The initial dialog example (that motivated me to send the initial email to > the list) comes from a system based on SLED 11 SP3. > > When checking, the actual dialog presented at login is identical to what > happens when you run the passwd command in the shell to change your > password. Thus it seems like the dialog texts does not originate from > OpenSSH itself. So the "culprit" might actually be PAM... It could be PAM. What is odd is that the transcript you originally posted does not contain the text "You must change your password now and login again!" which sshd prints when it changes passwd by exec'ing /bin/passwd. If you are investigating PAM's behaviour you might want to try the test harness tool I wrote for this purpose: http://www.dtucker.net/patches/#pamtest -- 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 peter at stuge.se Tue Jan 27 23:36:09 2015 From: peter at stuge.se (Peter Stuge) Date: Tue, 27 Jan 2015 13:36:09 +0100 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: <54C7792E.8090207@ericsson.com> References: <54C227DD.8020708@ericsson.com> <20150123155038.2007.qmail@stuge.se> <54C5EE18.4030808@ericsson.com> <20150126113306.5999.qmail@stuge.se> <54C7792E.8090207@ericsson.com> Message-ID: <20150127123609.20581.qmail@stuge.se> John Olsson M wrote: > Where can I find instructions on how to setup my own build and test > environment for OpenSSH development on Ubuntu 14.04? git clone https://anongit.mindrot.org/openssh.git cd openssh autoreconf -fi ./configure --prefix=/tmp/ossh && make install Now make changes, then run git commit, then git show to review your commit, when you are happy with it run git format-patch -1 to save it into a patch file which you either email to the list or attach in bugzilla. > it seems like the dialog texts does not originate from OpenSSH itself. Then there's of course nothing sshd can do to fix it. //Peter From john.m.olsson at ericsson.com Wed Jan 28 00:34:33 2015 From: john.m.olsson at ericsson.com (John Olsson M) Date: Tue, 27 Jan 2015 14:34:33 +0100 Subject: Usability issue when forced to change password when logging in to a system In-Reply-To: References: <54C227DD.8020708@ericsson.com> <20150123155038.2007.qmail@stuge.se> <54C5EE18.4030808@ericsson.com> <20150126113306.5999.qmail@stuge.se> <54C7792E.8090207@ericsson.com> Message-ID: <54C793E9.7060202@ericsson.com> Thank you Darren! > It could be PAM. What is odd is that the transcript you originally > posted does not contain the text "You must change your password now > and login again!" which sshd prints when it changes passwd by exec'ing > /bin/passwd. > Actually, once password has been successfully changed the login process continues and you finally get a prompt. No need to go through the "logout + login" procedure. > If you are investigating PAM's behaviour you might want to try the > test harness tool I wrote for this purpose: > http://www.dtucker.net/patches/#pamtest > Thank you! :) /John On 2015-01-27 13:02, Darren Tucker wrote: > On Tue, Jan 27, 2015 at 6:40 AM, John Olsson M > > wrote: > > Why don't you try? All arguments are better received with a patch. > > Sure! :) > > Where can I find instructions on how to setup my own build and > test environment for OpenSSH development on Ubuntu 14.04? > > > The general requirements and build instructions are in the INSTALL > file. The -dev packages you need for Debian based distros like Ubuntu > are listed in README.platform. > > Any official OpenSSH design rules I should consider (apart from > following the style already used in the source code)? > > > OpenSSH follows the OpenBSD style: > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9 > > The initial dialog example (that motivated me to send the initial > email to the list) comes from a system based on SLED 11 SP3. > > When checking, the actual dialog presented at login is identical > to what happens when you run the passwd command in the shell to > change your password. Thus it seems like the dialog texts does not > originate from OpenSSH itself. So the "culprit" might actually be > PAM... > > > It could be PAM. What is odd is that the transcript you originally > posted does not contain the text "You must change your password now > and login again!" which sshd prints when it changes passwd by exec'ing > /bin/passwd. > > If you are investigating PAM's behaviour you might want to try the > test harness tool I wrote for this purpose: > http://www.dtucker.net/patches/#pamtest > > -- > 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 emichoux at yahoo.com Wed Jan 28 20:45:19 2015 From: emichoux at yahoo.com (MICHOUX Emmanuel) Date: Wed, 28 Jan 2015 09:45:19 +0000 (UTC) Subject: Failure of openSSH service (windows) Message-ID: <85855872.1039547.1422438319557.JavaMail.yahoo@mail.yahoo.com> Hello, I have a problem with the OpenSsh services which fails, but I don't find the reasons of these regular failuresI need help for reading the logs inserted below I have several SSH connexions between :- a File Server in which the Ssh server based on OpenSsh 6.6.1p1-3(Windows 2008 SP2 64bits)? has been installed,- a Ssh client OpenSsh 4.3P2, installed on a SANTOS Linux distribution, - others Ssh clients based on OpenSsh 6.2p2-1(Windows 2008 SP2 64bits) Note : The problem was also present with the version setupssh-6.2p2-1-v1.exe, which have been firstly installed on my File server my configuration is based on RSA authentification (sshd_config attached) I have also changed the following parameters, but without any successLoginGraceTimeThe server disconnects after this time if the user hasnotsuccessfully logged in. If the value is 0, there is no time limit.Thedefault is 600 (seconds).LoginGraceTime 30 ?KeepAliveSpecifies whether the system should send keepalive messages to theotherside. If they are sent, death of the connection or crash of oneof the machineswill be properly noticed. However, this means thatconnections will die if theroute is down temporarily, and some peoplefind it annoying. On the other hand,if keepalives are not send,sessions may hang indefinitely on the server,leaving "ghost" usersand consuming server resources.???????????????he default is"yes" (to send keepalives), and the server will noticeif the networkgoes down or the client host reboots. This avoidsinfinitely hangingsessions.KeepAlive yes ?ClientAliveCountMax ? This indicates the total number of checkalive message sent by the sshserver without getting any response from the ssh client. Default is 3.ClientAliveCountMax ?0 ??? ClientAliveInterval ? This indicates the timeout in seconds. After x numberof seconds, ssh server will send a message to the client asking for response.Deafult is 0 (server will not send message to client to check.).ClientAliveInterval10 It's seems it's the linux client (IP : 192.168.32.30 ) which provokes the failure of the OpenSsh service on my File Server? In my EventViewer, I have the logs : (PRESENT) sshd: PID 5236: debug1: attempt 1 failures 0 sshd: PID 5236: debug2: input_userauth_request: try method publickey sshd: PID 5236: debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive sshd: PID 5236: debug1: userauth_send_banner: sent sshd: PID 5236: debug2: input_userauth_request: try method none sshd: PID 5236: debug1: userauth-request for user operateur service ssh-connection method publickey sshd: PID 5236: debug1: test whether pkalg/pkblob are acceptable sshd: PID 5236: debug1: temporarily_use_uid: 1000/513 (e=500/513) sshd: PID 4604: debug3: session_unused: session id 0 unused sshd: PID 4604: debug1: do_cleanup sshd: PID 4604: debug3: channel 0: status: The following connections are open:\r\n? #0 server-session (t4 r619955 i3/0 o3/0 fd -1/-1 cc -1)\r\n sshd: PID 4604: debug1: session_close: session 0 pid 3864 sshd: PID 4604: Transferred: sent 5328, received 687736 bytes sshd: PID 5236: debug2: parse_server_config: config reprocess config len 442 sshd: PID 5236: debug2: input_userauth_request: setting up authctxt for operateur sshd: PID 4604: Closing connection to 10.101.8.2 port 2388 OpenSSHd: PID 2340: service `OpenSSHd' failed: signal 11 raised sshd: PID 5248: debug2: channel 0: close_read sshd: PID 5248: debug2: channel 0: input open -> drain sshd: PID 5248: debug2: channel 0: read failed sshd: PID 5248: debug2: notify_done: reading sshd: PID 5248: debug2: channel 0: read<=0 rfd 8 len 0 sshd: PID 5248: debug2: channel 0: ibuf empty sshd: PID 5248: debug3: channel 0: will not send data after close sshd: PID 5248: debug2: channel 0: rcvd close sshd: PID 5248: debug2: channel 0: send close sshd: PID 5248: debug2: channel 0: send eof sshd: PID 5248: debug2: channel 0: input drain -> closed sshd: PID 5248: debug2: channel 0: request exit-status confirm 0 sshd: PID 5248: debug1: session_exit_message: release channel 0 sshd: PID 5248: debug1: session_exit_message: session 0 channel 0 pid 3080 sshd: PID 5248: debug1: Received SIGCHLD. sshd: PID 5248: debug1: session_by_pid: pid 3080 sshd: PID 5248: debug2: channel 0: write failed sshd: PID 5248: debug2: channel 0: read 0 from efd 10 sshd: PID 5248: debug2: channel 0: closing read-efd 10 sshd: PID 5248: debug2: channel 0: output open -> closed sshd: PID 5248: debug2: channel 0: close_write sshd: PID 5248: debug2: channel 0: send eow sshd: PID 5248: Transferred: sent 430056, received 2368 bytes sshd: PID 5248: Closing connection to 192.168.32.30 port 56963 sshd: PID 5248: debug1: do_cleanup sshd: PID 5248: debug3: channel 0: status: The following connections are open:\r\n? #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)\r\n sshd: PID 5248: Connection closed by 192.168.32.30 sshd: PID 4604: debug2: channel 0: window 1998376 sent adjust 98776 sshd: PID 4604: debug2: channel 0: window 1966472 sent adjust 130680 sshd: PID 4604: debug2: channel 0: rcvd close sshd: PID 4604: debug2: channel 0: window 1966472 sent adjust 98010 sshd: PID 4604: debug2: channel 0: window 1966472 sent adjust 130680(PAST) regardsEmmanuel From sebastian.ratz at student.kit.edu Thu Jan 29 05:23:58 2015 From: sebastian.ratz at student.kit.edu (Sebastian Ratz) Date: Wed, 28 Jan 2015 19:23:58 +0100 Subject: Port forwardings are duplicated when connecting to host by nickname Message-ID: <54C9293E.1050209@student.kit.edu> Hello, I found a problem with port forwardings specified in the config file. The following is run on OpenSSH 6.7p1: Assume the following ~/.ssh/config: Host some.host.name.com foo Hostname some.host.name.com DynamicForward 55555 When connecting to the real hostname everything is fine: $ ssh -v some.host.name.com ... debug1: Local connections to LOCALHOST:55555 forwarded to remote address socks:0 debug1: Local forwarding listening on ::1 port 55555. debug1: channel 0: new [port listener] debug1: Local forwarding listening on 127.0.0.1 port 55555. debug1: channel 1: new [port listener] ... But when using the short nickname: $ ssh -v foo ... debug1: Hostname has changed; re-reading configuration ... debug1: Local connections to LOCALHOST:55555 forwarded to remote address socks:0 debug1: Local forwarding listening on ::1 port 55555. debug1: channel 0: new [port listener] debug1: Local forwarding listening on 127.0.0.1 port 55555. debug1: channel 1: new [port listener] debug1: Local connections to LOCALHOST:55555 forwarded to remote address socks:0 debug1: Local forwarding listening on ::1 port 55555. bind: Address already in use debug1: Local forwarding listening on 127.0.0.1 port 55555. bind: Address already in use channel_setup_fwd_listener_tcpip: cannot listen to port: 55555 ... The reason is that in the second case OpenSSH reparses the config and then tries to adds the same forwarding rules again. I looked into the source and there is a method compare_forward() in mux.c that is used to prevent adding of duplicates. Maybe that should be used also when parsing the config or commandline in ssh.c / readconf.c? Regards, Sebastian From aixtools at gmail.com Thu Jan 29 18:53:00 2015 From: aixtools at gmail.com (Michael Felt) Date: Thu, 29 Jan 2015 08:53:00 +0100 Subject: Latest 6.7p1 building failed on AIX 5.3 Message-ID: New to list I could not reply directly to message http://lists.mindrot.org/pipermail/openssh-unix-dev/2015-January/033290.html so I shall reply here. va_copy missing is something I used to run into frequently - and I forget how I got that to go away - so I cannot help you directly there. If I recall, this may be related to your starting point. FYI: I use a basic build system based on AIX 5.3 TL7 SP10 (closing SP for TL7) with one exception - I have the openssl from AIX 5.3 TL12 (in any case later than TL7) FYI: openssl for AIX 5.3TL7 is openssl.0.9.8d (fileset openssl.base.0.9.8.4) whereas the later openssl is 0.9.8.k (openssl.base.0.9.8.1101) - Note d is 4th letter of alphabet and k is the 11th I have successfully built openssh-6.7p1 on this system - and it loads on both AIX 5.3 as AIX 6.1 (TL9 is what I tested). It does not run on AIX 7.1 - even though, imho, it should. I did a short write-up on this build on my AIX portal - http://www.rootvg.net/content/view/679/169/. There is a link to a binary package in the article - please excuse the 'advertising'. To help with standardizing, and being lazy, I have developed a package I call 'buildaix' that makes use of mkinstallp to configure, make and mkinstallp opensource packages. I have just uploaded my current version of this package to https://sourceforge.net/projects/buildaix/ So, in reply to the request for any "help" or "suggestions" I would be interested in how it helps and/or with other "aixtools" opensource things I have packaged. One that is often needed is GNU gettext. Lastly, my experience when packaging is that the real test is when others load, or try to load a package and say what went wrong. So I will be grateful for feedback should you try my packaged version of openssh and/or requests for fixes/features with buildaix. regards, Michael From phil at dunlop-lello.uk Fri Jan 30 06:55:25 2015 From: phil at dunlop-lello.uk (Phil Lello) Date: Thu, 29 Jan 2015 19:55:25 +0000 Subject: SSH over websockets Message-ID: Hi all, I can't find a working archive search for this list, so please forgive me if this has been discussed before. Has any thought been given to supporting websockets in the ssh client? I'm talking about solely using a websocket as the transport layer, and leaving the actual protocol intact, as opposed to the (to me, frankly terrifying) idea of allowing a web server to act as an ssh client to a regular sshd and providing a terminal interface. I'm weighing up the pros and cons of this idea in my own mind at the moment, and whilst I like the idea for providing another transport to services such as git-over-ssh, I can't help wonder if it would encourage poor network security. My main motivation is that it is generally easier to route HTTP across multiple corporate firewalls than getting ports opened for ssh (even if it is an embedded sshd such as in gerrit rather than an actual shell). That said, my main motivation is also probably the biggest reason not to push this as a standard part of the ssh client. I'm not subscribed to the list, please cc me in any responses. Best wishes, Phil Lello From alex at alex.org.uk Fri Jan 30 07:15:46 2015 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 29 Jan 2015 20:15:46 +0000 Subject: SSH over websockets In-Reply-To: References: Message-ID: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> On 29 Jan 2015, at 19:55, Phil Lello wrote: > Has any thought been given to supporting websockets in the ssh client? I'm > talking about solely using a websocket as the transport layer, and leaving > the actual protocol intact, as opposed to the (to me, frankly terrifying) > idea of allowing a web server to act as an ssh client to a regular sshd and > providing a terminal interface. Be frightened: https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=en -- Alex Bligh From dtucker at zip.com.au Fri Jan 30 08:18:31 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 29 Jan 2015 16:18:31 -0500 Subject: SSH over websockets In-Reply-To: References: Message-ID: On Thu, Jan 29, 2015 at 2:55 PM, Phil Lello wrote: > > Has any thought been given to supporting websockets in the ssh client? No, but you could implement it on the client side in a ProxyCommand. I dunno how you'd route from the websocket whatever to sshd on the server side but I imagine it'd be possible. -- 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 keisial at gmail.com Fri Jan 30 08:53:29 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 29 Jan 2015 22:53:29 +0100 Subject: SSH over websockets In-Reply-To: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> Message-ID: <54CAABD9.4030502@gmail.com> On 29/01/15 21:15, Alex Bligh wrote: > Be frightened: > https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=en > That's a ssh client implemented in chromium, not a web server acting as sshd. However... ?Secure Shell also knows how to connect to an HTTP-to-ssh relay that was built inside Google. Unfortunately that relay isn't open source, and Google doesn't maintain a public pool of relays? -- http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob;f=chromeapps/nassh/doc/faq.txt Phil wrote: > My main motivation is that it is generally easier to route HTTP across > multiple corporate firewalls than getting ports opened for ssh (even if it > is an embedded sshd such as in gerrit rather than an actual shell). It will depend on how picky the firewalls are. You may prefer to embed it into a https stream, such as using a proxy command of socat - openssl-connect:%h:%p From phil at dunlop-lello.uk Fri Jan 30 18:39:05 2015 From: phil at dunlop-lello.uk (Phil Lello) Date: Fri, 30 Jan 2015 07:39:05 +0000 Subject: SSH over websockets In-Reply-To: <54CAABD9.4030502@gmail.com> References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> <54CAABD9.4030502@gmail.com> Message-ID: On 29 Jan 2015 21:53, "?ngel Gonz?lez" wrote: > > On 29/01/15 21:15, Alex Bligh wrote: >> >> Be frightened: >> https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=en >> > That's a ssh client implemented in chromium, not a web server acting as sshd. However? > ?Secure Shell also knows how to connect to an HTTP-to-ssh relay that was built inside Google. Unfortunately > that relay isn't open source, and Google doesn't maintain a public pool of relays? > -- http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob;f=chromeapps/nassh/doc/faq.txt > > > > > Phil wrote: >> >> My main motivation is that it is generally easier to route HTTP across >> multiple corporate firewalls than getting ports opened for ssh (even if it >> is an embedded sshd such as in gerrit rather than an actual shell). > > It will depend on how picky the firewalls are. You may prefer to embed it into a https stream, > such as using a proxy command of socat - openssl-connect:%h:%p > That's certainly worth considering. However, my focus when posting was more motivated by defining a standard for ssh - over - web sockets, such as ws://host/path, along with a standard (as opposed to proxy command) implementation. I think in intranet environments tunneling over HTTP is good so that firewalls can inspect session setup/endpoints; in public environments I'd go for HTTPS to prevent precisely that. So, would a patch to the client to support hostnames as ws:// or wss:// be a welcome addition? If so, should a reference server be included too, given that I would be doing this as an apache module? Phil From aixtools at gmail.com Fri Jan 30 19:28:20 2015 From: aixtools at gmail.com (Michael Felt) Date: Fri, 30 Jan 2015 09:28:20 +0100 Subject: SSH over websockets In-Reply-To: References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> <54CAABD9.4030502@gmail.com> Message-ID: I must be missing the point here somehow. From my simple mind I think that two things would be needed - first a mod, e.g., mod_sshd, or better an addition to mod_auth and mod_proxy so that a URL could be used to initiate contact to an sshd server elsewhere. The mod_auth part could/should be used to verity the credentials to used - basically setting up the VPN between ssh and httpd as ssh; the httpd server would setup it's own separate connection with the target sshd - with mod_proxy_logic - to verify that the httpd server can and will make a connection. Lastly, to prevent a continous man in the middle the original ssh client would make a second connection to establish ciphers, mac and kex via the two connections using the httpd as man-in-the-middle. This is awkward - I apologize - but what I think I am saying is that the goal is to setup something similar to an IKE tunnel - except the destination end-point leap frogs. To maintain encryption the ssh client will need to have a secret key with the target sshd - but to communicate it would need to encrypt twice - once for the 'hop' to the httpd server - who would undo that envelope and then send this encrypted message forward - functioning more as a router because it would not necessarily need to encrypt it again to get it there. The reply, assuming the httpd is not re-encrypting the encrypted message, is a bit more complex - i.e., needs openssh cooperation/understanding. "Somehow" sshd knows there is a proxy in the middle so it also does a double encryption - initial for the other "endpoint", and one for the first hop back to the httpd (let me call it) - mid-way point. Now - repackaging/encryption will be needed so the ssh client is able to recognize IP endpoints. I suppose - there could also be requirements where re-encryption by httpd is always needed - because of firewall rules only permitting the httpd IP address endpoint to pass through ipsec/ipfilter rules. Personally - under the assumption it can be done - I doubt I would want my httpd server to be handling this kind of load. Nor would I want to be the one - depending on a role, e.g., to say to my boss, or to say to a customer buying security consultation services that "openssh is great - we have added stuff that can be used to bypass firewalls. If this kind of tunneling is something I want to support I would examine using openssh - ASIS - plus a virtual machine aka "jailed process" with it's own IP address and just use normal openssh tunneling from port X (e.g., X==80) to somewhere else. my 3 and half bits :-) On Fri, Jan 30, 2015 at 8:39 AM, Phil Lello wrote: > On 29 Jan 2015 21:53, "?ngel Gonz?lez" wrote: > > > > On 29/01/15 21:15, Alex Bligh wrote: > >> > >> Be frightened: > >> > > https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=en > >> > > That's a ssh client implemented in chromium, not a web server acting as > sshd. However? > > ?Secure Shell also knows how to connect to an HTTP-to-ssh relay that was > built inside Google. Unfortunately > > that relay isn't open source, and Google > doesn't maintain a public pool of relays? > > -- > > http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob;f=chromeapps/nassh/doc/faq.txt > > > > > > > > > > Phil wrote: > >> > >> My main motivation is that it is generally easier to route HTTP across > >> multiple corporate firewalls than getting ports opened for ssh (even if > it > >> is an embedded sshd such as in gerrit rather than an actual shell). > > > > It will depend on how picky the firewalls are. You may prefer to embed it > into a https stream, > > such as using a proxy command of socat - openssl-connect:%h:%p > > > That's certainly worth considering. However, my focus when posting was more > motivated by defining a standard for ssh - over - web sockets, such as > ws://host/path, along with a standard (as opposed to proxy command) > implementation. > > I think in intranet environments tunneling over HTTP is good so that > firewalls can inspect session setup/endpoints; in public environments I'd > go for HTTPS to prevent precisely that. > > So, would a patch to the client to support hostnames as ws:// or wss:// be > a welcome addition? If so, should a reference server be included too, given > that I would be doing this as an apache module? > > Phil > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From alex at alex.org.uk Fri Jan 30 20:18:31 2015 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 30 Jan 2015 09:18:31 +0000 Subject: SSH over websockets In-Reply-To: References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> <54CAABD9.4030502@gmail.com> Message-ID: On 30 Jan 2015, at 08:28, Michael Felt wrote: > I must be missing the point here somehow. From my simple mind I think that > two things would be needed - first a mod, e.g., mod_sshd, or better an > addition to mod_auth and mod_proxy so that a URL could be used to initiate > contact to an sshd server elsewhere. See https://github.com/abligh/apache-websocket/tree/master/vncproxy which is a fork of apache-websocket to include a generalised tcpproxy. Ignore the name vncproxy - it does some extra stuff for vnc if you want, but will forward any tcp channel. Feel free to hack it about, then forward it to 127.0.0.1:22. -- Alex Bligh From phil at dunlop-lello.uk Fri Jan 30 20:50:25 2015 From: phil at dunlop-lello.uk (Phil Lello) Date: Fri, 30 Jan 2015 09:50:25 +0000 Subject: SSH over websockets In-Reply-To: References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> <54CAABD9.4030502@gmail.com> Message-ID: On Fri, Jan 30, 2015 at 8:28 AM, Michael Felt wrote: > I must be missing the point here somehow. From my simple mind I think that > two things would be needed - first a mod, e.g., mod_sshd, or better an > addition to mod_auth and mod_proxy so that a URL could be used to initiate > contact to an sshd server elsewhere. > The mod_auth part could/should be used to verity the credentials to used - > basically setting up the VPN between ssh and httpd as ssh; the httpd server > would setup it's own separate connection with the target sshd - with > mod_proxy_logic - to verify that the httpd server can and will make a > connection. Lastly, to prevent a continous man in the middle the original > ssh client would make a second connection to establish ciphers, mac and kex > via the two connections using the httpd as man-in-the-middle. > I may have explained myself poorly. The proposed apache mod would only exist as a reference implementation to verify that the client was working correctly. I'm not thinking of supporting proxying from a webserver, other than through traditional ssh netcat-style proxying. This would simply be a mechanism to transport ssh traffic over websockets instead of vanilla TCP, to allow ssh key-based authentication of a websocket connection. The proposed use case is only for when the webserver is presenting an application that wants ssh key-based authentication. Part of my motivation is that I'd like to expose git or gerrit over websockets, and since these already support ssh key-based authentication. rsync over websockets could be good too. As far as the security/political implications go, I fully agree it might not work from a PR perspective, but I don't think this creates any more issues than allowing sshd to run as a SOCKS proxy, or dynamically forward inbound or outbound TCP. For the reference implementation itself, I was thinking of using https://github.com/disconnect/apache-websocket and providing a sshd plugin. Phil From aixtools at gmail.com Fri Jan 30 22:57:39 2015 From: aixtools at gmail.com (Michael Felt) Date: Fri, 30 Jan 2015 12:57:39 +0100 Subject: SSH over websockets In-Reply-To: References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> <54CAABD9.4030502@gmail.com> Message-ID: We may have just read in what we wanted to see ;) * an interesting question - which got me thinking. But if I were in the role of IT Dept. Manager I do not think I would want this, nor the other links suggested as related. It is very simple to verify if a client is working correctly - connect locally. Perhaps what you mean is the client compatible - as I have been discovering with my ancient ssh clients (one from 2002, something free I love and cannot update) versus clients that can be updated. So, as far as verification is concerned - to my reading this means you believe the normal port should be reachable but you are not getting the (expected) response from the client. Something much simpler already exists - both the client (ssh) as the server (sshd) support connectivity. * for tcp connectivity, for years, rather than ping I use: "telnet host port", e.g. telnet 192.168.129.70 22 - and as response I see "SSH-2.0-OpenSSH_6.7" * for regular connectivity issues - first just read the message - if any, e.g. ssh michael at 192.168.129.70 has three possible results: a) no response - perhaps a fw is blocking (or in this case, the demon is not active) C:\Users\Michael>ssh2 michael at 192.168.129.70 warning: Connecting to 192.168.129.70 failed: Destination Unreachable b) there is an authetification error - thus, there is connectivity, but no agreement on auth-handshake C:\Users\Michael>ssh2 michael at 192.168.129.70 warning: Authentication failed. Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.). c) connection successful - prompt for password, or some successful key exchange for auto-connect C:\Users\Michael>ssh2 michael at 192.168.129.70 michael's password: In closing, to validate connectivity, but not authentification just add -d 1 or -d 2 - at either end. On my server (sshd -d) I am seeing: Connection from 192.168.129.5 port 60743 on 192.168.129.70 port 22 debug1: Client protocol version 1.99; client software version 3.2.9 SSH Secure Shell Windows Client debug1: no match: 3.2.9 SSH Secure Shell Windows Client debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7 debug1: permanently_set_uid: 202/201 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] no matching cipher found: client aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com [preauth] And at the client I see: C:\Users\Michael>ssh2 -d 2 michael at 192.168.129.70 debug: Ssh2: License file not found, certificates & smart cards disabled. debug: Ssh2: User config file not found, using defaults. (Looked for 'C:/Users/M ichael/Application Data/SSH/ssh2_config') debug: Connecting to 192.168.129.70, port 22... (SOCKS not used) debug: Ssh2Transport: My version: SSH-1.99-3.2.9 SSH Secure Shell Windows Client debug: client supports 2 auth methods: 'publickey,password' debug: Ssh2Common: local ip = 192.168.129.5, local port = 60743 debug: Ssh2Common: remote ip = 192.168.129.70, remote port = 22 debug: SshConnection: Wrapping... debug: Remote version: SSH-2.0-OpenSSH_6.7 debug: OpenSSH: Major: 6 Minor: 7 Revision: 0 debug: Ssh2Transport: All versions of OpenSSH handle kex guesses incorrectly. debug: Ssh2Transport: Algorithm negotiation failed for c_to_s_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com debug: Ssh2Transport: Algorithm negotiation failed for s_to_c_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com debug: Ssh2Transport: lang s to c: `', lang c to s: `' debug: Ssh2Transport: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host_key = ssh-dss) debug: Ssh2Common: DISCONNECT received: Algorithm negotiation failed. warning: Authentication failed. Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.). debug: Ssh2Common: Destroying SshCommon object. debug: SshConnection: Destroying SshConn object. So, if I read you correctly - my question now is: how is using a websocket an improvement over what is already available? On Fri, Jan 30, 2015 at 10:50 AM, Phil Lello wrote: > > On Fri, Jan 30, 2015 at 8:28 AM, Michael Felt wrote: > >> I must be missing the point here somehow. From my simple mind I think >> that two things would be needed - first a mod, e.g., mod_sshd, or better an >> addition to mod_auth and mod_proxy so that a URL could be used to initiate >> contact to an sshd server elsewhere. >> The mod_auth part could/should be used to verity the credentials to used >> - basically setting up the VPN between ssh and httpd as ssh; the httpd >> server would setup it's own separate connection with the target sshd - with >> mod_proxy_logic - to verify that the httpd server can and will make a >> connection. Lastly, to prevent a continous man in the middle the original >> ssh client would make a second connection to establish ciphers, mac and kex >> via the two connections using the httpd as man-in-the-middle. >> > > I may have explained myself poorly. The proposed apache mod would only > exist as a reference implementation to verify that the client was working > correctly. I'm not thinking of supporting proxying from a webserver, other > than through traditional ssh netcat-style proxying. This would simply be a > mechanism to transport ssh traffic over websockets instead of vanilla TCP, > to allow ssh key-based authentication of a websocket connection. The > proposed use case is only for when the webserver is presenting an > application that wants ssh key-based authentication. Part of my motivation > is that I'd like to expose git or gerrit over websockets, and since these > already support ssh key-based authentication. rsync over websockets could > be good too. > > As far as the security/political implications go, I fully agree it might > not work from a PR perspective, but I don't think this creates any more > issues than allowing sshd to run as a SOCKS proxy, or dynamically forward > inbound or outbound TCP. > > For the reference implementation itself, I was thinking of using > https://github.com/disconnect/apache-websocket and providing a sshd > plugin. > > Phil > From nkadel at gmail.com Fri Jan 30 23:32:58 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 30 Jan 2015 07:32:58 -0500 Subject: SSH over websockets In-Reply-To: References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> <54CAABD9.4030502@gmail.com> Message-ID: On Fri, Jan 30, 2015 at 6:57 AM, Michael Felt wrote: > We may have just read in what we wanted to see ;) > > * an interesting question - which got me thinking. But if I were in the > role of IT Dept. Manager I do not think I would want this, nor the other > links suggested as related. > > It is very simple to verify if a client is working correctly - connect > locally. Perhaps what you mean is the client compatible - as I have been > discovering with my ancient ssh clients (one from 2002, something free I > love and cannot update) versus clients that can be updated. So, as far as > verification is concerned - to my reading this means you believe the normal > port should be reachable but you are not getting the (expected) response > from the client. > > Something much simpler already exists - both the client (ssh) as the server > (sshd) support connectivity. > * for tcp connectivity, for years, rather than ping I use: "telnet host > port", e.g. telnet 192.168.129.70 22 - and as response I see > "SSH-2.0-OpenSSH_6.7" Personally, I prefer 'nc hostname 22" or "ssh-keyscan hostname" or even "/usr/lib64/nagios/plugins/check_ssh -H hostname". The "telnet" tool is a not an easily scriptable interface, and has become pretty deprecated in modern Linux systems. Most of those are also available in CygWin for Windows users. > * for regular connectivity issues - first just read the message - if any, > e.g. ssh michael at 192.168.129.70 has three possible results: > a) no response - perhaps a fw is blocking (or in this case, the demon is > not active) > C:\Users\Michael>ssh2 michael at 192.168.129.70 > warning: Connecting to 192.168.129.70 failed: Destination Unreachable > > b) there is an authetification error - thus, there is connectivity, but no > agreement on auth-handshake > C:\Users\Michael>ssh2 michael at 192.168.129.70 > warning: Authentication failed. > Disconnected; key exchange or algorithm negotiation failed (Algorithm > negotiation failed.). > > c) connection successful - prompt for password, or some successful key > exchange for auto-connect > C:\Users\Michael>ssh2 michael at 192.168.129.70 > michael's password: > > In closing, to validate connectivity, but not authentification just add -d > 1 or -d 2 - at either end. > > On my server (sshd -d) I am seeing: > Connection from 192.168.129.5 port 60743 on 192.168.129.70 port 22 > debug1: Client protocol version 1.99; client software version 3.2.9 SSH > Secure Shell Windows Client > debug1: no match: 3.2.9 SSH Secure Shell Windows Client > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.7 > debug1: permanently_set_uid: 202/201 [preauth] > debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth] > debug1: SSH2_MSG_KEXINIT sent [preauth] > debug1: SSH2_MSG_KEXINIT received [preauth] > no matching cipher found: client > aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour > server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, > aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com [preauth] > > And at the client I see: > C:\Users\Michael>ssh2 -d 2 michael at 192.168.129.70 > debug: Ssh2: License file not found, certificates & smart cards disabled. > debug: Ssh2: User config file not found, using defaults. (Looked for > 'C:/Users/M > ichael/Application Data/SSH/ssh2_config') > debug: Connecting to 192.168.129.70, port 22... (SOCKS not used) > debug: Ssh2Transport: My version: SSH-1.99-3.2.9 SSH Secure Shell Windows > Client > > debug: client supports 2 auth methods: 'publickey,password' > debug: Ssh2Common: local ip = 192.168.129.5, local port = 60743 > debug: Ssh2Common: remote ip = 192.168.129.70, remote port = 22 > debug: SshConnection: Wrapping... > debug: Remote version: SSH-2.0-OpenSSH_6.7 > debug: OpenSSH: Major: 6 Minor: 7 Revision: 0 > debug: Ssh2Transport: All versions of OpenSSH handle kex guesses > incorrectly. > debug: Ssh2Transport: Algorithm negotiation failed for c_to_s_cipher: > client list: > aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour > vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, > aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com > debug: Ssh2Transport: Algorithm negotiation failed for s_to_c_cipher: > client list: > aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour > vs. server list : aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com, > aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com > debug: Ssh2Transport: lang s to c: `', lang c to s: `' > debug: Ssh2Transport: Couldn't agree on kex or hostkey alg. (chosen_kex = > NULL, chosen_host_key = ssh-dss) > debug: Ssh2Common: DISCONNECT received: Algorithm negotiation failed. > warning: Authentication failed. > Disconnected; key exchange or algorithm negotiation failed (Algorithm > negotiation failed.). > debug: Ssh2Common: Destroying SshCommon object. > debug: SshConnection: Destroying SshConn object. > > So, if I read you correctly - my question now is: how is using a websocket > an improvement over what is already available? "When what you have is a hammer, everything looks like a nail." I agree that the available command line tools are sufficient. I can completely understand wanting to wedge it into web clients and web servers, but I'm afraid personally of the security ramifications of gluing it into an entirely distinct set of tools, many of which are maintained by security casual software authors. From keisial at gmail.com Sat Jan 31 02:43:09 2015 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Fri, 30 Jan 2015 16:43:09 +0100 Subject: SSH over websockets In-Reply-To: References: <4590FB1A-5F6F-4B1D-B832-F8FEB2A5B9FF@alex.org.uk> <54CAABD9.4030502@gmail.com> Message-ID: <54CBA68D.8000207@gmail.com> On 30/01/15 08:39, Phil Lello wrote: > > > It will depend on how picky the firewalls are. You may prefer to > embed it into a https stream, > > That's certainly worth considering. However, my focus when posting was > more motivated by defining a standard for ssh - over - web sockets, > such as ws://host/path, along with a standard (as opposed to proxy > command) implementation. > How would then programs (like vcs) that use a path like ssh://host/path to mean "connect remotely using ssh" learn what to do with a ssh-over-websocket url if you used ws:// there? IMHO ssh-over-websocket should be ssh+ws:// (if at all desired) > I think in intranet environments tunneling over HTTP is good so that > firewalls can inspect session setup/endpoints; in public environments > I'd go for HTTPS to prevent precisely that. > The first thing a websocket client would do if knowingly using a proxy would be to open a HTTP tunnel with CONNECT. If that's allowed by the proxy, you could as well use ssh-over-http directly, instead of websockets. > So, would a patch to the client to support hostnames as ws:// or > wss:// be a welcome addition? If so, should a reference server be > included too, given that I would be doing this as an apache module? > If any, I would make ssh connect directly to a ssh:// url, and for a ssh+foo(\+[^:])*:// execute a 'foo' wrapper (eg. /usr/bin/tunnel.foo) as ProxyCommand I'm not convinced of the general usefulness of doing ssh over websockets yet. From aixtools at gmail.com Sat Jan 31 04:14:00 2015 From: aixtools at gmail.com (Michael Felt) Date: Fri, 30 Jan 2015 18:14:00 +0100 Subject: Patches for openssh-6.7p1 (aka -stable) Message-ID: I feel I am running in circles trying to find patches aka -stable for openssh-6.7p1 - i have found the snapshots (which I am guessing are more a -dev branch than a maintainence/-stable branch. FYI: for someone new like myself it was a bit confusing to be sent to an errata page that only goes to version 5.6 - until I (hope I) figured it out that that is the version number of openbsd - not openssh. So, since I am not sure what the git URL, etc. will send me to I am asking for clarification. Thanks, Michael