I was struggling with setting up public key authentication via SSH on a Windows Server 2012 R2 instance. I installed OpenSSH on the instance.
I made sure to have the public key on the instance in the ssh folder of the user and tried to SSH in from an instance with the private key. However, I kept being asked for the password.
Finally, I came across this blog which says to comment out the following lines
#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
in the C:\ProgramData\ssh\sshd_config file. After that, I was able to login with the public key.
My question is, why did that work? I've never seen any indication on any other blog that this needs to be done and I'm not sure what commenting those lines does.
This change is introduced in here:
Override default location for authorized_keys for administrators by manojampalam · Pull Request #369 · PowerShell/openssh-portable
And here is the tread discussing this change:
Is administrators_authorized_keys a security problem? · Issue #1324 · PowerShell/Win32-OpenSSH
These two lines redirect the authorized_keys to a path that requires elevated session to make change while you are logging in with a admin account. This is said to prevent an admin login in a non-elevated session, generate a key pair and append the pubkey to authorized_keys in his home path. And then ssh localhost to get a elevated session inside a non-elevated one, which could bypass the UAC. The author of the commit thinks this is a privilege escalation.
According to the discussion in that thread, this change didn't actually solve any concern, but rather introduced a bunch of new issues. The biggest one is that it breaks the pubkey authentication in non-English environment.
It introduces a localization issue and even more unexpected behavior.
The entry in the default sshd_config reads: Match Group administrators - but that is a localized group name that only applies
to english Windows installations. This means that this Match
statement only ever matches as intended on english Windows installs,
in any other locale the translated name of the S-1-5-32-544 group
will not match and the authorized_keys of administrative users will
continue to be in their respective userprofile paths - what a mess!
Source: issuecomment-749098394
This is the reason I searched for the same issue in midnight and came across your question. Just delete or comment out those two lines.
Related
Unfortunately I forgot my id_rsa key passphrase. Since the only solution I found so far is to reset the key by a new SSH key. I now have the problem that I need to add the new key to each server I'm connected to. Is there a possibility to do this automatically? Maybe by copying the information from the "known_hosts" file of the old key to the new one?
This is not quite a duplicate of How to reset or change the passphrase for a GitHub SSH key?, but the answer there is valid.
You have to remember that the whole point of the passphrase mechanism was to prevent access by untrusted hosts. The machinery is specifically setup so only a machine with the proper passphrase (or several) can connect to the server.
The known hosts are only useful to you as a todo list. You need to access one by one somehow (not SSH), to send the new passphrase you generated. The known hosts itself is not the security mechanism, it's just a small part (the less important part, security can do without). It will save you typing some ys in the future.
I'm sorry to say you have to manually get to each machine. If by some miracle you had another vpnish API that all your servers shared you could automate that, but most of us don't.
I work for a webdevelopment company that also manages the hosting of our customers websites.The hosting is shared and only on 3 servers. The webservers are debian webservers where each customer has his own account to reach his own website files.
Normally I would login to the server as this customer and add my ssh key to an authorized_keys file so that I can simply ssh into the account without having to lookup the password, this works perfectly fine.
The downside is I have to do this for every account over again, is there a way to add it to the server only once so that I can access all the accounts?
I tried putting the authorized_keys file in a .ssh folder in the root of the server but this doesn't seem to provide me access with any account. I have to admit my linux knowledge is limited, so am wondering if this is even possible?
You can update your sshd_config and add to AuthorizedKeysFile also for example some path in /etc/ssh/authorized_keys where you can put your master key. This would authorize you with this key to all accounts. But don't forget to leave there also the original one:
[...]
AuthorizedKeysFile .ssh/authorized_keys /etc/ssh/authorized_keys
[...]
Or you can use certificates as described in ssh-keygen manual page. This would allow you to audit the access with these keys.
You can consider to use emcSSH tool for your purposes. This is blockchain-based distributed Public Key Infrastructure and group management system.
You can read details and download here: http://emercoin.com/EMCSSH
If needed any assistance, feel free for contact me. I'm author of this system, and can answer your questions.
I had a working instance of Gitlab until a few weeks ago, when we had to move all the user directories to another disk b/c of resource constraints. I've gone through and fixed all the paths that I could find, and so now my gitlab instance is up and running again. Git appears to be working, and I pass the gitlab self-diagnostic test.
However, from a remote client that's previously worked, I get prompted to provide the git user's password, which suggests an ssh problem.
Looking in my .gitolite stuff (conf/gitolite.conf & the keydir), things look in order. My public key is in the keydir, and the rights are assigned in the gitolite.conf correctly.
EDIT: gitolite public keys were in the .ssh/authorized_keys file and the protections were as created by gitolite setup.
What am I missing?
My public key is in the keydir, and the rights are assigned in the gitolite.conf correctly.
This isn't enough.
For ssh to not ask you for a password, you need to check if your ~gitlab/.ssh/authorized_keys is complete (with the gitolite public keys in it, and with the right protections)
Check out the gitolite setup command (for gitolite V3).
I am having a strange problem which I've googled and googled with no result. I'm attempting to setup a certificate for a wcf service application on windows server 2008 R2. I've imported the certificate into the localmachine personal store, and I'm getting the dreaded
"Keyset does not exist...the certificate ... must have a private key that is capable of key exchange. The process must have access rights for the private keys."
I have tried to set the permissions on the private key, using the "Manage private keys" option in mmc, also tried setting the permissions on the private key file manually that is located in C:\programdata\microsoft\crypto\rsa\machinekeys. I verified I'm modifying the right file by using the findprivatekeys tool, and also tried using the WSE X.509 Certificate tool. For sanitys sake, I even gave read access to "Everyone" on the file, still doesn't work.
Is there something I'm missing here? I'm using IIS7 and I normally give access to the file for the IIS_IUSRS group. All of this has worked fine in other testing on VMs. I've even used the exact same certificate on other machines, and they work there...
I'm lost...The one thing I've noticed is that if I edit the permissions in the 'manage private keys' dialog, the security settings changes don't reflect when I look at the permissions for the file, and vice versa. Where else could the file be? Regardless, I gave max permissions from both places with no luck.
Not sure what was going on here, but over the course of testing, the permissions on the MachineKeys folder was drastically modified - so I removed permissions for all the users listed there except the Administrators group, deleted the problem certificate (through mmc) and re-imported it again. Then, I added IIS_IUSRS read and execute permission only for that private key, and I seem to be back up.
On a related note, I was using aspnet_regiis -pi to import a key pair for something else, which was failing with "Safe handle was closed." Fixing the permissions on the MachineKeys folder fixed that as well...
I guess I'm being a little hesitant but I deal with vcs's occasionally and always get asked for some sort of prompt, of course I'm attempting to access an external machine which I'm sshing into.
Basically my question is, say I don't have root access on this machine, would it still be possible to set this up? I've skimmed through reading it a couple times and I'm pretty sure I got the method down - you generate pub/private keys, sftp to the machine and throw your public into some authorized_keys directory. How is this managed with multiple users for example? Could the generic file name ( the .pub ) get overwritten, or am I completely misunderstanding the process here and it's setup to allow multiple keys natively?
If I'm not a sudoer and one of the server's directories needs to be chmod'd to say 700 whereas it's 655, I can't really do anything other than ask for su access, right?
If you have ssh access to the remote machine, you can generate the key pair on your local machine, add the public key to the authorized_users file on the remote machine, and then use this for authentication. You don't need root privileges to do this. The keys and authorized_files usually reside under your home directory ( myhome/.ssh/authorized_keys etc) so they don't get confused between users.
Your questions about setting directory permissions is unrelated, but if you own the directory or its parent (or its parent...) you will be able to set any permissions on the file in that directory.
Sounds to me like it might be time to curl up with a general *nix administration book, perhaps? Not light reading, but it can be useful and I always find it most informative to learn the details when I'm actually struggling with them.
I ssh all the time into a machine that allows su or sudo. But, it's set up not to allow ssh via "ssh root#machine". So to answer your question, yes it's possible.
You can only change the directory permissions if you own the directory or if you have root access.