Passwordless SSH (and RSH) Logins - Revision history

Steve vmwx at 23:20, 14 December 2006

2006-12-14T23:20:26Z

← Older revision		Revision as of 19:20, 14 December 2006
Line 80:		Line 80:

	A closing note or two:		A closing note or two:

			For RedHat and derivatives, the permissions are quite fussy:

			chmod 644 ~/.ssh/auth*

			chmod 755 ~/.ssh

	When compiling / running MPI 1.2x remember either the "setenv P4_RSHCOMMAND ssh" or run configure with "-rsh=ssh" (it'll whinge that you should use the command line option - ignore it)		When compiling / running MPI 1.2x remember either the "setenv P4_RSHCOMMAND ssh" or run configure with "-rsh=ssh" (it'll whinge that you should use the command line option - ignore it)

Deadline: spam

2006-11-20T14:09:41Z

spam

New page

'''DISCLAIMER:''' Implementing any of these techniques will allow you to login to the target system without being prompted for a password. In all but one set of circumstances this is a very, very, very BAD thing.

'''OpenSSH Public Key Authentication'''

The info below comes from Robert G Brown (aka RGB) at Duke University email on the Beowulf list.

Now, let's arrange it so that we can login to a remote host (also running sshd) without a password. Let's start by seeing if we can login to the remote host at all, I<with> a password:

<pre>
rgb@lucifer|T:151>ssh lilith
The authenticity of host 'lilith (192.168.1.131)' can't be established.
RSA key fingerprint is 8d:55:10:15:8b:6c:64:65:17:00:a7:84:a3:35:9f:f6.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'lilith,192.168.1.131' (RSA) to the list of known hosts.
rgb@lilith's password:
rgb@lilith|T:101>
</pre>

>>

So far, so good. Note that the FIRST time we remotely login, ssh will ask you to verify that the host you are connecting to is really that host. When you answer yes it will save its key fingerprint and use it thereafter to automatically verify that the host is who you think it is. This is one small part of the ssh security benefit. However, we had to enter a password to login. This is no big deal for a single host, but is a BIG deal if you have to do it 1024 times on a big cluster just to get pvm started up!

To avoid this, we use the ssh-keygen command to generate a public/private ssh key pair of our very own:

<pre>
rgb@lucifer|T:104>ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/rgb/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/rgb/.ssh/id_rsa.
Your public key has been saved in /home/rgb/.ssh/id_rsa.pub.
The key fingerprint is: c3:aa:6b:ba:35:57:95:aa:7b:45:48:94:c3:83:81:11
</pre>

>>

This generates a default 1024 bit RSA key; alternatively we could have made a DSA key or increased or decreased the number of bits in the key (decreasing being a Bad Idea). Note that we used a blank passphrase; this will keep ssh from prompting us for a passphrase when we connect.

A more secure option is to use a non-blank passphrase. In this case, you will have to use a couple more ssh tools (once per session).

<pre>
guest@localhost$ ssh-agent $SHELL
guest@localhost$ ssh-add
Enter passphrase for /home/guest/.ssh/id_rsa:
Identity added: /home/guest/.ssh/id_rsa (/home/guest/.ssh/id_rsa)
</pre>

