pantz.org banner
Using SSH and sudo instead of root for remote commands
Posted on 11-18-2010 02:56:05 UTC | Updated on 11-23-2010 01:33:33 UTC
Section: /software/ssh/ | Permanent Link

Anyone who has to administer a lot of *NIX servers has been in the position of needing to execute remote commands on those servers as root. Usually it is done to change a file or run a command. The easy way to do this is to run your command with ssh as the root user but, we all know how bad it is to leave "PermitRootLogin yes" in our sshd_config files. On many systems this is the default setting. But allowing root a remote login through SSH is a security issue so we turn it off. This begs the question what are you to do when you need to execute commands remotely on systems as root but root logins are disabled? It's easier than you think.

Usually when you need to execute these commands it is for a group of servers. To start put your SSH key on all the machines you need to execute your commands on and don't put a password on your key when setting it up. If want to know how to do this look here. After setting those up on your machines you should be able to login to each one without needing a password.

Next, setup sudo so your user can execute commands with root privileges. If you need to know how to do this look here. Here's the short version. As root type "visudo" and put in "yourusername ALL=(ALL) ALL". If your using Ubuntu then this is likely already done for you.

Now with your SSH keys setup and your sudo privs set we are ready. Before you type this command there is a WARNING. This command makes you type your password in cleartext for anyone to see. DON'T type this command in your terminal program because it will stay in your history. DON'T type it on screen because it will stay in your terminals scroll back buffer. The safest way to use this is to make a script, chmod 700 the file, and execute that file. Better yet only type the password in the file right before you need to execute it. Then remove the password from the file when your done. This is still not a super secure way to do this but if remote root is turned off you might not have a choice.

From the machine your going to use to login to your other machines execute the command below. Where it says "hostname" put in the hostname of the machine your trying to get into. Where it says "password" put your password. Where it says "command" put the command your trying to execute like "df -h". As with any command on the command line if there are any special characters you will need to escape them with \ in the bash shell at least. I'll put in an examples with comments below the first line.

# original command
ssh hostname "echo password | sudo -S command"

# execute command "df -h" with escaped password character !
ssh host.pantz.org "echo PaSSworD\! | sudo -S df -h"

Using SSH and sudo this way works best when the above line is part of a script. This gives you the ability to automate executing the same command across many machines at one time.

Here is a little shell script you might use with the above command. The /home/user/hosts file the script refers to is just a text file with a single host name on each line. It will execute whatever command you give it from the command line for each host in the hosts file. So if you called your script go.sh then you could execute the command "df -h" by typing "./go.sh df -h".

#!/bin/bash

for HOST in $(< /home/user/hosts); do
  echo ""
  echo "###############"
  echo "# HOSTNAME: $HOST"
  echo "###############"
  # This line is for back grounding each command to execute them on all systems at once
  # ssh -q -o ConnectTimeout=3 $HOST "echo password | sudo -S $* >/dev/null 2>&1 &"
 
  ssh -q -o ConnectTimeout=3 $HOST "echo password | sudo -S $*"

  if [ $? -ne 0 ]; then
    echo "---- COULD NOT CONNECT TO $HOST ----"
  fi
done

Good luck and be careful with this command. Please don't use it from the command line. On some distributions your sudo commands are logged to /var/log/secure but the echo statement with the password does not show up so no worries about that.

Del.icio.us! | Digg Me! | Reddit!

Related stories

Convert OpenSSH keys to ssh.com keys
Posted on 07-31-2009 01:07:39 UTC | Updated on 07-31-2009 01:14:05 UTC
Section: /software/ssh/ | Permanent Link

This example will show how to convert the OpenSSH key format to ssh.com (Tectia enterprise products) key format. It will also show you how to import the converted keys into ssh.com's Secure File Transfer Client.

1. Copy your private OpenSSH key from your unix system to your local windows machine. The private key is in your home dir ~/.ssh/. Usually it's called id_(something) like id_dsa. I'm going to call mine id_dsa for this example. Make sure your copy the file by transferring it over the network with scp/sftp, shared mount point you have to your your windows machine, or usb key. DO NOT cat the file in a terminal and then copy and paste it into a text editor on the windows machine. This will not work because of the differences in file formats of unix and windows.

2. Go and download Putty. Get the zip version from the website and unzip it. Find the program puttygen.exe in the unzipped files and execute it.

3. Click the "load" button. Select "files of all type" drop down. Then select all files. Point puttygen to your OpenSSH key that you copied over in step 1. Then click "open". Enter your keys pass phrase (If you have one. You should be using pass phrases on your keys.).

4. Click conversions->export->ssh.com key. Then save your converted private key with the name "id_dsa_sshcom". This is your converted private key. Names are important to the ssh.com program when importing keys. The key pair has to have matching names to be imported. You can call it anything you want but it has to take the format: key_name and key_name.pub.

