I need to do a sudo command on a ssh server.
It asks for password
[sudo] password for myname:
but it's apparently different from the password for ssh server itself.
Can sudo only be used by root?
If not, should I ask the maintenance people for the password?
Or is there a way to set it up myself?
See : http://www.gratisoft.us/sudo/sudoers.man.html
Specifically see rootpw, targetpw , etc.
It is possible to have two different passwords, one for the account and another for the sudo command.
You should ask to the Maintenance people....
Related
I am using ssh to connect to remote server from local.
[siebel#local ~]$ ssh remote
siebel#remote password:
I dont want to input the password manually. I want to write a script in which I will give the password as an input. It will enable me to login without manual action.
I don't want to setup passwordless authentication by ssh-keygen. I tried to use expect but spawn is not working. I don't want to install any other utility also.
As I said its strongly discouraged to hardcode passwords for security reasons but what I will suggest, only if you just can't avoid doing it. is to use sshpass.
You can easily do a:
sudo apt install sshpass
following that the following simple command will do the trick for you.
sshpass -p "PASSWORD" ssh -o StrictHostKeyChecking=no USERNAME#REMOTE_HOST:Custom port number(default is 22)
I know this question has already been asked several times but I got another problem. I have a part in my script where I connect through ssh and scp and everytime I run the script it always ask for the password. Most of you would probably answer that I should use expect or sshpass yet I don't have any of this two. I tried running:
compgen -c
and there's no expect and sshpass existing.
Are there any alternative commands? I would really appreciate your help. Thanks
Update: I also can't install any of this since I'm only an ordinary user.
First I logged in to server A as testuser and entered the ff command:
ssh-keygen -d
Do not enter any passphrase.
This will generate files in the folder ~/.ssh/
Then scp the file rsa_id.pub (public key) to server B.
scp ~/.ssh/id_dsa.pub testuser#B:/home/testuser/.ssh/authorized_keys2
Do the same vice versa (if you want access to both). Then you can now transfer from one server to the other without the being asked for your password.
source
If you don't want to set up keys for passwordless access (against the rules?), you can set up "SSH connection sharing".
Insert these lines into your .ssh/config file:
ControlMaster auto
ControlPath /tmp/ssh_%r#%n:%p
ControlPersist 8h
Now, when you log into a server from the machine with that config it will ask you your password the first time, and won't ask again until 8 hours of idle time have passed (so, you'll get asked once per day, usually).
What it's doing is keeping the connection open in the background, and then reusing the same connection for all your SSH sessions. This gives a useful connect-speed boost, and means you don't need to re-authenticate. All-in-all, it's great for accelerating scripted SSH and SCP commands.
The target server is a relatively clean install of Ubuntu 14.04. I generated a new ssh key using ssh-keygen and added it to my server using ssh-copy-id. I also checked that the public key was in the ~/.ssh/authorized_keys file on the server.
Even still, I am prompted for a password every time I try to ssh into the server.
I noticed something weird however. After I log into my first session using my password, the next concurrent sessions don't ask for a password. They seem to be using the ssh key properly. I've noticed this behaviour on two different clients (Mint OSX).
Are you sure your SSH key isn't protected by a password? Try the following:
How do I remove the passphrase for the SSH key without having to create a new key?
If that's not the case, it may just be that ssh is having trouble locating your private key. Try using the -i flag to explicitly point out its location.
ssh -i /path/to/private_key username#yourhost.com
Thank you Samuel Jun for the link to help.ubuntu.com - SSH Public Key Login Troubleshooting !
Just a little caveat:
If you copy your authorized keys file outside your encrypted home directory please make sure your root install is encrypted as well (imho Ubuntu still allows for unencrypted root install coupled with encryption of the home directory).
Otherwise this defeats the whole purpose of using encryption in the first place ;)
If this is happening to you on Windows (I'm on Windows 10)
Try running the program that you're trying to connect via ssh to the server as administrator.
For me I was using powershell with scoop to install a couple of things so that I could ssh straight from it. Anyway... I ran PowerShell as admin and tried connecting again and it didn't ask for my password.
For LinuxSE
Check the SE context with
% ls -dZ ~user/.ssh
Must contain unconfined_u:object_r:ssh_home_t:s0
If not, that was the problem , as root run
# for i in ~user/.ssh ~user/.ssh/*
do
semanage fcontext -a -t ssh_home_t $i
done
# restorecon -v -R ~user/.ssh
It looks like it's related to encryption on your home directory and therefore the authorized_keys file cannot be read.
https://unix.stackexchange.com/a/238570
Make sure your ssh public key was copied to the remote host in the right format. If you open the key file to edit it should read 1 line.
Basically, just do ssh-copy-id username#remote. It will take care of the rest.
I was given some login information for an EC2 machine, basically an ec2-X-X-X.compute-X.amazonaws.com plus a username and password.
How do I access the machine? I tried sshing:
ssh username#ec2-X-X-X.compute-X.amazonaws.com
but I get a Permission denied, please try again. when I enter the password. Is sshing the right way to access the EC2 machine? (Google hits I found suggested that you could ssh into the machine, but they also used keypairs.) Or is it more likely that the problem is that I was given invalid login credentials?
If you are new to AWS and need to access a brand new EC2 instance via ssh, keep in mind that you also need to allow incoming traffic on port 22.
Assuming that the EC2 instance was created accepting all the default wizard suggestions, access to the machine will be guarded by the default security group, which basically prohibits all inbound traffic. Thus:
Go to the AWS console
Choose Security Groups on the left navigation pane
Choose default from the main pane (it may be the only item in the list)
In the bottom pane, choose Inbound, then Create a new rule: SSH
Click Add rule and then Apply Rule Changes
Next, assuming that you are in possession of the private key, do the following:
$ chmod 600 path/to/mykey.pem
$ ssh -i path/to/mykey.pem root#ec2-X-X-X.compute-X.amazonaws.com
My EC2 instance was created from a Ubuntu 32-bit 12.04 image, whose configuration does not allow ssh access to root, and asks you to log in as ubuntu instead:
$ ssh -i path/to/mykey.pem ubuntu#ec2-X-X-X.compute-X.amazonaws.com
Cheers,
Giuseppe
Our Amazon AMI says to "Please login as the ec2-user user rather than root user.", so it looks like each image may have a different login user, e.g.
ssh -i ~/.ssh/mykey.pem ec2-user#ec2-NN-NNN-NN-NN.us-foo-N.compute.amazonaws.com
In short, try root and it will tell you what user you should login as.
[Edit] I'm supposing that you don't have AWS management console credentials for the account, but if you do, then you can navigate to the EC2->Instances panel of AWS Management Console, right click on the machine name and select "Connect..." A list of the available options for logging in will be displayed. You will (or should) need a key to access an instance via ssh. You should have been given this or else it may need to be generated.
If it's a Windows instance, you may need to use Remote Desktop Connection to connect using the IP or host name, and then you'll also need a Windows account login and password.
The process of connecting to an AWS EC2 Linux instance via SSH is covered step-by-step (including the points mentioned below) in this video.
To correct this particular issue with SSH-ing to your EC2 instance:
The ssh command you ran is not in the correct format. It should be:
ssh -i /path/my-key-pair.pem ec2-user#ec2-198-51-100-1.compute-1.amazonaws.com
Note, you need access to the private key (.pem) file to use in the command above. AWS prompts you to download this file when you first launch your instance. You will need to run the following command to ensure that only your root user has read-access to it:
chmod 400 /path/to/yourKeyFile.pem
Depending on your Linux distribution, the user you need to specify when you run ssh may be one of the following:
For Amazon Linux, the user name is ec2-user.
For RHEL, the user name is ec2-user or root.
For Ubuntu, the user name is ubuntu or root.
For Centos, the user name is centos.
For Fedora, the user name is ec2-user.
For SUSE, the user name is ec2-user or root.
Otherwise, if ec2-user and root don't work, check with your AMI provider.
You need to enable an inbound SSH firewall. This can be done under the Security Groups section of AWS. Full details for this piece can be found here.
For this you need to be have a private key it's like keyname.pem.
Open the terminal using ctrl+alt+t.
change the file permission as a 400 or 600 using command chmod 400 keyname.pem or chmod 600 keyname.pem
Open the port 22 in security group.
fire the command on terminal ssh -i keyname.pem username#ec2-X-X-X.compute-X.amazonaws.com
Indeed EC2 (Amazon Elastic Compute Cloud) does not allow password authentication to their instances (linux machines) by default.
The only allowed authentication method is with an SSH key that is created when you create the instance. During creation they allow you to download the SSH key just once, so if you loose it, then you have to regenerate it.
This SSH key is only for the primary user - usually named
"ec2-user" (Amazon Linux, Red Hat Linux, SUSE Linux)
"root" (Red Hat Linux, SUSE Linux)
"ubuntu" (Ubuntu Linux distribution)
"fedora" (Fedora Linux distribution)
or similar (depending on distribution)
See connection instructions: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html
If you want to add a new user the recommended way is to generate and add a new SSH key for the new user, but not specify a password (which would be useless anyway since password authentication is not enabled by default).
Managing additional users: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/managing-users.html
After all if you want to enable password authentication, which lowers down the security and is not recommended, but still you might need to do that for your own specific reasons, then just edit
/etc/ssh/sshd_config
For example:
sudo vim /etc/ssh/sshd_config
find the line that says:
PasswordAuthentication no
and change it to
PasswordAuthentication yes
Then restart the instance
sudo reboot
After restarting, you are free to create additional users with password authentication.
sudo useradd newuser
sudo passwd newuser
Add the new user to the sudoers list:
sudo usermod -a -G sudo newuser
Make sure user home folder exists and is owned by the user
sudo mkdir /home/newuser
sudo chown newuser:newuser /home/newuser
New you are ready to try and login with newuser via ssh.
Authentication with ssh keys will continue to work in parallel with password authentication.
i am trying to setup rsync between two machines over ssh2 protocol.
Earlier we used ssh1 for automated rsync without any passphrase, but recently we migrated to ssh2 and running rsync with ssh2 prompts for passphrase.
I generated a new SSH2-RSA key and that too without passphrase, but it still asks me for the passphrase.Here is the command that i run for ssh
/usr/bin/ssh -2 -i /usr/local/www-rsync-key fsuser#xyz
What steps do you have to do to get an ssh2 key with a null password to work? I'm guessing there are certain settings in /etc/ssh/sshd_config you have to set, but I can't figure out what!
This question appeared on Superuser, discussing the topic of ssh without a password.
If you're getting prompted for a password, check that you've added the public key to the correct file on the far side (could be authorized_keys2 now), and that the directory permissions are correct (.ssh and its contents shouldn't have any group or world permissions set).