# Problem setting up SSHD [SOLVED]

## eXess

Hi all, 

I recently decided to change setup on sshd on my server. I added AllowRootLogin = no to the config and I am trying to use DSA keys to get things strainght. I already have generated a keys pair. As I'm using Mac OS X on my workstation, the syntax is quite identical to what you find on linux. So, the keys are in ~/.ssh/ in my home directory :

```
$ ls -al

total 32

drwx------   5 xs  xs   170 27 Feb 13:05 .

drwxr-xr-x  24 xs  xs   816 29 Mar 17:07 ..

-rw-------   1 xs  xs   736 27 Feb 13:05 id_dsa

-rw-r--r--   1 xs  xs   603 27 Feb 13:05 id_dsa.pub

-rw-r--r--   1 xs  xs  4196 17 Apr 13:39 known_hosts
```

The id_dsa.pub key looks like this :

```
ssh-dss AAAAB3NzaC1kc3MAAACBAJ (...) jjctvB7JHg1tdKs= xs@g4xs.local
```

xs being my local account and g4xs being the workstation name. Actually I use this key pair for identification on Sourceforge CVS server. Seems to work quite fine in that case. I have copied the id_dsa.pub key to /home/xspirlet/.ssh/authorized_keys (xspirlet being the account with which I intend to log in on the server). 

When logging in via ssh, I still get a password challenge :

```
$ ssh 192.168.1.14 -l xspirlet

Password:
```

If I add ChallengeResponseAuthentication no to sshd config (and restart), I don't get a password challenge, but it doesn't work either :

```
$ ssh 192.168.1.14 -l xspirlet

Permission denied (publickey).
```

 :Sad: 

Anyone knows how I could fix this?

----------

## ekutay

Start your connection try in verbose mode, to see what the sshd is saying regarding your ssh-key. A common problem is, pasting the key into the authorized_keys file with CR's. 

```
ssh -v yourhost.here
```

 and check for line breaks in the authorized_keys file

----------

## moocha

Don't yell at me for asking, but are you sure that your sshd_config contains

```
PubkeyAuthentication yes
```

? Perhaps it's commented out...

----------

## eXess

```
$ ssh -v 192.168.1.14

OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

debug1: Reading configuration data /etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: Connecting to 192.168.1.14 [192.168.1.14] port 22.

debug1: Connection established.

debug1: identity file /Users/xs/.ssh/identity type -1

debug1: identity file /Users/xs/.ssh/id_rsa type -1

debug1: identity file /Users/xs/.ssh/id_dsa type 2

debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1

debug1: match: OpenSSH_3.9p1 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2004-0175

debug1: Miscellaneous failure

No credentials cache found

debug1: Miscellaneous failure

No credentials cache found

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host '192.168.1.14' is known and matches the RSA host key.

debug1: Found key in /Users/xs/.ssh/known_hosts:1

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /Users/xs/.ssh/identity

debug1: Trying private key: /Users/xs/.ssh/id_rsa

debug1: Offering public key: /Users/xs/.ssh/id_dsa

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Next authentication method: keyboard-interactive
```

