Penguin

Differences between version 19 and predecessor to the previous major change of SSHKeys.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 19 Last edited on Friday, August 26, 2005 5:03:02 pm by JohnMcPherson Revert
Older page: version 18 Last edited on Thursday, July 28, 2005 7:09:00 pm by MattBrown Revert
@@ -13,19 +13,23 @@
 __NOTE:__ Do not run an agent on hosts you do not trust. Their SuperUser can then steal your keys. 
  
 !!! Generating key pairs 
  
-This is what ssh-keygen(1) is for. Use a SSH2 key if at all possible .  
-  
- ssh-keygen -t dsa  
- # or  
- ssh-keygen -t rsa 
+This is what ssh-keygen(1) is for.  
+<verbatim>  
+ssh-keygen -t dsa  
+# or  
+ssh-keygen -t rsa  
+</verbatim>  
+(DSA keys are probably preferable to RSA keys.)  
  
 !!! Distributing public keys 
  
-If you accepted the defaults for ssh-keygen(1) you should have two new files in ~/.ssh, __id_dsa__ and __id_dsa.pub__ (or rsa.. )%%% 
+If you accepted the defaults for ssh-keygen(1) you should have two new files in ~/.ssh, __id_dsa__ and __id_dsa.pub__ (or id_ rsa and id_dsa .pub )%%% 
 The .pub file is your public key, you need to upload it to all remote hosts that you want to use Keys with.%%% 
-You need a __.ssh__ directory in your home on the remote machine. This directory must not have permissions set to more than 700. Depending on whether you're using SSH1 or SSH2, keys go into __.ssh/authorized_keys__ or __ .ssh/authorized_keys2__ , respectively (rename the file), which must have its permissions set to no more than __0600 __. Obviously the directoriy and these files must be owned by the user they belong to . If the permissions are wrong, [SSH] will refuse to read them (without telling you, unfortunately - it only cries to syslogd(8)). [Debian] provides a ssh-copy-id(1) program which does all this automagically. Just say 
+You need a __.ssh__ directory in your home on the remote machine. This directory must not be group or world writable. Keys go into the __.ssh/authorized_keys__ file, which must also not be group or world writable .  
+One any local machine that you wish to ssh *from* , you must have the private key __id _dsa __ (unless you forward an "ssh agent", discussed below) and it must not be readable by anyone other than the owner .  
+ Obviously the directory and these files must be owned by the correct user. If the permissions are wrong, [SSH] will refuse to read them (without telling you, unfortunately - it only cries to syslogd(8)). [Debian] provides a ssh-copy-id(1) program which does all this automagically. Just say 
  
  ssh-copy-id ''hostname'' 
  
 !!! Key Security Options 
@@ -72,96 +76,97 @@
  
 !!SSH Agent, Deluxe Ultra Series 
  
 There is an elegant way to combine these methods independently of whether your window manager provides a facility for autoexecuting commands at launch. Using the __exec__ command, the shell can replace itself with a new ssh-agent(1) instance if it cannot detect an existing agent. The new agent then immediately spawns a new shell to re-execute the script, which now successfully detects the agent and continues to do its actual work. In practice, your __.xinitrc__ or __.xsession__ might look something like this: 