5. Now click file->save public key. Save the public key with the name id_dsa_sshcom.pub in the same area (folder) you saved your private key in step 4. This is your public key that goes with your private key. Make sure the first part of the names match.

6. Open the ssh.com Secure File Transfer Client. Click edit->settings. Then go to user authentication->keys (in the left pane). Click the import button. Select "files of all type" drop down. Then select all files. Click the "Look in" drop down and point it to the folder where your "id_dsa_sshcom.pub" and "id_dsa_sshcom" files are. Select your public key id_dsa_sshcom.pub and click ok. Then ok out of the settings area. FYI: The ssh.com client will ask for the public key and then when it is selected is will match the private key that goes with it by the same name. Just without the .pub at the end.

7. Now you should be able to connect to any host that you have put your public keys on with ssh.com's Secure File Transfer Client.

8. After you have tested your connection make sure you delete your private key you copied over from your system when we started.

Del.icio.us! | Digg Me! | Reddit!

Related stories

Upgraded OpenSSH and now X11 forwarding fails
Posted on 12-13-2007 16:23:00 UTC | Updated on 12-13-2007 16:23:00 UTC
Section: /software/ssh/ | Permanent Link

I upgraded OpenSSH and X11 forwarding now fails with "X11 connection rejected because of wrong authentication". Lets say you upgraded OpenSSH on machine1 and you now try to ssh to machine2 and X11 forward fails. You get the following errors seen below.

user@machine:~$ ssh -X user@machine2
user@machine2's password:
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.

The error you see when trying to open a program expecting X11 forwarding is the following.

user@machine2:~$ xterm
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

I figured out the problem seems to be trusted X11 forwarding is turned off or disabled. To fix it you have to ssh with the -Y parameter instead of the -X. The other thing you could do is edit your /etc/ssh/ssh_config file on machine1 and set "ForwardX11Trusted" to "yes". Which would look like "ForwardX11Trusted yes".

Del.icio.us! | Digg Me! | Reddit!

Related stories


RSS Feed RSS feed logo
About


3com
3ware
alsa
alsactl
alsamixer
amd
android
apache
areca
arm
ati
auditd
awk
badblocks
bash
bind
bios
bonnie
cable
carp
cat5
cdrom
cellphone
centos
chart
chrome
cifs
cisco
cloudera
comcast
commands
comodo
compiz-fusion
corsair
cpufreq
cpufrequtils
cpuspeed
cron
crontab
crossover
cu
cups
cvs
database
dbus
dd
dd_rescue
ddclient
debian
decimal
dhclient
dhcp
diagnostic
diskexplorer
disks
dkim
dns
dos
dovecot
drac
dsniff
dvdauthor
e-mail
echo
editor
emerald
ethernet
expect
ext3
ext4
fat32
fedora
fetchmail
fiber
filesystems
firefox
firewall
flac
flexlm
floppy
flowtools
fonts
format
freebsd
ftp
gdm
gmail
gnome
greasemonkey
greylisting
growisofs
grub
hacking
hadoop
harddrive
hba
hex
hfsc
html
html5
http
https
idl
ie
ilo
intel
ios
iperf
ipmi
iptables
ipv6
irix
javascript
kde
kernel
kickstart
kmail
kprinter
krecord
kubuntu
kvm
lame
ldap
linux
logfile
lp
lpq
lpr
maradns
matlab
memory
mencoder
mhdd
mkinitrd
mkisofs
moinmoin
motherboard
mouse
movemail
mplayer
multitail
mutt
myodbc
mysql
mythtv
nagios
nameserver
netflix
netflow
nginx
nic
ntfs
ntp
nvidia
odbc
openbsd
openntpd
openoffice
openssh
openssl
opteron
parted
partimage
patch
perl
pf
pfflowd
pfsync
photorec
php
pop3
pop3s
ports
postfix
power
procmail
proftpd
proxy
pulseaudio
putty
pxe
python
qemu
r-studio
raid
recovery
redhat
router
rpc
rsync
ruby
saltstack
samba
schedule
screen
scsi
seagate
seatools
sed
sendmail
sgi
shell
siw
smtp
snort
solaris
soundcard
sox
spam
spamd
spf
sql
sqlite
squid
srs
ssh
ssh.com
ssl
su
subnet
subversion
sudo
sun
supermicro
switches
symbols
syslinux
syslog
systemrescuecd
t1
tcpip
tcpwrappers
telnet
terminal
testdisk
tftp
thttpd
thunderbird
timezone
ting
tls
tools
tr
trac
tuning
tunnel
ubuntu
unbound
vi
vpn
wget
wiki
windows
windowsxp
wireless
wpa_supplicant
x
xauth
xfree86
xfs
xinearama
xmms
youtube
zdump
zeromq
zic
zlib