If entering the passphrase once per session is annoying, then you should try [http://www.gentoo.org/proj/en/keychain/index.xml keychain], which will reuse ssh-agents across all of your sessions. The associated IBM developerWorks articles are very nice introductions to openssh public key authentication.

The last step is to create an authorized keys file in your ~/.ssh directory. If your home directory is NFS exported to all the nodes, then you are done; otherwise you'll also need to copy the I<entire .ssh directory> to all the hosts that don't already have it mounted. The following illustrates the steps and a test.

<pre>
rgb@lucifer|T:113>cd .ssh
rgb@lucifer|T:114>ls
id_rsa id_rsa.pub known_hosts
rgb@lucifer|T:115>cp id_rsa.pub authorized_keys
rgb@lucifer|T:116>cd ..
rgb@lucifer|T:118>scp -r .ssh lilith:
rgb@lilith's password:
known_hosts 100% |*****************************| 231 00:00
id_rsa 100% |*****************************| 883 00:00
id_rsa.pub 100% |*****************************| 220 00:00
authorized_keys 100% |*****************************| 220 00:00
rgb@lucifer|T:120>ssh lilith
rgb@lilith|T:101>
</pre>

>>

Note that with the last ssh we logged into lilith with no password!

ssh is really pretty easy to set up this way; if you read the man page(s) you can learn how to generate and add additional authorized keys and do fancier things with it, but many users will need no more than what we've done so far. A warning - it is a good idea to log into each host in your cluster one time after setting it up before proceeding further, to build up the known_hosts file so that you aren't prompted for each host the first time PVM starts up a virtual machine.

[end]

A closing note or two:

When compiling / running MPI 1.2x remember either the "setenv P4_RSHCOMMAND ssh" or run configure with "-rsh=ssh" (it'll whinge that you should use the command line option - ignore it)

Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in '''both''' directions!

'''OpenSSH hostbased authentication'''

A cluster adminstrator may want to save his users the trouble of setting up public keys themselves by enabling [http://www.omega.telia.net/vici/openssh/ hostbased authentication]. Keep in mind that if someone compromises your trusted host(s), then they will have comprimised your entire cluster.

'''RLOGIN and RSH'''

There's a fair degree of implementation difference between distro's. The RedHat flavours and derivatives all seem to be vaguely similar. You always want the non-Kerberos version of the "R" utilites. Rather than producing the whole thing, here's a link to an articles that worked for the author:

http://howto.x-tend.be/openMosixWiki/index.php/Enabling%20RSH/RLOGIN%20without%20a%20password%20%28even%20for%20root%21%29

Here's the upstream URL too: http://howto.x-tend.be/openMosixWiki/index.php/ -> Stick "RSH" in the search box.

In some respects the R utilites are quicker than their chatty SSH cousins. However, this becomes irrelevant after MPI starts up (that by design handles its own comms after the link is established). Also a lot of utilites leave their SSH connection open rather than rsh which they rerun on every request (eg. MOODSS).

Seriously think about *why* you want RSH/RLOGIN. As you can see above, SSH isn't hard and (I'd argue) a bit easier!

Deadline: spam removal

2006-11-06T20:05:24Z

spam removal

New page

Shewmaker at 04:00, 23 February 2006

2006-02-23T04:00:10Z

← Older revision		Revision as of 00:00, 23 February 2006
Line 2:		Line 2:


	'''~~SSH~~'''		'''OpenSSH Public Key Authentication'''

	The info below comes from Robert G Brown (aka RGB) at Duke University email on the Beowulf list.		The info below comes from Robert G Brown (aka RGB) at Duke University email on the Beowulf list.
Line 10:		Line 10:
	Now, let's arrange it so that we can login to a remote host (also running sshd) without a password. Let's start by seeing if we can login to the remote host at all, I<with> a password:		Now, let's arrange it so that we can login to a remote host (also running sshd) without a password. Let's start by seeing if we can login to the remote host at all, I<with> a password:

			<pre>
	rgb@lucifer\|T:151>ssh lilith		rgb@lucifer\|T:151>ssh lilith

	The authenticity of host 'lilith (192.168.1.131)' can't be established.		The authenticity of host 'lilith (192.168.1.131)' can't be established.

	RSA key fingerprint is 8d:55:10:15:8b:6c:64:65:17:00:a7:84:a3:35:9f:f6.		RSA key fingerprint is 8d:55:10:15:8b:6c:64:65:17:00:a7:84:a3:35:9f:f6.

	Are you sure you want to continue connecting (yes/no)? yes		Are you sure you want to continue connecting (yes/no)? yes

	Warning: Permanently added 'lilith,192.168.1.131' (RSA) to the list of known hosts.		Warning: Permanently added 'lilith,192.168.1.131' (RSA) to the list of known hosts.

	rgb@lilith's password:		rgb@lilith's password:

	rgb@lilith\|T:101>		rgb@lilith\|T:101>
			</pre>

	>>		>>
Line 32:		Line 27:
	To avoid this, we use the ssh-keygen command to generate a public/private ssh key pair of our very own:		To avoid this, we use the ssh-keygen command to generate a public/private ssh key pair of our very own:

			<pre>
	rgb@lucifer\|T:104>ssh-keygen -t rsa		rgb@lucifer\|T:104>ssh-keygen -t rsa

	Generating public/private rsa key pair.		Generating public/private rsa key pair.

	Enter file in which to save the key (/home/rgb/.ssh/id_rsa):		Enter file in which to save the key (/home/rgb/.ssh/id_rsa):

	Enter passphrase (empty for no passphrase):		Enter passphrase (empty for no passphrase):

	Enter same passphrase again:		Enter same passphrase again:

	Your identification has been saved in /home/rgb/.ssh/id_rsa.		Your identification has been saved in /home/rgb/.ssh/id_rsa.

	Your public key has been saved in /home/rgb/.ssh/id_rsa.pub.		Your public key has been saved in /home/rgb/.ssh/id_rsa.pub.

	The key fingerprint is: c3:aa:6b:ba:35:57:95:aa:7b:45:48:94:c3:83:81:11		The key fingerprint is: c3:aa:6b:ba:35:57:95:aa:7b:45:48:94:c3:83:81:11
			</pre>

	>>		>>
Line 55:		Line 44:
	A more secure option is to use a non-blank passphrase. In this case, you will have to use a couple more ssh tools (once per session).		A more secure option is to use a non-blank passphrase. In this case, you will have to use a couple more ssh tools (once per session).

			<pre>
	guest@localhost$ ssh-agent $SHELL		guest@localhost$ ssh-agent $SHELL
	guest@localhost$ ssh-add		guest@localhost$ ssh-add
	Enter passphrase for /home/guest/.ssh/id_rsa:		Enter passphrase for /home/guest/.ssh/id_rsa:
	Identity added: /home/guest/.ssh/id_rsa (/home/guest/.ssh/id_rsa)		Identity added: /home/guest/.ssh/id_rsa (/home/guest/.ssh/id_rsa)
			</pre>

	If entering the passphrase once per session is annoying, then you should try [http://www.gentoo.org/proj/en/keychain/index.xml keychain], which will reuse ssh-agents across all of your sessions. The associated IBM developerWorks articles are very nice introductions to openssh public key authentication.		If entering the passphrase once per session is annoying, then you should try [http://www.gentoo.org/proj/en/keychain/index.xml keychain], which will reuse ssh-agents across all of your sessions. The associated IBM developerWorks articles are very nice introductions to openssh public key authentication.
Line 64:		Line 55:
	The last step is to create an authorized keys file in your ~/.ssh directory. If your home directory is NFS exported to all the nodes, then you are done; otherwise you'll also need to copy the I<entire .ssh directory> to all the hosts that don't already have it mounted. The following illustrates the steps and a test.		The last step is to create an authorized keys file in your ~/.ssh directory. If your home directory is NFS exported to all the nodes, then you are done; otherwise you'll also need to copy the I<entire .ssh directory> to all the hosts that don't already have it mounted. The following illustrates the steps and a test.

			<pre>
	rgb@lucifer\|T:113>cd .ssh		rgb@lucifer\|T:113>cd .ssh

	rgb@lucifer\|T:114>ls		rgb@lucifer\|T:114>ls

	id_rsa id_rsa.pub known_hosts		id_rsa id_rsa.pub known_hosts

	rgb@lucifer\|T:115>cp id_rsa.pub authorized_keys		rgb@lucifer\|T:115>cp id_rsa.pub authorized_keys

	rgb@lucifer\|T:116>cd ..		rgb@lucifer\|T:116>cd ..

	rgb@lucifer\|T:118>scp -r .ssh lilith:		rgb@lucifer\|T:118>scp -r .ssh lilith:

	rgb@lilith's password:		rgb@lilith's password:

	known_hosts 100% \|*****************************\| 231 00:00		known_hosts 100% \|*****************************\| 231 00:00

	id_rsa 100% \|*****************************\| 883 00:00		id_rsa 100% \|*****************************\| 883 00:00

	id_rsa.pub 100% \|*****************************\| 220 00:00		id_rsa.pub 100% \|*****************************\| 220 00:00

	authorized_keys 100% \|*****************************\| 220 00:00		authorized_keys 100% \|*****************************\| 220 00:00

	rgb@lucifer\|T:120>ssh lilith		rgb@lucifer\|T:120>ssh lilith

	rgb@lilith\|T:101>		rgb@lilith\|T:101>
			</pre>

	>>		>>
Line 104:		Line 84:

	Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in '''both''' directions!		Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in '''both''' directions!


			'''OpenSSH hostbased authentication'''

			A cluster adminstrator may want to save his users the trouble of setting up public keys themselves by enabling [http://www.omega.telia.net/vici/openssh/ hostbased authentication]. Keep in mind that if someone compromises your trusted host(s), then they will have comprimised your entire cluster.

Shewmaker at 03:48, 23 February 2006

2006-02-23T03:48:58Z

← Older revision		Revision as of 23:48, 22 February 2006
Line 1:		Line 1:
	'''DISCLAIMER:''' ~~Implemeting~~ any of these techniques will allow you to login to the target system without being prompted for a password. In all but one set of circumstances this is a very, very, very BAD thing.		'''DISCLAIMER:''' Implementing any of these techniques will allow you to login to the target system without being prompted for a password. In all but one set of circumstances this is a very, very, very BAD thing.


Line 52:		Line 52:

	This generates a default 1024 bit RSA key; alternatively we could have made a DSA key or increased or decreased the number of bits in the key (decreasing being a Bad Idea). Note that we used a blank passphrase; this will keep ssh from prompting us for a passphrase when we connect.		This generates a default 1024 bit RSA key; alternatively we could have made a DSA key or increased or decreased the number of bits in the key (decreasing being a Bad Idea). Note that we used a blank passphrase; this will keep ssh from prompting us for a passphrase when we connect.

			A more secure option is to use a non-blank passphrase. In this case, you will have to use a couple more ssh tools (once per session).

			guest@localhost$ ssh-agent $SHELL
			guest@localhost$ ssh-add
			Enter passphrase for /home/guest/.ssh/id_rsa:
			Identity added: /home/guest/.ssh/id_rsa (/home/guest/.ssh/id_rsa)

			If entering the passphrase once per session is annoying, then you should try [http://www.gentoo.org/proj/en/keychain/index.xml keychain], which will reuse ssh-agents across all of your sessions. The associated IBM developerWorks articles are very nice introductions to openssh public key authentication.

	The last step is to create an authorized keys file in your ~/.ssh directory. If your home directory is NFS exported to all the nodes, then you are done; otherwise you'll also need to copy the I<entire .ssh directory> to all the hosts that don't already have it mounted. The following illustrates the steps and a test.		The last step is to create an authorized keys file in your ~/.ssh directory. If your home directory is NFS exported to all the nodes, then you are done; otherwise you'll also need to copy the I<entire .ssh directory> to all the hosts that don't already have it mounted. The following illustrates the steps and a test.

Steve vmwx at 03:49, 22 February 2006

2006-02-22T03:49:45Z

← Older revision		Revision as of 23:49, 21 February 2006
Line 95:		Line 95:

	Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in '''both''' directions!		Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in '''both''' directions!


			'''RLOGIN and RSH'''

			There's a fair degree of implementation difference between distro's. The RedHat flavours and derivatives all seem to be vaguely similar. You always want the non-Kerberos version of the "R" utilites. Rather than producing the whole thing, here's a link to an articles that worked for the author:

			http://howto.x-tend.be/openMosixWiki/index.php/Enabling%20RSH/RLOGIN%20without%20a%20password%20%28even%20for%20root%21%29

			Here's the upstream URL too: http://howto.x-tend.be/openMosixWiki/index.php/ -> Stick "RSH" in the search box.

			In some respects the R utilites are quicker than their chatty SSH cousins. However, this becomes irrelevant after MPI starts up (that by design handles its own comms after the link is established). Also a lot of utilites leave their SSH connection open rather than rsh which they rerun on every request (eg. MOODSS).

			Seriously think about why you want RSH/RLOGIN. As you can see above, SSH isn't hard and (I'd argue) a bit easier!

Steve vmwx at 03:45, 22 February 2006

2006-02-22T03:45:44Z

New page

'''DISCLAIMER:''' Implemeting any of these techniques will allow you to login to the target system without being prompted for a password. In all but one set of circumstances this is a very, very, very BAD thing.

'''SSH'''

The info below comes from Robert G Brown (aka RGB) at Duke University email on the Beowulf list.

Now, let's arrange it so that we can login to a remote host (also running sshd) without a password. Let's start by seeing if we can login to the remote host at all, I<with> a password:

rgb@lucifer|T:151>ssh lilith

The authenticity of host 'lilith (192.168.1.131)' can't be established.

RSA key fingerprint is 8d:55:10:15:8b:6c:64:65:17:00:a7:84:a3:35:9f:f6.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'lilith,192.168.1.131' (RSA) to the list of known hosts.

rgb@lilith's password:

rgb@lilith|T:101>

>>

So far, so good. Note that the FIRST time we remotely login, ssh will ask you to verify that the host you are connecting to is really that host. When you answer yes it will save its key fingerprint and use it thereafter to automatically verify that the host is who you think it is. This is one small part of the ssh security benefit. However, we had to enter a password to login. This is no big deal for a single host, but is a BIG deal if you have to do it 1024 times on a big cluster just to get pvm started up!

To avoid this, we use the ssh-keygen command to generate a public/private ssh key pair of our very own:

rgb@lucifer|T:104>ssh-keygen -t rsa

Generating public/private rsa key pair.

Enter file in which to save the key (/home/rgb/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/rgb/.ssh/id_rsa.

Your public key has been saved in /home/rgb/.ssh/id_rsa.pub.

The key fingerprint is: c3:aa:6b:ba:35:57:95:aa:7b:45:48:94:c3:83:81:11

>>

This generates a default 1024 bit RSA key; alternatively we could have made a DSA key or increased or decreased the number of bits in the key (decreasing being a Bad Idea). Note that we used a blank passphrase; this will keep ssh from prompting us for a passphrase when we connect.

The last step is to create an authorized keys file in your ~/.ssh directory. If your home directory is NFS exported to all the nodes, then you are done; otherwise you'll also need to copy the I<entire .ssh directory> to all the hosts that don't already have it mounted. The following illustrates the steps and a test.

rgb@lucifer|T:113>cd .ssh

rgb@lucifer|T:114>ls

id_rsa id_rsa.pub known_hosts

rgb@lucifer|T:115>cp id_rsa.pub authorized_keys

rgb@lucifer|T:116>cd ..

rgb@lucifer|T:118>scp -r .ssh lilith:

rgb@lilith's password:

known_hosts 100% |*****************************| 231 00:00

id_rsa 100% |*****************************| 883 00:00

id_rsa.pub 100% |*****************************| 220 00:00

authorized_keys 100% |*****************************| 220 00:00

rgb@lucifer|T:120>ssh lilith

rgb@lilith|T:101>

>>

Note that with the last ssh we logged into lilith with no password!

ssh is really pretty easy to set up this way; if you read the man page(s) you can learn how to generate and add additional authorized keys and do fancier things with it, but many users will need no more than what we've done so far. A warning - it is a good idea to log into each host in your cluster one time after setting it up before proceeding further, to build up the known_hosts file so that you aren't prompted for each host the first time PVM starts up a virtual machine.

[end]

A closing note or two:

When compiling / running MPI 1.2x remember either the "setenv P4_RSHCOMMAND ssh" or run configure with "-rsh=ssh" (it'll whinge that you should use the command line option - ignore it)

Most Linux distro's are setup with some sensible default firewall settings. Remember to modify them so SSH is allowed in '''both''' directions!