-  
- #!/bin/bash  
- # check if there's no agent already  
- if [ [ -x /usr/bin/ssh-agent -a -z "$SSH_AUTH_SOCK" ] ; then  
- exec /usr/bin/ssh-agent $  
- fi  
- #  
- # the usual .xinitrc mumbo jumbo goes here  
- #  
- /usr/bin/ssh-add < /dev/null &  
- exec /usr/X11R6/bin/twm  
- 
+<verbatim>  
+#!/bin/bash  
+# check if there's no agent already  
+if [ -x /usr/bin/ssh-agent -a -z "$SSH_AUTH_SOCK" ] ; then  
+ exec /usr/bin/ssh-agent $  
+fi  
+#  
+# the usual .xinitrc mumbo jumbo goes here  
+#  
+/usr/bin/ssh-add < /dev/null &  
+exec /usr/X11R6/bin/twm  
+</verbatim>  
 You can easily do something similar if you use CommandLine only systems; in that case, your __.bash_profile__ might look like this: 
-  
- #!/bin/bash -x  
- # check if there's no agent already  
- if [ [ -x /usr/bin/ssh-agent -a -z "$SSH_AUTH_SOCK" ] ; then 
+<verbatim>  
+#!/bin/bash -x  
+# check if there's no agent already  
+if [ -x /usr/bin/ssh-agent -a -z "$SSH_AUTH_SOCK" ] ; then 
  exec /usr/bin/ssh-agent sh -c "exec -a '$0' -- $SHELL" 
- fi  
- #  
- # usual .bash_profile mumbo jumbo goes here  
- #  
- # add keys unless we've already done so  
- if [ [ -x /usr/bin/ssh-add ] && ! ssh-add -l &> /dev/null ; then 
+fi  
+#  
+# usual .bash_profile mumbo jumbo goes here  
+#  
+# add keys unless we've already done so  
+if [ -x /usr/bin/ssh-add ] && ! ssh-add -l &> /dev/null ; then 
  /usr/bin/ssh-add 
- fi  
- 
+fi  
+</verbatim>  
 The check for existing keys was added here because in contrast to your __.xinitrc__, __.bash_profile__ is typically executed quite frequently - f.ex, for every xterm(1) you open. 
  
 Under Debian 3.0 (woody), and possibly others, ssh-agent is normally set up to run like this anyway. If you use one of the standard session options, it all works fine. However, if (as in my case) you run a custom setup (ie, have a heavily modified __.xsession__ file), then the ssh-agent either doesn't get called for some reason, or it dies early. Using the above script should solve this. 
  
 Page 144 of "[Linux Server Hacks|http://library.wlug.org.nz/show.pl?id=1]" by O'Reilly shows another, more convenient but less secure variant on the way to run an agent (page 144). The above script doesn't provide an immediate way to pass the agent information between virtual consoles, so you'll usually spawn a new agent for each of them and so have to enter the credentials once for each. The script shown below is more convenient in that a single agent running will suffice, but there's no automatic mechanism for terminating agents, so it will hang around indefinitely. If you are not concerned about this and want more comfort, see below: 
+<verbatim>  
+# the `hostname` part is there so that this script can be run from the same home  
+# NFS-mounted on different machines without them clobbering each other's settings  
+AGENTFILE=~/.agent.`hostname`.env  
  
- # the `hostname` part is there so that this script can be run from the same home  
- # NFS-mounted on different machines without them clobbering each other's settings  
- AGENTFILE=~/.agent.`hostname`.env  
-  
- # don't do anything if there's already an agent, such as when  
- # logging into this machine with agent forwarding enabled on the remote end  
- if [ [ -z "$SSH_AUTH_SOCK" ]; then  
-  
- # have settings?  
- if [[ -f $AGENTFILE ]; then 
+# don't do anything if there's already an agent, such as when  
+# logging into this machine with agent forwarding enabled on the remote end  
+if [ -z "$SSH_AUTH_SOCK" ]; then 
  
- # load them  
- . $AGENTFILE > /dev/null  
+ # have settings?  
+ if [ -f $AGENTFILE ]; then  
  
- # make sure they're not invalid  
- if [[ ! kill -0 $SSH_AGENT_PID > /dev/null 2> ]; then  
- echo "Stale agent file found. Spawning new agent..."  
- eval `ssh-agent | tee $AGENTFILE`  
- ssh-add  
- fi  
- else  
- # no existing settings found, start new agent and save them  
- echo "Starting ssh-agent..."  
- eval `ssh-agent | tee $AGENTFILE`  
- ssh-add  
- fi  
- fi  
+ # load them  
+ . $AGENTFILE > /dev/null 
  
+ # make sure they're not invalid  
+ if [ ! kill -0 $SSH_AGENT_PID > /dev/null 2> ]; then  
+ echo "Stale agent file found. Spawning new agent..."  
+ eval `ssh-agent | tee $AGENTFILE`  
+ ssh-add  
+ fi  
+ else  
+ # no existing settings found, start new agent and save them  
+ echo "Starting ssh-agent..."  
+ eval `ssh-agent | tee $AGENTFILE`  
+ ssh-add  
+ fi  
+fi  
+</verbatim>  
 ''In fact, it should easily be possible to merge these methods such that you get the benefits of both. I need to mull over the best way to do this.'' --AristotlePagaltzis 
  
 !!Removing keys when you're not around. 
  
 If you're a paranoid ol' bugger like me, and leave your machine logged in most of the time, but don't want to leave your keys freely accessible to everyone while you're away from the computer, here's a simple script that sniffs when the screensaver runs, and removes all your keys, and, when the screensaver is dismissed it prompts you for your keys again: 
- #!/bin/bash 
+<verbatim>  
+ #!/bin/bash 
  
- KEYS="id_dsa id_rsa identity insecure sourceforge" 
+KEYS="id_dsa id_rsa identity insecure sourceforge" 
  
- delete_all_keys() {  
- ssh-add -D  
-
+delete_all_keys() {  
+ ssh-add -D  
+
  
- add_all_keys() {  
- local OK_KEYS  
- unset OK_KEYS  
- for i in $KEYS; do  
- [ [ -r ~/.ssh/$i ] && OK_KEYS="$OK_KEYS /home/$USER/.ssh/$i"  
- done  
- echo Adding keys...  
- ssh-add $OK_KEYS  
- echo done  
-
+add_all_keys() {  
+ local OK_KEYS  
+ unset OK_KEYS  
+ for i in $KEYS; do  
+ [ -r ~/.ssh/$i ] && OK_KEYS="$OK_KEYS /home/$USER/.ssh/$i"  
+ done  
+ echo Adding keys...  
+ ssh-add $OK_KEYS  
+ echo done  
+
  
- exec xscreensaver-command -watch | while read command arg; do  
- case $command in  
- LOCK) 
+exec xscreensaver-command -watch | while read command arg; do  
+ case $command in  
+ LOCK) 
  delete_all_keys 
  ;; 
  UNBLANK) 
  add_all_keys 
@@ -174,11 +179,11 @@
  ;; 
  *) 
  echo Unknown command: $command 
  echo " with arg: $arg" 
- esac  
- done  
- 
+ esac  
+done  
+</verbatim>  
 Place this script somewhere in your PATH (eg. $HOME/bin/screenwatch) then start it from either your .xsession or your session manager (Gnome, KDE etc) with ''x-terminal-emulator -e "$HOME/bin/screenwatch"'' 
  
 !!Agent Connection Forwarding