And PubkeyAuthentication yes (was worth trying anyway, sometimes it's the simplest things...) And no, there are positively no line breaks in the authorized_keys file... Obviously the "No credentials cache found" must mean something... Except I don't know what  :Smile: 

----------

## ekutay

Hmm, the credentials cache I just know from kerberos installations, thus I do not know what it means in this context. You sshd does not do kerboeros stuff. All I can see is that the server does not like / accept your keys. 

If you cannot find any hints in the sshd log or using ssh -vv (being more verbose, to find out about the credentials cache) I'm out off ideas. You could start the sshd in debug mode too.

Anybody else?

[edit]googled around - all people having this credentials cache statement (not using kerberos) are apparently be mac users. hints were all strange, like reboot or moving your configuration files ...[/edit]

----------

## moocha

Try commenting out or turning off the GSSAPI options. Seems it's related to that.

Also make sure that /var/empty exists, is a directory, is owned by root:root with 0755 permissions, and only contains one file named .keep (and make sure to stop the ssh server before checking).

----------

## eXess

moocha: Checked all you told, dir/file is ok (including owner and perms) but changing the GSSAPI options gives me this : 

```
# /etc/init.d/sshd restart

 * Stopping sshd...                                                                         [ ok ]

 * Starting sshd...

/etc/ssh/sshd_config line 68: Unsupported option GSSAPIAuthentication

/etc/ssh/sshd_config line 69: Unsupported option GSSAPICleanupCredentials                   [ ok ]
```

And it doesn't change anything, I still got the same problem. I reverted my config as it doesn't seem like being quite this we're looking for... 

ekutay: I did the same as you and found the same results :s I'll try to use some of these recipes. The problem is that I found much more related to the use of the SSHD server on the Mac, not much about logging in from the mac to sth else... Deactivating sshd on my Mac workstation didn't change anything. 

Here is the "very verbose" output from the ssh command. I'll try to look for Mac-specific problems around here... 

```
$ ssh xspirlet@192.168.1.14 -vv

OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

debug1: Reading configuration data /etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug2: ssh_connect: needpriv 0

debug1: Connecting to 192.168.1.14 [192.168.1.14] port 22.

debug1: Connection established.

debug1: identity file /Users/xs/.ssh/identity type -1

debug1: identity file /Users/xs/.ssh/id_rsa type -1

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug2: key_type_from_name: unknown key type 'Proc-Type:'

debug2: key_type_from_name: unknown key type 'DEK-Info:'

debug2: key_type_from_name: unknown key type '-----END'

debug1: identity file /Users/xs/.ssh/id_dsa type 2

debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1

debug1: match: OpenSSH_3.9p1 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2004-0175

debug1: Miscellaneous failure

No credentials cache found

debug1: Miscellaneous failure

No credentials cache found

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: reserved 0 

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se, aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se, aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: reserved 0 

debug2: mac_init: found hmac-md5

debug1: kex: server->client aes128-cbc hmac-md5 none

debug2: mac_init: found hmac-md5

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 129/256

debug2: bits set: 1008/2048

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host '192.168.1.14' is known and matches the RSA host key.

debug1: Found key in /Users/xs/.ssh/known_hosts:1

debug2: bits set: 1025/2048

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /Users/xs/.ssh/identity

debug1: Trying private key: /Users/xs/.ssh/id_rsa

debug1: Offering public key: /Users/xs/.ssh/id_dsa

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,keyboard-interactive

debug2: we did not send a packet, disable method

debug1: Next authentication method: keyboard-interactive

debug2: userauth_kbdint

debug2: we sent a keyboard-interactive packet, wait for reply

debug2: input_userauth_info_req

debug2: input_userauth_info_req: num_prompts 1

Password:
```

EDIT:  Added spaces to a few lines for line wrapping.  --pjp

----------

## ekutay

hm, really strange.

what makes me wonder are the lines *Quote:*   

> debug1: Offering public key: /Users/xs/.ssh/id_dsa
> 
> debug2: we sent a publickey packet, wait for reply
> 
> debug1: Authentications that can continue: publickey,keyboard-interactive
> ...

 

has your client sent the publickey packet or not ....

have you checked the server side log files?

Regards

----------

## ekutay

This is a correct behaviour *Quote:*   

> debug2: key: .ssh/id_thornhammer (0x8097270)
> 
> debug2: key: .ssh/id_thrall (0x8099a88)
> 
> debug2: key: /home/erol/.ssh/id_rsa ((nil))
> ...

 

The server has to send a accept back to the client. 

Please check on 192.168.1.14 the /var/log/sshd/current or where ever your sshd logfiles are.

Maybe restart your sshd with -d on startup to enable debug mode.

----------

## eXess

 *ekutay wrote:*   

> has your client sent the publickey packet or not ....
> 
> have you checked the server side log files?

 

I guess the public key was sent, but maybe the wrong key? If I desable challenge authentication, here is what I get in the verbose output:

```
$ ssh xspirlet@192.168.1.14 -v

OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

debug1: Reading configuration data /etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: Connecting to 192.168.1.14 [192.168.1.14] port 22.

debug1: Connection established.

debug1: identity file /Users/xs/.ssh/identity type -1

debug1: identity file /Users/xs/.ssh/id_rsa type -1

debug1: identity file /Users/xs/.ssh/id_dsa type 2

debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1

debug1: match: OpenSSH_3.9p1 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2004-0175

debug1: Miscellaneous failure

No credentials cache found

debug1: Miscellaneous failure

No credentials cache found

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host '192.168.1.14' is known and matches the RSA host key.

debug1: Found key in /Users/xs/.ssh/known_hosts:1

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /Users/xs/.ssh/identity

debug1: Trying private key: /Users/xs/.ssh/id_rsa

debug1: Offering public key: /Users/xs/.ssh/id_dsa

debug1: Authentications that can continue: publickey

debug1: No more authentication methods to try.

Permission denied (publickey).

debug1: Calling cleanup 0x1c540(0x0)
```

I'm wondering... Shouldn't the Mac offer the id_dsa.pub key? Or is it implied and the .pub suffix is not placed there? Erm... Anyway, I had a look at the log file (unfortunately it's in /var/log/messages -- no idea how I can put it to separate log file?) and it contains strictly nothing interesting (not even the failed connections notice :s )...

----------

## eXess

I tried to edit ssh_config on my workstation and added this :

```
   HostbasedAuthentication yes

   IdentityFile ~/.ssh/id_dsa

   Protocol 2  
```

But it didn't change anything. This is becoming quite problematic...

----------

## ekutay

For instance with 

```
SyslogFacility AUTH
```

 there should be an additional auth logfile. You can also specify the log level to something more paranoid 

```
LogLevel DEBUG2
```

 but don't forget to deactivate this afterwards, as it is really verbose, in other words it logs almost everything..  :Twisted Evil: 

The tweaks in ssh_config you paste better in your home directory, eg. ~/.ssh/config

 *Quote:*   

> HOST=fire
> 
> HOSTNAME=192.168.1.14
> 
> IdentityFile ~/.ssh/id_dsa
> ...

 

you can now connect using 

```
ssh -vv fire 
```

 in your previous example you have pasted you have connected only with one -v  :Wink: 

----------

## eXess

Don't worry about the location of the tweaks on the Mac  :Wink:  I used SyslogFacility AUTH and restarted sshd, but err... what should it change for me?  :Embarassed:  sorry but I don't know enough about logging... Then again, what should I see in my logs that I wouldn't see in the output of the ssh -vv command? And yes, I posted -v, but you've got the -vv dump earlier in this post, and it doesn't show much more... 

If only I could know where the problem lies... In the Mac, in the server, in config files (on either side) ? ...

----------

## ekutay

the log files are the files generated on the server side of things.

the ssh -vv enables you to see some responses from the server side too, though this is still the client side of things. I think it could help to trace the problem down to, if we can see what the server says regarding the offered keys. okay, maybe I do not know enough of OS X configuration, but enabling the auth log should provide a new log location or at least a new prefix in the log file. you could leave the SyslogFacility as it was, but enable verbose logging (DEBUG2) and watch messages.

P.S.

regarding the v versus vv:

 *Quote:*   

> I guess the public key was sent, but maybe the wrong key? If I desable challenge authentication, here is what I get in the verbose output: 

  the following output does not show any debug2 statements....

----------

## eXess

What an ass I am !!! 

.ssh dir (on server) was owned by root ! I just chmod'd to user:usergroup and now it works ! However I still have one little question regarding passphrase. My keys (DSA) were generated using a passphrase. Do I always have to provide it when logging or may I find a trick to avoid this? Here is the transcript from a -vv successful login :

```
$ ssh xspirlet@192.168.1.14 -vv

OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

debug1: Reading configuration data /etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug2: ssh_connect: needpriv 0

debug1: Connecting to 192.168.1.14 [192.168.1.14] port 22.

debug1: Connection established.

debug1: identity file /Users/xs/.ssh/id_rsa type -1

debug2: key_type_from_name: unknown key type '-----BEGIN'

debug2: key_type_from_name: unknown key type 'Proc-Type:'

debug2: key_type_from_name: unknown key type 'DEK-Info:'

debug2: key_type_from_name: unknown key type '-----END'

debug1: identity file /Users/xs/.ssh/id_dsa type 2

debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1

debug1: match: OpenSSH_3.9p1 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2004-0175

debug1: Miscellaneous failure

No credentials cache found

debug1: Miscellaneous failure

No credentials cache found

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: reserved 0 

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se, aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se, aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: reserved 0 

debug2: mac_init: found hmac-md5

debug1: kex: server->client aes128-cbc hmac-md5 none

debug2: mac_init: found hmac-md5

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 122/256

debug2: bits set: 1000/2048

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host '192.168.1.14' is known and matches the RSA host key.

debug1: Found key in /Users/xs/.ssh/known_hosts:1

debug2: bits set: 1044/2048

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /Users/xs/.ssh/id_rsa

debug1: Offering public key: /Users/xs/.ssh/id_dsa

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: pkalg ssh-dss blen 434 lastkey 0x306f70 hint 1

debug2: input_userauth_pk_ok: fp 25:64:62:1b:78:5e:fc:42:ca:8f:1f:b6:e1:da:4a:f7

debug1: PEM_read_PrivateKey failed

debug1: read PEM private key done: type <unknown>

Enter passphrase for key '/Users/xs/.ssh/id_dsa':
```

NB: I turned logging DEBUG on, but as it works, I just stopped it... If it's ever needed again, it's no problem...

EDIT:  Added spaces to a few lines for line wrapping.  --pjp

----------

## ekutay

Either you use no passphrase when generating the key pair, but I would not recommend it, or use an ssh-agent, which is the weapon of choice ...

----------

## eXess

Right. And now I can "officially" recommend SSHkeychain as a very robust and transparent ssh-agent for Mac OS X. And now I'll officially deal with putty.exe, which is really a problem. 

Thanks a real huge lot to all of you for your time and patience ![/url]

----------

## ekutay

I'm just working on my Tux's lil' helper  :Smile: 

Btw.: Putty has also an ssh-agent, which name I cannot memorize right now. 

You could add an resolved to the title, if everything is fine now.  :Wink: 

----------

## eXess

Done. 

Putty in itself is an excellent piece of software and is downloadable here :

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

You can also use PuttyGen for generating key pairs and Pageant as an SSH-agent. Though I'm having trouble setting up all this right now, but it doesn't mean that it's the computer's fault!  :Wink: 

----------

