# ssh without password?

## stan_laurel

Hi!

I want to login from my local machine where i am user xxx to another machine as a user yyy.

This could be done the following way:

```

xxx@milhouse / $ssh -l yyy bla.blup.com

yyy@bla.blup.com's password:

```

How can i set it up that i dont have to enter a password ?

is this impossible since the users are different ?

another question - how can i setup ssh-agent that it is started when i login ?

PLease help me!

(... and forgive me for my awfull english  :Wink:  )

stan

----------

## n0n

What you need to do is generate a public key on your box.  Then send that public key over to the box that you want to transfer files to, and stick it in the user's ~/.ssh/authorized_hosts file.  If you don't want any password at all, then make sure that the public key you've created isn't password-protected (this should go without saying, I suppose).  So when you're asked for a password during the key creation, just hit Enter.

There's actually some pretty good information about this on sourceforge.net, although obviously the procedure for uploading the keys to sourceforge.net don't apply.

----------

## kyron

Yu will need to incorporate the public key (of the destination machine) into your ~/.ssh/ directory (known_hosts or something like that...) ... the details of the procedure eludes me for the moment (did i a long time ago) and it does work well...though I did it for the root user, don't know if it works for use on other users though....

The procedure can be a bit*h but it canbe done...

Here is a link that might help you:

http://astrophysics.phys.cmu.edu/pipermail/problems/2001-December/000308.html

Found this by performing the following search on google.com 

(search for: ssh autologin public key)

: 

[url]http://www.google.com/search?num=100&hl=en&lr=lang_en|lang_fr&ie=UTF-8&oe=UTF-8&q=ssh+autologin+public+key&spell=1[/url]

----------

## rizzo

Using openssh, I believe the file is called "authorized_keys", not hosts.  Plus you should only use ssh protocol 2, and then the file will be called "authorized_keys2".

----------

## n0n

 *rizzo wrote:*   

> Using openssh, I believe the file is called "authorized_keys", not hosts.

 

Whoops!  Yeah, it's authorized_keys . . .

 *rizzo wrote:*   

> Plus you should only use ssh protocol 2, and then the file will be called "authorized_keys2".

 

I'm using version 2 and plain old authorized_keys works for me.

----------

## klieber

 *stan_laurel wrote:*   

> How can i set it up that i dont have to enter a password ?

 

All your questions and more will be answered in drobbins' three part series on OpenSSH key management.  Truly a must-read for anyone using SSH to any large degree.

Part 1: http://www-106.ibm.com/developerworks/linux/library/l-keyc.html

Part 2: http://www-106.ibm.com/developerworks/linux/library/l-keyc2/

Part 3: http://www-106.ibm.com/developerworks/linux/library/l-keyc3/

 *stan_laurel wrote:*   

> another question - how can i setup ssh-agent that it is started when i login ?

 

Use keychain which is a must-have tool for anyone using SSH to any large degree.  :Smile:   Its usage is discussed in part 2 of the series of articles I mentioned above.

--kurt

----------

## rac

 *n0n wrote:*   

> 
> 
>  *rizzo wrote:*   Plus you should only use ssh protocol 2, and then the file will be called "authorized_keys2". 
> 
> I'm using version 2 and plain old authorized_keys works for me.

 

Yeah.  authorized_keys2 was a temporary kludge that was needed for a few versions, but the key file has been reunited, and you can use authorized_keys for all keys now.

----------

## rizzo

 *rac wrote:*   

> Yeah.  authorized_keys2 was a temporary kludge that was needed for a few versions, but the key file has been reunited, and you can use authorized_keys for all keys now.

 

Well, I did not know that.  Thanks.

----------

## stan_laurel

Thanks for your help!

Everything works fine now - I am using keychain.

But there is a small problem left: man keychain says:

 *Quote:*   

> 
> 
> Typically, one uses keychain by adding the following to the top of their
> 
>  ~/.bash_profile .....
> ...

 

But as far as i know ~/.bash_profile is only executed when using a login shell. In my case i want to use keychain for every shell on my kde desktop. Where should i place keychain ?

stan

----------

## n0n

 *stan_laurel wrote:*   

> In my case i want to use keychain for every shell on my kde desktop. Where should i place keychain ?

 

