I have finally figured out why my backups stopped working -- I upgraded ssh. When I run it as root under (the equivalent of) sudo, it exits without doing anything, saying permanently_set_uid: was able to restore old [e]gid This may be somebody's idea of a good idea, but it is not mine. I need to use ssh because NFS is too flaky. If you can't fix ssh, at least I urge you to fix that horrible error message. And add "ssh:" to its errors. And make it not blat hundreds of lines of garbage to the system log about whatever this garbage is about. Jan 13 18:45:31 stoneboro PAM-env[4425]: Unknown PAM_ITEM: <DISPLAY> Jan 13 18:45:31 stoneboro sshd[4425]: PAM pam_putenv: delete non-existent entry; DISPLAY Jan 13 18:45:31 stoneboro PAM-env[4425]: Unknown PAM_ITEM: <XAUTHORITY> Jan 13 18:45:31 stoneboro sshd[4425]: PAM pam_putenv: delete non-existent entry; XAUTHORITY Reproducible: Always Steps to Reproduce: 1. sudo ssh machine echo a 2. 3. Actual Results: permanently_set_uid: was able to restore old [e]gid Expected Results: a
the PAM stuff is COMPLETELY unrelated to ssh, it's a pam bug (search bugzilla)
so for now, lets punt this bug until you provide information you neglected to provide `emerge info` like the bug report page told you to what version of openssh ? wtf are you doing exactly ? `sudo scp` ?
openssh-3.9_p1-r1, I think. x86 stable of about 3 days ago. I've unmerged it. Upgrading to openssh-3.7_p2-r1 has fixed my problem. I will probably eventually upgrade all the way to rcp. Please tell the genius who broke ssh how clever he really is. What I'm doing exactly is: in a sudo shell, ssh foo "cat > file", or any other command, including echo a. emerge info: Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.4.25 i686) ================================================================= System uname: 2.4.25 i686 Pentium II (Deschutes) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.19-r1,sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7,sys-devel/libtool-1.4.3-r4 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo ftp://gentoo.ccccom.com http://mirrors.tds.net/gentoo http://cudlug.cudenver.edu/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X arts avi berkdb bitmap-fonts cdr crypt cups doc emacs encode foomaticdb fortran gdbm gif gpm gtk gtk2 ipv6 java jpeg libwww mad maildir mikmod motif mozilla mpeg ncurses oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang spell ssl svga tcltk tcpd tetex tiff truetype xml2 xmms xv zlib"
stop with the useless snide remarks, it only serves to piss us off and mark you as a waste of time i'm not quite sure i can reproduce this ... here's what i've tried: $ ssh vapier@hake $ sudo ssh vapier@dolphin "echo blah > somefile" $ logout $ ssh vapier@dolphin $ cat blah somefile
Huh. I entered a (contrite) comment and tried to change this bug to WORKSFORME. Guess it didn't work. My problem was using (the equivalent of) sudo instead of real sudo. It changes my uid/gid from 525/525 to 0/525 rather than sudo's 0/0. This code in uidswap.c function permanently_set_uid() /* Try restoration of GID if changed (test clearing of saved gid) */ if (old_gid != pw->pw_gid && (setgid(old_gid) != -1 || setegid(old_gid) != -1)) fatal("%s: was able to restore old [e]gid", __func__); is attempting to verify that it has dropped setuid/setgid privs. There should be no case where a correctly configured ssh hits that error. But it assumes it's going from 0/0 to 525/525, not (as in my case) 0/525 to 0/525. I have old_gid = 525, pw->gid = 0, old and new uid = 0 so setgid() succeeds. Whether that's a bug I don't know. They certainly didn't deliberately break setuid ssh.
uidswap.c (permanently_set_uid): if (setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) < 0) fatal("setresgid %u: %.100s", (u_int)pw->pw_gid, strerror(errno)); ... /* Try restoration of GID if changed (test clearing of saved gid) */ if (old_gid != pw->pw_gid && (setgid(old_gid) != -1 || setegid(old_gid) != -1)) fatal("%s: was able to restore old [e]gid", __func__); The thinking is: We want to check that we have successfully changed the saved gid to pw->pw_gid. There is getgid() and getegid() -- and it uses them to test those gid's -- but no portable getsgid(). So we assume if the saved gid is set to something wrong, it is set to old_gid. The setgid() and setegid() will succeed in that case. The flaw is: setgid() will succeed for root even if old_gid does not match the saved gid. A fix is: /* Try restoration of GID if changed (test clearing of saved gid) */ if (old_gid != pw->pw_gid && getuid() != 0 && (setgid(old_gid) != -1 || setegid(old_gid) != -1)) fatal("%s: was able to restore old [e]gid", __func__); The setgid()/setegid() tests will never detect anything useful for uid 0. The analagous test for uid /* Try restoration of UID if changed (test clearing of saved uid) */ if (old_uid != pw->pw_uid && (setuid(old_uid) != -1 || seteuid(old_uid) != -1)) fatal("%s: was able to restore old [e]uid", __func__); never finds old_uid != pw->pw_uid since pw is original_real_uid = getuid(); pw = getpwuid(original_real_uid); ... uid_t old_uid = getuid(); initialized with pw->pw_uid == old_uid. It has the bug too, but will never hit it. But it too should check getuid() != 0, since the second line is nonsense without it.
That should be geteuid() != 0
Re-assign.
you havent by chance filed a bug upstream have you ? http://www.openssh.org/report.html
(In reply to comment #9) > you havent by chance filed a bug upstream have you ? > > http://www.openssh.org/report.html Afraid not, but I have now done so, sort of.
