Bug 131544 - FC3 release notes -- openssh 3.9 changes
FC3 release notes -- openssh 3.9 changes
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: fedora-release (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ed Bailey
:
Depends On:
Blocks: fc-relnotes-blocker
  Show dependency treegraph
 
Reported: 2004-09-01 22:57 EDT by Ulrich Drepper
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-22 16:09:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ulrich Drepper 2004-09-01 22:57:08 EDT
The openssh 3.9 code in FC3 behaves a bit differently than previous
releases.  It is much more strict when it comes to access permissions
of config files etc.  The new version will simply stop working, maybe
leading to failing access to remote machines.

The openssh 3.9 release notes say this:

  Add strict permission and ownership checks to programs reading
  ~/.ssh/config
  NB ssh(1) will now exit instead of trying to process a config with
  poor ownership or permissions


Something like this should be added since otherwise people might lock
themselves out of their machines.
Comment 1 Ed Bailey 2004-09-02 16:39:42 EDT
Ulrich -- Sounds like an important issue to bring up.  Does this sound
ok to you:

Fedora Core 3 contains OpenSSH 3.9, which includes strict permission
and ownship checks for the ~/.ssh/config file.  For example, ssh will
exit if this file does not have appropriate ownership and permissions.
 Therefore, make sure that ~/.ssh/config is owned by the owner of ~/,
and that its permissions are set to mode 600.
Comment 2 Ulrich Drepper 2004-09-02 17:48:01 EDT
Drop the "For example" and you should be fine.
Comment 3 Ed Bailey 2004-09-03 12:24:07 EDT
Well, I needed some noise words in there to get away from the
situation of starting a sentence with a command that should not be
capitalized... :-)

Here's what I ended up doing; if this just doesn't work for you, feel
free to reopen this bug:

Fedora Core 2.91 Test 2 contains OpenSSH 3.9, which includes strict
permission and ownship checks for the ~/.ssh/config file. These checks
mean that ssh will exit if this file does not have appropriate
ownership and permissions.

Therefore, make sure that ~/.ssh/config is owned by the owner of ~/,
and that its permissions are set to mode 600.

Thanks for reporting this!
Comment 4 Ulrich Drepper 2004-10-17 17:12:48 EDT
Typo in the text:

  ownship -> ownership

Also probably in the RHEL4 version.
Comment 5 Ed Bailey 2004-10-18 12:29:51 EDT
Good catch -- thanks!  Fixed the RHEL4 version as well...
Comment 6 John Poelstra 2004-10-21 13:55:13 EDT
I think you should add something about X11 forwarding over ssh.  With
previous versions it was enabled by default when ssh-ing to another
machine. It was intially confusing when I changed from FC2 to FC3
because the error message returned in FC3 is not clear that the
problem/change is related to ssh.  e.g. "(gnome-terminal:14625):
Gtk-WARNING **: cannot open display:

Now I find that I have do ssh -X user@remote machine for it to work or
for privileged commands ssh -Y user@remote machine (e.g. gnome,
firefox, etc).
Comment 7 Nalin Dahyabhai 2004-10-21 17:45:11 EDT
How about adding:
   OpenSSH is no longer configured to request X11 forwarding by
   default when connecting to servers.  To enable X11 forwarding, the
   -X or -Y option must be specified, or the "ForwardX11" option must
   be enabled in ~/.ssh/config.

   The behavior of ssh clients which are invoked with the -X flag has
   changed.  In OpenSSH 3.8 and later, X11 forwarding is performed in
   a way that applications run as "untrusted" clients by default.
   Previously, X11 forwarding was performed so that applications
   always ran as "trusted" clients.  Some applications may not
   function properly when run as untrusted clients.  To forward X11
   so that applications are run as trusted clients, invoke ssh with
   the -Y flag instead of the -X flag, or set "ForwardX11Trusted" in
   ~/.ssh/config.
Comment 8 Ed Bailey 2004-10-22 16:09:14 EDT
Added -- thanks Nalin!

Note You need to log in before you can comment on or make changes to this bug.