Bug 746290 - ssh-keygen should default to ~/.ssh not to the current directory
ssh-keygen should default to ~/.ssh not to the current directory
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Petr Lautrbach
BaseOS QE Security Team
: FutureFeature, Triaged
Depends On:
Blocks: 746961
  Show dependency treegraph
 
Reported: 2011-10-14 12:44 EDT by Matěj Cepl
Modified: 2012-11-05 08:08 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 746961 (view as bug list)
Environment:
Last Closed: 2012-11-05 08:08:06 EST
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 Matěj Cepl 2011-10-14 12:44:47 EDT
So, following the orders of the Fedora project people I have decided to recreate my ssh keys. And this is what happens:

mitmanek:~ $ cd
mitmanek:~ $ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/matej/.ssh/id_rsa): id_fedora_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
open id_fedora_rsa failed: Permission denied.
Saving the key failed: id_fedora_rsa.
mitmanek:~ $ restorecon -v -R .ssh
mitmanek:~ $

Of course, it was my fault, that I forgot that keys have to be generated in ~/.ssh and not anywhere else because of SELinux, but it would be helpful if when getting a relative path (like in this case) ssh-keygen defaulted to ~/.ssh rather than to the current working directory.

Thank you
Comment 1 Daniel Walsh 2011-10-14 14:16:13 EDT
We could fix the SELinux but this could be a problem from a security point of view, since the ~/.ssh directory tends to be a protected directory.  I think if the user specifies a file without a path it should default to ~/.ssh
Comment 2 Tomas Mraz 2011-10-17 03:42:55 EDT
I think SELinux should allow ssh-keygen writing anywhere. Basically ssh-keygen is a simple admin/user called local tool, not connecting anywhere, and it should be unconfined.

As for it defaulting to .ssh directory - this should be changed upstream first.
Comment 3 Miroslav Grepl 2011-10-17 04:13:03 EDT
We might want to think about removing a transition to ssh-keygen at all since we have file name transition now so .ssh dir will create with the correct label.

Matej,

chcon -t bin_t `which ssh-keygen`

should work.
Comment 4 Tomas Mraz 2011-10-17 04:20:16 EDT
Yes, Miroslav, I agree.
Comment 5 Daniel Walsh 2011-10-17 12:31:03 EDT
Yes in Rawhide we want to remove transition from user roles.
Comment 6 Daniel Walsh 2011-10-17 12:38:03 EDT
Removed transition in selinux-policy-3.10.0-41.fc16
Comment 7 Fedora Admin XMLRPC Client 2011-11-30 07:25:22 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Petr Lautrbach 2012-11-05 08:08:06 EST
$ id -Z 
staff_u:staff_r:staff_t:s0
$ mkdir tmp
$ cd tmp/
$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/staff/.ssh/id_rsa): id_fedora_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_fedora_rsa.
Your public key has been saved in id_fedora_rsa.pub.
The key fingerprint is:
4e:ba:ef:fd:de:60:07:ad:b6:2b:6c:22:c3:d2:9f:df staff@f16-openssh
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|             .   |
|        S   . .  |
|       +     o   |
|     o. ..  = .  |
|    . =..o++ =   |
|     ..*=+o+E..  |
+-----------------+
$ ls -lZ
-rw-------. staff staff staff_u:object_r:user_home_t:s0  id_fedora_rsa
-rw-r--r--. staff staff staff_u:object_r:user_home_t:s0  id_fedora_rsa.pub
$ ssh-copy-id -i id_fedora_rsa localhost
staff@localhost's password: 
Now try logging into the machine, with "ssh 'localhost'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

$ ssh -i id_fedora_rsa localhost
staff@localhost's password: 
$ exit


$ chcon -t ssh_home_t id_fedora_rsa
$ ssh -i id_fedora_rsa localhost
Last login: Mon Nov  5 14:02:13 2012 from localhost

$ rpm -q openssh selinux-policy
openssh-5.8p2-25.fc16.x86_64
selinux-policy-3.10.0-91.fc16.noarch

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