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.
Related
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.
I've been working with the server only for 2 days so I am sorry if that is simple question. I looked everywhere, but didn't find an answer.
So I have a Google compute engine account and I have owner privileges. When I run
gcloud compute ssh instance --zone us-central1-a
it works, but it creates a key with username that it takes from my computer account.
So when I am in google shell I can add or remove files using sudo. But when I go to Filezilla I have to use ssh file key and username from that key. And the only folder that accessible with that username is it's own folder. I am not sure what is the problem so I gave all the facts I could.
I'm not entirely sure I'm answering the right question, but I'll take a stab at it. The ssh keys created by/used by gcloud are specific to a particular linux user on your VM. As you note, you can use sudo when ssh'd in to edit files/directories owned by different users---the way this works is that you (roughly speaking) temporarily switch users to root when doing the file edit.
An scp client like Filezilla isn't going to be able to switch users that way. So you'll need a different technique to edit files with Filezilla.
I suggest ssh-ing in to your vm and using chmod or chown to change the ownership of files/directories that you want to use with Filezilla. Alternatively you could you use useradd -G to add you username to a group that can edit the files you care about.
Exactly what you'll do depends on the security policy you want to enforce for your files, but there a lots of decent options. The key test to run---can you get to a state where you can edit the files when logged in with SSH, but not using sudo? If so then you should be able to edit the files with Filezilla.
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 am trying to access an ec2 instance using a different (mac) computer. In order to do so, I created a new keypair, used chmod 600 to set the permission, and then used ssh-add. When I try to ssh into my ec2 instance, I get "permission denied (publickey)". I'm sure my error is something idiotic and simple, but I can't seem to find it, can anyone help me out?
You need to ensure the ~/.ssh/id_rsa.pub (if it's an RSA key) from your Mac is appended to the ~/.ssh/authorized_keys file on the target machine. Normally, if this is a default Amazon API, the user is "ec2-user" -- ~ec2-user/.ssh/authorized_keys
REMEMBER TO APPEND and not remove other entries in that file -- else, you risk locking yourself out of that machine ...
is your private key on the new computer?
You need to put that on the computer you ssh in with. I usually keep mine on a flash drive.... I am not running linux atm so i forget the default directory it checks. Maybe this joggs your memory some. I think the directory would be like ~/.id_rsa/ or something?
I spent some time logged into a server (Debian) trying to get Samba access to work better from my Mac.
After logging out and attempting to log back in I was unable to log in using my private key which has been working for years.
Private key login worked for another user from the same client machine, and I was able to modify the sshd.config to allow password login so that I could log back onto the server.
What could I have done to break the keyed login just for my username and why?
I was messing around with creating a Samba password for my username, and I also made my home folder 777 to try to get write access working from Samba. (This was NOT a recursive chmod so the folders below are not 777.)
Your home directory should never be ugo+rwx (777). You should not allow other users to write to your home directory. The ssh daemon checks for file system permissions and will refuse to use the contents of ~/.ssh/ if it or its parent (~/) is writable by other users.
See http://www.openssh.org/faq.html question # 3.14.
Also see 'man sshd_config' and StrictModes (don't turn it off).
Hope this helps.
You can turn on logging in your sshd config if it isn't already. That'll tell you exactly what went wrong. It's often a permission problem on the files in ~/.ssh
The logfile is usually in either /var/log/secure or /var/log/auth.log
There is another possibility that none of the earlier answers have raised: SELinux. If this is active, it will prevent the .ssh folder from being accessed via a Samba share.
It is easy to test: temporarily disable SELinux ("setenforce 0") and see if the .ssh folder can be accessed.