ssh and login password

[geezer]

On 15.10 and previous versions I was able to use ssh and login to the local computers connected to my router without having to input the user password each time.

This made it very good for use in scripts to issue commands on the other computers.

In 16.04 I have found that I can no longer do this. Instead I have to manually enter the user password each time.

I do not remember how I was able to configure ssh previously to obtain this "feature". Did something change in the new ssh to disable this "feature"?

Is it possible to configure ssh to enable the remote login through ssh without having to manually enter the user password?

[Snowhog]

Maybe How can I set up password-less SSH login?

[elijathegold]

Not when used as a client, I just had to restore my .ssh directory which had my certificates.

[geezer]

Maybe How can I set up password-less SSH login?

Thanks - still trying their advice - just doesn't seem to work as they claim.

[elijathegold]

Thanks - still trying their advice - just doesn't seem to work as they claim.

When using the ssh-copy-id command you need the user password on the target machine. If that is disabled in the ssh configuration, enable it and restart the service to allow the cop.

[oshunluvr]

This might be a more complete tutorial: https://help.ubuntu.com/community/SSH/OpenSSH/Keys

However, if you had this working before, you should be able to copy ~/.ssh to your new home and it should just work. Did here anyway...

[geezer]

This might be a more complete tutorial: https://help.ubuntu.com/community/SSH/OpenSSH/Keys

However, if you had this working before, you should be able to copy ~/.ssh to your new home and it should just work. Did here anyway...

I was thinking of chnaging the names of all the files in ~/.ssh and starting from scratch.

If I change the

PasswordAuthentication

The I find that the other local computers cannot logon at all. They get a permission denied message and can do nothing.

One web site advised to change

ChallengeResponseAuthentication

and

UsePAM

Also. That made things worse.

So I have changed everything back to what they were and now I can at least log on from the other computers again, but I need to enter the password. Which I find interesting. I initially thought that not having to enter the password would be a security hole, but all the sites I read said that having to enter the password is the security hole and that just using the ssh key is far more secure. !!

[oshunluvr]

The key can't be duplicated but a password can be guessed. Keys are the way to go. Also, if you're computers are exposed to the internet, consider using non-standard ports.

Another neat tip if you use ssh a lot: in ~/.ssh create file name "config" and you can put your ssh hosts, usernames, and ports in it. This would be a bit less secure than not having it, but if all your hosts use a secure key I think you're pretty safe. Here's an example of the config file:

Host server
  Port 9999
  User bigbob
  Host 192.168.1.2
  
Host laptop
  Port 9999
  User bigbob
  Host Dell-4560


Host router
  Port 9999
  User bigbob
  Host 192.168.1.1

You can use a hostname (like Dell-4560 above) or an IP address to identify the ssh host. With the secure keys properly placed, I need only type "ssh server" and I'm logged into my server. I configure my fixed devices with fixed IP's and put them in my hosts files. Makes them easier to find....

[geezer]

Okay - I finally got ssh to work properly. Forget all the online tutorials, They all seem to be years out of date.

I finally learned to invoke ssh as:

ssh -v name@192.168.11

That told ssh to output a lot of information of what was happening as it happened and what it was doing.

There was one line:

debug1: Skipping ssh-dss key ~/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

That really threw me since I had followed the directions of at least 4 different web page auhors and generated DSA keys as:

ssh-keygen -t dsa

So I quickly checked the directory ~/.ssh and sure enough the file 'id_dsa' was indeed there and with r/w permissions for me alone. But ssh didn't think something about it was right or didn't like the permissions or whatever.

So I did a lot of reading on the web about RSA vs DSA. According to all that I read, maybe the 2 are of equal strength, but RSA with a bit length of 2048 was thought to be stronger than the equivalent length key in DSA. The biggest reason to use one over the other had to do with the speeds of encryuptionand decryption. DSA being faster to encrypt and RSA fast to decrypt. For commercial users who have a lot of client computers and encrypt a document once with a lot of clients decrypting it, the faster decryption of RSA is a factor in choosing RSA.

One web page seemed to indicate that the ssh authors were leaving DSA because they thought that the NSA had cracked it and probably inserted a backdoor in their collaboration with NIST. They probably did. I think it is probably a sure bet that they did. It is also known that NSA paid RSA a lot of money (well a lot to me anyway - less than lunch money to the NSA) to put a backdoor in their commercial offering. The opensource offering very likely does not have the backdoor.

So maybe ssh authors have left DSA and now don't recognize it anymore, at least maybe the version I upgraded to in 16.04.

