INTL 3:770/1 3:770/3   
   REPLYADDR theom+news@chiark.greenend.org.uk   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  8a6650b2   
   REPLY:  7587ca27   
   PID: SoupGate-Win32 v1.05   
   Chris Green  wrote:   
   > Theo  wrote:   
   > > Chris Green  wrote:   
   > > If the keylogger is on your machine, it can get the passphrase but it   
   > > doesn't get the private key unless it is specifically designed for   
   attacking   
   > > ssh and can read your private keys.  eg you might see the following in the   
   > > keylog:   
   > >   
   > > ssh chris@server.bigcorp.com   
   > > abr@cad4bra   
   > > ls   
   > >   
   > > and it's clear that abr@cad4bra is your password.  If that was your   
   > > passphrase it wouldn't help attack anyone.   
   > >   
   > Not true, you're advocating separate keys for each remote and not   
   > keeping thenm in an agent so login isn't 'passwordless' or automatic.   
      
   I wasn't advocating that.  The agent's purpose is so you only have to type   
   the passphrase once per session - if that makes keys easier to use and maybe   
   helps you have a stronger passphrase (since you don't need to type it so   
   often), then why not?   
      
   There may be some threat models where you don't want your machine holding   
   unlocked keys in RAM, in which case fair enough and you need to type the   
   passphrase each time, but for many use cases ssh-agent (and its integration   
   into things like KDE KWallet or MacOS keychain) is fine.   
      
   > Thus, when I login I see:-   
   >   
   >     chris@esprimo$ ssh backup   
   >     Enter passphrase for key '/home/chris/.ssh/backup_id_rsa':   
   >     chris@backup$   
   >   
   > ... the keylogger will see 'ssh backup' followed by the passphrase.   
      
   If the keylogger is running locally, stealing the passphrase from a key   
   won't help the attacker because they don't have the private key.   
      
   If the keylogger in an infected SSH daemon on the server (which is where SSH   
   passwords are typically harvested) it will see parts of the public key   
   exchange but it doesn't see your passphrase or private key and the protocol   
   is designed so you can't replay what it does see.  If it has passwords it   
   can replay them on other sites.   
      
   > > etckeeper will keep track of changes to /etc in a git repo   
   > >   
   > I use Mercurial.   
      
   etckeeper supports that too.   
      
   > > If you want to do this to a lot of machines, it's worth learning Ansible as   
   > > it'll keep your fleet of machines in sync.  Just write an ansible recipe   
   > > and it will ensure it is applied (and only once) across all your   
   > > machines.   
   > >   
   > I may take a look, though I already have a common Mercurial repository   
   > where I keep everything like .bashrc, .profile, .ssh/config and so on.   
   > The Mercurial repository is shared across systems using syncthing.   
      
   I suppose you could push/pull your etckeeper repo to keep your /etc in sync,   
   but probably not ideal since things like hostnames will be different between   
   machines.  Ansible is a better bet.   
      
   Theo   
      
   --- SoupGate-Win32 v1.05   
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)   
   SEEN-BY: 10/0 1 15/0 90/1 103/705 105/81 106/201 128/260 129/305 135/225   
   SEEN-BY: 153/757 7715 218/0 1 601 700 840 870 930 220/70 221/1 6 226/17   
   SEEN-BY: 226/30 100 227/114 229/110 112 113 200 206 307 317 400 426   
   SEEN-BY: 229/428 470 550 616 664 700 240/1120 266/512 267/800 282/1038   
   SEEN-BY: 291/111 292/854 301/1 113 812 310/31 320/219 322/757 335/364   
   SEEN-BY: 341/66 342/200 396/45 460/58 633/280 712/848 770/1 3 100   
   SEEN-BY: 770/330 340 772/210 220 230 5020/400 1042 5058/104 5075/35   
   PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426