You could always change the shortcut to have each shell be a login shell (though I'm not familiar enough with konsole to figure out what the exact syntax would be).  The xterm option "-ls" is what does that for me . . .

----------

## fireboy1919

Aren't they all login shells?

They've recently modified keychain.  I've found that placing this in my .bashrc works well:

keychain ~/.ssh/id_dsa ~/.ssh/identity ~/.ssh/id_rsa

source ~/.keychain/$HOSTNAME-sh > /dev/null

----------

## n0n

 *fireboy1919 wrote:*   

> Aren't they all login shells?

 

Typically not, in my experience anyway.

----------

## discostu

I can't get it to work. It still prompts me for a password after following the instructions on both the sourceforge link above and this link http://www.linuxgazette.com/issue67/nazario2.html. Any ideas?

```
$ ssh-keygen -t dsa -C "disc0stu@shell.sf.net"

$ scp .ssh/id_dsa.pub disc0stu@shell.sf.net:.ssh/

$ ssh-agent /bin/bash

$ ssh-add

$ ssh -l disc0stu shell.sf.net

password:

```

Thanks,

Stu

----------

## klieber

 *discostu wrote:*   

> I can't get it to work. It still prompts me for a password after following the instructions on both the sourceforge link above and this link http://www.linuxgazette.com/issue67/nazario2.html. Any ideas?

 

Check the permissions on ~/.ssh/id_dsa on the local machine and ~/ on the remote machine.  SSH won't authorize you if your perms are too loose on your private key (go+w, iirc) and/or if the permissions on your home directory on the remote machine are too loose.

Use ssh -v to get more useful debugging output.  ssh -vv to get even more.

--kurt

----------

## discostu

When I did the ssh-keygen it made a file called id_dsa and id_dsa.pub. I uploaded id_dsa.pub to sourceforge in .ssh directory. Then I used ssh-add to add id_dsa.

Here is the output from using -vv:

```
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to shell.sf.net [66.35.250.208] port 22.

debug1: Connection established.

debug1: identity file /home/stuart/.ssh/identity type -1

debug1: identity file /home/stuart/.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 /home/stuart/.ssh/id_dsa type 2

debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1

debug1: match: OpenSSH_3.5p1 pat OpenSSH_3.2*,OpenSSH_3.3*,OpenSSH_3.4*,OpenSSH_3.5*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.7.1p2

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,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: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: 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: 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: 138/256

debug2: bits set: 1574/3191

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'shell.sf.net' is known and matches the DSA host key.

debug1: Found key in /home/stuart/.ssh/known_hosts:11

debug2: bits set: 1584/3191

debug1: ssh_dss_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

debug2: key: /home/stuart/.ssh/identity ((nil))

debug2: key: /home/stuart/.ssh/id_rsa ((nil))

debug2: key: /home/stuart/.ssh/id_dsa (0x8091ef0)

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

debug1: Next authentication method: publickey

debug1: Trying private key: /home/stuart/.ssh/identity

debug1: Trying private key: /home/stuart/.ssh/id_rsa

debug1: Offering public key: /home/stuart/.ssh/id_dsa

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,password,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

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

debug2: we did not send a packet, disable method

debug1: Next authentication method: password

password:

```

Permissions on sourceforge:

```

drwx------ .ssh

-rw-r--r-- id_dsa.pub

```

My local permissions:

```

drwx------ .ssh

-rw-r--r-- authorized_keys

-rw------- id_dsa

-rw-r--r--  id_dsa.pub

-rw------- id_dsa_cvs

-rw-r--r-- id_dsa_cvs.pub

-rw-r--r-- known_hosts

```

----------

## sikpig

Disco Stu;

You also need to copy the contents of id_dsa.pub from your local machine to authorized_keys on the SF server, like so:

```
you@shell.sf.net$ cat .ssh/id_dsa.pub >> .ssh/authorized_keys
```

or re-scp it to the correct file name.

----------

## discostu

Thanks sikpig! I had put it in my local authorized_keys but not on sf's authorized keys. It worked for shell.sf.net. I also tried adding cvs.sf.net, but that didn't work.

```
you@shell.sf.net$ cat .ssh/id_dsa.pub >> .ssh/authorized_keys

you@shell.sf.net$ cat .ssh/id_dsa_cvs.pub >> .ssh/authorized_keys
```

```
$ ssh-agent /bin/bash

$ ssh-add

$ ssh-add /home/stuart/.ssh/id_dsa_cvs

```

When I try a cvs-update it asks for a password.

Thanks,

Stu

----------

## sikpig

I'm not sure how shell.sf.net and cvs.sf.net relate, ie. is it the same account, or do you just have the same userid for both systems.  If they are not the same account (same home directory), then you need to copy the authorized_keys file to cvs.sf.net.

Have you looked at this: http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1#top?

It seems that you may be able to manage your SSH keys through SF's account management site.

----------

## discostu

Cool! I had skimmed over it, but hadn't noticed that you could do it from the website. I also found that to ssh to cvs.sf.net you should use cvs1.sf.net. So now ssh to cvs1.sf.net works. However, cvs update still asks for a password.

-Stu

----------

## sikpig

Well, I'm no expert when it comes to CVS, and I have not used SourceForge the way you are, but this works for me on my CVS server (assuming that keys are already in place):

```
CVS_RSH=/usr/bin/ssh cvs -d :ext:userid@cvs.server:/home/cvsroot [checkout|update] module_name
```

Hopefully that works for you.

----------

## discostu

It seems to be working now, although I haven't done anything (it just started asking for passphrase instead of password, so I did an ssh-add and it works).  Maybe it just took a while for sf's cvs to recognize the key.

Thanks,

Stu

----------

