sux - fails with new ssh
I installed the new ssh (via YOU) yesterday and am now seeing a problem with "sux -". Scenario: 1. New ssh on on both the remote (SuSE 8.0) and the local (SuSE 7.3) system. 2. All ssh config files are copied from the "*.rpmnew" versions created by the install of the new ssh EXCEPT that "X11Forward yes" is enabled. (I get the same problem using my original ssh config files from before the update.) 3. Log in to the remote system via ssh. 4. From the shell now running on the remote system attempt to switch to root with "sux -". 5. The following error is shown: > sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" # "su -" works without the above error but then I can't launch X applications: > su - Password: # export DISPLAY=:10.0 # /opt/mozilla/mozilla Gtk-WARNING **: cannot open display: localhost:10.0 I am not sure if it is the new ssh that has done this to me but I did just install the update and both the above scenarios worked fine yesterday before the update. -- Robert C. Paulsen, Jr. robert@paulsenonline.net
See today's new announcement about the openssh advisrory but... * Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 12:47]:
3. Log in to the remote system via ssh.
Using '-X'?
5. The following error is shown:
> sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" #
This is just a warning, you can verify this with echo $? I think the warning may have something to do with the new UsePrivilegeSeparation stuff but in any case it will work. -- -ckm
On Wed, Jun 26, 2002 at 02:42:21PM -0700, Christopher Mahmood wrote:
See today's new announcement about the openssh advisrory but...
* Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 12:47]:
3. Log in to the remote system via ssh.
Using '-X'?
No, because it's enabled in the config file (as mentioned in the part you didn't quote above).
5. The following error is shown:
> sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" #
This is just a warning, you can verify this with echo $? I think the warning may have something to do with the new UsePrivilegeSeparation stuff but in any case it will work.
That may be just a warning, but as I say in the part you didn't quote following the above, it *doesn't* work; I can't start X applications. Again -- All this worked *before* updating to the new ssh. I just reinstalled ssh from the original CDs and all is back to normal. I will have to live with this exposure until ssh is fixed. -- Robert C. Paulsen, Jr. robert@paulsenonline.net
* Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 14:56]:
Using '-X'?
No, because it's enabled in the config file (as mentioned in the part you didn't quote above).
That doesn't mean that I didn't want to see you explicitly use it.
That may be just a warning, but as I say in the part you didn't quote following the above, it *doesn't* work; I can't start X applications.
I tested it mixing different versions with 3.3 and it works fine, that's why I specified using '-X'. Please use '-v' as well.
Again -- All this worked *before* updating to the new ssh. I just reinstalled ssh from the original CDs and all is back to normal. I will have to live with this exposure until ssh is fixed.
What exposure? Please read the security announcements before saying things like that; there's already too much confusion around this. -- -ckm
On Wed, Jun 26, 2002 at 03:11:20PM -0700, Christopher Mahmood wrote:
* Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 14:56]:
Using '-X'?
No, because it's enabled in the config file (as mentioned in the part you didn't quote above).
That doesn't mean that I didn't want to see you explicitly use it.
OK, I re-did the YOU update and used ssh -X. No change. But, I guess I did neglect to mention just what error message I get when starting an X application after using "sux -". Here is is (last two lines):
sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" avalon:~ # xterm X11 connection rejected because of wrong authentication. X connection to localhost:10.0 broken (explicit kill or server shutdown).
That may be just a warning, but as I say in the part you didn't quote following the above, it *doesn't* work; I can't start X applications.
I tested it mixing different versions with 3.3 and it works fine, that's why I specified using '-X'. Please use '-v' as well.
Here is the output from "ssh -X -v". Note two lines i particular: debug1: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. These don't appear with the shipped version of ssh. It appears to be a problem on the server side since I can use the latest updates on the client side w/o problem. =====================[ debug output ]=================================== robert@avalon:~> ssh -X -v avalon OpenSSH_3.3, SSH protocols 1.5/2.0, OpenSSL 0x0090603f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to avalon [192.168.0.31] port 22. debug1: Connection established. debug1: identity file /home/robert/.ssh/identity type -1 debug1: identity file /home/robert/.ssh/id_rsa type -1 debug1: identity file /home/robert/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.3 debug1: match: OpenSSH_3.3 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 130/256 debug1: bits set: 1599/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'avalon' is known and matches the RSA host key. debug1: Found key in /home/robert/.ssh/known_hosts:10 debug1: bits set: 1577/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password debug1: next auth method to try is publickey debug1: try privkey: /home/robert/.ssh/identity debug1: try privkey: /home/robert/.ssh/id_rsa debug1: try pubkey: /home/robert/.ssh/id_dsa debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x8093c48 hint 2 debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key '/home/robert/.ssh/id_dsa': debug1: read PEM private key done: type DSA debug1: ssh-userauth2 successful: method publickey debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: ssh_session2_setup: id 0 debug1: channel request 0: pty-req debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: x11-req debug1: channel request 0: shell debug1: fd 3 setting TCP_NODELAY debug1: channel 0: open confirm rwindow 0 rmax 32768 Last login: Wed Jun 26 19:56:25 2002 from avalon.paulsen.org Have a lot of fun... robert@avalon:~> sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" avalon:~ # xterm debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 39754 debug1: fd 7 setting TCP_NODELAY debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug1: X11 rejected 1 i0/o0 debug1: channel 1: read failed debug1: channel 1: close_read debug1: channel 1: input open -> drain debug1: channel 1: ibuf empty debug1: channel 1: send eof debug1: channel 1: input drain -> closed debug1: channel 1: write failed debug1: channel 1: close_write debug1: channel 1: output open -> closed debug1: X11 closed 1 i3/o3 debug1: channel 1: send close debug1: channel 1: rcvd close debug1: channel 1: is dead debug1: channel 1: garbage collecting debug1: channel_free: channel 1: x11, nchannels 2 X connection to localhost:11.0 broken (explicit kill or server shutdown). =========================================================================
Again -- All this worked *before* updating to the new ssh. I just reinstalled ssh from the original CDs and all is back to normal. I will have to live with this exposure until ssh is fixed.
What exposure? Please read the security announcements before saying things like that; there's already too much confusion around this.
Well, there was a security notice recommending an update. If there is no exposure why update? -- Robert C. Paulsen, Jr. robert@paulsenonline.net
On Wed, Jun 26, 2002 at 08:22:03PM -0500, Robert C. Paulsen Jr. wrote:
Here is the output from "ssh -X -v". Note two lines i particular:
debug1: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication.
I'm having the same problem after updating SSH. I only want to point that the problem is not with sux, sux is just a shell script. When I try xhost + and su I am getting: kastus@bursa:~> xhost + debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 1869 debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 access control disabled, clients can connect from any host debug1: channel 1: rcvd eof debug1: channel 1: output open -> drain debug1: channel 1: obuf empty debug1: channel 1: close_write debug1: channel 1: output drain -> closed debug1: channel 1: FORCE input drain debug1: channel 1: ibuf empty debug1: channel 1: send eof debug1: channel 1: input drain -> closed debug1: channel 1: send close debug1: channel 1: rcvd close debug1: channel 1: is dead debug1: channel 1: garbage collecting debug1: channel_free: channel 1: x11, nchannels 2 kastus@bursa:~> su Password: bursa:/netmount/home/kastus # xosview debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 1870 debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug1: X11 rejected 1 i0/o0 Something appears to be dead broken in SSH 3.3 Did anybody try 3.4? -Kastus
I did the SSH Update from YOU in 8.0 and sux / su still work for me... Once I figure out how to get back in my SELinux enhanced laptop, I will try a compile install. RKDavies On Thu, 2002-06-27 at 00:06, Konstantin (Kastus) Shchuka wrote:
On Wed, Jun 26, 2002 at 08:22:03PM -0500, Robert C. Paulsen Jr. wrote:
Here is the output from "ssh -X -v". Note two lines i particular:
debug1: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication.
I'm having the same problem after updating SSH. I only want to point that the problem is not with sux, sux is just a shell script.
When I try xhost + and su I am getting:
kastus@bursa:~> xhost + debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 1869 debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 access control disabled, clients can connect from any host debug1: channel 1: rcvd eof debug1: channel 1: output open -> drain debug1: channel 1: obuf empty debug1: channel 1: close_write debug1: channel 1: output drain -> closed debug1: channel 1: FORCE input drain debug1: channel 1: ibuf empty debug1: channel 1: send eof debug1: channel 1: input drain -> closed debug1: channel 1: send close debug1: channel 1: rcvd close debug1: channel 1: is dead debug1: channel 1: garbage collecting debug1: channel_free: channel 1: x11, nchannels 2 kastus@bursa:~> su Password: bursa:/netmount/home/kastus # xosview debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 1870 debug1: fd 7 setting O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: X11 connection uses different authentication protocol. X11 connection rejected because of wrong authentication. debug1: X11 rejected 1 i0/o0
Something appears to be dead broken in SSH 3.3 Did anybody try 3.4?
-Kastus
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com --
This post is encrypted in the "english language method", any attempt to decipher meaning from these symbols is a violation of the DMCA. This includes, but is not limited to: interpreting the symbols through use of biological, visual decryption devices, translating the symbols into another language encryption scheme, and digital processing the symbols into a form conducive to oral intrepretation. Thank you for your time. **********************************************************************
* Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 18:31]: ::Well, there was a security notice recommending an update. If there is no ::exposure why update? Please check out. www.slashdot.org linuxtoday.com techweb.com and about 100 other sites for information about the OpenSSH root exploit that was discovered. Thanks. -=Ben --=====-----=====-- mailto:ben@whack.org --=====-- Tell me what you believe..I tell you what you should see. -DP --=====-----=====--
On Wed, Jun 26, 2002 at 09:51:05PM -0700, Ben Rosenberg wrote:
* Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 18:31]:
::Well, there was a security notice recommending an update. If there is no ::exposure why update?
Please check out.
www.slashdot.org linuxtoday.com techweb.com
and about 100 other sites for information about the OpenSSH root exploit that was discovered.
ok, these three plus about 100 other are right and Olaf Kirch in http://lists.suse.com/archive/suse-security/2002-Jun/0399.html saying: ISS and the OpenSSH team just released advisories concerning the OpenSSH vulnerability. These advisories state that the vulnerability exists only if the package has been compiled with support for S/Key or BSDAUTH authentication. Inspecting the patches included in the OpenSSH advisory however show that there is a second vulnerability that can be exploited when interactive keyboard mode is enabled (via the PAMAuthenticationViaKbdInt option in sshd_config). Neither S/Key or BSDAUTH were enabled in previous RPMs released by SuSE (i.e. the OpenSSH 2.9.9p2 RPMs previously released on March 6, and the OpenSSH 3.0.2p1 RPMs released with SuSE Linux 8.0). Support for interactive keyboard mode is compiled in, and is off by default in recent RPMs. However, it can be enabled by the administrator. Which means that, in the default configuration, SuSE Linux users are not affected by this vulnerability. is wrong. Thanks, -Kastus
* Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 18:22]:
sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" avalon:~ # xterm X11 connection rejected because of wrong authentication. X connection to localhost:10.0 broken (explicit kill or server shutdown).
This must be because of the UsePrivilegeSeparation in 3.3 but I can't figure out why it works for me. I'll look into today and repost.
Well, there was a security notice recommending an update. If there is no exposure why update?
It's explained in the addendum to SuSE-SA:2002:023 (http://lists.suse.com/archive/suse-security-announce/2002-Jun/0006.html) the default confirguration in the SuSE OpenSSH 2.9.9p2 RPMs were not affected by the S/Key or BSDAUTH vulnerabilities. Likewise, PAMAuthenticationViaKbdInt is not enabled by default. The workaround recommended by the openssh developers (UsePrivilegeSeparation) is only available in 3.3 and is causing problems with md5 passwds, some pam stuff, and apparantly xauth (although that just may be because of the chroot it creates). As test, try turning setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config on the server and I think xauth (and sux) will work fine. Of course, if you turn that off there's no point in running the less tested 3.3 so you might as well just go back to 2.9.9p2. -- -ckm
On Thu, Jun 27, 2002 at 11:18:53AM -0700, Christopher Mahmood wrote:
* Robert C. Paulsen Jr. (robert@paulsenonline.net) [020626 18:22]:
sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" avalon:~ # xterm X11 connection rejected because of wrong authentication. X connection to localhost:10.0 broken (explicit kill or server shutdown).
This must be because of the UsePrivilegeSeparation in 3.3 but I can't figure out why it works for me. I'll look into today and repost.
Well, there was a security notice recommending an update. If there is no exposure why update?
It's explained in the addendum to SuSE-SA:2002:023 (http://lists.suse.com/archive/suse-security-announce/2002-Jun/0006.html) the default confirguration in the SuSE OpenSSH 2.9.9p2 RPMs were not affected by the S/Key or BSDAUTH vulnerabilities. Likewise, PAMAuthenticationViaKbdInt is not enabled by default.
The workaround recommended by the openssh developers (UsePrivilegeSeparation) is only available in 3.3 and is causing problems with md5 passwds, some pam stuff, and apparantly xauth (although that just may be because of the chroot it creates). As test, try turning setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config on the server and I think xauth (and sux) will work fine. Of course, if you turn that off there's no point in running the less tested 3.3 so you might as well just go back to 2.9.9p2.
I just installed the latest 3.4p1 via YOU and get the same problem discussed above ("sux -" after ssh login fails). I tried setting 'UsePrivilegeSeparation no' but it made no difference. Again, reinstalling ssh from the SuSE 8.0 CD put me back in business. -- Robert C. Paulsen, Jr. robert@paulsenonline.net
* Christopher Mahmood (ckm@suse.com) [020626 15:28]: :: ::> Again -- All this worked *before* updating to the new ssh. I just ::> reinstalled ssh from the original CDs and all is back to normal. I will ::> have to live with this exposure until ssh is fixed. :: Well, I'm not exactly sure what's wrong with your machine. But I've tried sux with both my home workstation (SuSE 7.3) and my workstation in the office (SuSE 7.2) and they both work. I would look at the options and configurations of your machine before you say things are broken. I can try it on a few other machines at work if that helps..but these would all be 8.0 configured by me..so if one works I bet they all do. Going back to the pkg from the CD's hurts no one but yourself. You could try to figure out what the issue is instead of just waving a flag to the script kiddies that your open for business..their business. *shrug* It's all on you. -=Ben --=====-----=====-- mailto:ben@whack.org --=====-- Tell me what you believe..I tell you what you should see. -DP --=====-----=====--
I just verified that all is back to normal if I reinstall ssh from the original CDs. On Wed, Jun 26, 2002 at 02:47:32PM -0500, Robert C. Paulsen Jr. wrote:
I installed the new ssh (via YOU) yesterday and am now seeing a problem with "sux -".
Scenario:
1. New ssh on on both the remote (SuSE 8.0) and the local (SuSE 7.3) system.
2. All ssh config files are copied from the "*.rpmnew" versions created by the install of the new ssh EXCEPT that "X11Forward yes" is enabled. (I get the same problem using my original ssh config files from before the update.)
3. Log in to the remote system via ssh.
4. From the shell now running on the remote system attempt to switch to root with "sux -".
5. The following error is shown:
> sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" #
"su -" works without the above error but then I can't launch X applications:
> su - Password: # export DISPLAY=:10.0 # /opt/mozilla/mozilla Gtk-WARNING **: cannot open display: localhost:10.0
I am not sure if it is the new ssh that has done this to me but I did just install the update and both the above scenarios worked fine yesterday before the update.
-- Robert C. Paulsen, Jr. robert@paulsenonline.net
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com
-- Robert C. Paulsen, Jr. robert@paulsenonline.net
"Robert C. Paulsen Jr."
> sux - Password: No matches found, authority file "/dev/fd/62" not written xauth: (argv):1: unable to read any entries from file "(stdin)" #
I have a similar configuration and see the same message but I prefer to use "ssh -X -l root hostname" which I consider safer (I haven't studied the ssh implementation so I may be wrong). You can use it as a workaround. -- Alexandr.Malusek@imv.liu.se
participants (6)
-
Alexandr Malusek -
Ben Rosenberg -
Christopher Mahmood -
Konstantin (Kastus) Shchuka -
Phantasm -
Robert C. Paulsen Jr.