Password-less logins with OpenSSH

Posted by Steve on Fri 3 Jun 2005 at 09:45

Because OpenSSH allows you to run commands on remote systems, showing you the results directly, as well as just logging in to systems it's ideal for automating common tasks with shellscripts and cronjobs. One thing that you probably won't want is to do though is store the remote system's password in the script. Instead you'll want to setup SSH so that you can login securely without having to give a password.

Thankfully this is very straightforward, with the use of public keys.

To enable the remote login you create a pair of keys, one of which you simply append to a file upon the remote system. When this is done you'll then be able to login without being prompted for a password - and this also includes any cronjobs you have setup to run.

If you don't already have a keypair generated you'll first of all need to create one.

If you do have a keypair handy already you can keep using that, by default the keys will be stored in one of the following pair of files:

  • ~/.ssh/identity and ~/.ssh/identity.pub
    • (This is an older DSA key).
  • ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub
    • (This is a newer RSA key).

If you have neither of the two files then you should generate one. The DSA-style keys are older ones, and should probably be ignored in favour of the newer RSA keytypes (unless you're looking at connecting to an outdated installation of OpenSSH). We'll use the RSA keytype in the following example.

To generate a new keypair you run the following command:

skx@lappy:~$ ssh-keygen -t rsa

This will prompt you for a location to save the keys, and a pass-phrase:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/skx/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/skx/.ssh/id_rsa.
Your public key has been saved in /home/skx/.ssh/id_rsa.pub.

If you accept the defaults you'll have a pair of files created, as shown above, with no passphrase. This means that the key files can be used as they are, without being "unlocked" with a password first. If you're wishing to automate things this is what you want.

Now that you have a pair of keyfiles generated, or pre-existing, you need to append the contents of the .pub file to the correct location on the remote server.

Assuming that you wish to login to the machine called mystery from your current host with the id_rsa and id_rsa.pub files you've just generated you should run the following command:

ssh-copy-id -i ~/.ssh/id_rsa.pub username@mystery

This will prompt you for the login password for the host, then copy the keyfile for you, creating the correct directory and fixing the permissions as necessary.

The contents of the keyfile will be appended to the file ~/.ssh/authorized_keys2 for RSA keys, and ~/.ssh/authorised_keys for the older DSA key types.

Once this has been done you should be able to login remotely, and run commands, without being prompted for a password:

skx@lappy:~$ ssh mystery uptime
 09:52:50 up 96 days, 13:45,  0 users,  load average: 0.00, 0.00, 0.00

What if it doesn't work?

There are three common problems when setting up passwordless logins:

  • The remote SSH server hasn't been setup to allow public key authentication.
  • File permissions cause problems.
  • Your keytype isn't supported.

Each of these problems is easily fixable, although the first will require you have root privileges upon the remote host.

If the remote server doesn't allow public key based logins you will need to updated the SSH configuration. To do this edit the file /etc/sshd/sshd_config with your favourite text editor.

You will need to uncomment, or add, the following two lines:

RSAAuthentication yes
PubkeyAuthentication yes

Once that's been done you can restart the SSH server - don't worry this won't kill existing sessions:

/etc/init.d/ssh restart

File permission problems should be simple to fix. Upon the remote machine your .ssh file must not be writable to any other user - for obvious reasons. (If it's writable to another user they could add their own keys to it, and login to your account without your password!).

If this is your problem you will see a message similar to the following upon the remote machine, in the file /var/log/auth:

Jun  3 10:23:57 localhost sshd[18461]: Authentication refused: 
 bad ownership or modes for directory /home/skx/.ssh

To fix this error you need to login to the machine (with your password!) and run the following command:

cd
chmod 700 .ssh

Finally if you're logging into an older system which has an older version of OpenSSH installed upon it which you cannot immediately upgrade you might discover that RSA files are not supported.

In this case use a DSA key instead - by generating one:

ssh-keygen

Then appending it to the file ~/.ssh/authorized_keys on the remote machine - or using the ssh-copy-id command we showed earlier.

Note if you've got a system running an older version of OpenSSH you should upgrade it unless you have a very good reason not to. There are known security issues in several older releases. Even if the machine isn't connected to the public internet, and it's only available "internally" you should fix it.


Instead of using authorized_keys/authorized_keys2 you could also achieve a very similar effect with the use of the ssh-agent command, although this isn't so friendly for scripting commands.

This program allows you to type in the passphrase for any of your private keys when you login, then keep all the keys in memory, so you don't have password-less keys upon your disk and still gain the benefits of reduced password usage.

If you're interested read the documentation by running:

man ssh-agent

 

 


Posted by whizse (62.209.xx.xx) on Fri 3 Jun 2005 at 12:12
[ Send Message ]
A great way to make use of ssh-agent is with the pam_ssh module. This makes it possible to only type one password when you log in (as usual) and also lock up you SSH keys. For the rest of the session you can use SSH without typing any passwords.

The information to enable this (for GDM at least) is available in the README in the libpam-ssh package.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Fri 3 Jun 2005 at 20:07
[ Send Message | View Steve's Scratchpad | View Weblogs ]

An interesting package which I'd not heard of before. Thanks for the tip!

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Posted by shufla (83.30.xx.xx) on Fri 3 Jun 2005 at 13:42
[ Send Message ]
Hello,

Well, I use ssh-key with password at work, to access some of my private hosts. My work box could be "compromised" (I have to give access to it to my cooperators), and I do not want then to access my own hosts. But from other side, I'd like not to type my password for key again and again. There comes `ssh-add' command, which use ssh-agent to store unecrypted key for my session (in my case it's Gnome on Ubuntu, but it's suitable for debian).

Very nice article :)

Lukasz Nowak

[ Parent | Reply to this comment ]

Posted by spanginator (69.207.xx.xx) on Fri 3 Jun 2005 at 20:07
[ Send Message ]
It's strange how in the past couple days, two things that I've known could be done (and wanted to know how to do), but -hadn't- known how to do have appeared here. (The multiple file-renaming was the other.)

Thanks, Steve!

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Fri 3 Jun 2005 at 20:09
[ Send Message | View Steve's Scratchpad | View Weblogs ]

You're most welcome.

The only reason I chose to put this up right now is so that I can cover mosshe shortly - that really does require that you use password-less logins....

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Posted by wouter (195.162.xx.xx) on Fri 3 Jun 2005 at 20:47
[ Send Message ]
It would be more secure to put the command in the authorized_keys file -- read sshd(8). The remote sshd server then executes the command and terminates without giving back a shell. That way, even when someone either compromises the key or the computer with the key on it, they can only execute that one command. Especially for your example of 'uptime' or any other simple command you need often, this would be even much more secure.

To backup remote servers, I use rsync over ssh with the key valid only for the rsync-listener (and a shell script to double-check the given parameters). It is the most secure way I can think of to backup servers directly. And it's pretty fast too...

[ Parent | Reply to this comment ]

Posted by Anonymous (209.149.xx.xx) on Sat 4 Jun 2005 at 00:42
wouter is right on the money here.. If you must use a passphraseless key, restricting its use is a must.

[ Parent | Reply to this comment ]

Posted by Anonymous (209.149.xx.xx) on Sat 4 Jun 2005 at 00:40
Using passphraseless SSH keys is a very bad idea. It's convenient, but dangerous. Anyone that gets ahold of them has unfettered access to any servers with the public key.

In the past I have written a bit about how you can still gain some convenience without compromising security with SSH keys here:

http://chris.quietlife.net/2003/10/13/key-management/
http://chris.quietlife.net/2003/10/14/security-part-ii/
http://chris.quietlife.net/2003/10/23/security-part-iii/

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Sat 4 Jun 2005 at 12:22
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Good links, and a good point.

In general I'd agree that having passphrase-less keys is a bad idea, for purely internal LAN access it's not such a terrible idea, but for cross-network links its best to limit the commands that can be run.

I think enough people have commented to make that obvious now, so I'll not make a new article 'Password-less logins with OpenSSH - Securely' ;)

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Posted by Kellen (68.15.xx.xx) on Sat 4 Jun 2005 at 05:32
[ Send Message | View Weblogs ]

Unless you have a very specific command that can be embedded in an authorized_keys file, you should always use a passphrase on your keys.

I worked on solving just this problem for an article I'm writing (which will be posted here in the not-too-distant future). Here is a section, with some minor modifications:

In order to script our backups while using a ssh key with a passphrase, we need an application which will retain use of the key over a long term. We'll use keychain, a tool which itself uses ssh-agent, which does the actual caching.

Install keychain:

~# apt-get install keychain
To set up local root's bash profile to run keychain on login, add these lines to ~/.bash_profile:
keychain --clear id_dsa
. ~/.keychain/$HOSTNAME-sh 

This will have keychain first clear the existing keys (in the case of a normal root compromise, the attacker can't access the remote systems), then attempt to load the id_dsa key and finally source the appropriate output from ssh-agent.

The next time root logs in, she will be prompted to enter the passphrase for the ssh key, and any subsequent process running as root will not need to use a password to log into the remote system.

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Sat 4 Jun 2005 at 12:24
[ Send Message | View Steve's Scratchpad | View Weblogs ]

I had planned on mentioning keychain at some point, but I'll look forward to your piece instead of covering it myself.

This piece was mostly setup for covering things such as remote backups via rsync over ssh - and simple server monitoring with mosshe.

Still I guess I should have made more comments about limitting the commands executed, or security in general.

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Posted by Anonymous (193.128.xx.xx) on Wed 8 Jun 2005 at 14:47
How does keychain make anything at all better than a 'key less' passphrase. Anyone using the system where keychain is running will have the same access as if they stole your plain text passphrase surely?

[ Parent | Reply to this comment ]

Posted by Kellen (132.239.xx.xx) on Wed 8 Jun 2005 at 17:18
[ Send Message | View Weblogs ]
If you have a passphrase-free key and an attacker can read arbitrary data (say they walked off with your hard drive), they can simply copy your key and use it anywhere. Using keychain in conjunction with a passphrase-enabled key prevents this type of attack.

Upon login, either keychain or ssh-agent (not sure which, but leaning towards ssh-agent) clears the keys from memory. So if your account is breached by a brute-force password attack, for example, the attacker still won't have access to remote systems without breaking your passphrase on your ssh key.

You are correct in noting that an advanced attacker could still potentially get the key from memory (I don't have any specific info on this, but it is a concern).

The main point here is that if a system is broken into, and you're using passhprase-free keys, all the systems on which these keys are used are also breached. Using keychain with passphrase-enabled keys requires a higher level of sophistication on the part of the attacker in order to either break the passphrase or know how to exploit the key from memory.

[ Parent | Reply to this comment ]

Posted by Anonymous (82.119.xx.xx) on Sat 4 Jun 2005 at 10:09
My question is not directly about password-less logins... I want to be able to login from public computer, so I don't want to use password (because of lekyloggers). Do you know any howto on using one-time passwords with ssh? I want to be able to print out X passwords on paper to carry with me. ssh should accept normal password and after it, one-time password...

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Sat 4 Jun 2005 at 12:26
[ Send Message | View Steve's Scratchpad | View Weblogs ]

You'd probably be able to start looking at the opie-client package, then started to look more depending on what software you're authenticating against.

Still if you're worried about keyloggers on a machine passwords would be the least of your problem.

You'd want to make sure all the software were legit and not just logging all network traffic.

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Posted by simms (69.157.xx.xx) on Sat 4 Jun 2005 at 12:51
[ Send Message ]
password-less DSA (isn't RSA less safe?) key logins can indeed be uber-convenient, but i have to agree with a lot of folks here that having these 'free entry' tokens out there (the id_dsa.pub part) makes me nervous.

having said that, if you have to use this method there are ways of making it less vulnerable. one thing every noob should know is that you can restrict which user accounts on the server are allowed to be accessed in a 'password-less' way via its /etc/ssh/sshd_config file.
the line
AuthorizedKeysFile %h/.ssh/SOME_ORIGINAL_NAME
can be made to point to a filename which is non-default (as above), and which you will only use in the home directories of users with severely restricted privileges.

while we're at it, sshd_config also contains the line PermitRootLogin that should likely be set to No unless you have a damn good reason.

finally, you can restrict which accounts can be accessed via SSH at all by explicitly listing them with
AllowUsers username

[ Parent | Reply to this comment ]

Posted by Steve (82.41.xx.xx) on Sat 4 Jun 2005 at 13:04
[ Send Message | View Steve's Scratchpad | View Weblogs ]

AllowUser and PermitRootLogin have already been covered in Keeping SSH Access Secure.

But the idea of limitting key access to a restricted set of accounts is a good one.

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Posted by simms (69.157.xx.xx) on Sat 4 Jun 2005 at 13:36
[ Send Message ]
ahh, excellent.
i am humbled by the depth and breadth of this site.

[ Parent | Reply to this comment ]

Posted by Kellen (68.15.xx.xx) on Sun 12 Jun 2005 at 09:23
[ Send Message | View Weblogs ]

My understanding is that RSA was in SSH1, DSA was introduced in SSH2, then RSA was added back into SSH2.

Here is an excerpt from Bruce Schneier's Crypto-Gram for November 15, 1999:

The security of most other public-key algorithms -- ElGamal, DSA, etc. -- is based on the discrete logarithm problem. The two problems are very similar, and all of the modern factoring algorithms can be used to calculate discrete logarithms in the multiplicative group of a finite field. To a rough approximation, factoring a number of a certain size and calculating the discrete logarithm of numbers the same size takes the same amount of work. This means that for a given key size, RSA, ElGamal, DSA, etc. are approximately equally secure. (This isn't strictly true, but it's a good enough approximation for this essay.)

[ Parent | Reply to this comment ]

Posted by Anonymous (216.220.xx.xx) on Wed 8 Jun 2005 at 19:36
I have never been able to make this work without including the following line in the /etc/sshd_config of the remote box:

UsePAM no

Am I crazy?

[ Parent | Reply to this comment ]

Posted by Anonymous (71.116.xx.xx) on Mon 22 Aug 2005 at 20:11
You are not crazy... in locking down my debian/ubuntu ssh I found that I had to change this to no otherwise sshd still allowed password-based auth

[ Parent | Reply to this comment ]

Posted by Anonymous (129.42.xx.xx) on Tue 25 Jul 2006 at 20:14
Only a little crazy. "ChallengeResponseAuthentication no" is the more specific setting for disabling the password prompt generated by the PAM module.

[ Parent | Reply to this comment ]

Posted by redbeard (216.49.xx.xx) on Wed 27 Jun 2007 at 05:44
[ Send Message | View redbeard's Scratchpad | View Weblogs ]
I realize this is a really old thread, but it's a possible answer to a question I have. Is this really true? In other words, if I have:
UsePAM yes
ChallengeResponseAuthentication no
I can prevent using PAM passwords (requiring public/private key authentication) but still use the PAM framework for implementing other things? If that's the case, I'd be absolutely thrilled. Unfortuntaely, the man page is a little vague on ChallengeResponseAuthentication:
Specifies whether challenge-response authentication is allowed. All authentication styles from login.conf5 are supported. The default is "yes".
I'll repost this elsewhere if no one notices ;)

[ Parent | Reply to this comment ]

Posted by Anonymous (130.231.xx.xx) on Thu 9 Jun 2005 at 11:41
The article subject is quite trivial and the fine manuals describe it well. The comments have some interesting expansion, though.

[ Parent | Reply to this comment ]

Posted by nathanbullock (205.206.xx.xx) on Mon 20 Jun 2005 at 19:33
[ Send Message | View Weblogs ]

Slightly off topic but something I would like to know. I have a script that uses scp, ssh, and rsync multiple times. Currently I have to type in the one password about 5 times each time I run the script. I run the script manually so I have no problem typing in the password, but I would like to do it only once.

Is there a way to keep one secure connection open and just use that connection for each of the various commands? Or some way to cache the password for just the duration of that script?

[ Parent | Reply to this comment ]

Posted by Anonymous (69.128.xx.xx) on Wed 29 Jun 2005 at 05:28
Yes, you can use expect. I greatly caution against using this, since it has the same security issues passwordless secret keys have. You can customize the script below to change the ssh command or whatever. The interact command causes the script to "connect" the keyboard to the spawned command. You can read about expect for more information.
#!/usr/bin/expect spawn ssh user@host expect "Password: " { sleep 1 send "secret\r" } timeout { send_user "Error connecting" } # I have no idea why this needs to be here, except if it isn't the # password does not get sent and the login doesn't happen # So this should just timeout expect "alksjd" { send_user "Whoa" } timeout { } interact

[ Parent | Reply to this comment ]

Posted by Anonymous (195.23.xx.xx) on Wed 25 Jul 2007 at 12:35
Just to let you know that the second expect is not needed, only the final interact, and it will work like a charm :-)

[ Parent | Reply to this comment ]

Posted by wouter (195.162.xx.xx) on Wed 14 Sep 2005 at 22:33
[ Send Message ]

You can probably find a way to cache the password by reading it in with the 'read' shell command (put echo off).

A more correct way is to write a script and run that on the remote host. Or you could also pass more complex commands (including shell programming) with ssh, you are not limited to one command. I don't know why you wouldn't use a key for that, though. I backup remote machines from cron on a secure machine with a DSA key -- rsync over ssh. I don't have to type any passwords because the key doesn't have one (which is perfectly fine in this case because it's a secure host that's not directly connected to the internet and has no services running). I can not run keychain on it because I'm rarely present in that office and it is rebooted occasionally due to bad power lines, but I'm thinking up a way to feed keychain PGP-signed and -encrypted input by means of a secure bot script hidden somewhere on the web.

[ Parent | Reply to this comment ]

Posted by Mavin (170.148.xx.xx) on Fri 25 Nov 2005 at 07:33
[ Send Message ]
All this security is as vulnerable as the machines on which the passphrases/passwords are typed. Is there a way to include something like one of those RSA authentication tokens as another factor in the auth? These things generate a new number every minute and the same number is generated on the server. So even if someone hijacks your password, etc its only for one session. Also could the SSH server be configured to ask for the RSA token generated number once every half hour or so?

[ Parent | Reply to this comment ]

Posted by Anonymous (202.164.xx.xx) on Fri 22 Dec 2006 at 12:01
Great article! I've had a bit of trouble finding an easy to understand tutorial on this subject, and I'm glad I found it.

I ran into one problem while I was working. You suggest editing /etc/sshd/sshd_config. On my systems this file is /etc/ssh/sshd_config (note the extra 'd').

It might be a typo on your part or a change in naming -- this tutorial is eighteen months old now, and I'm running bleeding edge sid! Thanks for the work.

[ Parent | Reply to this comment ]

Posted by Anonymous (199.67.xx.xx) on Fri 23 Feb 2007 at 09:58
no, ssh_config refers to client setup, sshd_config refers to daemon setup

[ Parent | Reply to this comment ]

Posted by Anonymous (24.186.xx.xx) on Mon 22 Nov 2010 at 23:41
I'm afraid you missed the point, reader - he is talking about the DIRECTORY, not the FILE NAME - it's the same with my system - it's etc/SSH/sshd_config, NOT /etc/SSHD/sshd_config (please note that allcaps are for emphasis only).

[ Parent | Reply to this comment ]

Posted by Anonymous (205.234.xx.xx) on Thu 8 Mar 2007 at 15:57
GREAT ! it is really great !
just a question, is there any way to do such a thing in Windows too ?
in windows i use putty , and everytime I have to enter my password...

[ Parent | Reply to this comment ]

Posted by Steve (80.68.xx.xx) on Thu 8 Mar 2007 at 16:24
[ Send Message | View Steve's Scratchpad | View Weblogs ]

Yes, you want to read the putty documentation - it can store public keys too, and allow passwordless logins.

Steve

[ Parent | Reply to this comment ]

Posted by Anonymous (134.67.xx.xx) on Fri 9 Sep 2011 at 18:19
Thanks a lot - this was quite helpful!

[ Parent | Reply to this comment ]

Posted by jk04 (220.233.xx.xx) on Tue 3 Apr 2007 at 13:33
[ Send Message ]
Steve
I followed the guidelines and came across a couple of issues that I would like to share with you.

1. The ssh-copy-id command stored the public key in the authorized_keys rather than authorized_keys2 although the new keys were of type RSA.

2. I ended up using the identity file switch to make the password-less feature work
ssh -i ~/.ssh/id_rsa REMOTE_HOST

I was using a FC6 machine as the local and a Debian3.1 one for the remote.

Regards

[ Parent | Reply to this comment ]

Posted by Anonymous (202.7.xx.xx) on Fri 14 Sep 2007 at 03:16
Also on FC6, but with Debian 4.0 as the client, and FC6 as the server, on the server I had to do:
chmod 644 ~/.ssh/authorized_keys
... for some reason (not sure why the permissions were set differently), in order to get password-less SSH logins to work. So that's perhaps another thing to check if it's not working for you.

[ Parent | Reply to this comment ]

Posted by Anonymous (121.247.xx.xx) on Thu 1 Nov 2007 at 10:57
simple and useful writeup. password-less logins worked for me.

[ Parent | Reply to this comment ]

Posted by Anonymous (61.88.xx.xx) on Thu 22 Nov 2007 at 00:38
Another reason for it not working... SSH isn't running on the default port. And sadly, it appears ssh-copy-id doesn't support connecting to other ports.

I had to manually copy the public key over using scp, then ssh in (using a password) and manually append the key to authorized_keys2 (cat source >> authorized_keys2).

[ Parent | Reply to this comment ]

Posted by Anonymous (12.184.xx.xx) on Thu 28 Apr 2011 at 16:56
If you're running ssh on a non-standard port, like me, an easier way to copy the key than manually copying it is to modify the ssh-copy-id command as I've noted below. Note those are single quotes. Replace 9210 with the port your sshd is listening on. I used 9210 as an arbitrary number for this example only.

ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 9210 username@host'

[ Parent | Reply to this comment ]

Posted by Anonymous (216.239.xx.xx) on Sat 2 Jun 2012 at 16:04
Thanks for this useful tip

[ Parent | Reply to this comment ]

Posted by Anonymous (192.94.xx.xx) on Mon 21 Jul 2008 at 13:29
My E-Mail: ahmad.abdulghany@gmail.com

I tried it, and the attitude is strange! It always asks me for a password when I try to connect to a machine on certain NIS domain that I'm not on it, and it doesn't prompt for password in the reverse path (From the NIS machine to mine)!

How can I solve??
Thanks,
Ahmad

[ Parent | Reply to this comment ]

Posted by AJxn (91.95.xx.xx) on Thu 24 Jul 2008 at 12:02
[ Send Message | View Weblogs ]
Please check names of the machines that you see from outside (the other machine) and what that machine sees from its side.
You can also run ssh with some -v to get verbose trace of what happens when you connect to the other machine.

[ Parent | Reply to this comment ]

Posted by Anonymous (98.64.xx.xx) on Mon 16 Mar 2009 at 20:14
Using: OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007,

I had been having problems with getting sftp to work in batch mode. And I was getting this error:

Permission denied (publickey,password).
Couldn't read packet: Connection reset by peer

I followed the instructions the article to use ' ssh-copy-id -i ~/.ssh/id_rsa.pub "my_remote_host"'. And afterwards, by golly, I could ssh to my_remote_host without having to type in a password. But I still could not use sftp. Then I read that perhaps the client and server are using a newer version of the protocol, and that when using the newer version sftpd looks for ~/.ssh/authorized_keys2.

So I copied ~/.ssh/authorized_keys to ~/.ssh/authorized_keys2, and now sftp works fine.

[ Parent | Reply to this comment ]

Posted by Anonymous (80.134.xx.xx) on Thu 16 Jul 2009 at 23:09
hey nice stuff
as of today (July '09), the following two commands suffice on an updated Debian "stable" version:
$ ssh-keygen
$ ssh-copy-id login@host

regards, 'Titan'

[ Parent | Reply to this comment ]

Posted by Siper2 (74.94.xx.xx) on Thu 24 Sep 2009 at 17:05
[ Send Message ]
Great document. I'm trying to get password-less logins to work between Linux-run IBM xSeries servers for a project at work. We have some running Debian, and the others are Fedora. Right now I've only tried this for Debian.

The command is:
scp -p [file] [remote_host]@[IP]:/home/[dir]

I'm working with our lab machines now, and it seems that we have DSA, not RSA. The output of ssh -V shows:
OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004

I'm aware that OpenSSH goes up to at least 5.2 by now. I don't think our company is really interested in version updates, so at this point I'm just wondering if there's any options.

The result of the scp command is a password prompt, so the process isn't working. I've tried using the above RSA procedure, only starting with "ssh-keygen -t dsa" instead of "rsa" and also tried the suggestions from other users, above. chmod 644, etc.

I'm a lower-intermediate user, and keys are pretty new to me, but this doc was a huge step in at least the right direction. Any help or suggestions?

[ Parent | Reply to this comment ]

Posted by Siper2 (74.94.xx.xx) on Wed 7 Oct 2009 at 18:30
[ Send Message ]
I wanted to update everyone... I got this to work, today.

Thanks mostly to:
http://ubuntuforums.org/showthread.php?t=1047156

The issue, for me at least, was mostly the $home permissions. Needed to be 715, and I think the default that the company uses is 777. OpenSSH obviously doesn't want full permissions.

So long as ~/.ssh/authorized_keys is chmod to 600 (maybe id_rsa.pub as well), and ~ is 715, it works for me. This also works on Fedora test systems (we have standard OS installs of both Debian and Fedora, no unique packages).

Thanks!

[ Parent | Reply to this comment ]

Posted by Anonymous (115.118.xx.xx) on Mon 21 Dec 2009 at 16:54
Q) I had done the ssh process and my system get connected to remote system automatically with out password. But I want to get this executed through script and when doing this after getting connected to the remote system,the script is being not working.

for example:
#!/bin/bash
ssh 123.12.3.45 {sample ip address}
echo "hai vamsi"

output:
just connecting to remote system and stopping over there.

I need your help in this regards to proceed further.

Thanks in advance
Vamsi
vamsi.kunasani@gmail.com

[ Parent | Reply to this comment ]

Posted by Anonymous (67.166.xx.xx) on Thu 28 Jan 2010 at 04:05
Hello,

You probably figured this out by now, but...

You need to test your command for executing in bash before you put it in the script--because it works the same way in the script or on the command line. Then you will see you can just write in the script: ssh user@ip-address command --it looks like you are trying to issue commands over SSH but by using echo? That's not right. I hope this helps.

[ Parent | Reply to this comment ]

Posted by Anonymous (213.86.xx.xx) on Tue 25 May 2010 at 14:55
If you still can't get it to work you can use up to three -v options for diagnostic messages

ssh -v -v -v mystery

[ Parent | Reply to this comment ]

Posted by Anonymous (98.118.xx.xx) on Fri 25 Jun 2010 at 16:51
Great Article, very straight forward, worked for me on Ubuntu, took only 5 minutes! Thank you, you made my day =)

[ Parent | Reply to this comment ]

Posted by Anonymous (202.60.xx.xx) on Thu 16 Sep 2010 at 12:49
Its great article. Is there any similar way to set passwordless connection from windows to windows machine.

[ Parent | Reply to this comment ]

Posted by Anonymous (76.79.xx.xx) on Tue 28 Sep 2010 at 23:46
I've tried all that, and it STILL doesn't work. I can get it to work from B to A, but not A to B. When I add the "-v" option, there's no difference before or after I "ssh-copy-id" the RSA public key. But if I do the same steps from B to A, it works like a charm. On B, I see the "authorized_keys" file being updated, but it just ignores it. Permissions on .ssh are 700 and all the files in that directory are 600.

/etc/ssh/sshd_config on each computer are identical.

Is there some sort of SELinux or firewall setting that could be blocking it?

[ Parent | Reply to this comment ]

Posted by narcisgarcia (87.111.xx.xx) on Thu 7 Oct 2010 at 17:52
[ Send Message ]
A new guide to configure better the client and the server:
http://wiki.lapipaplena.org/index.php/How_to_mount_SFTP_accesses

(with special care with owners and permissions questions)

[ Parent | Reply to this comment ]

Posted by Anonymous (98.223.xx.xx) on Wed 8 Dec 2010 at 18:16
I also had to change the permissions of my home folder to get mine to work:

chmod ~ 755

[ Parent | Reply to this comment ]

Posted by Anonymous (203.83.xx.xx) on Sat 11 Dec 2010 at 15:48
Thanks, changing home directory permissions to 755 did trick for me too..

[ Parent | Reply to this comment ]

Posted by icegood (94.212.xx.xx) on Fri 31 Dec 2010 at 05:12
[ Send Message ]
Guys, about to get mad...
Have main server and nodes. Want to do passwordless connection to nodes from server.
1) Pair private-public created
2) copiyed via ssh-copy-id -i ~/.ssh/id_rsa.pub me@on-node. It's actually same place because all nodes import home directory from server via nfs.
3) Permissions checked:
-rw------- 1 ice ice 1422 2010-12-31 05:32 authorized_keys
or
-rw-r--r-- 1 ice ice 1422 2010-12-31 05:32 authorized_keys

-rw------- 1 ice ice 1743 2010-12-31 05:32 id_rsa
-rw-r--r-- 1 ice ice 394 2010-12-31 05:32 id_rsa.pub
4) On ssh config on node:
RSAAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no

Permissions for ~ice and ~ice/.ssh both changed to 775.

Output: doesn't work. Sometimes even asks for login password ommiting rsa-auth. WTF????

[ Parent | Reply to this comment ]

Posted by icegood (94.212.xx.xx) on Fri 31 Dec 2010 at 05:14
[ Send Message ]
Besides for root everything works... It kills me :(

[ Parent | Reply to this comment ]

Posted by Steve (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Fri 31 Dec 2010 at 11:02
[ Send Message | View Steve's Scratchpad | View Weblogs ]

If it works for users but not for root, then check /etc/ssh/sshd_config and look to see what "PermitRootLogin" is set to.

If you change it run "/etc/init.d/ssh restart".

Steve

[ Parent | Reply to this comment ]

Posted by icegood (129.125.xx.xx) on Fri 31 Dec 2010 at 23:41
[ Send Message ]
It's stupid! What it business what ownership on my ~ and ~/.ssh is. Besides, post about 775 to ~ is useless! Become even worse - no rsa auth at all!

[ Parent | Reply to this comment ]

Posted by icegood (94.212.xx.xx) on Sat 1 Jan 2011 at 14:34
[ Send Message ]
Now situation is next: to enable at least rsa connections ~ and ~/.ssh BOTH should have 700 permissions. But for regular user on nodes passwordless doesn't work. Is it somehow connected to fact that nfs changes permissions to files because it only operates on file requests? But why then for root everything works... Don't understand...

[ Parent | Reply to this comment ]

Posted by Anonymous (91.120.xx.xx) on Tue 26 Apr 2011 at 13:14
Hi!

Thanks for this article. I followed the steps above, but I had no success. After I searching for the logs, I found the problem in /var/log/secure. (Under fedora it is not in /var/log/auth). Finally I changed permissions and ownership, and it led to success. My ~/.ssh/ folder seems like this:


-rw-r--r--. 1 root root 1080 Apr 26 12:54 authorized_keys
-rw------- 1 root root 1675 Apr 26 12:45 id_rsa
-rw-r--r-- 1 root root 400 Apr 26 12:45 id_rsa.pub
-rw-r--r--. 1 root root 1957 Apr 26 12:51 known_hosts

Thanks again, it's work perfectly.

Balazs Huvely from Hungary

[ Parent | Reply to this comment ]

Posted by Anonymous (115.113.xx.xx) on Thu 26 May 2011 at 10:37
Hi,

Good Article. The most important part of this article is "TROUBLESHOOTING". I found many article on net explaining how to create keyless login but not the "TROUBLESHOOTING" part. I was already using this key less login for my development but when i tried in one new system it was not working. The problem was the permission for ".ssh" dir. After changing it to "700" it worked fine.

Thanks.
Mitesh koradia

[ Parent | Reply to this comment ]

Posted by Anonymous (72.5.xx.xx) on Wed 6 Feb 2013 at 01:21
Same here. Looking in the log file and changing permission on home directory made all the difference. I was stumped before. Thanks a lot!

[ Parent | Reply to this comment ]

Posted by Anonymous (203.26.xx.xx) on Fri 15 Jul 2011 at 07:51
Hi,

does anyone know if there is a way to overcome the problem that, in spite of a public-key ssh connection, if the server's user has its password expired (needs to be changed) it still asks for a password.
Isn't public-key ssh just there to ignore passwords altogether?

Thanks

[ Parent | Reply to this comment ]

Posted by Anonymous (210.55.xx.xx) on Wed 24 Aug 2011 at 05:20
Great article. you have just save my day!

[ Parent | Reply to this comment ]

Posted by Anonymous (212.88.xx.xx) on Sat 11 Feb 2012 at 13:14
This procedure works well for me. However, i have one problem. When i repeat the procedure for another password-less login to another remote server, The first setup i created stops working i.e. i can no longer do a password-less login on the previous server. How can i overcome this and still be able to do a password-less login on the second remote server?

[ Parent | Reply to this comment ]

Posted by Anonymous (84.20.xx.xx) on Wed 18 Jul 2012 at 09:36
I believe you are performing the entire procedure completely when you login to another server. Which I guess is not entirely correct.

So let's asume you have laptop L and have gone through this article to establish a passwordless connection to server S1.

Now you also want L to connect without a password to server S2. In this case, you would generate the id_rsa and id_rsa.pub files at the S2 machine and ssh-copy-id from S2 towards L. But be aware that from L towards S2, at the L machine you already have the id_rsa and id_rsa.pub files. If you generate them again they will be different than what S1 expects to find and L-S1 will not work. So in this case, you don't generate new id_rsa and id_rsa.pub files, you only need to ssh-copy-id these keys towards S2.

I hope this helps.

[ Parent | Reply to this comment ]

Posted by Anonymous (202.69.xx.xx) on Thu 29 Mar 2012 at 06:19
Thank you. No site/forum has mentioned about editing the /etc/ssh/sshd_config file when ssh login is not working.
It was the issue I had.

Now working perfectly.!!!!

[ Parent | Reply to this comment ]

Posted by Anonymous (15.243.xx.xx) on Thu 26 Jul 2012 at 00:47
what does older version of ssh mean ? I have open ssh 4.3 ? does it support RSA? I am asking because public key authentication is not working and I do not have root access .

[ Parent | Reply to this comment ]

Posted by Anonymous (176.44.xx.xx) on Fri 28 Dec 2012 at 11:17
Hello,
I came across your guidelines and I strictly followed your guidelines and still face the problem with SSH ( passwordless ssh AIX login between two machine for non-root user )
The details of the problem are mentioned here: unix dot com / aix/211183-passwordless-ssh-problem-aix-machines.html

Can anyone help me.

[ Parent | Reply to this comment ]

Posted by Anonymous (167.234.xx.xx) on Sat 30 Mar 2013 at 13:55
Great, I tried using this and stuck up with file permission issue, now fixed with the exact file permissions given. Finally worked :) Good article... I like it.. :)

[ Parent | Reply to this comment ]

Posted by Anonymous (202.157.xx.xx) on Sat 19 Oct 2013 at 16:27
The reason why my didn't work in spite or trying everything above was because SELINUX was enabled. I disabled it by editing /etc/selinux/config file, rebooted, and then it worked smoothly.

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

Which init system are you using in Debian?






( 1607 votes ~ 7 comments )