I'm currently facing a weird problem while executing a command from my bash script.
My script has this command,
ssh IPAddressA -l root "ssh -l root IPAddressB ls"
where IPAddressA & IPAddressB would be replaced by hard coded IP addresses of two machines accessible from each other.
The user would enter the password whenever asked. But, I'm getting this error after I enter the IPAddressA's password.
root#IPAddressA's password:
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
]$
There's a better trick for that..
In ~/.ssh/config add a host entry for IPAddressA, configured like so:
Host IPAddressA
User someguy
ProxyCommand ssh -q someguy#IPAddressB nc -q0 %h 22
The slick thing about this method is that you can scp/sftp to IPAddressB without any weird stuff on your shell command line.
For bonus points, generate yourself a public key-pair and drop the public key on both IPAddressA and IPAddressB in ~/.ssh/authorized_keys. If you don't put a password on it, you won't even be bothered to enter that.
Additionally, if you're trying to get access to a remote LAN that only has a single entry point - SSH can actually act as a VPN client, bridging you through the proxy host. Of course, the remote end needs to support tap/tun devices (as does your local machine)... But if it's all there already.. super painless mechanism to bridge.
When the inner ssh password is prompted, there's no interactive keyboard available. You can get what you want with ssh tunneling.
ssh root#IPAddressA -L2222:IPAddressB:22 -Nf
ssh root#localhost -p2222
The first line open a tunnel, so your localhost 2222 port points to IPAddressB:22 andd bring the ssh process in background (-f) without executing a command (-N)
The second line connects IPAddressB:22 through the new opened tunnel
Related
o's!
Maybe you can help me with this. I can't find an answer to my specific questions, because there is an obvious solution which I'm not allowed to use. But first things first, the context:
In my company, which is a service provider, we administrate a bunch of
Linux servers. Some of my colleagues has for a long time been running
a BASH script from a source server, that then performs some tasks over
SSH on a number of remote Linux servers. The tasks it performs has to
be executed as root, so what the script does is it authorizes the
source server as root on the remote Linux servers via SSH (the remote
servers has the source servers public SSH key). Then what happened is
a new security policy was enforced and now root login over SSH is
denied. So the mentioned method no longer works.
The solution I keep finding, which we are by policy not allowed to do, is to create an entry in the sudoers file allowing sudo to root without password for the specific user.
This is the terms and they have to obey that. The only procedure that is allowed is to log on to the target server with your personal user, and then sudo su - to root WITH password.
Cocky as I apparently was, I said, "It should be possible to have the script do that automatically", and the management was like "Cool, you do it then!" and now I'm here at Stack Overflow,
because I know this is where bright minds are.
So this is exactly what I want to do with a BASH script, and I do not know if it's possible or how it's done, I really hope you can help me out:
Imagine Bob, he's logged into the source server, and he wants to
execute the script against a target server. Knowing that root over SSH
doesn't work, the authorization part of the script has been upgraded.
When Bob runs the script, it prompts him for his password. The
password is then stored in a variable (encrypted would be amazing) and
the script then logs on the target server as his user (which is
allowed) and then automatically elevates him to root on the target
server using the password he entered on the source server. Now the
script is root and it runs its tasks as usual.
Can it be done with BASH? and how?
UPDATE:
The Script:
## define code to be run on the remote system
remote_script='sudo -S hostname'
## local system
# on the local machine: prompt the user for the password
read -r -p "Enter password for $host: " password
# ...and write the password, followed by a NUL delimiter, to stdin of ssh
ssh -t 10.0.1.40 "$remote_script" < <(printf '%s\0' "$password")
The error:
[worker#source ~]$ sh elevate.sh
Enter password for : abc123
elevate.sh: line 10: syntax error near unexpected token `<'
elevate.sh: line 10: `ssh -t 10.0.1.40 "$remote_script" < <(printf '%s\0' "$password")'
First: Because it exposes plaintext passwords to the remote system (where they can be read by an attacker using diagnostic tools such as strace or sysdig), this is less secure than correctly using the NOPASSWD: flag in sudoers. If your security team aren't absolute idiots, they'll approve a policy exemption (perhaps with some appropriate controls, such as having a dedicated account with access to a setuid binary specific to the command being run, with authentication to that account being performed via public key authentication w/ the private key stored encrypted) rather than approving use of this hack.
Second: Here's your hack.
## define code to be run on the remote system
remote_script='sudo -S remote_command_here'
## local system
# on the local machine: prompt the user for the password
read -r -p "Enter password for $host: " password
# ...and write the password, followed by a NUL delimiter, to stdin of ssh
ssh "$host" "$remote_script" < <(printf '%s\0' "$password")
Allright, this is not the final answer, but I think I'm getting close, with the great help of CharlesDuffy.
So far I can run the script without errors on a remote server, that already has the publickey of my source server. However the command I execute doesn't create a file as I tell it to on the remote system.
However the script seems to run and the password seems to be accepted by the remote system.
Also I have to change in the sudoers on the remote host the line "Defaults requiretty" to "Defaults !requiretty", else it will tell me that I need a TTY to run sudo.
#!/bin/bash
## define code to be run on the remote system
remote_script='sudo -S touch /elevatedfile'
## local system
# on the local machine: prompt the user for the password
read -r -p "Enter password for $host: " password
# ...and write the password, followed by a NUL delimiter, to stdin of ssh
ssh -T 10.0.1.40 "$remote_script" < <(printf '%s\0' "$password")
UPDATE: When I tail /var/log/secure on the remote host I get the following after executing the script, which seems like the password is not being accepted.
May 11 20:15:20 target sudo: pam_unix(sudo:auth): conversation failed
May 11 20:15:20 target sudo: pam_unix(sudo:auth): auth could not identify password for [worker]
May 11 20:15:20 target sshd[3634]: Received disconnect from 10.0.1.39: 11: disconnected by user
May 11 20:15:20 target sshd[3631]: pam_unix(sshd:session): session closed for user worker
What I see on the source server, from where I launch the script:
[worker#source ~]$ bash elevate.sh
Enter password for : abc123
[sudo] password for worker:
[worker#source ~]$
Just make a daemon or cron script running as root, that in turn will check for any new scripts in specified secure location (ie. DB that it only has READ access to), and if they exist, it will download and execute them.
I am trying to execute a command on remote server using ssh. The command is as
ssh machine -l user "ls"
This command get stuck in between and finally we have to suspend it.
But, executing the command ssh machine -l user works fine and this command makes us connect to remote machine.
Can someone please help in getting the root cause of why the ls on remote server doesn't work by ssh.
EDIT 1 : Here is the ouput after using -v switch with SSH
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: ls
After printing Sending command: ls the terminal stucks.
I suspect one of two things is happening. First of all, the ssh server may be set to start a particular command for the user, regardless of what command you asked to run. You'd see this behavior if the user was restricted to running SFTP in the usual manner, for example. There are two ways this may be set up:
A ForceCommand directive in the remote server's sshd configuration file.
A directive in the remote user's authorized_keys file for the key being used.
The simplest way to check this would be to log in to the remote server and examine the two files. Alternately, you could start one of these ssh sessions, let it hang, and then run "ps" on the remote server to see what actual processes are running for the user in question.
The other possibility is that the remote user has a line in his .bashrc or other shell startup script which is introducing a wait or else waiting for you to type something. Again, you should start one of these ssh sessions, let it hang, and then run "ps" on the remote server to see what actual processes are running for the user.
Questions:
Does the problem occur on the commandline or within a script?
Are you prompted for your passowrd?
Is there any output? If yes: post it here.
And try
ssh -v user#host "ls"
or
ssh -v -l user host "ls"
and you will get additional output. You can use -v option upto 3 times for higher verbosity.
ssh -vvvl user host "ls"
EDIT:
If I had to debug this, I'd do the following:
go to the target machine, the one you want to 'ssh' to.
log in with the same user you tried with ssh
enter the "ls" command"
It is an unusal thing, but 'ls' is not necessarily what you expect it to be. At the commandline on the target-machine, try
which ls
and then use the output with the fully qualified name for your ssh call, e.g.:
ssh machine -l user "/bin/ls"
Remember, that when excuting a command via ssh you do not automatically have the same path as with a regular login.
Finally, examine your log-files on the target-machine. They usually reside under /var/log (at least under debian).
EDIT2:
On linux machines, I've sometimes experienced a problem with the 'ls' command hanging without any output. This happend to me when there were filesystems in the directory which were in some way 'invalid'. For example if there was an invalid mount of an android mtpfs, the ls command couldn't deal with that and hung.
So try to 'ls' a different directory, e.g.
ssh host -l user "ls /tmp"
If this works, then check from the commandline whether there is a directory or a file whith some invalid state which causes the ls command to fail.
I am trying to SSH from one Unix host to another and execute some commands.
Whenever I run ssh hostname <any command> I get back "logname: no login name".
I can succesfully just ssh hostname and then execute the same command without any issues. SSH is setup to use rsa keys for password-less connections.
Everything works fine using a different user account so I suspect it might be related to bash profile or something along those lines? I would appreciate any pointers.
I have to run some userdefined commands on remote servers. So I do the following. It works for many commands such as crontab -l, ls, date +%s, etc... However, it doesn't work for ip addr
When I actually ssh INSIDE those server ip addr works fine. But when I execute it using ssh it doesnt.
This is how I execute it.
$ sshpass -p myPassword ssh -q root#127.0.0.1 'ip addr' > $PWD/tmp
$ cat $PWD/tmp
Again, this works for any commands I've tried so far except ip addr.
For ip addr it gives the following output
bash: ip: command not found
So i was wondering why and if there's anything wrong I'm doing....
Also, please don't sugges to use rsync or any other nondefault linux command since the environment I work in does not have them nor do I have the permission to install.
Thank you in advance
This is caused because a non-interactive ssh session does not source your login profile, which amongst other things is setting your PATH variable.
The default path does not contain /sbin, which is the usual location of the ip command.
how do I execute command/script on a remote linux box?
say I want to do service tomcat start on box b from box a.
I guess ssh is the best secured way for this, for example :
ssh -OPTIONS -p SSH_PORT user#remote_server "remote_command1; remote_command2; remote_script.sh"
where the OPTIONS have to be deployed according to your specific needs (for example, binding to ipv4 only) and your remote command could be starting your tomcat daemon.
Note:
If you do not want to be prompt at every ssh run, please also have a look to ssh-agent, and optionally to keychain if your system allows it. Key is... to understand the ssh keys exchange process. Please take a careful look to ssh_config (i.e. the ssh client config file) and sshd_config (i.e. the ssh server config file). Configuration filenames depend on your system, anyway you'll find them somewhere like /etc/sshd_config. Ideally, pls do not run ssh as root obviously but as a specific user on both sides, servers and client.
Some extra docs over the source project main pages :
ssh and ssh-agent
man ssh
http://www.snailbook.com/index.html
https://help.ubuntu.com/community/SSH/OpenSSH/Configuring
keychain
http://www.gentoo.org/doc/en/keychain-guide.xml
an older tuto in French (by myself :-) but might be useful too :
http://hornetbzz.developpez.com/tutoriels/debian/ssh/keychain/
ssh user#machine 'bash -s' < local_script.sh
or you can just
ssh user#machine "remote command to run"
If you don't want to deal with security and want to make it as exposed (aka "convenient") as possible for short term, and|or don't have ssh/telnet or key generation on all your hosts, you can can hack a one-liner together with netcat. Write a command to your target computer's port over the network and it will run it. Then you can block access to that port to a few "trusted" users or wrap it in a script that only allows certain commands to run. And use a low privilege user.
on the server
mkfifo /tmp/netfifo; nc -lk 4201 0</tmp/netfifo | bash -e &>/tmp/netfifo
This one liner reads whatever string you send into that port and pipes it into bash to be executed. stderr & stdout are dumped back into netfifo and sent back to the connecting host via nc.
on the client
To run a command remotely:
echo "ls" | nc HOST 4201