Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm using a VirtualBox VM with Debian as guest OS. In order to share SSH keys between the Windows host and the Linux guest system, I've defined the folder ~/.ssh as a shared folder. Bun now I'm getting an error:

# git clone git@github.com-user:user/project.git
Cloning into project...
Bad owner or permissions on /root/.ssh/config
fatal: The remote end hung up unexpectedly

Usually to resolve this problem it's only needed to set stricter permissions for ~/.ssh. But in this case it's not possible, since it's a shared folder.

Is there another solution/workaround for this issue?

Thx

share|improve this question

migrated from serverfault.com Mar 14 '13 at 23:02

This question came from our site for professional system and network administrators.

5  
Your first problem is that /root shouldn't be a shared folder. You shouldn't normally be doing things as root. –  Zoredache Mar 7 '13 at 23:34
    
Why not? It's ("only") a virtual machine, not a real server. –  automatix Mar 7 '13 at 23:58
6  
Because it is a bad habit. If you do things in a insecure manor on your local system, you will never train yourself to do things correctly on production systems. –  Zoredache Mar 8 '13 at 0:40
3  
Start over and set up your virtual machine correctly, not using the root account. –  Michael Hampton Mar 8 '13 at 2:20

4 Answers 4

The proper solution is to stop using root to check out a git repository. Give each user their own account and keep the permissions tight enough that security isn't compromised.

A different solution would be to use one of the web-based git servers rather than an SSH-based one. I've never used any of those so I can't give you much advice there.

share|improve this answer
    
Thank you for your answer! To the first solution: It's a VM and I'm using only one user -- root. It's comfortable and no problem in the VM context. To the second solution: I use GitHub and it needs SSH authenification. –  automatix Mar 7 '13 at 23:48
3  
@automatix Create a normal (unprivileged) user account, like your operating system's documentation almost certainly encourages you to. As Zoredache pointed out, you are practicing bad habits - always treat systems as if they're production. –  voretaq7 Mar 8 '13 at 1:44
    
@automatix, root is never to be used as a regular user in Unix. Ever. –  vonbrand Mar 8 '13 at 12:40
    
This doesn't in any way answer the question of how to configure ssh so that it doesn't complain about the permissions of his key folder. –  frankster Oct 7 '13 at 11:36
1  
@frankster Of course not; It's a bad idea. I have answered the question "Is there another solution/workaround for this issue?" –  Ladadadada Oct 7 '13 at 14:15

A solution do this that would permit you to still have /root as a 'shared folder' would be to use the AuthorizedKeysFile in your sshd_config file, and set it to pull your authorized keys from some other directory.

share|improve this answer
    
I'm not sure, whether I've understood you correctly. The VM is not the SSH server. Both -- the host and the guest system -- are clients. The dealing with the file sshd_config is the server (in this case GitHub) part. –  automatix Mar 8 '13 at 0:02
    
Ah, in that case then update your global ssh_config, and use the IdentityFile to relocate your key files so they are stored in a location with proper permissions. –  Zoredache Mar 8 '13 at 0:14
    
It will not resolve the problem: I will still have to choose between a shared key folder and the SSH authentification. –  automatix Mar 8 '13 at 0:37

Disclaimer: I now believe this is a permissions check by the git client, not the ssh server. That would make this answer incorrect. I am leaving my answer here so that we don't have to go over the topic again.

I really don't want to answer this, but someone is going to post the answer you're looking for eventually and it may as well be with the appropriate disclaimers.

  1. Don't do this. Everyone else has been steering you away from this answer for a reason. It's terrible security.
  2. No, really. Don't do this. No matter how convenient it may seem, this goes against some of the most basic security conventions that are taken for granted in the Unix industry. You will lose a great deal of respect from those in your professional life if they discover that you have done this, even if it's casually on your own system.
  3. You are asking to be owned.
  4. If you're still determined on going through with this...

The answer is in man sshd_config, you're looking for StrictModes. It cannot be configured on a per-user basis; that's very deliberate.

share|improve this answer
2  
On second thought, this question probably falls under "system misuse" in the FAQ. I'm going to flag it. –  Andrew B Mar 8 '13 at 1:19
    
Unfortunately users are permitted to shoot themselves in the foot if they really want to. @automatix - If you decide to do this you may find this question and its answers helpful in short order... –  voretaq7 Mar 8 '13 at 1:40
    
Thank you for your excelent answer! Yes, I understand your point. But IMHO in the context of a VM I don't need to follow the normal security guidelines. I've set StrictModes to no. But I'm still getting the same error: Bad owner or permissions on /root/.ssh/config fatal: The remote end hung up unexpectedly. –  automatix Mar 8 '13 at 1:54
3  
@automatix A virtual machine needs the same security as a physical machine. Perhaps you mean it needs less security because it's on an isolated network - if so, fine. But if its attached to the network like a physical machine, it needs the same security. –  Grant Mar 8 '13 at 2:13
1  
@ParthianShot, Debian (or any for-regular-users) Linux distribution is Unix-like enough for the current discussion's issue. –  vonbrand Jul 11 at 23:24
up vote -1 down vote accepted

Solution

I had mounted my shared folder with this command (saved in /etc/rc.local in order to mount the folder on system start automatically):

mount -t vboxsf -o uid=1000,gid=1000 sshkeys /root/.ssh

Now I've changed the user, the usergroup, and the access rights of the mounted folder in the mount commando:

mount -t vboxsf -o uid=0,gid=0,umask=077 sshkeys /root/.ssh

It works.

P.S. For everyone, who has participated in this discussion:

Since the thread became a bit chaotic, I would like to summarize it:

At first I had the problem, that I could not use my keys, when they came from a shared folder (Bad owner or permissions... error). The corollary for me was, that there were two ways: (a) either to set the user, group and the access rights for the folder how the SSH client (?) needs or (b) to make it ignore its access rights restrictions. Since I could not apply chown/chmod to my shared folder and thought, it were not possible to change the access rights for it, I saw (b) as the last possibility to resolve the issue -- and changed the question/title. It was a mistake and I've just made this change back.

To the discussion about the security: I'm working as root (on my dev VM!) and it's a deadly sin for every safety-conscious user. Actually I also think, that normally one should not log in as root. But I hold the opinion, that it doesn't apply to the case of a dev virtual machine. Anyway -- it is an offtopic, since it has nothing to do with the issue, I've described. This issue can occur for every user of every usergroup.

share|improve this answer
    
You are free to hold that opinion, just as we are free to disagree with you. .ssh is intended to be a highly secure, unshared directory that is not managed this way. (whether it be root or any other user) You would not find the same resistance if it involved automation without permission munging. This is akin to saying that it's okay to munge the permissions of per-user registry hives in Windows so that you can tweak their security preferences; it's just something people don't do. –  Andrew B Mar 8 '13 at 15:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.