I don't understand why, in every tutorial or book I read about authenticating clients to servers using SSH keys, they recreate the pair of SSH keys?
Isn't the pair already created when you install ssh client? like in ubuntu, after doing: apt-get install ssh openssh-client, when you go to /etc/ssh, you find your keys!
So why regenerate them? and why ssh-copy-id doesn't use these keys, in /etc/ssh directory?
Thank you
Isn't the pair already created when you install ssh client?
No, it is not.
like in ubuntu, after doing : apt-get install ssh openssh-client, when you go to /etc/ssh, you find your keys!
These are not authentication keys, but server host keys. If you would install only openssh-clients, these keys will not be created. They are created only if you install openssh-server!
So why regenerate them? and why ssh-copy-id doesn't use these keys, in /etc/ssh directory?
Answered above. They are not authentication keys, but server host keys. Authentication keys are per-user and in your home directory (~/.ssh/).
Related
So recently I've been trying to set up a Git server to manage personal projects and work. I created a bare Git repo on a spare laptop running Ubuntu and I installed Git Bash on my Windows machine. Right now I'm having some issues in actually being able to clone my Ubuntu git server to my Windows computer.
I used git remote add origin myserver#myserver-Dell-System:/home/myserver/CentralRepo.git but
whenever I try to clone to my Windows machine, Git bash spits out this error:
ssh: Could not resolve hostname myserver#myserver-Dell-System: Name or service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and repository exists.
I double checked my add to make sure the address of my Git server was correct and I assume Git bash for Windows comes with OpenSSH.
Does anyone know why this is happenning and how I can get my Windows machine to sucessfully clone from a server to itself? Thanks!
A valid ssh url would be
auser#myserver-Dell-System
You can check if you can resolve and connect to that server with
ssh -T auser#myserver-Dell-System
That supposes that you have generated a public/private ssh key pair, and added your public key to ~auser/.ssh/authorized_keys file first.
See "Adding SSH Keys to authorized_keys"
when I make git clone with ssh from a user prompt it works properly.
git clone ssh://URL.com/soft.git soft_git
the ssh key id_rsa and id_rsa.pub are under /home/user/.ssh
my purpose is the execute git with sudo but I got the following error
Cloning into '/home/user/git/soft'...
Permission denied (publickey,keyboard-interactive).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I create a folder /root/.ssh and I copy the ssh keys into it but I got the same error
how to execute git with sudo properly.
When you run git using sudo, git will run as root. Because git is running as root, ssh is running as root. Because ssh is running as root, it is trying to log on to the remote server as root. The remote server is not okay with this (as it should be!)
You will need to do two things:
Put the username in your URL: ssh://myusername#URL.com/soft.git.
Make your SSH key available to the root user, because it will look under /root/.ssh instead of /home/user/.ssh. (You could also probably point SSH at the correct key, but I don't know how to do this, and SSH is picky about permissions.)
On my computer (Ubunutu 18.04), adding SSH_AUTH_SOCK=$SSH_AUTH_SOCK after sudo and before git fixed the problem:
sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK git clone git#github.com:my-github-account/my-repo.git
Normally, sudo's SSH_AUTH_SOCK environment variable won't be set properly. Executing the git clone with SSH_AUTH_SOCK=$SSH_AUTH_SOCK sets sudo's SSH_AUTH_SOCK environment variable to whatever it is for you.
This way, you don't need to add an extra .ssh dir for sudo with copies of your keys, which is what I think one of the other answers suggests.
The solution is more fully explained in this rather old github gist:
https://gist.github.com/scottjacobsen/4281310
P.S. I'm adding a new answer several years later; I googled a solution to this problem, and this SO Q/A is one of the first things that comes up.
Normally the default remote ssh user is the same as your user name. If you're using sudo this will be root which probably isnt' going to work. You need to supply the remote username.
sudo git clone ssh://username#URL.com/soft.git soft_git
You can generally resolve git ssh issues easier by trying to login to the remote with plain ssh. You'll get better diagnostics and can see what's going wrong.
sudo ssh ssh://URL.com/
This question already has answers here:
WinSCP connect to Amazon AMI EC2 Instance changing user after login to "root"
(6 answers)
Closed last year.
I am trying to use WinSCP to transfer files over to a Linux Instance from Windows.
I'm using private key for my instance to login to Amazon instance using ec2-user. However ec2-user does not have access to write to the Linux instance
How do I sudo su - to access the root directory and write to the Linux box, using WinSCP or any other file transfer method?
Thanks
I know this is old, but it is actually very possible.
Go to your WinSCP profile (Session > Sites > Site Manager)
Click on Edit > Advanced... > Environment > SFTP
Insert sudo su -c /usr/lib/sftp-server in "SFTP Server" (note this path might be different in your system)
Save and connect
Source
AWS Ubuntu 18.04:
There is an option in WinSCP that does exactly what you are looking for:
AFAIK you can't do that.
What I did at my place of work, is transfer the files to your home (~) folder (or really any folder that you have full permissions in, i.e chmod 777 or variants) via WinSCP, and then SSH to to your linux machine and sudo from there to your destination folder.
Another solution would be to change permissions of the directories you are planning on uploading the files to, so your user (which is without sudo privileges) could write to those dirs.
I would also read about WinSCP Remote Commands for further detail.
Usually all users will have write access to /tmp.
Place the file to /tmp and then login to putty , then you can sudo and copy the file.
I just wanted to mention for SUSE Enterprise server V15.2 on an EC2 Instance the command to add to winSCP SFTP server commands is :
sudo su -c /usr/lib/ssh/sftp-server
I didn't have enough Reputation points to add a comment to the original answer but I had to fish this out so I wanted to add it.
ssh to FreePBX and run the commands stated below in your terminal:
sudo nano -f /etc/sudoers.d/my_config_file
YourUserName ALL=(ALL) NOPASSWD:ALL
sudo systemctl restart sshd
Winscp:
under session login ==> Advanced ==> SFTP
Change SFTP Server to:
sudo /usr/libexec/openssh/sftp-server
I do have the same issue, and I am not sure whether it is possible or not,
tried the above solutions are not worked for me.
for a workaround, I am going with moving the files to my HOME directory, editing and replacing the files with SSH.
Tagging this answer which helped me, might not answer the actual question
If you are using password instead of private key, please refer to this answer for tested working solution on Ubuntu 16.04.5 and 20.04.1
https://stackoverflow.com/a/65466397/2457076
I have a private repo that I want to install in my package.json file.
"private-module": "git+ssh://git#bitbucket.org:private/private-module.git"
By default npm uses your default private key. I want to be able to specify which ssh key npm should use when running npm install. Is there any way to do this?
Here are a few solutions:
Add an entry to your ~/.ssh/config. For example:
Host bitbucket.org
IdentityFile ~/.ssh/bitbucket_key
IdentitiesOnly yes
Use ssh-agent and add your key to the agent instance beforehand.
Use something like ssh-ident for choosing ssh agents and identities dynamically based on the current working directory or arguments passed to ssh-ident. As their readme states, you would typically alias ssh-ident to ssh so that it's automatically used everywhere.
After you have made the changes in the first part of mscdex's answer you might need to add the host to the list of known hosts - before the npm install command will work.
You can do this by cloning the private repo to another directory:
git clone ssh://git#bitbucket.org:private/private-module.git
You might be asked if you want to proceed, type yes and enter, then bitbucket.org is trusted. Go back to your project directory and retry npm install. This is what was needed for mscdex's answer to work for me.
There are other ways of adding trusted hosts, but this does that in addition to verify that you can actually get to the desired private repo.
You can apparently do this with
export GIT_SSH_COMMAND='ssh -i ~/.ssh/your_private_key'
Otherwise, you can use your NPM Token in your .npmrc file:
// .npmrc
//registry.npmjs.org/:_authToken=${YOUR_NPM_TOKEN}
Source: https://blog.npmjs.org/post/118393368555/deploying-with-npm-private-modules
I removed the gitosis-admin folder, but naturally something is still screwed up when I run gitolite. I ran apt-get install gitolite and then gl-setup on the new .pub key I created and used to set up the passwordless access. The set up seemed to run fine, but now I'm prompted for a password (of course I am!) when running the git clone gitolite#server:pathgoeshere command.
I'm so tired. I have wrestled with gitosis for 2 weeks. PLEASE don't tell me installing Gitolite will be as painful. Should I remove all the stuff Gitosis polluted my server with to ensure Gitolite is working correctly? Where would it be. Consultation of the interwebs revealed multiple possible hiding places for Gitosis things...like keys. I removed the Gitosis folder in home.... so far that's all.
This piece of advice is probably helpful to you here.
And in case you have multiple keypairs, make sure that your .ssh/config is set up to use the proper key for this connection.
Having Gitosis pre-installed shouldn't affect how Gitolite works, but of course there might be some conflict. I have never installed Gitosis, just Gitolite.
(Which, by the way, worked perfectly fine with only user permissions on my remote shell!)