I am running an automation script to automate the login and some other commands to be run on a remote target using plink. I used following approach to do a automatic login and saving the RSA key:
user#ubuntu~$ echo -e 'y\n' | plink root#<target ip> -pw <password> "pwd"
This command saves the key when run through command line, but when run using script, is inconsistent in saving the RSA key. Consider username and password being passed as correct, it prompts the error message as the Connection refused, as 'y' is not fetched in the prompt input.
Many times, it will prompt for accepting the key again and again as I have many simultaneous consecutive plink commands used in my script. Ideally, it shouldn't ask for user input more than once. I checked, 'sshhostkeys' file which was not present in ~/.putty folder, which is the cause for prompt for user input each time plink is run.
Has anyone faced this problem earlier? Any fix for this , or any hack/workaround for this?
P.S: Using expect scripts, or manually saving a profile using putty, or manually running the plink command and saving the key for once, is being ruled out (not to be considered).
Got the solution, actually the issue was with permission assigned to the $HOME/.putty directory. The ownership information for the folder was also root, thus when I was trying to run
user#ubuntu~$ echo -e 'y\n' | plink root#<target ip> -pw <password> "pwd"
I was getting the prompt for '(y/n)' repeatedly as the key was not getting saved in .putty folder due to the permission issues. Above command when once run was not able to create file sshhostkeys file due to which it was asking again and again for saving the key, each time it tries to save the key but was not able to save as it didn't have root permission. This issue is resolved by assigning rwx permission for all other (sudo chmod 707 ~/.putty) or other approach can be changing the ownership information to the user running the script by 'chown'.
Related
I have a bash script to backup a database and send it to another server, running the script on ssh (root) it sends the file correctly, but when using cPanel cron, i got this error:
cd: Fatal error: pseudo-tty allocation failed: No such file or directory
put: Fatal error: pseudo-tty allocation failed: No such file or directory
It looks like to fail on lftp changing to uploads folder
Cron
/bin/sh /home/test/backup/script.sh >> /home/test/backup/log.txt 2>&1
Bash
/bin/lftp sftp://user:pass#domain.com:22/uploads -e "put $FILE2; bye"
I assume your issue is this: You are logging in via SFTP using a ssh key (otherwise every time you try to sftp you would normally be required to enter a password and that will mess the cron). Probably you have the ssh key saved under the user root but when you execute the cron, it executes as a cpanel user (unless you executed directly in the root crontab). If executed as a cpanel user, and that user doesn't have the ssh key, then the cron hangs asking for the sftp password. Please be sure that the ssh private key used to SFTP as root is also added to the cpanel user's account under which the cron is executed. It should work then
My script is coded in a way that doesn't allow you to connect to a server directly by root. This code basically copies files from a server to my computer and it works but I don't have access to many files because only root can access them. How can I connect to a server as a user and then copy its files by switching to root?
Code I want to change:
sshpass -p "password" scp -q -r username#74.11.11.11:some_directory copy_it/here/
In other words, I want to be able to remotely copy files which are only accessible to root on a remote server, but don't wish to access the remote server via ssh/scp directly as root.
Is it possible through only ssh and not sshpass?
If I understand your question correctly, you want to be able to remotely copy files which are only accessible to root on the remote machine, but you don't wish to (or can't) access the remote machine via ssh/scp directly as root. And a separate question is whether it could be done without sshpass.
(Please understand that the solutions I suggest below have various security implications and you should weigh up the benefits versus potential consequences before deploying them. I can't know your specific usage scenario to tell you if these are a good idea or not.)
When you ssh/scp as a user, you don't have access to the files which are only accessible to root, so you can't copy all of them. So you need to instead "switch to root" once connected in order to copy the files.
"Switching to root" for a command is accomplished by prefixing it with sudo, so the approach would be to remotely execute commands which copy the files via sudo to /tmp on the remote machine, changes their owner to the connected user, and then remotely copy them from /tmp:
ssh username#74.11.11.11 "sudo cp -R some_directory /tmp"
ssh username#74.11.11.11 "sudo chown -R username:username /tmp/some_directory"
scp -q -r username#74.11.11.11:/tmp/some_directory copy_it/here/
ssh username#74.11.11.11 "rm -r /tmp/some_directory"
However, sudo prompts for the user's password, so you'll get a "sudo: no tty present and no askpass program specified" error if you try this. So you need to edit /etc/sudoers on the remote machine to authorize the user to use sudo for the needed commands without a password. Add these lines:
username ALL=NOPASSWD: /bin/cp
username ALL=NOPASSWD: /bin/chown
(Or, if you're cool with the user being able to execute any command via sudo without being prompted for password, you could instead use:)
username ALL=NOPASSWD: ALL
Now the above commands will work and you'll be able to copy your files.
As for avoiding using sshpass, you could instead use a public/private key pair, in which a private key on the local machine unlocks a public key on the remote machine in order to authenticate the user, rather than a password.
To set this up, on your local machine, type ssh-keygen. Accept the default file (/home/username/.ssh/id_rsa). Use an empty passphrase. Then append the file /home/username/.ssh/id_rsa.pub on the local machine to /home/username/.ssh/authorized_keys on the remote machine:
cat /home/username/.ssh/id_rsa.pub | ssh username#74.11.11.11 \
"mkdir -m 0700 -p .ssh && cat - >> .ssh/authorized_keys && \
chmod 0600 .ssh/authorized_keys"
Once you've done this, you'll be able to use ssh or scp from the local machine without password authorization.
I am trying to create a bash script that starts with the user executing a sudo -s command.
This is my script:
#!/bin/bash
SSH_USER=testuser
SUDO_PASSWD=secretpassword
FILE=/www/a/logs/service.log
MACHINES=( 'machine1' );
for HOST in ${MACHINES[#]}; do
ssh -t -l "$SSH_USER" "$HOST" "echo '$SUDO_PASSWD' | sudo -Ss chmod 777 $FILE"
done
I feel like this script should not prompt me for the password but it does. I do not want to have to input the password 30 different times. I have tried multiple versions where I hard code the password into the script but I still get prompted to enter in a password. HELP ME PLEASE. I'm VERY new at creating bash scripts and need some serious guidance.
The idea you have there will never work as sudo(1) does not read passwords from standard input unless it's a terminal. Hardcoding passwords into a script is also very bad idea, as pointed out repeatedly in comments.
If you really want to make this happen (I recommend against it), you should do edit /etc/sudoers in your target machine to let you run sudo(1) without it asking a password for things you need to be done without a password. For that you should not let yourself run any chmod command lines without a password, but instead create a script in target machine (for example ยด/usr/local/bin/do-my-promiscuous-chmod`) then tell sudo to let you run just that script without asking a password.
For example adding the following to /etc/sudoers will let user "foo" run /usr/local/sbin/do-unsafe without a password and with root privileges:
foo ALL = (root) NOPASSWD: /usr/local/sbin/do-unsafe
Agree with Sami, no hardcoding password in scripts.
more suggestions.
If the script needn't run as root, and can be run by some other application admin account, such as DBA, you should nominate to that user only to limit the permissions, such as:
foo ALL = (dba) NOPASSWD: /usr/local/sbin/do-unsafe
Secondly, don't give any files with 777 permissions, it is unsafe. Think some others way, such as ACL permission set.
chmod 777 $FILE
I am creating multiple users (this case 3 users) on a linux bash script using the line
sudo adduser --force-badname CPE_User"$count"
and I am trying to give those users a password that I assign in the script using:
echo "CPE_User"$count":1234" | chpasswd
but the terminal gives me this message :
Allowing use of questionable username.
adduser: The user `CPE_User1' already exists.
Changing password for CPE_User1.
chpasswd: (user CPE_User1) pam_chauthtok() failed, error:
Authentication token manipulation error
chpasswd: (line 1, user CPE_User1) password not changed
What is the problem?
It says it quite clearly: a user with that name already exists. Linux doesn't allow to have more than one user with the same name...
Not sure what the chpasswd problem might be (you are running it as root, right?) If you can't get chpasswd to work, consider using passwd (potentially via an expect script) - that will work for sure.
This is my first shot at trying out cgi-perl scripts. I have SSH keys set up between my (root user) local machine and a remote machine. I'm trying to run a command on the remote box and display the output on a webpage hosted from my local machine. The script runs fine from command line however, it throws SSH key error when called from the webpage because the user running the script is apache and not root. Is there a way to get around this issue?
If you not already have a restricted account, create one, create the SSH keys and add the commands that the user should be allowed to execute via sudo to the /etc/sudoers file (e.g. via visudo, more about sudoers). This is the safest approach imho.
You can even restrict the user in such a way, that he can only execute these commands. For
I don't know about Perl, but normal you can specify which user should be logged in via SSH:
ssh user#host
Update:
Are you using the Net::SSH::Perl module? If so, just set the user accordingly:
my $host = "perlhowto.com";
my $user = "user";
my $password = "password";
#-- set up a new connection
my $ssh = Net::SSH::Perl->new($host);
#-- authenticate
$ssh->login($user, $pass);
(I just copied and pasted this code from perlhowto.com)