I had an user account set up by my collegue weeks ago, to access our server(rhel). Now Im asked to copy my key so I can login to other servers in the cluster.
My first approach was to copy my /home/user/.ssh folder from the (already set-up) server to the new one. This one obviously fails, I found out with ls -a , that in my .ssh directory is only one file - known_hosts.
Im bit confused from my search results, is it necessary to create a new private-public key pair (I dont have any log about creating in before for the first server, so it was probably already setup for me), or is it sufficient to copy files from the first server and setup owners and permissions?
What you're probably looking for is file ~/.ssh/authorized_keys on the server. If you have your key set up, your public key should be stored there. If there is no such file, than you don't have your keys set up(do you have private keys files on your desktop?).
Please note that for usually ssh will require strict access permissions(rwx for user only) for your ~/.ssh directory and authorized_keys file.
Also you can use as many and as few keys as you wish, depending on your security needs. So using single key pair for multiple servers is possible.
Related
After allowing an application to install ssh keys on my local machine, I can no longer connect to my Digital Ocean shell. (The app is not related to DO; totally different.) I get a
Permission denied (public key)
error that, with -vvv, debugs to
Trying private key: /Users/macbook/.ssh/id_dsa
no such identity: path/.ssh/id_dsa: No such file or directory
My keys are rsa. I have no idea why the machine is asking for dsa.
My .ssh/config file (which I have never read until now) has only information about the application I allowed access. Maybe it was overwritten. If this is the case, could you tell me how to rewrite my .ssh/config file?
My keys on my cloud server (accessed through a DO gui shell) and on my machine still match up. The folder permissions are ok. I've been using this for months with no trouble until now.
Any suggestions?
Edit:
This was probably a result of the third party application overwriting my .ssh/config file. Because the writing of this file was always automated for me, I never took any notice of it. If you try:
regenerating new keys
appending the new public key to the authorized_keys file on your server on a new line
writing a new .ssh/config file as so:
-
Host 111.11.11.1
User bob
IdentityFile ~/.ssh/new_file.pem
then you might make it. Somehow now I can't get a passphrase to work on the new keys.
I have an account on a server that I need to give sftp access to another person. This person however only needs access to a small subset of directories. Is it possible, without creating another user account, to restrict an ssh key to that subset of directories.
Basically the website on which these directories are located lives within the home directory of a specific user account. I would prefer not to have to create a separate user account just to lock the use down to those directories. If it is possible to lock down the access to specific directories using an ssh key that would be ideal.
It's possible, but it's sort of a hack. The much preferred, simpler way is just to only grant that user permissions to certain files and directories.
This is an answer on how to accomplish your goal using ssh rather than sftp. This has some chance of being acceptable to the OP because it still uses the ssh tool chain.
This technique is using a feature of ssh that allows ssh to run a command based on the private key presented to host machine. When the host sees that key, then it runs the associated command. For the command we will use "cat" which will dump the file.
add a line that looks like this to ~mr_user/.ssh/authorized_keys2
command="/usr/bin/cat ~/sshxfer/myfile.tar.gz.uu",no-port-forwarding ssh-dss xxxPUBLIC_KEYxxx mr_user#tgtmach
populate the file like this:
uuencode -m myfile.tar.gz /dev/stdout >~mr_user/sshxfer/myfile.tar.gz.uu
transfer the file by being on the target machine and running this:
ssh -i ~/keys/privatekey.dsa mr_user#srcmach |sed -e's/
//g' |uudecode >myfile.tar.gz
The tricky part to that command is there is a newline in the sed command to remove the newlines from the .uu file.
I did not found a way to pass in a name of a file to transfer, so I had to make a key for each file I wanted to transfer. This was okay for my use case because I only had two files I wanted to transfer.
I couldn't find any basic info for designers (on a mac) for how SSH keys work - so thought I'd ask them here.
If I want to connect my work workstation to:
Github
A DEV server
A LIVE server
Do I generate one ssh key on the workstation and add it to all those servers or do I generate multiple keys - one for each server?
Once I've generated a key (or keys), do I copy it into the id_rsa file in my user account on that server (I realize I may have to create the id_rsa file)?
And if I now want to access the same server but from my home laptop, do I add the laptop's ssh key to the same id_rsa file on the server or do I create a new file?
If I need to create a new file, does it matter what the file is called - laptop_rsa?
I basically want to disable root login on my servers but I don't really understand how SSH applies to multiple machines and multiple servers.
Any help or pointers in the right direction would be much appreciated.
Cheers
You only need one key for the local machine that you are connecting
to all three servers.
For the DEV server and the LIVE server, you can add the contents of
your id_rsa.pub file to the
authorized_keys file on each of the target servers.
This file will be in the ~/.ssh directory. You will
need to create the file if it's not there (touch
~/.ssh/authorized_keys). Adding your public key to this file
will let you login with your passphrase rather than a password.
Place all authorized keys (i.e. your laptops id_rsa.pub) in the same
authorized_keys file on the target server.
Adding your keys to authorized_keys doesn't affect root login (that is a separate setting), however, it will prevent people from attempting to brute-force your password if you then turn off password login.
I use a private SSH key and passwordless entry for a number of user accounts on a server that hosts a number of websites.
I use the same private key for each user account. (because I'm lazy? or is that the "right" way).
I now want to authorise another trusted computer in a different part of the country. If I copy the contents of my ~/.ssh onto that machine will that work without any other set up?
Will both machines be able to maintain a connection at the same time?
Update: as an additional security recommendation, you should generate a new set of keys for a new machine and send your new public key out to the various hosts you use it on, rather than copying your private keys. If you're just moving everything to a new computer however, you can take your keys with you, but remember to destroy them securely on the old computer.
The correct answer is to copy your .ssh directory from the old machine to the new. This part is easy (scp -r .ssh user#newmachinehost:~ will do fine—or you can type the keys in character-by-character, up to you).
BUT—I think the missing link to answer this question is what you have to do after you copy your private keys to the new machine.
I had to run the following for each key (I have 3 separate keys for various organizations)
ssh-add .ssh/[key-filename]
If the filename argument is omitted, id_rsa is assumed.
Once you do this to each key (and enter they key's passphrase if required; it will prompt you), ssh will be able to use those keys to authenticate.
Otherwise, no amount of copying will do much. SSH will ignore the keys in .ssh until they are explicitly used (via ssh -i [keyfilename] ...).
This should work, and both machines should be able to maintain a connection at the same time - I've had to copy my ~/.ssh directory a few times before when hard drives have crashed.
Copying ~/.ssh between systems is fine so long as it's limited to just files like authorized_keys, config, and known_hosts. If you want two hosts to be able to access each other, each host needs its own private SSH key, which must then be added to the other host's authorized_keys file.
It is not a good idea to copy private keys across systems!
Think of real world secrets. Each person who learns the secret increases the chance of it being revealed.
Every time you copy your private key to a new system, you increase your risk of exposure because copied private keys are less secure than the weakest system they live on (because the other systems aren't invulnerable either).
If your laptop gets stolen, you need to revoke all private keys (and saved passwords) that were stored there. This becomes problematic when the only way to log into servers is with that very key. You'd better remember to generate a new key on your desktop and install it on each system you revoke the old key from!
Now consider your desktop gets hacked and somebody steals your private key without your knowledge. Perhaps you had shared this key between your work laptop and your personal desktop, but your desktop doesn't really need access to your work system (because you have good work/life balance). That attacker can now access your work system even without having compromised your laptop. The infosec team at work forces you to hand over your laptop so they can audit it, but after a week of analysis, they find nothing. Not so fun.
These may seem far-fetched and unlikely, especially if you're not a prime target (e.g. an executive or sysadmin), but it's just a good practice, especially given how easy it is to create new keys for each system and install their public keys on each appropriate server. (Consider one of the myriads of config/dotfile propagation systems if this seems daunting.)
Additionally, it means you'll upgrade the security of each key to meet the standards as they improve. As you retire old systems and remove their keys, you rotate out their weaker keys. (And if some trash picker finds your old laptop and undeletes your keys, they won't grant any access.)
This is secure so long as you don't share you private key. Just place the public key in the remote machine's ~/.ssh/authorized_keys file for passwordless entry. Don't share the private key though.
The keys are just for authentication. You can log on as many times as you wish with the same key, so long as you can log on with that private key once.
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.