-1

I need to make passwordless login for same linux server with same user.

[airwide@eir ~]$ hostname -i
10.3.7.73
[airwide@eir ~]$ ssh [email protected]
[email protected]'s password: 

how can make to passwordless for same server?

6
  • Uhm what is the purpose of your passwordless login if I may ask? This should never be an option unless you use key-based authentication.
    – Broco
    Aug 14, 2014 at 13:20
  • my application require passwordless login for report generation
    – Asif Patel
    Aug 14, 2014 at 13:42
  • yes, but same server.... not another server
    – Asif Patel
    Aug 14, 2014 at 13:52
  • 2
    This makes absolutely no sense. If you are logged in into a machine why would you log in into the same machine again? If you have to disable the password completely your application does something wrong. May I ask which one it is? If it is a daemon or a job you want to start just start it with the right permissions or use crontab.
    – Broco
    Aug 14, 2014 at 14:02
  • 1
    I agree, you're going down the rabbit hole with ssh to the same server. If your reports application is on the same server as the data, you shouldn't need to ssh to the server at all. Your application is already on the server.
    – Satalink
    Aug 14, 2014 at 14:08

4 Answers 4

3

Easy. Just create an SSH password-less key on your system like this. Below is an example using a local sandbox setup I have using Ubunbtu 12.04 but should work well for most any modern Linux/Unix setup.

First, create the key:

ssh-keygen -t rsa

You will then get the following prompts. Just hit Enter (with no other typing) for each item:

Enter file in which to save the key (/home/myuser/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again:

After that you should see something like this on the screen. Which means the key has been created:

Your identification has been saved in /home/myuser/.ssh/id_rsa.
Your public key has been saved in /home/myuser/.ssh/id_rsa.pub.
The key fingerprint is:
ab:12:cd:34:ef:56:gh:78:ij:90:kl:12:mn:34:op:56 myuser@my_host
The key's randomart image is:
+--[ RSA 2048]----+
|    . ==*o       |
|     o =++       |
|      +.+        |
|     . +         |
|  . o . S        |
| o o .          |
|o E              |
|+  .            |
|=+.             |
+-----------------+

Now, copy the contents of ~/.ssh/id_rsa.pub into authorized_keys:

nano ~/.ssh/authorized_keys

Just place the contents of ~/.ssh/id_rsa.pubat the bottom of~/.ssh/authorized_keys. If you do not have anauthorized_keysfile already you will be creating one with thatnanocommand so you should set proper permissions on the file—600` aka owner/user read & write only—so SSH does not choke on it like this:

chmod 600 ~/.ssh/authorized_keys

Now with that done, you are pretty much done. In the final step you just login to your machine within your machine and you will be presented a “known hosts” warning something like this:

The authenticity of host 'my_host(123.456.78.90)' can't be established.
ECDSA key fingerprint is ab:12:cd:34:ef:56:gh:78:ij:90:kl:12:mn:34:op:56.
Are you sure you want to continue connecting (yes/no)? yes

Just answer yes and then you will get a message like this:

Warning: Permanently added 'my_host,123.456.78.90' (ECDSA) to the list of known hosts.

And now you should be all set. Any SSH login you make to that machine moving forward will be 100% password-less.

If you want to debug the connection, be sure to use the -v (verbose) option like this:

ssh -v myuser@my_host

If all works well, you will get verbose—but clean—output like this:

OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to my_host [123.456.78.90] port 22.
debug1: Connection established.
debug1: identity file /home/myuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_dsa type -1
debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA ab:12:cd:34:ef:56:gh:78:ij:90:kl:12:mn:34:op:56
debug1: Host 'my_host' is known and matches the ECDSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts:3
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to my_host  ([123.456.78.90]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.13.0-34-generic x86_64)

And if that doesn’t work, just look at the debug output & see where things are choking to debug.

5
  • Just an addition: I recently learned that ssh-copy-id saves you some time ;-)
    – Broco
    Aug 14, 2014 at 14:11
  • 1
    @Broco ssh-copy-id has it’s uses to obscure all of the “gotchas” one faces when dealing with SSH keys & such, but I don’t believe it saves time. My steps above really contain only about 3 lines of commands. Which is trivial to handle. And if things go wrong, guess what? You are typing in more & more commands no matter what anyway. Aug 14, 2014 at 14:16
  • 1
    thanks Jake.... its working fine and i am able to login without password on same server. thanks a lot
    – Asif Patel
    Aug 14, 2014 at 14:33
  • Hi Jake, i have tried on another server same procedure but its not working on that server
    – Asif Patel
    Aug 14, 2014 at 15:23
  • @AsifPatel Sorry, but as you see this setup works. If it is not working on another server you need to debug that. And if the issue requires further assistance you need to start a new question. I’ve helped as best as I can & cannot help any more. Best of luck! Aug 14, 2014 at 15:26
3

Create a rsa auth key public/private pair using:

ssh-keygen

If you don't want to be prompted for a password, don't enter anything for the passphrase.

then take the content of the public key and cat it to the server side user's .ssh/authorized_keys file. You can ftp the pub key to the server users .ssh directory.

cat ~/.ssh/your_id_rsa.pub >> ~/.ssh/authorized_keys

You should now be able to ssh [email protected] without being prompted for a password/passphrase. If you have any problems, check the permissions of the files in .ssh -- The public files need to be 644, private files need to be 600, directory needs to be 644 (I think). Google this to make sure. Typically, if you use ssh-keygen it will set the permissions correctly for you.

9
  • still its not working
    – Asif Patel
    Aug 14, 2014 at 13:48
  • from your console where the reports are going to be ran from, try connecting with: ssh -v [email protected] then share the output of the verbose ssh
    – Satalink
    Aug 14, 2014 at 14:05
  • Don't use ssh keys without passwords. Use ssh-agent + keychain if you need it for automation. spf13.com/post/secure-automated-key-based-ssh
    – Broco
    Aug 14, 2014 at 14:06
  • @AsifPatel It probably is not working because you didn’t have a authorized_keys to begin with so the permissions of the file should be changed to chmod 600 ~/.ssh/authorized_keys. See my detailed answer which provides a step-by-step walkthrough on how to setup password-less SSH keys. Aug 14, 2014 at 14:06
  • @Broco There is nothing wrong with SSH keys without passwords if the use they are connected to is limited in rights or access. In this case, the only risk would be if the password-less key was used by a privileged user for access to the system from an external point. Aug 14, 2014 at 14:08
0

You need to setup ssh public key authentication and then force ssh to only use keys for authentication.

For security purposes, I would discourage you to disable passwords and authentication completely.

NOTE: You don't have to disable password authentication if you don't want to, public key authentication would still work. But its just good practise to have if you have a public serving server.

2
  • i reequire command line procedur
    – Asif Patel
    Aug 14, 2014 at 13:50
  • The links I provided in the answer does contain commands. Also, you should elaborate what didn't work with @satalink 's answer, i.e. post errors etc.
    – codehitman
    Aug 14, 2014 at 14:03
0

you need to add ssh pub keys to your authorised keys to do this , simplest way is to do that is

ssh-copy-id root@myhost1

this will ask password , after doing it once , next time onwards you will be able to login without password

1

Not the answer you're looking for? Browse other questions tagged .