SSH login without passwords - Revision history

Root at 17:35, 29 September 2009

2009-09-29T17:35:30Z

← Older revision		Revision as of 17:35, 29 September 2009
Line 9:		Line 9:
	client1		client1
	server1		server1
	</nowiki></pre>respectively and username in the remote machine is <nowiki>		</nowiki></pre>respectively and username in the server (remote machine) is <nowiki>
	</nowiki><pre><nowiki>		</nowiki><pre><nowiki>
	user1		user1
Line 22:		Line 22:
	</nowiki></pre>		</nowiki></pre>
	#Copy public-key to somewhere in server1<nowiki>		#Copy public-key to somewhere in server1<nowiki>
	</nowiki><pre><nowiki>$ scp ~/.ssh/id_dsa.pub user1@~~client1~~:~/.ssh/id_dsa.pub</nowiki></pre>		</nowiki><pre><nowiki>$ scp ~/.ssh/id_dsa.pub user1@server1:~/.ssh/id_dsa.pub</nowiki></pre>
	#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>		#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>
	</nowiki><pre><nowiki>cat ~user1/.ssh/id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>		</nowiki><pre><nowiki>cat ~user1/.ssh/id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>

Root: /* Synopsis */

2006-07-11T04:10:50Z

Synopsis

← Older revision		Revision as of 04:10, 11 July 2006
Line 2:		Line 2:
	{{wbox\|;IMPORTANT:		{{wbox\|;IMPORTANT:
	The method described here has inherant problem of sever being vulnarable if the client is compromised. There is no line of defence in between. This arises from the fact that we don't enter a pass-phrase when creating the key-pair. To overcome this issue, without going through the trouble of entering a password (or phrase) at every login, use the application known as [[Keychain]].}}		The method described here has inherant problem of sever being vulnarable if the client is compromised. There is no line of defence in between. This arises from the fact that we don't enter a pass-phrase when creating the key-pair. To overcome this issue, without going through the trouble of entering a password (or phrase) at every login, use the application known as [[Keychain]].}}
	Whenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security ~~issue~~ , it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.		Whenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security precaution, it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.

	==Howto==		==Howto==

Root: /* Synopsis */

2006-07-11T04:09:29Z

Synopsis

← Older revision		Revision as of 04:09, 11 July 2006
Line 1:		Line 1:
	==Synopsis==		==Synopsis==
	{{wbox\|;IMPORTANT:		{{wbox\|;IMPORTANT:
	The method described here has inherant problem of sever being vulnarable if the client is compromised. There is no line of defence in between. To overcome this issue the application known as [[Keychain]] ~~can be used~~.}		The method described here has inherant problem of sever being vulnarable if the client is compromised. There is no line of defence in between. This arises from the fact that we don't enter a pass-phrase when creating the key-pair. To overcome this issue, without going through the trouble of entering a password (or phrase) at every login, use the application known as [[Keychain]].}}
	Whenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security issue , it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.		Whenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security issue , it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.

Root: /* Synopsis */

2006-07-11T04:07:51Z

Synopsis

← Older revision		Revision as of 04:07, 11 July 2006
Line 1:		Line 1:
	==Synopsis==		==Synopsis==
			{{wbox\|;IMPORTANT:
			The method described here has inherant problem of sever being vulnarable if the client is compromised. There is no line of defence in between. To overcome this issue the application known as [[Keychain]] can be used.}
	Whenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security issue , it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.		Whenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security issue , it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.
	~~;IMPORTANT:~~
	The method described here has inherant problem of sever being vulnarable if the client is compromised. There is no line of defence in between. To overcome this issue the application known as [[Keychain]] can be used.

	==Howto==		==Howto==

Root: /* Howto */

2006-07-11T04:06:08Z

Howto

← Older revision		Revision as of 04:06, 11 July 2006
Line 15:		Line 15:
	#Create public-private key pair in client1<nowiki>		#Create public-private key pair in client1<nowiki>
	</nowiki><pre><nowiki>		</nowiki><pre><nowiki>
	$ssh-keygen -t dsa -f ~/.ssh/id_dsa		$ ssh-keygen -t dsa -f ~/.ssh/id_dsa
	Generating public/private dsa key pair.		Generating public/private dsa key pair.
	Enter passphrase (empty for no passphrase): (Don't type anything, just press enter here.)		Enter passphrase (empty for no passphrase): (Don't type anything, just press enter here.)
Line 22:		Line 22:
	</nowiki></pre>		</nowiki></pre>
	#Copy public-key to somewhere in server1<nowiki>		#Copy public-key to somewhere in server1<nowiki>
	</nowiki><pre><nowiki>scp ~/.ssh/id_dsa.pub user1@client1:~/.ssh/id_dsa.pub</nowiki></pre>		</nowiki><pre><nowiki>$ scp ~/.ssh/id_dsa.pub user1@client1:~/.ssh/id_dsa.pub</nowiki></pre>
	#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>		#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>
	</nowiki><pre><nowiki>cat ~user1/.ssh/id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>		</nowiki><pre><nowiki>cat ~user1/.ssh/id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>
	#Secure the authorized-keys file (otherwise the scheme will not work!) and remove unnecessary files. (in server1) <nowiki>		#Secure the authorized-keys file (otherwise the scheme will not work!) and remove unnecessary files. (in server1) <nowiki>
	</nowiki><pre><nowiki>		</nowiki><pre><nowiki>
	chmod 640 ~user1/.ssh/authorized_keys2		$ chmod 640 ~user1/.ssh/authorized_keys2
	rm ~user1/.ssh/id_dsa.pub		$ rm ~user1/.ssh/id_dsa.pub
	</nowiki></pre>.		</nowiki></pre>.

Root: /* Howto */

2006-07-11T04:04:58Z

Howto

← Older revision		Revision as of 04:04, 11 July 2006
Line 19:		Line 19:
	Enter passphrase (empty for no passphrase): (Don't type anything, just press enter here.)		Enter passphrase (empty for no passphrase): (Don't type anything, just press enter here.)
	Enter same passphrase again: (Again empty)		Enter same passphrase again: (Again empty)
	57:db:75:66:09:15:5e:cb:6f:a3:bf:39:9f:15:f6:1a user@client1		52:da:75:66:09:15:5e:cb:6f:a3:xd:39:rd:15:f6:da user@client1
	</nowiki></pre>		</nowiki></pre>
	#Copy public-key to somewhere in server1<nowiki>		#Copy public-key to somewhere in server1<nowiki>

Root: /* Howto */

2006-07-11T04:04:37Z

Howto

← Older revision		Revision as of 04:04, 11 July 2006
Line 15:		Line 15:
	#Create public-private key pair in client1<nowiki>		#Create public-private key pair in client1<nowiki>
	</nowiki><pre><nowiki>		</nowiki><pre><nowiki>
	ssh-keygen -t dsa -f ~/.ssh/id_dsa		$ssh-keygen -t dsa -f ~/.ssh/id_dsa
			Generating public/private dsa key pair.
			Enter passphrase (empty for no passphrase): (Don't type anything, just press enter here.)
			Enter same passphrase again: (Again empty)
			57:db:75:66:09:15:5e:cb:6f:a3:bf:39:9f:15:f6:1a user@client1
	</nowiki></pre>		</nowiki></pre>
	#Copy public-key to somewhere in server1<nowiki>		#Copy public-key to somewhere in server1<nowiki>

Root at 10:50, 2 May 2006

2006-05-02T10:50:29Z

← Older revision		Revision as of 10:50, 2 May 2006
Line 20:		Line 20:
	</nowiki><pre><nowiki>scp ~/.ssh/id_dsa.pub user1@client1:~/.ssh/id_dsa.pub</nowiki></pre>		</nowiki><pre><nowiki>scp ~/.ssh/id_dsa.pub user1@client1:~/.ssh/id_dsa.pub</nowiki></pre>
	#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>		#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>
	</nowiki><pre><nowiki>cat id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>		</nowiki><pre><nowiki>cat ~user1/.ssh/id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>
	#Secure the authorized-keys file (otherwise the scheme will not work!) and remove unnecessary files. (in server1) <nowiki>		#Secure the authorized-keys file (otherwise the scheme will not work!) and remove unnecessary files. (in server1) <nowiki>
	</nowiki><pre><nowiki>		</nowiki><pre><nowiki>

Root at 08:35, 22 March 2006

2006-03-22T08:35:41Z

← Older revision		Revision as of 08:35, 22 March 2006
Line 29:		Line 29:

	Now you should be able to login from client1 to user1@server1 without providing password.		Now you should be able to login from client1 to user1@server1 without providing password.

			[[Category:Unix]]

Root at 03:43, 15 March 2006

2006-03-15T03:43:44Z

New page

==Synopsis==
Whenever the ssh command is used to login to a remote machine, user needs to provide the remote machines password. While this is an obvious security issue , it soon becomes a headache once you start to login fifty-times a day to the same, known-and-trusted server from your known-and-trusted client! For such situations, the following is a good approach.
;IMPORTANT:
The method described here has inherant problem of sever being vulnarable if the client is compromised. There is no line of defence in between. To overcome this issue the application known as [[Keychain]] can be used.

==Howto==
;Note:Let's assume the client and server names are <nowiki>
</nowiki><pre><nowiki>
client1
server1
</nowiki></pre>respectively and username in the remote machine is <nowiki>
</nowiki><pre><nowiki>
user1
</nowiki></pre>.
#Create public-private key pair in client1<nowiki>
</nowiki><pre><nowiki>
ssh-keygen -t dsa -f ~/.ssh/id_dsa
</nowiki></pre>
#Copy public-key to somewhere in server1<nowiki>
</nowiki><pre><nowiki>scp ~/.ssh/id_dsa.pub user1@client1:~/.ssh/id_dsa.pub</nowiki></pre>
#In the server1, append the public-key for client1 to the authorized-keys file<nowiki>
</nowiki><pre><nowiki>cat id_dsa.pub >> ~user1/.ssh/authorized_keys2</nowiki></pre>
#Secure the authorized-keys file (otherwise the scheme will not work!) and remove unnecessary files. (in server1) <nowiki>
</nowiki><pre><nowiki>
chmod 640 ~user1/.ssh/authorized_keys2
rm ~user1/.ssh/id_dsa.pub
</nowiki></pre>.

Now you should be able to login from client1 to user1@server1 without providing password.