Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Thank y ou for the sugestion but that is what I wanted to avoid...
...without giving any compelling reason for it? Note having root log in over any network isn't exactly a security best practice. Next to that your method doesn't really scale well and besides there are other ways to get uptime ranging from 'ssh unprivileged_user@host 'cat /proc/uptime';' to ones that don't even require any interactive login like SNMP or even a simple Xinetd service.
Distribution: Red Hat (8.0, RHEL5,6), CentOS, SuSE (10.x, 11.x, 12.2, 13.2), Solaris (8-10), Tru64, MacOS, Raspian
Originally Posted by unSpawn
Note having root log in over any network isn't exactly a security best practice.
At least it's over an encrypted link. My main concern with security would be having the passwords saved in the shell script that was being executed.
Next to that your method doesn't really scale well and besides there are other ways to get uptime ranging from 'ssh unprivileged_user@host 'cat /proc/uptime';' to ones that don't even require any interactive login like SNMP or even a simple Xinetd service.
There's a fair amount of work involved -- more than just knowing an account/password -- to setting up SNMP (for security reasons please don't use the default community names and be aware that the uptime you get back from the SNMP daemon is the elapsed time since the daemon was last started and not necessarily the true system uptime) or a new xinetd service.
I'm guessing this is quite likely far beyond what should be mentioned in the "Newbie" forum but if obtaining uptime is going to be an important thing to track, why not set up a Nagios monitoring system on the network? It's probably only a matter of time before someone's going to want to know the state of file system use or any number of parameters on all those systems. I recall it being a fairly simple matter to implement custom queries on the Nagios server once you had NRPE configured on the monitored systems. Caveat: it's been a few years since I did any of that but it seemed easy enough. Probably more involved than the other things you mentioned but more flexible.
Personally, I still want to know what's eating the output of the uptime commands the OP has been using in his script. It's doing that on my system as well and I'm still scratching my head over it.
Expect is going to scan the input and consume what it doesn't recognize while looking for what it "expects". It looks like it would work if you removed expect from the script. It also might work if you did a "send uptime" after sending the password instead of using the command parameter. Remember, expect is not working from a pty...
This may cause a problem with expect as the remote connection terminates as soon as the command terminates... and that may be detected/signaled (socket closed) before the data is retrieved from the buffer that expect has.
Also the grep -v command shouldn't be needed with the command parameter as there is no "root:" prompt in the return data (which also points to the data in the buffer not being processed).
Try using a send "uptime" entry instead of using the uptime on the ssh command... This also forces sshd to use a pty on the remote end.
And that in turn also brings up another possibility - ssh has a -t option to direct sshd on the remote system to use a pty even with parameter commands. This may make it work too - as it would wait for the pty to close before closing the socket.
Try a send 'spawn ssh -t ...' command to expect...
...My main concern with security would be having the passwords saved in the shell script that was being executed
Saving password in script itself isn't recommended option at all. And even ssh will not accept it if you will use something like assign password to some variable first and then use this variable while invoking ssh cmd.
As I said above, you can use key based ssh authorization to achieve this. This is a common practice & you should consider using this option.
There's a fair amount of work involved -- more than just knowing an account/password -- to setting up SNMP (..) or a new xinetd service.
[ `id -g` -eq 0 ] || echo need root; umask 0027
cat > /etc/xinetd./uptime << EOF
disable = no
type = UNLISTED
protocol = tcp
port = 30000
socket_type = stream
wait = no
user = nobody
server = /usr/bin/uptime
log_on_failure += HOST
only_from = 127.0.0.1 10.1.0.0/16
chmod 0640 /etc/xinetd./uptime
selinuxenabled && chcon -u system_u -t etc_t /etc/xinetd./uptime
/sbin/service restart xinetd
...and that's all there is to it.
- enabling SSH agent on the monitoring host alleviates the need for sending passwords.
- A forced "/usr/bin/uptime" command in the clients authorized_keys file alleviates the need for executing the command.