I had quite a time trying to figure out how to make openssh tools work on a system with not unique uids... For different reasons I have a system with several "root" accounts (uid 0). Although in the man pages it is written: Normally each user wishing to use SSH with RSA or DSA authentication runs this once to create the authentication key in $HOME/.ssh/identity, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa. Additionally, the system adminis- trator may use this to generate host keys, as seen in /etc/rc. <above is from ssh-keygen> $HOME is never used. Instead, the home from /etc/passwd [returned by getpwuid(getuid))] is used in *TWO* places for ssh. I haven't cheked ssh-keygen, as it is not so critical. So, any specific reasons why this is so? I know this is the easy way (no error checking,etc.), but it is not the good way. At least update the documentation. I hacked a very dirty patch, please have a look. It can be improved a lot, I know, but for an hour I came with only that.
Created attachment 366 [details] _Dirty_ patch to allow non unique UIDs No checking whatsoever, trusting the enviroment, hardcoded 200 chars for $HOME, $LOGNAME... A lot to work on, but better than nothing as a start.
For a start, you don't need to malloc memory for or strdup the result of getenv, as it just returns a pointer to the environment space. Instead of: original_user_home_dir=(char *)malloc(sizeof(char)*200); original_user_home_dir = getenv("HOME"); pw->pw_dir = xstrdup(original_user_home_dir); you can just have: pw->pw_dir = getenv("HOME"); I don't know that this patch is a good idea, though (auth.c also uses tilde_expand_filename and there's probably no environment when it's called and you shouldn't trust it even if there was). I do agree that the man page for ssh-keygen is a little misleading.
Created attachment 888 [details] Don't pretend we accept $HOME This patch replaces $HOME with ~ in the manpage, matching what we actually do.
patch applied, will be in 4.2
It was suggested that the documentation be changed to reflect the fact that ssh does not use "$HOME" but "~" to determine the current user's home directory. This solution is invalid because "~" means exactly the same as "$HOME". What ssh currently does is this: It searches /etc/passwd for the FIRST entry that matches the current user's uid, then uses that entry's home directory. Ssh's current behavior is in contrast with what unix shells and other unix programs do. For all I know, shells and system tools are all carefully designed to support non-unique uids (for practical reasons which I will explain here, if desired). I suggest ssh should adhere to the standard and really use $HOME, instead of its current behavior. The only problem is that the suggested change will break backwards compatibility. For example, if there's an administrator named Joe (user "joe", home "/home/joe", uid 0), he probably put his ssh config in ~root/.ssh/config instead of /home/joe/.ssh/config, because that's where ssh has been looking for it so far. If we fix the bug now, Joe's ssh config under ~root/.ssh/config will no longer work, and Joe will be pissed... I suggest we do it anyway, because Joe will benefit from it in the long run. Or maybe we should introduce a non-default ssh config switch which activates the new behavior which could be placed in the system default ssh_config. This would not break backward compatibility.
Sorry, we won't be changing things to support non-unique UIDs.
Is there any particilar reason why openssh should not support non-unique id system? If not, somebody (even me) might just come up with a better patch. And if it is to be marked RESOLVED FIXED, I think it is necessary to have the better explanaition that Andy provided in comment #5. Just a s/\$HOME/\~/g is not enough. Reopening...
Using non-unique ids is a bad idea for a whole heap of reasons and we aren't going to make our code ugler and more complex for a bad idea. I'm sorry if you don't like this, but that is our decision. If you don't like this, then feel free to patch your own sshd - that is why we give away the source code.
What about users who change their $HOME environment variable in a login script? For example, I'm logging in as a NIS user with an NFS mounted homedir. However, I also have a local homedir that I run out of when the network gets slow. Most other programs work correctly just by setting $HOME=/localhost/username but ssh does not. Please reconsider changing the behavior to honor the $HOME environment variable. The $HOME variable isn't *only* used for non-unique UIDS.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.
This does not just affect non-unique UIDs. It also means that if I run ssh under sudo or fakeroot (such as when building a package with distcc using ssh), ssh fails the host key check because it looks in /root/.ssh for the known_hosts, rather than /home/josh/.ssh . Running with a $HOME different from the home directory of the current user has useful applications; please don't break those applications by ignoring $HOME.
The documentation matches reality, and we have no intention of changing the tools' behaviour. For a start it would break working configurations, but it would also require the removal of permission and ownership checks on .ssh/config, keys, etc.
Close resolved bugs after release.