http://permalink.gmane.org/gmane.ietf.secsh hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.secsh/6888 <pre>Please Contact Us With This Email: apnapaisaloan.com12&lt; at &gt;hotmail.com Apna Paisa Loan Company , ? Are you in any financial mess or do you need a loan to start up your own business? at 2% rate? ; Email :apnapaisaloan.com12&lt; at &gt;hotmail.com (1) Full Names: (2) State/Country: (3)Amount needed as loan): (4)Loan duration: (5)Cell-Phone number: Mr. Harsh Roongta </pre> Apna-Loan 2013-04-09T20:51:39 http://permalink.gmane.org/gmane.ietf.secsh/6887 <pre> Atención Estimado usuario de correo electrónico! El Administrador de e-mail está teniendo informe de errores de sobrecarga en su cuenta de correo electrónico. Esta cuenta se cerró para evitar accidentes base de datos. Para aumentar el tamaño del buzón, haga clic o copie el enlace de abajo y llene el vacío columnas: http://www.ljgalleries.ca/Contact/use/webform1/form1.html Neglet de esta alerta de advertencia se traducirá en el cierre de la cuenta de correo electrónico en breve! Haga clic aquí http://www.ljgalleries.ca/Contact/use/webform1/form1.html Gracias por cumplir! 83.137.226.165 Administrador Copyright &lt; at &gt; sistema de correo electrónico </pre> Admision Cajamarca 2013-04-07T14:21:14 http://permalink.gmane.org/gmane.ietf.secsh/6886 <pre>Dear our customer, This is an email from vpsoft company! VpSoft.us is a software retail and wholesale Store. Our company has been in this line of business for many years and enjoys high international prestige. And our products are of very good quality and our firm is always regarded by our customers as the most reliable one. A large-scale promotions activities will be held in our company. The DVD software still free ship and the download software will be send in 24 hours. We have many types of products: Office 2013(priced from $119.00) Office 2010(priced from $66.00) Office 2011(priced from $76.00) Windows 8 (priced from $59.00) Windows 7 (priced from $77.00) QuickBooks Pro 2013(priced from $129) ADOBE($66.00), Rosetta Stone($88.65), Exercise &amp; Fitness($42.00), 3D MAX($165.00), CorelDRAW($145.00) and so on. We will present with $5.00 coupons to the new customers. The coupon: 315f4f17bc Welcome to visit our website: www.vpsoft.us If you have any question, please email us. Thank you. Best Regards www.vpsoft.u</pre> LUCAS 2013-04-02T02:35:01 http://permalink.gmane.org/gmane.ietf.secsh/6885 <pre> Well, sure, same as if I'm on an ASCII device, or anything else that doesn't generate them. The same, in fact, as trying to generate UTF-8 octet streams with an 8859-1 device (which is someetimes possible but often not possible; many UTF-8 octet streams involve 0x80-0x9f octets, which are not 8859-* printables and may well be difficult to generate on an input device designed for an 8859-* encoding). It is possible at all for 8859-1 and 8859-7 only because the sets of octets that encode printables are so similar between the two encodings. It quite likely would border on impossible for, say, ASCII and EBCDIC. My point was not that it's possible or impossible. My point is that the issue is pushed out far enough that it's user-visible. ...because, of course, all Unix systems run X, or can otherwise handle arbitrary encodings. Depends. Even in X, there is the keyboard issue; I don't know what xterm does when it gets Greek keysyms but is running in an 8859-1 locale, or conversely, but I doubt it Just Wor</pre> Mouse 2013-04-02T05:15:06 http://permalink.gmane.org/gmane.ietf.secsh/6884 <pre> The ssh way, which requires the sysadmin to know what encoding is used. And if you're on a device using utf-8, you're going to have some difficulty generating the right octets. Now, if you're logging in from another unix system, you could always start an xterm in a latin1 locale (which you might want to do anyway, to handle the encoding in the channel data better), and use that for logging in, and things should work just fine. But on other devices, it might be harder to deal with. Regards, /Niels </pre> Niels Möller 2013-04-02T04:43:54 http://permalink.gmane.org/gmane.ietf.secsh/6883 <pre> need a Personal Representative to work in your area on part time and i will pay six hundred dollars per week. Kindly send your name &amp; location for more info. </pre> info< at >privateassignment.com 2013-04-02T04:23:23 http://permalink.gmane.org/gmane.ietf.secsh/6882 <pre> The biggest alternative to password files and/or ttys would seem to be PAM, like pam_ldap or pam_kerberos LDAP has enough native support for UTF-8 that I would think checking passwords with LDAP bind could support UTF-8, but still getting everything else consistent could be tough. </pre> Albert Lunde 2013-04-02T01:06:57 http://permalink.gmane.org/gmane.ietf.secsh/6881 <pre> Usernames and passwords are the only things that came to mind immediately. On a quick look at the RFCs, I also see: - SSH_MSG_USERAUTH_BANNER text - SSH_MSG_USERAUTH_PASSWD_CHANGEREQ prompt - SSH_MSG_DISCONNECT reason - SSH_MSG_DEBUG text - SSH_MSG_CHANNEL_OPEN_FAILURE description - SSH_MSG_CHANNEL_REQUEST exit-signal error message Some of these (eg, DISCONNECT reasons) are not much of an issue. Others (eg, USERAUTH_BANNER text) are not so simple. Which is? I gave two alternatives; your "this is the right way" is rather ambiguous. There actually is a third option, which, as theroetically undesirable as it is, has the advantage that it actually works in practice: push that up to the user. If my username - or password - is (hex) 4d f8 b5 a7 eb, then if I'm at a device which uses 8859-1, I need to type &lt;M&gt; &lt;o-slash&gt; &lt;micro&gt; &lt;section&gt; &lt;e-diaeresis&gt;; if I'm at a device which uses 8859-7, I need to type &lt;M&gt; &lt;psi&gt; &lt;dialytika tonos&gt; &lt;section&gt; &lt;lambda&gt;; if I'm using CP850, I don't know what the last four oc</pre> Mouse 2013-04-01T23:21:07 http://permalink.gmane.org/gmane.ietf.secsh/6880 <pre> Are you thinking only about usernames and passwords, or are there other strings on the wire where this is a problem? I think this is the right way, at least in theory. If you have non-ascii usernames and passwords on your system, and want to accept logins from remote systems, you can't expect any interoperability if you don't even know what character set you are using. You'd have to either tell the other end what you're using, or use some specific encoding on the wire and convert locally. SSH chooses the latter approach, but the first approach would have the same need for configurating what encoding to advertise. Not sure how big a hassle it is in practice. I guess in theory it's possible on a unix system to have different user's use different character encodings for their passwords. I don't see any good way to provide reliable interoperability in that case (and no, I don't think it's a good solution to say passwords are octet strings and it's the user's responsibility to figure out what the correspon</pre> Niels Möller 2013-04-01T19:31:54 http://permalink.gmane.org/gmane.ietf.secsh/6879 <pre> The basic problem is that various strings are specified as being UTF-8, but things in question are things that the systems in question don't store as character strings, but rather as octet strings. This means that either an ssh implementation has to have some configuration switch telling it what the string encoding is in use or it will conform only if the local admins stick to UTF-8 for those things. (In some cases it's conceptually possible to make the encoding setting user-specific, but in other cases, such as usernames, it's not.) There _is_ a third option, sort of, in that the implementation can pretend that anything that doesn't stick to the ASCII range - or, perhaps, which isn't a valid UTF-8 string - doesn't exist, but that's really just a hardcoded version of the "encoding in use is ASCII" (or "...is UTF-8") configuration, combined with a particular error recovery technique upon seeing octet sequences which are invalid for that encoding. In moussh's case, I chose to treat those things as opaque </pre> Mouse 2013-03-31T01:57:30 http://permalink.gmane.org/gmane.ietf.secsh/6878 <pre> Yeah. And, if I had control over the relevant buying decisions, that might actually happen. That too. :( Name-and-shame occasionally works, too; if I could recall which devices they were, I'd name them here. Agreed. Absolutely. I'll reply to just this part and change the Subject:. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmouse&lt; at &gt;rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B </pre> Mouse 2013-03-31T01:04:36 http://permalink.gmane.org/gmane.ietf.secsh/6877 <pre> &lt;sigh&gt; What's supposed to happen here is that you match on the server version, turn off the features that cause it to break, and then stop buying from that vendor until they fix their stuff. :-) Unfortunately, for that to be effective, you usually have to be large and/or numerous. Either that, or you file a bug report, and they fix it. I've heard that sometimes that works, against all reasonable expectations. Sometimes. True, and this is as it should be. We do seem to have a lot of influence over what actually gets deployed, so the system seems to mostly work. In the meantime, I like to think that being "opt-in" gives us the flexibility to be fairly particular about things. For that matter, the same is true of the &lt; at &gt;domain stuff - since it's easy for others to accept extensions, we don't have to standardize everything anyone might want to do. Hm? That seems fairly surprising, given that we had what claimed to be working implementations before we ever finished the specs. Perhaps you'd care t</pre> Jeffrey Hutzelman 2013-03-30T23:56:04 http://permalink.gmane.org/gmane.ietf.secsh/6876 <pre>Dear our customer, This is an email from vpsoft company! VpSoft.us is a software retail and wholesale Store. Our company has been in this line of business for many years and enjoys high international prestige. And our products are of very good quality and our firm is always regarded by our customers as the most reliable one. A large-scale promotions activities will be held in our company. The DVD software still free ship and the download software will be send in 24 hours. We have many types of products: Office 2013(priced from $119.00) Office 2010(priced from $66.00) Office 2011(priced from $76.00) Windows 8 (priced from $59.00) Windows 7 (priced from $77.00) QuickBooks Pro 2013(priced from $129) ADOBE($66.00), Rosetta Stone($88.65), Exercise &amp; Fitness($42.00), 3D MAX($165.00), CorelDRAW($145.00) and so on. We will present with $5.00 coupons to the new customers. The coupon: 315f4f17bc Welcome to visit our website: www.vpsoft.us If you have any question, please email us. Thank you. Best Regards www.vpsoft.u</pre> DARREL 2013-03-29T20:52:02 http://permalink.gmane.org/gmane.ietf.secsh/6875 <pre> We _already_ have that. I've seen (relatively) numerous embedded devices that claim to speak ssh, including using port 22, but actually speak a closely related protocol in which the private-part&lt; at &gt;domain extensibility mechanism does not work the way it does in ssh. (I haven't probed the envelope of the issue enough to know whether it is completely busted or busted only partially; I just know that when I don't turn that stuff off, they ungracefully close the connection on me when talking with moussh.) Of course, even this much is still only advisory in most respects. The IETF, IANA, and related bodies have no ability, either de jure or de facto, to prevent you, me, or anyone else from running not-quite-ssh software such as you'd now get by checking out moussh's IUTF8 branch (which now includes IUTF8 with value 42, as discussed upthread). ...this is just as well, actually, because ssh as specified is basically unimplementable on many - most? - Unix variants. /~\ The ASCII Mouse \ / Ribbon Campaign </pre> Mouse 2013-03-30T04:13:10 http://permalink.gmane.org/gmane.ietf.secsh/6874 <pre> On the contrary, that's exactly what you should do. What you should generally _not_ do is appear out of nowhere and say "here's code that uses this IANA-managed code point that hasn't been registered; please distribute and run it", because that creates interoperability problems. What happens when someone else comes along and uses that code to mean something else? Now you have two different programs floating around on the Internet that claim to support the same protocol, but they don't agree on what that protocol means. It's not the same as making a change that's only visible to programs that link against your library; this change is visible to the entire Internet. The answer is that we avoid that problem by having a central authority (IANA) whose job is to maintain a record of which codes mean what, and to avoid assigning or registering conflicting values. In this case, mostly because the number of available codes is small(*), the only way to obtain a code is to publish an IETF consensus document(+) w</pre> Jeffrey Hutzelman 2013-03-30T03:37:30 http://permalink.gmane.org/gmane.ietf.secsh/6873 <pre> On 30 Mar 2013, at 01:52, Mouse &lt;mouse&lt; at &gt;Rodents-Montreal.ORG&gt; wrote: I can probably help there. If an I-D on this appears to have consensus I'd be happy to sponsor it to become an RFC. So far it looks good S </pre> Stephen Farrell 2013-03-30T02:01:07 http://permalink.gmane.org/gmane.ietf.secsh/6872 <pre> Yes. Ah. Then, yes. The `feature' I as I understood it was something more like "IUTF8 in the tty driver modes". Certainly...though, as I think I remarked, it is difficult for me to test such a thing, since I don't run any OSes which have IUTF8. Offhand, your patch looks correct, though it's possible there's something else which needs to be changed which doesn't come to mind immediately - I'd grep for one of the other c_iflag bits to look for any such possible places. It's certainly very close. It's close enough for this. The master copy of moussh is kept as a git tree (clonable from git://git.rodents-montreal.org/moussh); in case you care, I've just now updated the FTPable copy to match the current tip of the master branch. I'll create a branch IUTF8 and add IUTF8 as if it were standard with value 42 there, to be merged (or, more likely, cherry-picked) into master if-and-when appropriate. That much, I believe you can; I-Ds get published with some pretty wacky content (draft-terrell-logic-anal</pre> Mouse 2013-03-30T01:52:27 http://permalink.gmane.org/gmane.ietf.secsh/6871 <pre>Hi David, On Fri, 29 Mar 2013, David Madore wrote: &lt;eliding some discussion&gt; That is the right way to do this. I'll send you separately an xml2rfc template that you can fill in, with instructions on how to submit it to the ID repository. Once you have published this as an Internet Draft, bring the discussion back to this group. Update the draft if needed and I'll tell you what to do to get it published as an RFC. Best regards, Chris </pre> Chris Lonvick 2013-03-29T18:47:33 http://permalink.gmane.org/gmane.ietf.secsh/6870 <pre> Please correct me if I'm wrong, but I seem to understand that moussh supports the IUTF8 mode using a private channel approach, which achieves the same purpose but in a different way from what I'd like to see standardized. I assume the reason you chose to use a private channel is precisely that the value for the IUTF8 terminal mode is not standardized: so this supports my statement "SSH implementors will not implement the feature unless it is normalized" (although the word "feature" was probably badly chosen: I meant something like "protocol token"). Would you be willing to create - if only for testing purposes - a version of moussh that implements the IUTF8 mode using protocol encoded terminal mode 42? I'm attaching a patch that I think will do this, based on the source code I found in &lt;URL: http://ftp.rodents-montreal.org/mouse/local/src/moussh/moussh/ &gt;, which may or may not be the appropriate version to use. It would be great if we could check interoperability with the patched version of OpenSSH I j</pre> David Madore 2013-03-29T17:32:08 http://permalink.gmane.org/gmane.ietf.secsh/6869 <pre>Attached is a(n absolutely trivial) patch that adds the IUTF8 terminal mode (with code 42) to OpenSSH. Prebuilt Debian packages for those architectures I was able to build for, for testing and stable distributions, are available in &lt;URL: ftp://quatramaran.ens.fr/pub/madore/misc/openssh-with-iutf8/ &gt;. It works for me (transmits the IUTF8 mode when both the server and client are patched, and, of course, does not break when only one of them is). I would love to see some independent confirmation, though. I understand that the Debian maintainer's position is that this patch will not be applied until the value is standardized. So this patch is submitted for testing purposes. I have written a separate email to the authors of RFC 4250 to ask for their guidance on how to get things moving on the standardization front, although I fear a chickend-and-egg problem. I am willing to try writing an Internet draft if nobody else will, but without some weight to back it up I'm afraid it won't go far. Happy hacking, </pre> David Madore 2013-03-29T17:05:03 http://permalink.gmane.org/gmane.ietf.secsh/6868 <pre>I'm working on improving my ssh client's connection setup time, round trips etc. The current behaviour of first_kex_packet_follows isn't useful where implementations have differing sets of kex or host key methods. I'm proposing a small modification allowing first_kex_packet_follows to be used between any implementations. Currently for first_kex_packet_follows to be utilised the first listed algorithm must be the same on both sides. For example OpenSSH specifies ssh-rsa-cert-v01&lt; at &gt;openssh.com as its first host key algorithm - first_kex_packet_follows can't work unless the other side also implements that. I've found a couple of old list mails that are relevant [1][2]. Section 7 of rfc4253 has: """The guess is considered wrong if: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or ...""" The modified behaviour would be: """The guess is considered wrong if: o the preferred (first listed) kex algorithm and/or the preferred host key </pre> Matt Johnston 2013-03-29T15:34:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.secsh