So I deleted all the files in ~/.ssh on all the computers plugged into my router and executed the following three commands on each and every one:

ssh-keygen -t rsa -b 2048

ssh-add

ssh-copy-id name@192.168.1.xx (once for each local computer)

After executing those 3 commands in a terminal, I then used ssh to log onto each of the local computers. The logon went without a single hitch and I was on with no password. I didn't jiggle or change anything in /etc/ssh/sshd_config

I think the real magic for my situation was the switch from DSA to RSA.

So I executed:

ssh -v name@192.168.1.xx

and read the ssh debuging output. The notice that it was skipping ~/.ssh/id_dsa was still there, but I'm no longer using DSA so it didn't matter in the least.

Hope this helps some maybe having the same problem. At least I now know a little bit more about ssh.

[oshunluvr]

Good sussing this one out and reporting your findings. 2xthumbs-up

[geezer]

More thoughts and actions

Okay - what I got from the previous posts was not exactly what I wanted.

With the 3 commands I posted before, I simply switched from having to input a password, short or long, simple or complicated, to a pass phrase, short, long, simple or complicated.

So it didn't really solve my problem of being able to use ssh in a script to automate commands for another computer on my local network. What I really wanted was to be able to ssh to a local computer with no input. Thus, the script would be completely automatic. Now this raised some alarms for me and would doubtless also do so for a lot of contributors on the forums.

I found a way to accomplish what I wanted that I think is still very secure.

When ssh-keygen asks for a pass phrase, it states that the pass phrase can be empty. I simply pressed the "Enter" key to this and input an empty pass phrase. Is this less secure? well psychologically maybe not since a lot of hackers would immediately assume a non-empty pass phrase. But then maybe not.

Well the empty pass phrase accomplished what I want. When I issue "ssh name@192.168.1.xx" I am immediately logged into the local computer I want.

So after a little experimentation and reading I found the command" AllowUsers" in the /etc/ssh/sshd_config file. With that command, I can restrict any local computer to ONLY ACCEPT logins from designated users on designated computers and only those users. ALL others are denied access through ssh. So I setup the /etc/ssh/sshd_config file on all local computers to ONLY accept logins from my ID on the local computers. After a little testing I found that it works extremely well. All IDs trying to ssh to my local computers are denied access except the local IDs@designated_local_computers allowed.

So barring some unknown to me bugs in ssh and AllowedUsers command, using an empty pass phrase is just as secure as a pass phrase, long, short, simple or complicated.

Now that would not work for a person who must access the local computers from another computer, local or remote, that has not been previously set into the configuration file. Fortunately that does not include me.

[oshunluvr]

I don't remember setting up ssh being this complicated, but at least you got it working the way you want.

Not sure what you're using this for, but there's also the rsh command which should work as well. It allows you to send a command to the other computer without actually opening a terminal prompt for it. The biggest difference is you get no feedback on what you entered. It's real useful for scripting tasks remotely.

Also, you should try the config file I talked about - then you won't have to even enter your username, just "ssh 192.168.1.XX" or "ssh hostname"

[geezer]

I don't remember setting up ssh being this complicated, but at least you got it working the way you want.

Not sure what you're using this for, but there's also the rsh command which should work as well. It allows you to send a command to the other computer without actually opening a terminal prompt for it. The biggest difference is you get no feedback on what you entered. It's real useful for scripting tasks remotely.

Also, you should try the config file I talked about - then you won't have to even enter your username, just "ssh 192.168.1.XX" or "ssh hostname"

Yes I remember I investigated rsh in the past for what I want, but had decided after some experimentation that it just didn't suit my needs. I remember nothing about rsh other than that. Don't remember why I rejected it or the criteria I used.

With the config file you wrote about, don't you have to enter a password or pass phrase?

[oshunluvr]

Ok, I've made a small amount of progress into my issue: It seems, at least here that hostname definitions in sudoers are not being honored. Specifically this does work:

stuart ALL = NOPASSWD: /usr/bin/apt, /usr/bin/apt-get, /usr/bin/add-apt-repository, /usr/bin/apt-add-repository, /sbin/blkid

but this does not:

stuart office = NOPASSWD: /usr/bin/apt, /usr/bin/apt-get, /usr/bin/add-apt-repository, /usr/bin/apt-add-repository, /sbin/blkid

"office" being the hostname of my system. This should work - as it does on my 15.04 install.

Can anyone here test this in there sudoers file and verify it's not just my system?