Configure SSH automation login
If you need a guide on how to configure SSH automation login, here is the steps.
SSH Automatic Login
Of course this is not the right phrase for it. It should be something like “key-based authorization with SSH”. Or simply “publickey authorization”. Or “unattended ssh login”. But I guess you know what I mean.
Here are the steps:
1. Create a public ssh key, if you haven’t one already.
Look at ~/.ssh. If you see a file named id_dsa.pub then you obviously already have a public key. If not, simply create one. ssh-keygen -t dsa should do the trick.
Please note that there are other types of keys, e.g. RSA instead of DSA. I simply recomend DSA, but keep that in mind if you run into errors.
2. Make sure your .ssh dir is 700:
chmod 700 ~/.ssh
3. Get your public ssh key on the server you want to login automatically.
A simple scp ~/.ssh/id_dsa.pub remoteuser@remoteserver.com: is ok.
4. Append the contents of your public key to the ~/.ssh/authorized_keys and remove it.
Important: This must be done on the server you just copied your public key to. Otherwise you wouldn’t have had to copy it on your server.
Simply issue something like cat id_dsa.pub >> .ssh/authorized_keys while at your home directory.
5. Instead of steps 3 and 4, you can issue something like this:
cat ~/.ssh/id_dsa.pub | ssh -l remoteuser remoteserver.com 'cat >> ~/.ssh/authorized_keys'
6. Remove your public key from the home directory on the server.
7. Done!
You can now login:
ssh -l remoteuser remoteserver.com or ssh remoteuser@remoteserver.com without getting asked for a password.
That’s all you need to do.
I found these steps from : http://wp.uberdose.com/2006/10/16/ssh-automatic-login/
If you working with Solaris, may be this guide will help you.
Setting Up SSH For No Password
Peter Cvar, April 2006
This setup will allow you to log in to another account without having to provide the password.
man ssh-keygen is a start, but it might need some clarifying for beginners.
This Tech Tip concentrates on SSH2, the second version of SSH. Don't use the first version any longer; it contains security bugs. Also, older versions of the second version might contain security bugs. Check with ssh -V that your version matches the latest one available from OpenSSH.
If you can't find any of the SSH commands (ssh and scp, for instance) on your system, get the SSH package first and install it. This suite should also install the ssh-keygen command on your machine. Make sure that SSH is installed on every system that you want to access. Starting from the Solaris 9 OS, SSH is included in the distribution.
If you can't find a package suitable for your version, refer to the OpenSSH web site for the source, and then download, unpack, read the README, compile, and install. Systems missing OpenSSL have to add that package as well for SSH to work. Test, for example, ssh localserver; this will create a .ssh subdirectory in your home directory.
In your ~/.ssh directory, create your personal SSH key:
server1:~/.ssh> ssh-keygen -t dsa
This creates id_dsa and id_dsa.pub in ~/.ssh.
If you want to enable remote connections that don't require a password, do not enter a passphrase. If you do enter a non-empty passphrase, when connecting to the remote server you will be asked for the passphrase instead of the password!
Append the public key to the file authorized_keys2:
server1:~/.ssh> cat id_dsa.pub >> authorized_keys2
Don't worry if authorized_keys2 does not yet exist before you execute this command.
Sun provides SSH in the Solaris OS starting from release 9, but uses SSH version 1 naming conventions. On the Solaris 9 OS, use the authorized_keys file instead of authorized_keys2.
Now you should already be able to make a secure connection to your own machine, using this account, without having to provide a password.
Check permissions on your keys and refer to the man page. The id_dsa file should be private, the other keys world readable. On the remote server, generate keys in the same way for your account on that server.
Copy your public key into ~/.ssh/ on the remote server.
server1:~/.ssh> scp id_dsa.pub server2:/your/remote/home/.ssh/server1.key.pub
user@server2's password:
id_dsa.pub 100% |*****************************| 236 00:00
Do the same thing for the remote key; copy it into your local ~/.ssh directory:
server1:~/.ssh> scp server2:/your/remote/home/.ssh/id_dsa.pub ./server2.key.pub
user@server2's password:
id_dsa.pub 100% |*****************************| 236 00:00
On both servers, append the key from the other server to the file authorized_keys2:
server1:~/.ssh> cat server2.key.pub >> authorized_keys2
And also for the second server:
user@server2:~/.ssh> cat server1.key.pub >> authorized_keys2
That's it! Try to connect to the remote server now. It should do something similar to this:
server1:~/.ssh> ssh server2
Last login: Mon Nov 21 16:23:26 2005 from :0
user@server2>
If things don't work, check the logs, possibly in /var/log/secure. This file contains useful information, such as:
Nov 21 10:24:41 ocean sshd[26446]: Authentication refused: bad ownership or
modes for file /home/name/.ssh/authorized_keys
Most likely, the problem is too many permissions.
By default, the Solaris OS doesn't allow ssh as root. Edit /etc/ssh/sshd_config and change the PermitRootLogin directive. Restart sshd for these changes to take effect.
Also on the Solaris OS, make sure that you use the file ~/.ssh/authorized_keys, without the two suffixes. The Solaris OS uses version 2 of ssh but without the version 2 naming convention.
A typical entry in ~/.ssh/authorized_keys(2) looks like this:
ssh-dss FGKJTJUVFMAAACBAOk6t1czfh7nV9sb0syK1CebJ/6nwLb9OPLr0LcqcE1J8GYbePDVfg\
erUIJSpn1UDmujH8emiLR30y9BQN9JU+XmEc5Ab1rrwHWEMahWgZANgEmQt4FmgBNfv+BFGn/tRmd\
cHX07mauLbAB3Uf8sIHJHK57659KHJL8473JUHFRT39uBxv1HAAAAFQCoRN6CXBpYH5VjOzbO4Euj\
cTdXkQAAAIAMUxdVJ6CAFE54a3mdvVO0OWOzhvS8w0iCBbZMdDbzqxmqEexAh8PHaZM5oMN1VzhO9\
HX7qxjlZCqffzZOwepOMPWv5pWabtEf5hfWa4xb4QkLqZC42JhHtUr7KUUnJwkvaoLwKjOcWERAQY\
5anvABcUE/h5CbOS4fh0M21lPdnAAAAIBaZuS3a2qdrtYX/fJ72Bp1kAt9qDq7apMOnA0m4Vireiu\
t433qchgBrvfYBpNyuJ0OXMVLciingYkfAs7a6nl8avMmW3LM37Gkgt06LP+hfdgetsdhsyHAd7dl\
SS9VV1wDloE1fwkJSjtSLbdeJSliu3liu43uztu4u34zutNMI7== name@email.com
Line broken at the '\' for readability.
If you can't connect to a remote server using a particular user name on that server, check that the appropriate key is in your authorized_keys(2) file, and that the remote server name, encryption method, and user name exist.
Use ssh -v, scp -v or sftp -v to display verbose output and analyze any other problems that you might come across.
This guide is from : http://www.sun.com/bigadmin/content/submitted/ssh_setting.html
SSH Automatic Login
Of course this is not the right phrase for it. It should be something like “key-based authorization with SSH”. Or simply “publickey authorization”. Or “unattended ssh login”. But I guess you know what I mean.
Here are the steps:
1. Create a public ssh key, if you haven’t one already.
Look at ~/.ssh. If you see a file named id_dsa.pub then you obviously already have a public key. If not, simply create one. ssh-keygen -t dsa should do the trick.
Please note that there are other types of keys, e.g. RSA instead of DSA. I simply recomend DSA, but keep that in mind if you run into errors.
2. Make sure your .ssh dir is 700:
chmod 700 ~/.ssh
3. Get your public ssh key on the server you want to login automatically.
A simple scp ~/.ssh/id_dsa.pub remoteuser@remoteserver.com: is ok.
4. Append the contents of your public key to the ~/.ssh/authorized_keys and remove it.
Important: This must be done on the server you just copied your public key to. Otherwise you wouldn’t have had to copy it on your server.
Simply issue something like cat id_dsa.pub >> .ssh/authorized_keys while at your home directory.
5. Instead of steps 3 and 4, you can issue something like this:
cat ~/.ssh/id_dsa.pub | ssh -l remoteuser remoteserver.com 'cat >> ~/.ssh/authorized_keys'
6. Remove your public key from the home directory on the server.
7. Done!
You can now login:
ssh -l remoteuser remoteserver.com or ssh remoteuser@remoteserver.com without getting asked for a password.
That’s all you need to do.
I found these steps from : http://wp.uberdose.com/2006/10/16/ssh-automatic-login/
If you working with Solaris, may be this guide will help you.
Setting Up SSH For No Password
Peter Cvar, April 2006
This setup will allow you to log in to another account without having to provide the password.
man ssh-keygen is a start, but it might need some clarifying for beginners.
This Tech Tip concentrates on SSH2, the second version of SSH. Don't use the first version any longer; it contains security bugs. Also, older versions of the second version might contain security bugs. Check with ssh -V that your version matches the latest one available from OpenSSH.
If you can't find any of the SSH commands (ssh and scp, for instance) on your system, get the SSH package first and install it. This suite should also install the ssh-keygen command on your machine. Make sure that SSH is installed on every system that you want to access. Starting from the Solaris 9 OS, SSH is included in the distribution.
If you can't find a package suitable for your version, refer to the OpenSSH web site for the source, and then download, unpack, read the README, compile, and install. Systems missing OpenSSL have to add that package as well for SSH to work. Test, for example, ssh localserver; this will create a .ssh subdirectory in your home directory.
In your ~/.ssh directory, create your personal SSH key:
server1:~/.ssh> ssh-keygen -t dsa
This creates id_dsa and id_dsa.pub in ~/.ssh.
If you want to enable remote connections that don't require a password, do not enter a passphrase. If you do enter a non-empty passphrase, when connecting to the remote server you will be asked for the passphrase instead of the password!
Append the public key to the file authorized_keys2:
server1:~/.ssh> cat id_dsa.pub >> authorized_keys2
Don't worry if authorized_keys2 does not yet exist before you execute this command.
Sun provides SSH in the Solaris OS starting from release 9, but uses SSH version 1 naming conventions. On the Solaris 9 OS, use the authorized_keys file instead of authorized_keys2.
Now you should already be able to make a secure connection to your own machine, using this account, without having to provide a password.
Check permissions on your keys and refer to the man page. The id_dsa file should be private, the other keys world readable. On the remote server, generate keys in the same way for your account on that server.
Copy your public key into ~/.ssh/ on the remote server.
server1:~/.ssh> scp id_dsa.pub server2:/your/remote/home/.ssh/server1.key.pub
user@server2's password:
id_dsa.pub 100% |*****************************| 236 00:00
Do the same thing for the remote key; copy it into your local ~/.ssh directory:
server1:~/.ssh> scp server2:/your/remote/home/.ssh/id_dsa.pub ./server2.key.pub
user@server2's password:
id_dsa.pub 100% |*****************************| 236 00:00
On both servers, append the key from the other server to the file authorized_keys2:
server1:~/.ssh> cat server2.key.pub >> authorized_keys2
And also for the second server:
user@server2:~/.ssh> cat server1.key.pub >> authorized_keys2
That's it! Try to connect to the remote server now. It should do something similar to this:
server1:~/.ssh> ssh server2
Last login: Mon Nov 21 16:23:26 2005 from :0
user@server2>
If things don't work, check the logs, possibly in /var/log/secure. This file contains useful information, such as:
Nov 21 10:24:41 ocean sshd[26446]: Authentication refused: bad ownership or
modes for file /home/name/.ssh/authorized_keys
Most likely, the problem is too many permissions.
By default, the Solaris OS doesn't allow ssh as root. Edit /etc/ssh/sshd_config and change the PermitRootLogin directive. Restart sshd for these changes to take effect.
Also on the Solaris OS, make sure that you use the file ~/.ssh/authorized_keys, without the two suffixes. The Solaris OS uses version 2 of ssh but without the version 2 naming convention.
A typical entry in ~/.ssh/authorized_keys(2) looks like this:
ssh-dss FGKJTJUVFMAAACBAOk6t1czfh7nV9sb0syK1CebJ/6nwLb9OPLr0LcqcE1J8GYbePDVfg\
erUIJSpn1UDmujH8emiLR30y9BQN9JU+XmEc5Ab1rrwHWEMahWgZANgEmQt4FmgBNfv+BFGn/tRmd\
cHX07mauLbAB3Uf8sIHJHK57659KHJL8473JUHFRT39uBxv1HAAAAFQCoRN6CXBpYH5VjOzbO4Euj\
cTdXkQAAAIAMUxdVJ6CAFE54a3mdvVO0OWOzhvS8w0iCBbZMdDbzqxmqEexAh8PHaZM5oMN1VzhO9\
HX7qxjlZCqffzZOwepOMPWv5pWabtEf5hfWa4xb4QkLqZC42JhHtUr7KUUnJwkvaoLwKjOcWERAQY\
5anvABcUE/h5CbOS4fh0M21lPdnAAAAIBaZuS3a2qdrtYX/fJ72Bp1kAt9qDq7apMOnA0m4Vireiu\
t433qchgBrvfYBpNyuJ0OXMVLciingYkfAs7a6nl8avMmW3LM37Gkgt06LP+hfdgetsdhsyHAd7dl\
SS9VV1wDloE1fwkJSjtSLbdeJSliu3liu43uztu4u34zutNMI7== name@email.com
Line broken at the '\' for readability.
If you can't connect to a remote server using a particular user name on that server, check that the appropriate key is in your authorized_keys(2) file, and that the remote server name, encryption method, and user name exist.
Use ssh -v, scp -v or sftp -v to display verbose output and analyze any other problems that you might come across.
This guide is from : http://www.sun.com/bigadmin/content/submitted/ssh_setting.html
Comments
Post a Comment
Feel free to leave your question or comment here, we will reply you as soon as possible.