First post, thanks in advance for any help.
I'm somewhat new to scripting in general but I've managed to build a nice wrapper in bash that's designed to collect some variables and then make some connections to a couple of remote boxes and do some things related to a web statistics system and launch some hadoop processes. Basically a series of tedious tasks that I'm trying to automate. (unnecessary details complete).
The problem I'm running into is finding a way to effectively connect to those remove servers, authenticate as as a regular user, then switch users for various tasks. Here's the relevant code:
#!/bin/sh
#Script's run as root. this asks for the sudoers pass
read -p "Enter password for $SUDO_USER: " -s password
#Defines some testing commands I want to pass to a remote box
CMD="hostname; id; sudo su -; id; pwd;"
#launches an expect script with some defined variables as arguments.
/home/ME/scripts/derp.expect $SUDO_USER $definedremoteserver "$command" "$password"
Now the expect script being used:
#!/usr/bin/expect
#expect script to help with SSH connections for the urchinizer bash script
set arg1 [lindex $argv 0]
set arg2 [lindex $argv 1]
set arg3 [lindex $argv 2]
set arg4 [lindex $argv 3]
spawn ssh -oStrictHostKeyChecking=no $arg1#$arg2 "$arg3"
expect "password:"
send "$arg4\r"
interact
expect "password"
send "$arg4\r"
interact
I'm having trouble determining why this fails. I've researched quite a bit and have tried numerous variations of the code. Basically when I run this, it takes my pass and I'm able to make the initial connection. Then the script tries to switch user and the second expect fails. The first 'id' and 'hostname' output successfully. When the user switch happens, the second expect doesn't work and I'm left with just a password prompt. I enter my pass anyway (which displays in plain text for some reason) and the script just hangs without outputting the second 'id' and 'pwd' commands I'm trying to use to verify that this is working.
If I actually login to that box and do a sudo -i or sudo su - this is what the password prompt looks like:
[sudo] password for my.name:
So for the second (not working) expect, I've tried a few different variations with somewhat different results but no success.
Sorry for the long post. This has been driving be nuts. Is what I'm trying to do possible? Is there a smarter way to handle this? Anyone spot any obvious mistakes? Also, a secondary question... how do wildcards work in those expect lines?
If you can, use some scripting language as Perl, Python or Ruby with some module for SSH.
For instance, using Perl and the Net::OpenSSH module:
use Net::OpenSSH;
my $ssh = Net::OpenSSH->new($host, user => $user, password => $password);
my $output = $ssh->capture({stdin_data => "$sudo_password\n"},
'sudo', '-Sk', '-p', '', '--',
'ls', '/');
You should use "Public Key Authentication" instead of "Password Authentication" in OpenSSH.
1: create the private/public key pair for the user you want to login with this command:
ssh-keygen -t rsa
Do not supply passwords, choose the default path (enter, enter, enter).
This should be done for each of your SSH machines (clients and servers).
2: from each client machine you want to login from, copy your new public key file content to your favourite text editor (notepad, gvim, etc)
cat ~/.ssh/id_rsa.pub
You should now have all your client's public keys pasted into your editor, something like this:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAt9sGP1PKR1XzpozHQc9ufyzOnePHCnRzUhdfSvfQTzJO28CgnHwhANdaBeOrLq5b+VOoPJFj5NquYXmJ6YikSJCwHlvfewA/5p0IkucsJLxqYQMDRhyeXb9fCk85MoNRJjAd+Cst+gI9Cwpp1ysLMDY77k/a9eT3ExkgbGd6mdtfjAlP/o/rRMcqNwp9Pdhh6kkxrM0v1ceNSTbTeO7XCLvekqtRiwjWImhQs56JVbB/RLySNKtqjbpr7Zhn1m+p6+vmBmgwF3xBBvzziYfMm/vG1ZvvGIsI3dxRDWuSZ8+o63w7Y20M9NQn4QkqV6NFjX3conBiDGtDBKain2zj6Q== dino#blackbigone
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0JR6d9LWgvPCbvBajrbVly3cxX7ZkbH4+MUBu+ak2G5SGLbGBcwdi3JquBAT1+U/hl+TKKUUw1XjjjazdjgYCHWIguDWzmqoyT4bQN2aymNoqD35T+LWAaqwC36m95fRfJh3HSOtx7KXpsBZjvR40rg901f8ReIjBoL7G620rrsRDqaDS08Mm6TjThBrCeTYX2YzugodpUNP2evwFOBMrYw/TIcX5Lza8xRCctm8MRodsx/yvuYuZJSanVLs3Q6sJ/n9o20L8Jt1Fu1cnyxJTs9THiLOnZyrTBXvbKJymit6p3hfDpDlWtO/crNeyt0H8jJcZfiCnhQwfib2VMMqJw== erica#blackbigone
3: paste the ascii armored public keys you have in your text editor into ~/.ssh/authorized_keys file on each SSH server you want to login into. You must be the user you want to login. Create the file if it doesn't exists.
This way you are granting the permission to login to the server where you created the authorized_keys file to all users presenting with the given public keys.
The login is successful if the user have the correct matching private key.
Once logged in on the remote server, you can use sudo (you have to configure /etc/sudoers file first with the visudo command) to execute commands by another user.
To avoid sudo to request for a password (because you are authenticated in /etc/sudoers...) you have to set the NOPASSWD flag, like the line below:
%admin ALL=(ALL) NOPASSWD: ALL
Related
I'm writing a script to set up VNC (amongst other things) on many debian based devices. I want to include VNC in this setup (specifically, tightVNC if possible) and have it set a given password (randomly generated by the script). The problem is, every guide I find seems to assume that a human is doing this, and is ready to sit and type in the password and press enter. I can't seem to get Bash to echo a password to VNC (it always says 'password too short') nor can I get 'expect' to work properly.
An example guide I found looks like this:
http://www.penguintutor.com/linux/tightvnc
I'm looking for something similar to this:
#!/bin/bash
echo "Going to configure VNC"
#turn on vnc server
tightvncserver
#spit out password to vnc server for first run only
echo $password
#confirm the pw
echo $password
But, on every virginal run of tightvncserver it always asks for a password to be inputted by hand:
Going to configure VNC
You will require a password to access your desktops.
Password: Password too short
How can I #1 get around this, or #2 use bash / expect to GIVE it a password to make it happy?
# Configure VNC password
umask 0077 # use safe default permissions
mkdir -p "$HOME/.vnc" # create config directory
chmod go-rwx "$HOME/.vnc" # enforce safe permissions
vncpasswd -f <<<"$password" >"$HOME/.vnc/passwd" # generate and write a password
Modify to taste, if your packaging for tightvnc uses a location other than ~/.vnc/ for the passwd file.
If you have separate view-only and full-control passwords, then:
vncpasswd -f <<<"$full_password"$'\n'"$view_password" >"$HOME/.vnc/passwd"
If you needed compatibility with /bin/sh (or otherwise weren't using #!/bin/bash shebangs), this would instead be:
vncpasswd -f >"$HOME/.vnc/passwd" <<EOF
$full_password
$view_password
EOF
I have to write a shell script which ssh to another server with other username without actually asking for a password from the user?
Due to constraints I cannot use key based authentication.
let,
Source Server -- abc.efg.com
Source UserName -- tom
Source Password -- tom123
Destination Server -- xyz.efc.com
Destination UserName -- bob
destination Password -- bob123
I have to place the bash script in source server.
Please let me know if something could be done using expect tool and/or sshpass.
It is okay for me to hardcode the password for destination server in the bash script but I cannot bear an interactive session, simply when I run he script, I want to see the destination server logged in with another username.
Thanks in Advance.
You want to use key-authentication http://ornellas.apanela.com/dokuwiki/pub:ssh_key_auth
Generate your keys ssh-keygen
Copy the keys to your new box ssh-copy-id -i ~/.ssh/id_rsa.pub me#otherhost.com
ssh to other host without password ssh me#otherhost.com
You can use expect to wrap ssh, but it's pretty hectic, and fails easily when there are network errors, so test it well or use a script specifically designed for wrapping ssh passwords. Key based authentication is better.
You can prevent interactive sessions by redirecting standard input from the null device, ie.
ssh me#destination destination-command < /dev/null
About placing the script in the source server, if the script you are running is local, rather than remote, then you can pass the script on standard input, rather than the command line:
cat bashscript.sh | ssh me#destination
You can install the sshpass program, which lets you write a script like
#!/bin/bash
sshpass -p bob123 ssh UserName#xyz.efc.com
The answer is that you can't as OpenSSH actively prevent headless password-based authentication. Use key-based authentication.
You may be able to fork the OpenSSH client code and patch it, but I think that is a bit excessive.
In my shell script I am running a command which is asking me for input.
How can I give the command the input it needs automatically?
For example:
$cat test.sh
ssh-copy-id tester#10.1.2.3
When running test.sh:
First, it will ask:
Are you sure you want to continue connecting (yes/no)?
Then, it will ask me to input the password:
tester#10.1.2.3's password:
Is there a way to input this automatically?
For simple input, like two prompts and two corresponding fixed responses, you could also use a "here document", the syntax of which looks like this:
test.sh <<!
y
pasword
!
The << prefixes a pattern, in this case '!'. Everything up to a line beginning with that pattern is interpreted as standard input. This approach is similar to the suggestion to pipe a multi-line echo into ssh, except that it saves the fork/exec of the echo command and I find it a bit more readable. The other advantage is that it uses built-in shell functionality so it doesn't depend on expect.
For general command-line automation, Expect is the classic tool. Or try pexpect if you're more comfortable with Python.
Here's a similar question that suggests using Expect: Use expect in bash script to provide password to SSH command
There definitely is... Use the spawn, expect, and send commands:
spawn test.sh
expect "Are you sure you want to continue connecting (yes/no)?"
send "yes"
There are more examples all over Stack Overflow, see:
Help with Expect within a bash script
You may need to install these commands first, depending on your system.
Also you can pipe the answers to the script:
printf "y\npassword\n" | sh test.sh
where \n is escape-sequence
ssh-key with passphrase, with keychain
keychain is a small utility which manages ssh-agent on your behalf and allows the ssh-agent to remain running when the login session ends. On subsequent logins, keychain will connect to the existing ssh-agent instance. In practice, this means that the passphrase must be be entered only during the first login after a reboot. On subsequent logins, the unencrypted key from the existing ssh-agent instance is used. This can also be useful for allowing passwordless RSA/DSA authentication in cron jobs without passwordless ssh-keys.
To enable keychain, install it and add something like the following to ~/.bash_profile:
eval keychain --agents ssh --eval id_rsa
From a security point of view, ssh-ident and keychain are worse than ssh-agent instances limited to the lifetime of a particular session, but they offer a high level of convenience. To improve the security of keychain, some people add the --clear option to their ~/.bash_profile keychain invocation. By doing this passphrases must be re-entered on login as above, but cron jobs will still have access to the unencrypted keys after the user logs out. The keychain wiki page has more information and examples.
Got this info from;
https://unix.stackexchange.com/questions/90853/how-can-i-run-ssh-add-automatically-without-password-prompt
Hope this helps
I have personally been able to automatically enter my passphrase upon terminal launch by doing this: (you can, of course, modify the script and fit it to your needs)
edit the bashrc file to add this script;
Check if the SSH agent is awake
if [ -z "$SSH_AUTH_SOCK" ] ; then
exec ssh-agent bash -c "ssh-add ; $0"
echo "The SSH agent was awakened"
exit
fi
Above line will start the expect script upon terminal launch.
./ssh.exp
here's the content of this expect script
#!/usr/bin/expect
set timeout 20
set passphrase "test"
spawn "./keyadding.sh"
expect "Enter passphrase for /the/path/of/yourkey_id_rsa:"
send "$passphrase\r";
interact
Here's the content of my keyadding.sh script (you must put both scripts in your home folder, usually /home/user)
#!/bin/bash
ssh-add /the/path/of/yourkey_id_rsa
exit 0
I would HIGHLY suggest encrypting the password on the .exp script as well as renaming this .exp file to something like term_boot.exp or whatever else for security purposes. Don't forget to create the files directly from the terminal using nano or vim (ex: nano ~/.bashrc | nano term_boot.exp) and also a chmod +x script.sh to make it executable. A chmod +r term_boot.exp would be also useful but you'll have to add sudo before ./ssh.exp in your bashrc file. So you'll have to enter your sudo password each time you launch your terminal. For me, it's more convenient than the passphrase cause I remember my admin (sudo) password by the hearth.
Also, here's another way to do it I think;
https://www.cyberciti.biz/faq/noninteractive-shell-script-ssh-password-provider/
Will certainly change my method for this one when I'll have the time.
You can write the expect script as follow:
$ vi login.exp
#!/usr/bin/expect -f
spawn ssh username#machine.IP
expect "*assword: "
send -- "PASSWORD\r"
interact
And run it as:
$ expect login.exp
This question already has answers here:
How to run the sftp command with a password from Bash script?
(12 answers)
Closed 7 years ago.
I am trying to write a script to back up a file over SFTP. The problem is, it requires a password, and I see no way to manually specify a password to SFTP. I've heard about requiring no password by using public keys, but that requires being able to ssh into the remote server and modify some configuration files, which I cannot do.
Currently my solution is to use cURL, but that is insecure (uses normal FTP). I also looked at the .netrc file, but that seems to be for FTP instead of SFTP. How do I manually specify a password for sftp?
Lftp allows specifying passwords for both ftp and sftp and does not require public keys at all. Your sh sync script may look like this:
#!/bin/sh
# Define folders
THEFOLDER='/mnt/my/folder'
# List files
THEFILES=`ls -p $THEFOLDER | grep -v "/"`
for file in $THEFILES
do
echo "Processing $file"
lftp -u login,password -e "put $THEFOLDER/$file;quit" theftp/sub/folder
done
cURL can support sftp, as documented by the manual:
USING PASSWORDS
FTP
To ftp files using name+passwd, include them in the URL like:
curl ftp://name:passwd#machine.domain:port/full/path/to/file
or specify them with the -u flag like
curl -u name:passwd ftp://machine.domain:port/full/path/to/file
FTPS
It is just like for FTP, but you may also want to specify and use
SSL-specific options for certificates etc.
Note that using FTPS:// as prefix is the "implicit" way as described in the
standards while the recommended "explicit" way is done by using FTP:// and
the --ftp-ssl option.
SFTP / SCP
This is similar to FTP, but you can specify a private key to use instead of
a password. Note that the private key may itself be protected by a password
that is unrelated to the login password of the remote system. If you
provide a private key file you must also provide a public key file.
You might also want to consider using python (the paramiko module), as it can quickly be called from the shell.
Install the Module
pip install paramiko
Example FTP Upload Script
import paramiko
username = 'my_username'
password = 'my_password'
transport = paramiko.Transport((server, 22))
transport.connect(username=username, password=password)
sftp = paramiko.SFTPClient.from_transport(transport)
local_filename = '/tmp/filename'
remote_filename = 'MyFiles/temp.txt'
sftp.put( local_filename, remote_filename )
Bash program to wait for sftp to ask for a password then send it along:
#!/bin/bash
expect -c "
spawn sftp username#your_host
expect \"assword\"
send \"your_password_here\r\"
interact "
Put that in a file called sftp_autologin.sh. The \r sends an to sftp to execute the command. I don't include the 'p' in password because on some systems it's uppercase, others lowercase. expect spawns the sftp command. Waits for the string 'assword' to be seen and sends a command. Then ends.
To get this to work:
Install expect, I'm using 5.44.1.15
Make sure you can sftp to your box in interactive mode and supply a password.
Make sure this bash script has executable permissions.
Then run it:
chmod +x sftp_autologin.sh
./sftp_autologin.sh
It should drop you into the sftp commandline without prompting you for a password.
Is it insecure?
It's about the most unsecure command you can run. It exposes the password to the commandline history, to anyone else who can read 'ps' output, and basically defeats the entire purpose of passwords all together.
But hey what's another log on the fraud fire, it's only about 250b dollars in victim losses per year. Lets go for 500b.
This automatically runs some commands with the sftp shell and exits automatically when done:
#!/bin/bash
expect -c "
spawn sftp myuser#myserver.com
expect \"assword\"
send \"yourpassword\r\"
expect \"sftp\"
send \"get your_directory/yourfilename.txt\r\"
expect \"sftp\"
send \"exit\r\"
interact "
In order to use public keys you do not need to modify any "configuration files". You merely need to leave a copy of your public key in a place where ssh knows to look (normally ~/.ssh/authorized_keys). You can do this with sftp. If you haven't established any authorized_keys file on the server, you can simply put your id_rsa.pub file in its place.
You can't specify a password to ssh / scp or sftp from the command line. The only way to connect without prompting for a password is to use public key authentication.
You say that you can't ssh to the server to modify configuration files but if you can sftp to the server you can probably upload your public key.
Your public key just has to go under the .ssh directory in your home directory.
AFAIK, the commands ssh or scp do not have/take a password parameter. Otherwise I could keep the password in a shell variable and probably get rid of the enter password prompt. If I write an scp command in my shell script, it prompts the user to input the password. I have multiple ssh and scp commands in my script and I do not want the user to enter the password every time. I would prefer to save the password in a shell variable in the beginning (by asking password once), then use it for every ssh or scp.
I read about "public key identification" in this question. Is it related to the solution I am looking for?
Update
I read in How to use ssh command in shell script? why it is unsafe to specify passwords on the commandline. Does using expect also store the password and is world visible (using ps aux)? Is that the security issue with using expect?
Further Explanation
To further make it clear, I am writing this shell script to automate code and database backup, do code upload, run necessary database queries, do all the things that are needed for a new version release of a LAMP project from a developer system to a remote live server. My shell script will be there inside the main codebase of the project in every developer instance.
Requirement
I want all developers (all may be working from different remote systems) knowing the SSH/FTP password to be able to use the shell by entering the ssh/ftp password same only at run-time once. I would prefer the password to be the ssh/ftp password
Note - I do not want other developers who don't know the SSH password to be able to use it (So I guess public key authentication will not work because it stores the passwords in the systems).
I do not want any command line solution which stores the password in some log in the system and can be world visible using ps aux or something.
Opening Bounty
From all the answers so far and my anaylsis of those solutions, it looks like other than public key authentication all others are insecure. I am not yet sure if using expect is insecure. I think it is otherwise the correct solution for me. In that case, I am getting command not found errors while trying to do that as already commented on one of the answers.
From http://www.debianadmin.com/sshpass-non-interactive-ssh-password-authentication.html -
First and foremost, users of sshpass
should realize that ssh’s insistance
on only getting the password
interactively is not without reason.
It is close to be impossible to
securely store the password, and users
of sshpass should consider whether
ssh’s public key authentication
provides the same end-user experience,
while involving less hassle and being
more secure.
So, is it not possible to securely run multiple ssh, scp commands by entering the ssh/ftp password (if only once at runtime? Please read my Requirement section again.
Also, can anyone explain this -
In particular, people writing programs
that satisfies are meant to
communicate the above points)password
programatically are encouraged to use
an anonymous pipe and pass the pipe’s
reading end to sshpass using the -d
option.
Does this mean anything is possible?
Indeed, you'll definitely want to look into setting up ssh keys, over saving a password in a bash script. If the key is passwordless, then no user input will be required to ssh/scp. You just set it up to use the key on both ends and voila, secured communication.
However, I'll get downvoted to hell if I don't say this. Many consider passwordless ssh keys to be a Bad Idea(TM). If anybody gets their hands on the keys, the have full access. This means that you are relying on other security measures such as file permissions to keep your password safe.
Also, look into ssh-agent. It allows you to set it up so that you have a password protected ssh-key, but you only need to type it in once and it will manage the password for the key for you and use it when necessary. On my linux box at home, I have ssh-agent set up to run in my .xinitrc file so that it prompts me once and then starts X. YMMV.
UPDATE:
With regards to your requirements, password protected public key authentication + ssh-agent still seems to fit. Only the developers privy to the SSH/FTP password could start up ssh-agent, type in the password and ssh-agent would manage the passwords for the public keys for the rest of the session, never requiring interaction again.
Of course, how it stores it is another matter entirely. IANASE, but for more information on security concerns of using ssh-agent, I found symantec's article to be pretty informative: http://www.symantec.com/connect/articles/ssh-and-ssh-agent
"The ssh-agent creates a unix domain
socket, and then listens for
connections from /usr/bin/ssh on this
socket. It relies on simple unix
permissions to prevent access to this
socket, which means that any keys you
put into your agent are available to
anyone who can connect to this socket.
[ie. root]" ...
"however, [..] they are only usable
while the agent is running -- root
could use your agent to authenticate
to your accounts on other systems, but
it doesn't provide direct access to
the keys themselves. This means that
the keys can't be taken off the
machine and used from other locations
indefinitely."
Hopefully you're not in a situation where you're trying to use an untrusted root's system.
The right way to do that is as follows:
Ensure that all your users are using ssh-agent (nowadays this is the default for most Linux systems). You can check it running the following command:
echo $SSH_AUTH_SOCK
If that variable is not empty, it means that the user is using ssh-agent.
Create a pair of authentication keys for every user ensuring they are protected by a non empty passphrase.
Install the public part of the authentication keys on the remote host so that users can log there.
You are done!
Now, the first time an user wants to log into the remote machine from some session it will have to enter the passphrase for its private key.
In later logins from the same session ssh-agent will provide the unlocked key for authentication in behalf of the user that will not be required to introduce the passphrase again.
Ugh. I hit the man pages hard for this. Here's what I got:
Use this code near the beginning of the script to silently get the ssh password:
read -p "Password: " -s SSHPASS # *MUST* be SSHPASS
export SSHPASS
And then use sshpass for ssh like so:
sshpass -e ssh username#hostname
Hope that helps.
You can Using expect to pass a password to ssh do this or as said already use public key authentication instead if that's a viable option.
For password authentication, as you mentioned in you description, you can use "sshpass". On Ubuntu, you can install as "sudo apt-get install sshpass".
For public/private key-pair base authentication,
First generate keys using, "ssh-keygen"
Then copy your key to the remote machine, using "ssh-copy-id username#remote-machine"
Once copied, the subsequent logins should not ask for password.
Expect is insecure
It drives an interactive session. If you were to pass a password via expect it would be no different from you typing a password on the command line except that the expect script would have retrieve the password from somewhere. It's typically insecure because people will put the password in the script, or in a config file.
It's also notoriously brittle because it waits on particular output as the event mechanism for input.
ssh-agent
ssh-agent is a fine solution if this is script that will always be driven manually. If there is someone who will be logged in to drive the execution of the script than an agent is a good way to go. It is not a good solution for automation because an agent implies a session. You usually don't initiate a session to automatically kick of a script (ie. cron).
ssh command keys
Ssh command keys is your best bet for an automated solution. It doesn't require a session, and the command key restricts what runs on the server to only the command specified in the authorized_keys. They are also typically setup without passwords. This can be a difficult solution to manage if you have thousands of servers. If you only have a few then it's pretty easy to setup and manage.
service ssh accounts
I've also seen setups with password-less service accounts. Instead of the command entry in tehh authorized_keys file, and alternative mechanism is used to restrict access/commands. These solutions often use sudo or restricted shells. However, I think these are more complicated to manage correctly, and therefore tend to be more insecure.
host to host automatic authentication
You can also setup host 2 host automatic authentication, but there are alot of things to get write to do this correctly. From setting up your network properly, using a bastion host for host key dissemination, proper ssh server configuration, etc. As a result this is not a solution a recommend unless you know what your doing and have the capacity and ability to set everything up correctly and maintain it as such.
For those for who setting up a keypair is not an option and absolutely need to perform password authentication, use $SSH_ASKPASS:
SSH_ASKPASS - If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particularly useful when calling ssh from a .xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.)
E.g.:
$ echo <<EOF >password.sh
#!/bin/sh
echo 'password'
EOF
$ chmod 500 password.sh
$ echo $(DISPLAY=bogus SSH_ASKPASS=$(pwd)/password.sh setsid ssh user#host id </dev/null)
See also Tell SSH to use a graphical prompt for key passphrase.
Yes, you want pubkey authentication.
Today, the only way I was able to do this in a bash script via crontab was like that:
eval $(keychain --eval --agents ssh id_rsa id_dsa id_ed25519)
source $HOME/.keychain/$HOSTNAME-sh
This is with the ssh agent already running and to achieve that it was needed the passphrase.
ssh, ssh-keygen, ssh-agent, ssh-add and a correct configuration in /etc/ssh_config on the remote systems are necessary ingredients for securing access to remote systems.
First, a private/public keypair needs to be generated with ssh-keygen. The result of the keygen process are two files: the public key and the private key.
The public key file, usually stored in ~/.ssh/id_dsa.pub (or ~/.ssh/id_rsa.pub, for RSA encryptions) needs to be copied to each remote system that will be granting remote access to the user.
The private key file should remain on the originating system, or on a portable USB ("thumb") drive that is referenced from the sourcing system.
When generating the key pair, a passphrase is used to protect it from usage by non-authenticated users. When establishing an ssh session for the first time, the private key can only be unlocked with the passphrase. Once unlocked, it is possible for the originating system to remember the unlocked private key with ssh-agent. Some systems (e.g., Mac OS X) will automatically start up ssh-agent as part of the login process, and then do an automatic ssh-add -k that unlocks your private ssh keys using a passphrase previously stored in the keychain file.
Connections to remote systems can be direct, or proxied through ssh gateways. In the former case, the remote system only needs to have the public key corresponding to the available unlocked private keys. In the case of using a gateway, the intermediate system must have the public key as well as the eventual target system. In addition, the original ssh command needs to enable agent forwarding, either by configuration in ~/.ssh/config or by command option -A.
For example, to login to remote system "app1" through an ssh gateway system called "gw", the following can be done:
ssh -At gw ssh -A app1
or the following stanzas placed in the ~/.ssh/config file:
Host app1
ForwardAgent = yes
ProxyCommand = ssh -At gw nc %h %p 2>/dev/null
which runs "net cat" (aka nc) on the ssh gateway as a network pipe.
The above setup will allow very simple ssh commands, even through ssh gateways:
ssh app1
Sometimes, even more important than terminal sessions are scp and rsync commands for moving files around securely. For example, I use something like this to synchronize my personal environment to a remote system:
rsync -vaut ~/.env* ~/.bash* app1:
Without the config file and nc proxy command, the rsync would get a little more complicated:
rsync -vaut -e 'ssh -A gw' app1:
None of this will work correctly unless the remote systems' /etc/ssh_config is configured correctly. One such configuration is to remove "root" access via ssh, which improve tracking and accountability when several staff can perform root functions.
In unattended batch scripts, a special ssh key-pair needs to be generated for the non-root userid under which the scripts are run. Just as with ssh session management, the batch user ssh key-pair needs to be deployed similarly, with the public key copied to the remote systems, and the private key residing on the source system.
The private key can be locked with a passphrase or unlocked, as desired by the system managers and/or developers. The way to use the special batch ssh key, even in a script running under root, is to use the "ssh -i ~/.ssh/id_dsa" command options with all remote access commands. For example, to copy a file within a script using the special "batch" user access:
rsync -vaut -e 'ssh -i ~batch/.ssh/id_dsa -A gw' $sourcefiles batch#app2:/Sites/www/
This causes rsync to use a special ssh command as the remote access shell. The special-case ssh command uses the "batch" user's DSA private key as its identity. The rsync command's target remote system will be accessed using the "batch" user.