[ssh] public key in geheugen?

[shadax]

Ik wil voor een crontab zorgen dat ik zonder password kan inloggen op een ander systeem. Ik heb inmiddels een public en private key, maar krijg het niet voor elkaar om de public key in het geheugen te houden, zodat ik m'n passphrase niet in hoef te voeren. Binnen 1 sessie gaat alles goed, maar als ik opnieuw inlog werkt het niet meer.

Het script om de agent te laden is:

code:

#!/bin/bash
# Creates an ssh-agent, writes ssh agent info
# to the file '~/.ssh-agent-info' and then prompts
# user for keys.  Then any shell can use the agent
# by sourcing the contents of ~/.ssh-agent-info:
#  . ~/ssh-agent-info

ssh-agent >~/.ssh-agent-info
chmod 600 .ssh-agent-info
. .ssh-agent-info
for i in identity
do
    ssh-add .ssh/$i
done
echo "Don't forget to '. .ssh-agent-info'"

Als ik opnieuw inlog, dan draait ssh-agent wel volgens ps aux, maar ssh-add -l geeft:
Could not open a connection to your authentication agent.

[ACM]

Waarom niet gewoon een public/private key combo maken
(man ssh, man sshd, man ssh-keygen)

[shadax]

Ik heb een public/private key combo. Public key staat ook op het remote systeem, maar om de key te gebruiken heb je toch altijd een passphrase nodig?

[ACM]

Neehoor, gewoon op enter drukken als ie daar om vraagt

[shadax]

Hoe veilig is dat, want in de handleiding die ik gebruikte stond: "Don't create an empty passphrase!"

[ACM]

Op dinsdag 11 juni 2002 10:25 schreef shadax het volgende:
Hoe veilig is dat, want in de handleiding die ik gebruikte stond: "Don't create an empty passphrase!"

Net zo onveilig als default je pass in de ssh-agent te laten zitten

Iemand kan daar net zo goed, na ingelogd te zijn, zonder problemen mee connecten als met je passless-key.

[Verwijderd]

Okee, je scriptje werkt dus blijkbaar niet :-).

Er is een pakketje dat doet wat jij wil: http://www.gentoo.org/projects/keychain.html. Voordat die er was had ik zelf al zoiets gemaakt maar dan veel eenvoudiger, voor mij werkt het (en ik vind het een stuk compacter en mooier zonder al die kleurtjes van keychain). Ik vermoed echter dat keychain wel wat meer kan dan mijn paar regels (die je met aliasen moet gebruiken).

Toch nog even mijn scriptje:

code:

SSH_AGENT_VARS="$HOME/.ssh/ssh-agent-vars"

. $SSH_AGENT_VARS 2> /dev/null 1> /dev/null

# test for empty variables and if $SSH_AUTH_SOCK exists
if [ -z X${SSH_AGENT_PID} -o -z X${SSH_AUTH_SOCK} -o ! -e ${SSH_AUTH_SOCK} ]; then
      eval `ssh-agent -s | tee $SSH_AGENT_VARS` 1> /dev/null;
      echo "starting new ssh-agent (pid $SSH_AGENT_PID), no identities";
else
      echo "using existing ssh-agent (pid$ SSH_AGENT_PID), identities:";
      ssh-add -l | cut -f 3-4 -d ' '
fi

Dit heb ik in een ~/bin/setssh-agent staan die ik uitvoer m.b.v. een alias setssha die `. ~/bin/setssh-agent' uitvoert (beetje ranzig waarschijnlijk, maar het werkt al te lang goed om het te 'fixen').

[Verwijderd]

Op dinsdag 11 juni 2002 10:27 schreef ACM het volgende:

[..]

Net zo onveilig als default je pass in de ssh-agent te laten zitten

Iemand kan daar net zo goed, na ingelogd te zijn, zonder problemen mee connecten als met je passless-key.

Het lijkt me toch minder schadelijk (hoewel ook schadelijk) als anderen tijdelijk toegang hebben tot je ssh-agent dan dat ze je complete private key hebben. Met die ssh-agent kunnen ze alleen inloggen zolang die bestaat (meen ik), met die private key kunnen ze altijd inloggen op computers die jouw public key hebben. Het is in ieder geval moeilijker (als mogelijk) om van een draaiende ssh-agent de private key te achterhalen dan van een niet versleuteld bestand.

Verder is zo'n script dus gewoon makkelijker dan steeds op enter drukken. :-)