In a multi-tiered environment, you must rely on ssh to run your benchmarks automatically and remotely. To run remote applications, it also relies on the ability of running them without the need of providing password.
In this article, we will discuss how to set up ssh so that you don't have to use a password.
In this article, we assume you have OpenSSH installed on your platforms. In our benchmark environment, we are using Windows and Linux systems. On the Windows, we have installed MKS Toolkit. For example, ssh-keygen.exe can be found in its bin folder.
OpenSSH suite has been installed on anotherserver below and sshd is up and running. By default, when you ssh into a remote machine, you will be asked to provide a password as shown below.
This command will generate both a private and a public key in the ~/.ssh folder:
After the above setup. you should then be able to use ssh to log in to the remote server without being asked for a password.
$ ssh anotheruser@anotherserver
Last login: Wed May 23 11:41:31 2012 from dhcp-xxxx-xxx-xxxx-anyconnect-10-xxx-xxx-94.xxx.mycompany.com
[anotheruser@anotherserver ~]$
If you have any problems, try:
In this article, we will discuss how to set up ssh so that you don't have to use a password.
OpenSSH
The OpenSSH suite replaces rlogin and telnet with the ssh program, rcp with scp, and ftp with sftp. Also included is sshd (SSH daemon), and the other utilities like ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen and sftp-server.In this article, we assume you have OpenSSH installed on your platforms. In our benchmark environment, we are using Windows and Linux systems. On the Windows, we have installed MKS Toolkit. For example, ssh-keygen.exe can be found in its bin folder.
Testing
OpenSSH SSH daemon on the server listens for connections from clients. It is normally started at boot time. It supports SSH protocols 1 and 2:- Protocol 1
- only supports RSA keys.
- Protocol 2
- supports both RSA and DSA keys
OpenSSH suite has been installed on anotherserver below and sshd is up and running. By default, when you ssh into a remote machine, you will be asked to provide a password as shown below.
$ ssh anotheruser@anotherserver
The authenticity of host 'anotherserver(10.xxx.xxx.159)' can't be established.
RSA key fingerprint is ed:eb:67:75:21:50:e5:33:72:36:d1:43:b6:64:4e:19.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'anotherserver,10.xxx.xxx.159' (RSA) to the list of known hosts.
anotheruser@anotherserver's password:
Last login: Wed May 9 18:08:23 2012 from dhcp-xxxx-xxx-xxxx-anyconnect-10-xxx-xxx-153.xxx.mycompany.com
Set up ssh So You Aren't Asked for a Password
Our servers will use SSH protocol 1 and RSA keys for communication. Here are the steps:- Use ssh-keygen to set up your user public and private keys
- You probably should passphrase protect your keys. However, we didn't do it here for simplicity.
- Make sure the remote system knows about your public keys.
- This means making sure that on the remote system (i.e., ssh server) there is a file called authorized_keys in your .ssh directory. This file should contain the contents of id_rsa.pub of ssh clients.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Documents and Settings\localuser\.ssh\id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Documents and Settings\localuser\.ssh\id_rsa.
Your public key has been saved in C:\Documents and Settings\localuser\.ssh\id_rsa.pub.
The key fingerprint is:
bd:97:40:b7:d6:8b:35:76:0d:6a:7c:fe:5a:20:3a:6a localuser@myserver
This command will generate both a private and a public key in the ~/.ssh folder:
- id_rsa
- id_rsa.pub
- ~/.ssh/authorized_keys
After the above setup. you should then be able to use ssh to log in to the remote server without being asked for a password.
$ ssh anotheruser@anotherserver
Last login: Wed May 23 11:41:31 2012 from dhcp-xxxx-xxx-xxxx-anyconnect-10-xxx-xxx-94.xxx.mycompany.com
[anotheruser@anotherserver ~]$
If you have any problems, try:
- Adding the -v switch to ssh command
- Check the log to determine why the connections were blocked
- For example, you can look at /var/log/secure log file on systems with Oracle Linux Server release 6.8
- Read [7] for more ideas
- For example, permissions could be another sort of problem causing publickey authentication failures.
- Check that your ~ and ~/.ssh directories are not readable by anybody except for your user (chmod 750 ~ && chmod 700 ~/.ssh could fix that)
No comments:
Post a Comment