Of course this is not the right phrase for it. It should be something like “key-based authorization with SSH”. Or simply “publickey authorization”. Or “unattended ssh login”. But I guess you know what I mean.
Here are the steps:
- Create a public ssh key, if you haven’t one already.
Look at ~/.ssh. If you see a file named id_dsa.pub then you obviously already have a public key. If not, simply create one. ssh-keygen -t dsa should do the trick.
Please note that there are other types of keys, e.g. RSA instead of DSA. I simply recomend DSA, but keep that in mind if you run into errors.
- Make sure your
.ssh dir is 700:
chmod 700 ~/.ssh
- Get your public ssh key on the server you want to login automatically.
A simple scp ~/.ssh/id_dsa.pub remoteuser@remoteserver.com: is ok.
- Append the contents of your public key to the ~/.ssh/authorized_keys and remove it.
Important: This must be done on the server you just copied your public key to. Otherwise you wouldn’t have had to copy it on your server.
Simply issue something like cat id_dsa.pub >> .ssh/authorized_keys while at your home directory.
- Instead of steps 3 and 4, you can issue something like this:
cat ~/.ssh/id_dsa.pub | ssh -l remoteuser remoteserver.com 'cat >> ~/.ssh/authorized_keys'
- Remove your public key from the home directory on the server.
- Done!
You can now login:
ssh -l remoteuser remoteserver.com or ssh remoteuser@remoteserver.com without getting asked for a password.
That’s all you need to do.
Leave a Reply
October 18th, 2007 at 10:29 pm
On OS X, you must change the permissions of you public key in ~/.ssh to something like 600, otherwise it won’t be accepted as public key because it is too open..
October 19th, 2007 at 7:29 am
@Hendrik: I have included that. Thanks.
November 6th, 2007 at 7:36 am
Thanks for the informative post. You might like to know that your blog post shows up as the first result (as of this writing) for the search “automatic ssh login”.
I have one comment, however, you say “done” but then do NOT specify the ssh command line command to connect to the remote server using public key authorization.
Also, what happens when the username is not the same?
Ie, I’m user “joe@localhost” on my notebook, but I want to login to ssh.someserver.com as ‘johndoe’?
FC
November 6th, 2007 at 9:04 am
@Fernando: Thanks for the heads up, I have added what you asked for and hopefully clarified a bit.
December 17th, 2007 at 4:20 pm
I followed all above steps but still I am asked to select rsa fingerprints and password.
December 17th, 2007 at 8:26 pm
@Devesh: Your server needs to allow this, there are settings that can disable public key authentication.
December 22nd, 2007 at 2:50 am
In os x leopard, it is not necessary to chmod 600. I don’t really know what the details are, but it worked for me. Also, I used RSA instead of DSA because I’d already set up ssh key-based authorization with RSA (I looked up this guide because I’d forgotten what I did before).
Thanks for the clear directions!
John
January 20th, 2008 at 10:15 am
This article helped me in building automated file transfers from my test servers to deplyment servers. I could do it all without my notice, and schedule the uploads in cron. Pretty nice explanation.
But in line #5, it is better to write instead:
cat ~/.ssh/id_dsa.pub | ssh -l remoteuser remoteserver.com ‘cat >> ~/.ssh/authorized_keys’
Just, I added ~/.ssh instaed of .ssh in the last.
January 20th, 2008 at 6:37 pm
@Bimal: Thanks for your suggestion I just edited the post.
February 8th, 2008 at 6:35 pm
Hi,
You can used extraputty :
# allow win32 application to send,receive data on Telnet, SSH, RLogin and Raw protocols.
# offers TestStand steps to send,receive data on Telnet, SSH, RLogin and Raw protocols.(installed by the windows installer)
# automatic sequencing of commands.
I hope that can help you. Asebt.
February 8th, 2008 at 6:38 pm
@asebt: This post is not about SSH clients, it’s about automatic login with ssh as the title suggests.
March 10th, 2008 at 4:06 pm
The whole process is much easier if you just use:
ssh-copy-id [-i [identity_file]] [user@]machine
1. ssh-keygen -t dsa
2. ssh-copy-id user@machine
done.
May 5th, 2008 at 12:18 pm
I did the things you have told..but its still asking for password.
These are the messages i got when i do ssh -v remoteserver.com
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /users/vchk/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /users/vchk/.ssh/id_dsa
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
remoteuser@remoteserver.com’s password:
Any suggestions about this?
May 5th, 2008 at 4:28 pm
@chiru I was having that same problem, and it turned out that the permissions on my home directory on the server I was connecting to were wrong…something to look at.
May 5th, 2008 at 4:36 pm
Thanks Keith…Removing group/others write permissions for home directory did the trick
July 6th, 2008 at 5:22 pm
In my case removing group write permissions from authorized_keys fixed it
August 31st, 2008 at 10:41 am
[…] Automatically ssh into machine See here for how to do that: http://wp.uberdose.com/2006/10/16/ssh-automatic-login/ […]
April 11th, 2009 at 10:39 am
[…] Para poder utilizar esto de forma automática, sería necesario tener las llaves de SSH preparados para un login automático. […]
August 4th, 2009 at 9:08 pm
On my NAS (Qnap TS-109 Pro II) there is no file called “authorized_keys”. There are only following files:
known_hosts
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_rsa_key
ssh_host_rsa_key_pub
Does it not support key autenthication at all or how can I find out into what file I have to include my key?
August 4th, 2009 at 9:39 pm
If it doesn’t exist simply create it, non-existence doesn’t mean it’s not supported. If your login then fails it’s best to have ssh output verbose messages, that way you see what’s supported or rejected by the server.
August 17th, 2009 at 11:27 am
I did all the things you said… and even changed the permissions of the authorizedkeys file to 700 but i’m still getting prompt for password:
ssh -v osr@10.17.120.207
OpenSSH_4.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.17.120.207 [10.17.120.207] port 22.
debug1: Connection established.
debug1: identity file /users/osr/.ssh/identity type -1
debug1: identity file /users/osr/.ssh/id_rsa type -1
debug1: identity file /users/osr/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1
debug1: match: OpenSSH_4.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1
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(1024<1024<8192) 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 ‘10.17.120.207′ is known and matches the RSA host key.
debug1: Found key in /users/osr/.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/osr/.ssh/identity
debug1: Trying private key: /users/osr/.ssh/id_rsa
debug1: Offering public key: /users/osr/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
any ideas what might be the problem?
August 17th, 2009 at 5:31 pm
Haven’t looked at ssh logs for quite some time. Your server has public key authentication enabled, so the problem shouldn’t be major. Is your user directory on the server world-writable? Some commenters had problems with this. You can also use -vvv for more details.
October 8th, 2009 at 5:30 pm
This article solved my problem for Solaris 10. The directory permissions are critical for it to work.
The user’s home & .ssh directorys on the remote machine must be set to 755 at a minimum. The permissions on authorized_keys does not see to matter. I set it to 777 and it worked fine.
After these permissions are set, then just do the following:
On the client:
ssh-keygen -t dsa
copy the resulting id_dsa.pub file to the remote machine’s .ssh directory
cat id_dsa.pub >> authorized_keys
2 things can happen from here:
If you entered a “passphrase” during ssh-keygen, you must:
ssh-agent $SHELL
ssh-add
Now you can just ssh to the remote machine without being prompted for the passphrase. This process of running ssh-agent and ssh-add will need to be done in every new shell instance.
If you did NOT enter a passphrase during ssh-keygen, there is no need to run ssh-agent & ssh-add
October 22nd, 2009 at 2:12 pm
Your tip seems useful, but do you now a way to make it work with web-based ssh clients like http://electrica-ms.mures.rdsnet.ro/ ?
October 22nd, 2009 at 2:25 pm
Since you can’t generate a key on their host: No.
November 7th, 2009 at 6:26 pm
Once you have created your public key you can use the “ssh-copy-id” command to copy it direct to the host and modify all the files you need.
November 10th, 2009 at 12:01 pm
I’d make the last line
‘cat >> ~/.ssh/authorized_keys && sort -u -o ~/.ssh/authorized_keys ~/.ssh/authorized_keys’
so that if you run it multiple times you only get a single entry in the authorised keys file
December 8th, 2009 at 1:26 pm
[…] machine using ssh but not having to do the ssh key sharing thats explained in many posts including this one. You could use expect to do the same thing and more. Below is a script that you pass the domain you […]
January 20th, 2010 at 10:27 am
Hi,
Having issue on setting up automatic SSH login on Solaris 10.
1. I already removed the write permission from group and others on the home directory as well as the $HOME/.ssh. please refer below:
$ pwd
/export/home/userX
$ ls -ld /export/home/userX
drwxr-xr-x 4 userX other 512 Jan 20 08:52 /export/home/userX
$ ls -ld .ssh
drwxr-xr-x 2 userX other 512 Jan 20 08:53 .ssh
$ ls -l .ssh
total 10
-rw-r–r– 1 userX other 450 Jan 20 08:54 authorized_keys
-rw——- 1 userX other 887 Jan 20 08:49 id_rsa
-rw-r–r– 1 userX other 225 Jan 20 08:49 id_rsa.pub
-rw-r–r– 1 userX other 450 Jan 20 08:50 known_hosts
-rw-r–r– 1 userX other 225 Jan 20 08:53 ServerA_id_rsa.pub
$
2. I have the save permission setup on my other server and it’s working there.
3. I also compared the sshd_config and ssh_config of this server that is having issue and the one that is working and found no difference.
4. As user root on this server, it is working. (as root, “ssh localhost” is working, but as normal user, “ssh localhost” asks for password, as well as normal user from remote machine).
Any idea?
Thanks!
January 20th, 2010 at 10:44 am
The two servers you are speaking of might have different binaries installed, with different options compiled in (just a guess). ssh’s verbose logging (-v, -vv, -vvv) can show you what is offered and what is rejected.
January 20th, 2010 at 10:12 pm
You should also need to run ‘chmod 700 ~/.ssh/authorized_keys’ on the server for this to work
January 28th, 2010 at 7:11 pm
#23 stumped Says:
October 8th, 2009 at 5:30 pm
The user’s home & .ssh directorys on the remote machine must be set to 755 at a minimum.
>> Thanks Stumped, that finally solved my problem of connecting a Macosx client to a Linux server over SSH without password!
February 7th, 2010 at 6:03 pm
Beautiful post. Step by step exactly what I needed (except that I used an RSA key) to scp and ssh with no hassle. THANKS!
February 10th, 2010 at 2:23 pm
I’m much more productive now. Just by one click I’m logged in to my build machine & ready to work.
Thanks,
Arun Kumar B
April 6th, 2010 at 1:17 pm
Just an advice, if you are using windows to login to your linux server then simply after step 4 copy paste (you can use winscp for this) the id_rsa file to the following windows directory: C:\Documents and Settings\accountname\.ssh
Thanks
November 27th, 2010 at 11:45 am
samykaruppa said: Your guidelines are very help to me, thanks. But, I want one more help, how can I set automatic ssh login for two domains?. I want to set “example.com”, “mysite.com”, assume that, they are two different sites.
Accidentally removed your comment, sorry. Assuming that you mean servers, not domains, you just repeat the steps 4 and above for every machine you want to log in.
December 30th, 2010 at 1:42 am
@Martin
-bash: ssh-copy-id: command not found
Not done.
January 27th, 2011 at 5:41 pm
ssh-copy-id is not available on all systems (eg: OS X)
May 6th, 2011 at 3:07 pm
[…] If you’re having trouble with this part, you can reference this tutorial which breaks this component into smaller steps: SSH Automatic Login. […]
July 4th, 2011 at 2:34 pm
I’m trying to set autologin on atca7367 machine but after following all steps mentioned at top its still asking for passwd? what to do
November 17th, 2011 at 10:47 pm
I have user1, user2, user3, and host1.
All 3 users have same authorized_keys file, which contains all 3 public keys.
All 3 users have same 700 permission for their home directory and .ssh directory.
All 3 users can ssh to
user1@host1
user2@host1
but user1 and user2 cannot ssh to
user3@host1
Any idea what is wrong with user3 account? What did I miss in users3 account?
Here is the log when attempting to ssh to user3@host1
host-z1> ssh -vv users1@host-z2
Sun_SSH_1.1.3, SSH protocols 1.5/2.0, OpenSSL 0×0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to host-z2 [10.93.64.197] port 22.
debug1: Connection established.
debug2: key_type_from_name: unknown key type ‘—–BEGIN’
debug2: key_type_from_name: unknown key type ‘—–END’
debug1: identity file /users/home/pcsadmin/.ssh/id_rsa type 1
debug1: identity file /users/home/pcsadmin/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1.3
debug1: match: Sun_SSH_1.1.3 pat Sun_SSH_1.1.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.3
debug1: use_engine is ‘yes’
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
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-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
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-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default
debug2: kex_parse_kexinit: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default
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-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default
debug1: Peer sent proposed langtags, stoc: en-CA,es-MX,en,en-US,es,fr,fr-CA,i-default
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: Negotiated lang: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: Remote: Negotiated main locale: C
debug1: Remote: Negotiated messages locale: C
debug1: dh_gen_key: priv key bits set: 116/256
debug1: bits set: 1617/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host ‘host-z2′ is known and matches the RSA host key.
debug1: Found key in /users/home/pcsadmin/.ssh/known_hosts:6
debug1: bits set: 1552/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for ‘out’ mode
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for ‘in’ mode
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying public key: /users/home/pcsadmin/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 6ecd0 hint 0
debug2: input_userauth_pk_ok: fp 97:ca:15:49:9d:7b:41:40:4d:b1:4f:ef:27:2a:e8:b5
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: keyboard-interactive
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:
debug1: Authentications that can continue: 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:
debug1: Authentications that can continue: 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:
debug1: Authentications that can continue: keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (keyboard-interactive).
debug1: Calling cleanup 0×34894(0×0)
host-z1>
November 18th, 2011 at 8:04 am
It tries several times to recover from failed authentication methods. The weird thing is that when trying publickey there doesn’t seem to be an error. It even looks as if that key was ok. Is publickey switched off?
I’d diff the log from another connection, say to user1@host1, with that output. It should become clearer.
February 2nd, 2012 at 10:34 pm
Thanks uberdose for the writeup and Q&A postings. I had troubles with the ssh but it was the home directory permissions as pointed out in the Q&A.
February 29th, 2012 at 4:04 pm
Thanks for the info. A quick tip (that I think would have helped a few people who posted previously): I like to hit the same server from various machines, so to stay organized, I give the keys (generated on the clients) names that are different from the default, i.e.,
ssh-keygen -t dsa -f client1
which results in the files “client1_dsa” and “client1_dsa.pub”. This goofs up ssh . . . Two fixes:
* Check the option “IdentityFile” in the man page for ssh_config.
* Create a symbolic link on the client, as:
cd .ssh
ln -s client1_dsa id_dsa
This seems to work just fine on OS X.
Thanks again!
April 22nd, 2012 at 7:35 pm
Thanks. It worked for me to login at Ubuntu from MacOs. I have used RSA.
August 14th, 2012 at 11:03 am
#23 stumped’s reply is correct for Solaris 5.10
To test the same, you can create users ssltest1 in server1 and ssltest2 in server2
server1# mkdir /home/ssltest1
server1# useradd -d /home/ssltest1 -s /bin/csh -c “ssltest1″ ssltest1
server1# chown ssltest1:other /home/ssltest1
server2# mkdir /home/ssltest2
server2# useradd -d /home/ssltest2 -s /bin/csh -c “ssltest2″ ssltest2
server2# chown ssltest2:other /home/ssltest2
login to ssltest1 and ssltest2 respectively on server1 and server2
server1% ssh-keygen -t rsa
server2% ssh-keygen -t rsa
(do NOT enter any passphrase)
server1% scp /home/ssltest1/.ssh/id_rsa.pub ssltest2@server2:/home/ssltest2
server2% cat /home/ssltest2/id_rsa.pub >> /home/ssltest2/.ssh/authorized_keys
server2% cat /home/ssltest2/.ssh/authorized_keys
ssh-rsa AAAB3NzaC1yc2EAAAABIwAAAIEAtxPz4+5hk2uZnkH9lRFkasKLli8mNWWbwbqZDT48bpUnkucFiS/JeZb++vSXwLOoyYZ2t9be4Ri9Q9YqvZqVSl7uxkM0UBFvoOz3V4UcMCAVb8EI0zEe+3lSQ883sfK9jWh/bwnoYB3qePDpcErauAjBz39cdsCS73gruHrrG8= ssltest1@server1
server1% ssl -vvv -l ssltest2 server2
Sun_SSH_1.1.3, SSH protocols 1.5/2.0, OpenSSL 0×0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to server2 [x.x.x.x] port 22.
debug1: Connection established.
…
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ssltest1/.ssh/identity
debug3: no such identity: /home/ssltest1/.ssh/identity
debug1: Trying public key: /home/ssltest1/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 6ede8 hint 1
debug2: input_userauth_pk_ok: fp a4:8b:09:21:c4:35:31:0a:ea:a0:91:f4:5f:0f:96:4d
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey)
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
server2%
The /etc/ssh/ssh_config should be like:
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file /etc/ssh/ssh_config
#
# Any configuration value is only changed the first time it is set.
# host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Example (matches compiled in defaults):
#
# Host *
# ForwardAgent no
# ForwardX11 no
PubkeyAuthentication yes
# PasswordAuthentication yes
# FallBackToRsh no
# UseRsh no
# BatchMode no
# CheckHostIP yes
# StrictHostKeyChecking ask
# EscapeChar ~
Regards
Bhagirath
November 20th, 2012 at 3:26 am
Hi,
I am trying to setup silent SSH between 2 servers,copied the public key onto server .
Following are permissions on server:
drwxr-xr-x 2 navftp other 512 Nov 20 06:51 .ssh
-bash-3.00$ cd .ssh
-bash-3.00$ ls -lrt
total 6
-rw——- 1 navftp other 222 Nov 19 20:18 authorized_keys
-rw-r–r– 1 navftp other 445 Nov 20 06:47 known_hosts
Output from SSH : It is continuously asking for password -
root@denav1o/> ssh navftp@172.27.10.201 -vvv
Sun_SSH_1.1.4, SSH protocols 1.5/2.0, OpenSSL 0×0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to 172.27.10.201 [172.27.10.201] port 22.
debug1: Connection established.
debug1: identity file /.ssh/identity type -1
debug3: Not a RSA1 key file /.ssh/id_rsa.
debug2: key_type_from_name: unknown key type ‘—–BEGIN’
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type ‘—–END’
debug3: key_read: no key found
debug1: identity file /.ssh/id_rsa type 1
debug1: identity file /.ssh/id_dsa type -1
debug1: Logging to host: 172.27.10.201
debug1: Local user: root Remote user: navftp
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: match: Sun_SSH_1.1 pat Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.4
debug1: use_engine is ‘yes’
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
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-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug3: kex_reset_dispatch — should we dispatch_set(KEXINIT) here? 0 && !0
debug1: SSH2_MSG_KEXINIT received
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-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
debug2: kex_parse_kexinit: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
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-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
debug1: Peer sent proposed langtags, stoc: en-CA,en-US,es-MX,es,fr,fr-CA,i-default
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: Negotiated lang: i-default
debug2: Server is expected to use UTF-8 locale
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: Remote: Negotiated main locale: C
debug1: Remote: Negotiated messages locale: C
debug1: dh_gen_key: priv key bits set: 126/256
debug1: bits set: 1574/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /.ssh/known_hosts
debug3: check_host_in_hostfile: match line 10
debug1: Host ‘172.27.10.201′ is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:10
debug1: bits set: 1627/3191
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug3: kex_reset_dispatch — should we dispatch_set(KEXINIT) here? 0 && !0
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for ‘out’ mode
debug3: aes-128-ctr NID found
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for ‘in’ mode
debug3: aes-128-ctr NID found
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/identity
debug3: no such identity: /.ssh/identity
debug1: Trying public key: /.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /.ssh/id_dsa
debug3: no such identity: /.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
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:
debug3: packet_send2: adding 32 (len 21 padlen 11 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive)
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug3: tty_make_modes: ospeed 9600
debug3: tty_make_modes: ispeed 9600
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 255
debug3: tty_make_modes: 7 255
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 11 25
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 16 0
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 1
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 1
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 0
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug1: channel request 0: shell
debug1: fd 4 setting TCP_NODELAY
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
Last login: Tue Nov 20 08:21:28 2012 from 10.175.252.4
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
-bash-3.00$
November 20th, 2012 at 5:24 am
Your .ssh is not 700 (step 2).
April 2nd, 2013 at 3:58 pm
Thanks for the handy set of steps. I always seem to forgot how to do this!