-1

We are trying to patch an issue we are having with some file systems by making SSH work without the permission validation on the SSH private key.

Error message: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

For some odd reasons, we are not able to change the access rights to some files (Welcome to the Cygwin world of Windows)

Anyone know if there is a way to bypass the ssh validation through whatever way? I did not find anything relevant in the ssh options.

If you are to reply chmod 400 or 600 it is not what I am looking for!

migrated from stackoverflow.com May 28 '13 at 16:09

This question came from our site for professional and enthusiast programmers.

  • 4
    If chmod 600 [file] doesn't work under Cygwin, then your Cygwin install is broken. What happens when you try it? What version of Cygwin are you running? – Aaron Miller May 28 '13 at 16:23
2

Anyone know if there is a way to bypass the ssh validation through whatever way?

Your question makes zero sense in this situation... you're receiving an error due to wrong pernsissions and/or ownership of the key

Keys must only be accessible to the user they're intended for and no other account, service, or group.


Windows Powershell Terminal


  • GUI:
    • [File] Properties - Security - Advanced
      1. Set Owner to the key's user
      2. Remove all users, groups, and services, except for the key's user, under Permission Entries
      3. Set key's user to Full Control


  • CLI:

    :: Set Variable ::
    set key="C:\Path\to\key"
    
    :: Remove Inheritance ::
    cmd /c icacls %key% /c /t /inheritance:d
    
    :: Set Ownership to Owner ::
    cmd /c icacls %key% /c /t /grant %username%:F
    
    :: Remove All Users, except for Owner ::
    cmd /c icacls %key%  /c /t /remove Administrator BUILTIN\Administrators BUILTIN Everyone System Users
    
    :: Verify ::
    cmd /c icacls %key%
    



WSL/Cygwin Terminal


  • CLI

    # Set Variables
    
      # Key  
        key="/path/to/key"
    
      # User:
        user="$(echo $USER)"
    
    # Set Ownership
      # This assumes user's name is also user's group name
        chown $user:$user $key
    
    # Set Access Rights
      chmod 0600 $key
    
    # Verify
      ls -l $key
    
  • This CLI solution worked for me on Windows 10 Bash (WSL) where all the point and click solutions failed. Thanks! – r3robertson Aug 17 '18 at 0:14
  • No problem at all =] Just a FYI (as I've been seeing many users trying to share an SSH key within a Windows directory with WSL): Sharing file access between Windows <-> WSL with a file that must only be accessible to a specific user, and that user only, is not supported. Anyone utilizing WSL should read this answer and the Windows Developer Blog post: Do not change Linux files using Windows apps and tools** – JW0914 Aug 17 '18 at 11:48
0

I'm not sure if you understand what this message means or what you are asking for.

Basically, SSH is telling you that your private key, which in this case as it's not owned by you, is public. That means in plan English: "Your password is in plain text. Everyone who has access to this box has access to it."

You want SSH to ignore this but SSH was design to be safe and secure. As you were told: if you can't change permissions on this file you have not installed cygwin correctly.

Could you please explain why you want to override this warning?

You can always install telnet-server

  • I am trying to slowly move out users from static passwords to ssh keys . I prefer them to have them have an insecure ssh key on their desktop than sharing passwords by email (as it is currently done) – Thierry May 28 '13 at 20:38
  • Again, try fixing real problem. (chmod 600). When your car is telling you that it's low on petrol do you mask it with the tape? Please post output of the chmod 600 on your folder/key file. Remember that ssh files are stored in .ssh! – Chris May 28 '13 at 21:12
  • telnet provides no means of securing the connection and should never be utilized, unless whatever ancient system one is working on only offers remote access via telnet (at which point, the ancient system should be upgraded rather than utilizing a known exploitable method) – JW0914 Jul 9 '18 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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