On Tue, 2015-06-30 at 13:30 +0200, Vincent Lefevre wrote: > You should learn how terminals work. When using a terminal, the > remote > charmap MUST be the same as the local one (or be a subset), otherwise > the terminal cannot interpret the byte sequences correctly. Sure... I haven't said that I wouldn't know, have I? o.O > So, if there is no way to tell the remote side what the local charmap > is, then the only possibility is that the remote side uses a charmap > compatible with every other charmap, i.e. US-ASCII. Seems to work for me quite well in practise and I connect to hundreds of different nodes here at the supercomputing centre, with different distros and versions thereof. Probably because most of these systems are simply set up to use either UTF8 or something compatible. But the potential issue I've described is still in place. If the remote side would accept things like charmap/locale automatically it may change it's behaviour/output (e.g. the sequences may be redirected to a file and not go to your terminal). That could possibly break things. > > Plus there is no real guarantee that by accepting something like > > TERM, > > FYI, again, TERM transmission is part of SSH, and this is AFAIK not > configurable: it is transmitted to the other side. Yes, and what I've told you here was, that even though this is transmitted, you have no guarantee that things really work,... as TERM may be wrongly set (e.g. as GNOME does) or the terminfo files may be newer/older at the remote side, and so on. > That's true, and that's why the user needs to fix things by rc files > on the other side. And that's why some non-standard env variable is > needed to transmit the charmap (I use LC_CHARMAP), because the > standard > LC_* variables do not (always) contain this information. Still, the > only way to get such information is to transmit it to the remote > side, > and SSH developers decided that SendEnv/AcceptEnv was the way to do > (except for TERM, which is always transmitted when a pty is > requested, > i.e. when it makes sense). > This is not completely true: this is the case *by default*, but the > user can always change the default. When I get an account on a > machine, > one of the first things I do is to install terminfo files in my home > directory, so then I always have the same ones on all machines. Which is a nice solution, but I fail to see how any of this justifies that we send/accept even more env vars that may cause troubles. What keeps you from also just setting your LC_*, XTERM_* and so on in your remote user's .profile/.bashrc/etc. *if* your sysadmins are so uncooperative not to add them to the accept list? > > Again take TERM... many other terminal emulators != xterm (or is it > > just GNOME? ;) ) still set it to "xterm", thereby breaking the > > whole > > idea of TERM. > > Such terminal emulators are broken, and I don't use them, unless the > user can choose the value of TERM (remember that the user can also > install terminfo files is his home directory). Hehe,... I had similar arguments when I reported this upstream (IIRC at the Debian level my bug report was simply ignored)... but they brought up some obsucre reasons why VTE/Gnome Terminal is amongst the few emulators where it's simply necessary that they fake xterm. Perhaps you can try to convince them to behave nicely :) > > Doesn't it also potentially affect the output/behaviour of > > programs? > > It allows to get the same output as characters. For instance, if > the charmap is passed correctly, "env LANG=fr_FR cp" will always > output something like: > > cp: opérande de fichier manquant > Saisissez « cp --help » pour plus d'informations. > > Otherwise one can get garbage in the terminal. Well but you'd only get the same output: a) on terminals b) when these have the correct charmap set. If for some reasons the output goes into a file, which can happen, then the binary representation would be different, wouldn't it? > I don't care what upstream does. Well I can't help you if you simply ignore intentional and good choices. > With Debian, the default is not > to have restricted user environments: when SSH is installed, any > local end user can log in via SSH. So, it makes sense to have a > default AcceptEnv following this. Then you could again argue to that we simply Accept/Send *, including e.g. LD_LIBRARY_PATH. May be of no harm for your use cases, cause when you can log in anyway you can also set it manually. But then again, you'd simply ignore the needs of all those users of SSH, that use it differently from your personal use cases. As indicated before, I don't think it would be appropriate to change a safe default to something that helps you with your sysadmins or charmap problems, or that may help e.g. myself with my special setups,... which may however cause issues to anyone else, especially not if those issues are possibly security relevant and if they wouldnd't be immediately visible. > In any case, if you think that there is any risk with SSHENV_FOO, > then there is also a risk for SSH_ORIGINAL_COMMAND. > > Anyway, if some program wants to use SSHENV_FOO or > SSH_ORIGINAL_COMMAND > for its own use, it should unset it first. This is good programming > practice. So since one cannot know in advance which names may ever be used by some other application, one would basically need to unset everything (except those names for which one knows that one definitely uses them securely, regardless of their content), right? Then we're basically back to having this job done safely by e.g. ssh (which it does per default). And as I've said before,... expecting that every program can/would do such proper cleanup is simply naive - which is again just the reason why we don't place this responsibility not into e.g. each and every CGI script but into Apache. > > But SSH_ORIGINAL_COMMAND is at least not generally set, but rather > > only > > when command="command" and I think ForceCommand are used, which > > both > > again, isn't the case per default. > > But if one doesn't use them, then the user can run any command by > default, and in particular, change the environment and do much more > things. Of course. But it's not acceptable that we silently put responsibility on the other people and possibly cause them troubles just because you, me or anyone else thinks that his use case of SSH would be the major use case and that all others would need to adapt to it. > > > BTW, a ssh server can have several users, with different needs: > > > some will need some environment variable passing, others won't > > > need that and can always clean up the environment before doing > > > anything else (say, start with "env -i" or do something similar). > > > > Which can be easily facilitated by a number of technologies in > > OpenSSH: > > - environment="NAME=value" in authorized_keys > > - PermitUserEnvironment in sshd_config > > (notice again, that the default to this directive is of course > > "no" > > for security reasons - just as with Send/AcceptEnv) > > - Match/Host blocks that select config directive based on the > > User/Host > > in ssh[d]_config > > ??? You said that some users would need env var passing some not. Again you wish for the default to be to transmit more (or everything) and want to put the burden/responsibility of cleaning things up on the others. Transmitting "more" would be helpful for your use cases,... so have it done and, and let everyone else adapt,... ranging from possibly years old code which no one really knows anymore. As I've said, that would bad behaviour/paradigm. Instead I showed you some ways where you could selectively configure the send/accepted environment based on the authenticating user, the user logged in to, and so on... by which one wouldn't need to possibly disturb everyone else. > But SendEnv is an exception: > > Multiple environment variables may be separated by whitespace or > spread across multiple SendEnv directives. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > i.e. it seems that a SendEnv directive is not overwritten. Hmm I guess that behaviour simply assumes that one cleverly sets up ssh[d]_config and not sets these directives on a too global scope... which again fits the default in OpenSSH to not Send/AcceptEnv. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature