This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 830237

Summary: SELinux Enforcing Prevents OpenSSH Chroot Shell Logins
Product: [Fedora] Fedora Reporter: adam.macmurray
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 18CC: dominick.grift, dwalsh, jjaburek, mattias.ellert, mgrepl, mvadkert, plautrba, tmraz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 831271 869340 (view as bug list) Environment:
Last Closed: 2012-12-20 10:40:40 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 831271, 833352, 869340    

Description adam.macmurray 2012-06-08 11:31:47 EDT
Description of problem:

Using OpenSSH chroot shell functionality the sshd process attempts a process transition from "chroot_user_t" to "unconfined_t" when launching the user shell (in this case "/bin/bash -r") and is denied, which disconnects the SSH session shortly after authentication.

This OpenSSH session disconnection behaviour also appears to occur in FC16.

Under FC15 i386 PAE the OpenSSH chroot ran as "sshd_t" and SELinux did not deny the process transition to "unconfined_t" when launching a chroot shell.


FC17 i386 PAE ps dump (captured with SELinux in Permissive mode):

system_u:system_r:sshd_t:s0-s0:c0.c1023 1143 2277 2277 2277 ?       -1 Ss       0   0:00  \_ sshd: testuser [priv]
system_u:system_r:chroot_user_t:s0-s0:c0.c1023 2277 2280 2277 2277 ? -1 S    1001   0:00      \_ sshd: testuser@pts/3
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2280 2281 2281 2281 pts/3 2281 Ss+ 1001   0:00          \_ /bin/bash -r


FC15 i386 PAE ps dump (captured with SELinux in Enforcing mode):

system_u:system_r:sshd_t:s0-s0:c0.c1023 27438 3789 3789 3789 ?      -1 Ss       0   0:00  \_ sshd: testuser [priv]
system_u:system_r:sshd_t:s0-s0:c0.c1023 3789 3792 3789 3789 ?       -1 S      503   0:00      \_ sshd: testuser@pts/2
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3792 3793 3793 3793 /chroot/dev/pts/2 3793 Ss+ 503   0:00          \_ /bin/bash -r

There are a number of other SELinux restrictions on "chroot_user_t" that prevent OpenSSH chroot from working for which audit2allow can create "allow" policy modules, but the policies will still not allow the process transition once the SELinux module is installed.

module fc17sshchroot 1.0;

require {
        type ptmx_t;
	type user_devpts_t;
        type chroot_user_t;
	type devpts_t;
	type shell_exec_t;
	type unconfined_t;
        class file execute;
        class dir search;
        class unix_dgram_socket { create connect };
        class chr_file { read write ioctl getattr };
        class process transition;
        class file { read open };
}

#============= chroot_user_t ==============
allow chroot_user_t ptmx_t:chr_file { read write ioctl };
allow chroot_user_t self:unix_dgram_socket { create connect };
allow chroot_user_t user_devpts_t:chr_file { read write ioctl getattr };
allow chroot_user_t devpts_t:dir search;
allow chroot_user_t shell_exec_t:file { read open execute };

#!!!! This avc is a constraint violation.  You will need to add an attribute to either the source or target type to make it work.
#Constraint rule:
allow chroot_user_t unconfined_t:process transition;

Version-Release number of selected component (if applicable):

openssh-server-5.9p1-22.fc17.i686
bash-4.2.28-1.fc17.i686
kernel-PAE-3.4.0-1.fc17.i686
selinux-policy-3.10.0-128.fc17.noarch
selinux-policy-targeted-3.10.0-128.fc17.noarch
selinux-policy-devel-3.10.0-128.fc17.noarch

How reproducible:

Setup OpenSSH for chroot environment and create the required chroot tree for chroot shell users.

In this case, the chroot part of the sshd_config is:

Match Group sshjail
        ChrootDirectory /chroot
        X11Forwarding no
        AllowTcpForwarding yes
        Banner /chroot/etc/sshjailmsg
        ForceCommand /bin/bash -r

OpenSSH setup for key authentication (PasswordAuthentication off).

Steps to Reproduce:
1. Add a user to a group that OpenSSH will force to chroot (e.g. sshjail)
2. Connect to SSH with target user and authenticate using key
3. SSH session will disconnect and the following avc denied entry will be recorded:

type=AVC msg=audit(1339167129.184:1339): avc:  denied  { transition } for  pid=2281 comm="sshd" path="/bin/bash" dev="dm-1" ino=522245 scontext=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process


Actual results:

SSH session disconnects after authentication due to SELinux denial

Expected results:

SSH shell spawns and user has a chroot SSH shell

Additional info:

related ssh sebools in FC17:

ssh_chroot_rw_homedirs --> off
ssh_sysadm_login --> off

Turning either or both of these booleans to "on" does not resolve the issue
Comment 1 Daniel Walsh 2012-06-08 11:36:14 EDT
We do not want ssh_chroot_t to transition to unconfined_t at all. 

ssh guys could this be related to the privsep patch?
Comment 2 Petr Lautrbach 2012-06-11 10:39:37 EDT
The transition is probably done by pam_selinux module which sets context for next executed shell. Maybe ssh_selinux_change_context() should clean SELinux exec context after SELinux context change.

Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Open Session
Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Username= test SELinux User = unconfined_u Level= s0-s0:c0.c1023
Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Selected Security Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): Checking if unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 mls range valid for  unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): set test security context to unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Jun 11 16:34:48 f17-openssh sshd[4347]: pam_selinux(sshd:session): set test key creation context to unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Jun 11 16:34:48 f17-openssh sshd[4347]: pam_unix(sshd:session): session opened for user test by (uid=0)
Jun 11 16:34:48 f17-openssh sshd[4347]: User child is on pid 4351
Jun 11 16:34:48 f17-openssh sshd[4351]: debug1: PAM: establishing credentials
Jun 11 16:34:48 f17-openssh sshd[4351]: debug3: ssh_selinux_setup_variables: setting execution context
Jun 11 16:34:48 f17-openssh sshd[4351]: debug3: ssh_selinux_change_context: setting context from 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u:system_r:chroot_user_t:s0-s0:c0.c1023'
Comment 3 Daniel Walsh 2012-06-13 17:27:40 EDT
Yes do a setexeccon(NULL)
Will clear the context.
Comment 4 Petr Lautrbach 2012-06-14 09:03:30 EDT
I realized that simply adding setexeccon() won't help. All chroot users are run 
with chroot_user_t, but this context is supposed to be used only for
internal-sftp. chroot_user_t process can't exec bash, use char files 
and so.

I believe that since we have privsep patch we don't need chroot_user_t
anymore - all unprivileged sshd child processes included internal-sftp 
are run with user's context so there's no need to change their context
to chroot_user_t if they are chrooted.
Comment 5 Miroslav Grepl 2012-06-14 10:28:48 EDT
(In reply to comment #4)
> I realized that simply adding setexeccon() won't help. All chroot users are
> run 
> with chroot_user_t, but this context is supposed to be used only for
> internal-sftp. chroot_user_t process can't exec bash, use char files 
> and so.
> 
> I believe that since we have privsep patch we don't need chroot_user_t
> anymore - all unprivileged sshd child processes included internal-sftp 
> are run with user's context so there's no need to change their context
> to chroot_user_t if they are chrooted.

Sounds as good idea. If I remember correctly, we wanted to get out at least this users stuff (interlnal-sftp) from sshd_t label. It was first step.

But now we have working privsep patch which makes me to agree with you.
Comment 6 Daniel Walsh 2012-06-19 09:58:29 EDT
But if the user runs with unconfined_t, we loose any lock down.  If you are saying we will recommend that the chroot_t user run with guest_t then I am fine with it.
Comment 7 adam.macmurray 2012-07-04 11:15:01 EDT
Is there a workaround we can use prior to a fix being released? In our particular case it would be better for us to have user processes for restricted users running as "unconfined" in a chroot SSH environment than to turn SELinux off altogether just to get chroot SSH to work.

Is there a policy file we can apply or some other temporary measure we can take to get this working for now?
Comment 8 Daniel Walsh 2012-07-11 14:40:23 EDT
Adam If you want you can add a policy module to make the chroot_user_t an unconfined_domain.

Create a file mychrootuser.te with the following content.
policy_module(mychrootuser,1.0
gen_require(`
type chroot_user_t;
')
unconfined_domain(chroot_user_t)

Then make the policy file

# make -f /usr/share/selinux/devel/include/Makefile
# semodule -i mychrootuser.pp
Comment 9 adam.macmurray 2012-07-11 15:59:35 EDT
Thanks for the policy module Daniel.

I tried to compile it under fc17 i386 PAE and modified it as follows [I believe the ")" was missing on the first line]:

---
policy_module(ssh_chroot_workaround,1.0)

gen_require(`
    type chroot_user_t;
')

unconfined_domain(chroot_user_t)
---

I had to use the Makefile in /usr/share/selinux/devel instead of /usr/share/selinux/devel/include as using the one in the include directory gave the following:

  make: *** /usr/share/selinux/targeted: Is a directory.  Stop.

The policy module compiled into a .pp which I then tried to install as follows:

---
[<myuser>@<myserver> devel]$ semodule -i ssh_chroot_workaround.pp
libsepol.expand_terule_helper: duplicate TE rule for chroot_user_t user_home_dir_t:fifo_file user_home_t
libsepol.expand_module: Error during expand
libsemanage.semanage_expand_sandbox: Expand module failed
semodule:  Failed!
---

I'm not sure what to do about this conflict.

FYI the selinux and kernel packages installed are as follows:

selinux-policy-devel-3.10.0-134.fc17.noarch
libselinux-python-2.1.10-3.fc17.i686
libselinux-2.1.10-3.fc17.i686
selinux-policy-3.10.0-134.fc17.noarch
selinux-policy-targeted-3.10.0-134.fc17.noarch
libselinux-utils-2.1.10-3.fc17.i686
kernel-PAE-3.4.4-5.fc17.i686
Comment 12 Petr Lautrbach 2012-08-27 09:52:05 EDT
I've finally prepared a test build for Fedora 18 [1] based on 
the openssh-6.0p1 version and without the chroot_user_t. 

I'd rather don't add this change to currrent versions given that there are 
probably some existing configurations depending on chroot_user_t and this 
update would break behavior.

Also I'd propose to note this change in release notes with notice that
chroot users shall be set to guest_u as Dan suggested.


[1] http://plautrba.fedorapeople.org/openssh/openssh-6.0p1-no-chroot_user_t/
Comment 13 Miroslav Grepl 2012-08-27 09:52:54 EDT
Great. I am willing to test it.
Comment 14 Miroslav Grepl 2012-09-06 08:26:51 EDT
It works and a user has a userdomain instead of chroot_user_t.
Comment 15 Fedora Update System 2012-09-15 12:33:18 EDT
openssh-6.1p1-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openssh-6.1p1-1.fc18
Comment 16 Fedora Update System 2012-09-16 15:16:01 EDT
Package openssh-6.1p1-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-6.1p1-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-13976/openssh-6.1p1-1.fc18
then log in and leave karma (feedback).
Comment 17 adam.macmurray 2012-09-18 20:16:10 EDT
I'm still seeing the user get disconnected when they ssh in with a chroot home directory set.

Steps
-----

Installed FC18 Alpha x86:

[getinfo@fc18alpha ~]# uname -a
Linux fc18alpha.pal.internal 3.6.0-0.rc2.git2.1.fc18.i686.PAE #1 SMP Wed Aug 22 11:57:34 UTC 2012 i686 i686 i386 GNU/Linux

[getinfo@fc18alpha ~]# rpm -qa | grep ssh
openssh-6.1p1-1.fc18.i686
openssh-server-6.1p1-1.fc18.i686
libssh2-1.4.2-2.fc18.i686
openssh-clients-6.1p1-1.fc18.i686


Set testuser to guest_u and verify:

[testuser@fc18alpha ~]id -Z
guest_u:guest_r:guest_t:s0


Connection attempt sshd LogLevel INFO:

Sep 18 18:41:27 fc18alpha sshd[1540]: Accepted publickey for testuser from w.x.y.z port 52416 ssh2
Sep 18 18:41:27 fc18alpha sshd[1540]: pam_unix(sshd:session): session opened for user testuser by (uid=0)
Sep 18 18:41:27 fc18alpha sshd[1543]: ssh_selinux_copy_context: getcon failed with No such file or directory
Sep 18 18:41:30 fc18alpha sshd[1540]: pam_unix(sshd:session): session closed for user testuser

If SELinux is in Enforcing mode the user is disconnected. If in Permissive mode they are not disconnected and can use their ssh chroot shell.

From the debug3 logs on a subsequent connection attempt it looks like chroot_user_t is the destination context for the transition:

Sep 18 19:04:41 fc18alpha sshd[736]: debug1: matching key found: file /home/testuser/.ssh/authorized_keys, line 1
Sep 18 19:04:41 fc18alpha sshd[736]: Found matching RSA key: <key>
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: restore_uid: 0/0
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed: key 0xb9149650 is allowed
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 22
Sep 18 19:04:41 fc18alpha sshd[736]: debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: Postponed publickey for testuser from w.x.y.z port 52590 ssh2 [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: userauth-request for user testuser service ssh-connection method publickey [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: attempt 2 failures 0 [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug2: input_userauth_request: try method publickey [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_key_allowed entering [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 21 [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive_expect entering: type 22 [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive entering [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive entering
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: monitor_read: checking request 21
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed entering
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed: key_from_blob: 0xb914dcd8
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: temporarily_use_uid: 1001/1001 (e=0/0)
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: trying public key file /home/testuser/.ssh/authorized_keys
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: fd 4 clearing O_NONBLOCK
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: matching key found: file /home/testuser/.ssh/authorized_keys, line 1
Sep 18 19:04:41 fc18alpha sshd[736]: Found matching RSA key: <key>
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: restore_uid: 0/0
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_keyallowed: key 0xb914dcd8 is allowed
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 22
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_key_verify entering [preauth]
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_send entering: type 23 [preauth]
Sep 18 19:04:41 fc18alpha sshd[739]: debug1: PAM: establishing credentials
Sep 18 19:04:41 fc18alpha sshd[739]: debug3: ssh_selinux_setup_variables: setting execution context
Sep 18 19:04:41 fc18alpha sshd[739]: debug3: ssh_selinux_change_context: setting context from 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u:system_r:chroot_user_t:s0-s0:c0.c1023'
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: monitor_read: checking request 61
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_audit_event entering
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_request_receive entering
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: monitor_read: checking request 73
Sep 18 19:04:41 fc18alpha sshd[736]: debug3: mm_answer_term: tearing down sessions
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: PAM: cleanup
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: PAM: closing session
Sep 18 19:04:41 fc18alpha sshd[736]: pam_unix(sshd:session): session closed for user testuser
Sep 18 19:04:41 fc18alpha sshd[736]: debug1: PAM: deleting credentials
Sep 18 19:04:59 fc18alpha sshd[735]: Received signal 15; terminating.

Are there more SELinux settings for me to set?
Comment 18 adam.macmurray 2012-09-19 14:03:25 EDT
For the sake of completeness, here are the selinux packages. Note that I updated the openssh packages after the install of FC18 Alpha, I just neglected to state so explicitly in my last comment:


[testuser@fc18alpha ~]# rpm -qa | grep selinux
libselinux-2.1.11-6.fc18.i686
selinux-policy-devel-3.11.1-21.fc18.noarch
libselinux-python-2.1.11-6.fc18.i686
selinux-policy-targeted-3.11.1-21.fc18.noarch
libselinux-utils-2.1.11-6.fc18.i686
selinux-policy-3.11.1-21.fc18.noarch
Comment 19 Daniel Walsh 2012-09-19 21:06:34 EDT
Any avc messages?

ausearch -m avc -ts recent 

after the failure.
Comment 20 adam.macmurray 2012-09-19 22:09:33 EDT
Here are the ausearch output for failed attempts as [1] a user assigned guest_u and [2] another user with default unconfined_u:

----
time->Wed Sep 19 20:57:09 2012
type=SYSCALL msg=audit(1348106229.432:287): arch=40000003 syscall=11 success=no exit=-13 a0=b7884188 a1=bfb0abd4 a2=b7890758 a3=0 items=0 ppid=988 pid=989 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts1 ses=14 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1348106229.432:287): avc:  denied  { transition } for  pid=989 comm="sshd" path="/bin/bash" dev="sda3" ino=1046547 scontext=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=guest_u:guest_r:guest_t:s0 tclass=process
----
time->Wed Sep 19 21:05:39 2012
type=SYSCALL msg=audit(1348106739.576:347): arch=40000003 syscall=11 success=no exit=-13 a0=b81500c0 a1=bffe1c64 a2=b815ecc8 a3=0 items=0 ppid=1078 pid=1079 auid=1002 uid=1002 gid=1003 euid=1002 suid=1002 fsuid=1002 egid=1003 sgid=1003 fsgid=1003 tty=pts1 ses=16 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1348106739.576:347): avc:  denied  { transition } for  pid=1079 comm="sshd" path="/bin/bash" dev="sda3" ino=1046547 scontext=system_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
Comment 21 Miroslav Grepl 2012-09-20 02:02:49 EDT
Something is wrong. chroot_user_t should not be in the game.
Comment 22 Fedora Update System 2012-09-23 23:25:57 EDT
openssh-6.1p1-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Petr Lautrbach 2012-10-09 04:36:57 EDT
I accidentaly didn't remove the sftp-chroot patch from the spec file so 
the chroot_user_t is still there. Sorry.
Comment 24 adam.macmurray 2012-10-22 09:07:22 EDT
Will the openssh package be updated to a version without the sftp-chroot patch prior to the final release of FC18?
Comment 25 Petr Lautrbach 2012-10-22 09:41:23 EDT
I've hit another issue with the whole concept. The F18 SELinux policy disallows setuid() call to confined users. A sshd process needs to do 3 steps: change its SELinux context, chroot() itself to a new directory, and change uid. SELinux context has to be changed before chroot() since we can't assume that there's the SELinux infrastructure in the chrooted dir. chroot() has to be called by uid 0 so setuid() must be called after chroot(). But since process is already running with the user's context, it's denied by the policy.


Dan, would be possible to re-allow confined users to call setuid() as it is in Fedora 17?
Comment 26 Petr Lautrbach 2012-10-23 11:43:47 EDT
I've prepared a test build with dropped the sftp-chroot patch. You can find it
here [1]. There's completely dropped usage of sftp_t and chroot_user_t, and
system configured SELinux users are used instead. It's strongly recommended to
use guest_u for chrooted users. Also it might be a good idea to add a new
SELinux user just for sftp sessions.

It needs the change in the selinux-policy. Confined users needs to be allowed to
call setuid() as described in comment 25. Before I push it to F18 update, I'd like to know if it's possible to do this change in selinux-policy. 

In the mean time, you need to create and load your custom SELinux module:

# cat user-setuid.te
module user-setuid 1.0;
require {
        attribute userdomain;
        class capability setuid;
}
#============= staff_t ==============
allow userdomain self:capability setuid;


[1] http://plautrba.fedorapeople.org/openssh/830237/
Comment 27 Fedora Update System 2012-10-29 06:48:14 EDT
openssh-6.1p1-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openssh-6.1p1-2.fc18
Comment 28 Fedora Update System 2012-10-29 14:13:31 EDT
Package openssh-6.1p1-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-6.1p1-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17159/openssh-6.1p1-2.fc18
then log in and leave karma (feedback).
Comment 29 Fedora Update System 2012-12-20 10:40:48 EST
openssh-6.1p1-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.