[Solved] Using SSH Keys instead of password auth

vendion · 2010-08-27 14:54:49

I am wanting to use RSA keys for ssh authentication instead of passwords, I have generated ssh keys for all of my machines and populated them around then edited the ssh_config and sshd_config files like so:

 #    $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
#   ForwardAgent no
ForwardX11 yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
PasswordAuthentication no
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
Protocol 2
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
HashKnownHosts yes
StrictHostKeyChecking ask

#    $OpenBSD: sshd_config,v 1.81 2009/10/08 14:03:41 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

LoginGraceTime 120 
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile    ~/.ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none
LogLevel VERBOSE

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/lib/ssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    ForceCommand cvs server

But when I try to ssh into a machine I am still asked for the password, why is that?

Last edited by vendion (2010-08-30 18:19:16)

.:B:. · 2010-08-27 15:55:43

ssh -v

will tell you why.

ngoonee · 2010-08-27 16:24:13

So would a quick google. Hint, keys have to be authorized by the server, and keys can have passwords of their own.

vendion · 2010-08-27 20:00:35

I didn't generate passphares for the keys besides ssh has a different prompt for that iirc it would as for the passphare for the key instead of the users password, also as I said in my original post I have already copied over the publickey to all my machines. So it is still using password authentication, here is the output using the verbose argument:

vendion ~ $ ssh -v vendion@loki
OpenSSH_5.5p1, OpenSSL 1.0.0a 1 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to loki [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file /home/vendion/.ssh/id_rsa type 1
debug1: identity file /home/vendion/.ssh/id_rsa-cert type -1
debug1: identity file /home/vendion/.ssh/id_dsa type -1
debug1: identity file /home/vendion/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4
debug1: match: OpenSSH_5.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5
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: 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 'loki' is known and matches the RSA host key.
debug1: Found key in /home/vendion/.ssh/known_hosts:7
debug1: ssh_rsa_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,keyboard-interactive            
debug1: Next authentication method: publickey                                        
debug1: Offering public key: /home/vendion/.ssh/id_rsa                               
debug1: Authentications that can continue: publickey,keyboard-interactive            
debug1: Trying private key: /home/vendion/.ssh/id_dsa                                
debug1: Next authentication method: keyboard-interactive                             
Password:

Last edited by vendion (2010-08-27 20:02:36)

KimTjik · 2010-08-27 20:17:28

I remember I got it to work on some machine by uncommenting #PasswordAuthentication yes and set it to no. The text "# To disable tunneled clear text passwords, change to no here!" isn't that clear though, at least in my opinion.

loafer · 2010-08-27 20:28:42

Have you edited the config files on the server or the client? It needs to be on the server.

Mustard · 2010-08-27 20:30:39

I remember I got it to work on some machine by uncommenting #PasswordAuthentication yes and set it to no. The text "# To disable tunneled clear text passwords, change to no here!" isn't that clear though, at least in my opinion.

This looks solved.

Last edited by Mustard (2010-08-27 20:32:24)

.:B:. · 2010-08-27 21:31:58

debug1: Trying private key: /home/vendion/.ssh/id_dsa                                
debug1: Next authentication method: keyboard-interactive
Password:

Says it all .

KimTjik wrote:

I remember I got it to work on some machine by uncommenting #PasswordAuthentication yes and set it to no.

That's just to make keys mandatory.

As you can see from his debug output keys are tried first, passwords are the fallback option:

debug1: Authentications that can continue: publickey,keyboard-interactive            
debug1: Next authentication method: publickey

fukawi2 · 2010-08-28 00:05:46

Check ownership and permissions of the keys on the server (~/.ssh/authorized_keys)
If you can, run the server in debug mode using `/usr/sbin/sshd -ddd -p222` (Use a different port so you don't get locked out!)

KimTjik · 2010-08-28 10:59:10

.:B:. wrote:

That's just to make keys mandatory.
As you can see from his debug output keys are tried first, passwords are the fallback option:
debug1: Authentications that can continue: publickey,keyboard-interactive            
debug1: Next authentication method: publickey

As I wrote it doesn't correspond well with the description. It could be I should have filed a bug report about it, but my experience stands: keys didn't kick in before I changed this setting.

One such Arch install is up running overseas, but I'm still "in charge" of it, so I could check it, to see whether it work today without that not fitting setting in place.

Last edited by KimTjik (2010-08-28 11:01:36)

vendion · 2010-08-28 12:34:41

loafer wrote:

Have you edited the config files on the server or the client? It needs to be on the server.

I have edited the config files on both the server and the client

.:B:. · 2010-08-28 12:46:23

Does

cat ~/.ssh/authorized_keys

show anything, on the server? Since your debug info show no matches being done, I assume it's empty - or doesn't contain the key you're trying to use, at least.

Alternatively, are the permissions on the .ssh dirs 700, and on the authorized_keys file 600?

vendion · 2010-08-28 12:48:49

.:B:. wrote:

Does
cat ~/.ssh/authorized_keys
show anything, on the server? Since your debug info show no matches being done, I assume it's empty - or doesn't contain the key you're trying to use, at least.

Yes my ~/.ssh/authorized_keys file has the public keys for my three machines and ownership of the file is correct and has the following permissions "-rwx-r-xr-x" should be correct right?

.:B:. · 2010-08-28 12:50:21

You were too quick .

I modified my post above ^^.

vendion · 2010-08-28 12:56:54

Haha, well they are now and still no change, one thing that I can try is copying my keys back into the authorized_keys but seeing as how I just did

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

in the first place I don't know how it would be different.

.:B:. · 2010-08-28 13:01:03

Both on the server and the client right?

R00KIE · 2010-08-28 19:57:52

At least the private key must be readable _only_ by the user, that means rwx------.

.:B:. · 2010-08-28 20:03:04

Readable is 600, not 700 .

mir · 2010-08-28 21:15:20

What's your problem? That you can't login with RSA-key-authentication, or is it that you want to disable password authentication?

I have some generic advice for both:

take a look into the server logs (and share them with us)
Disable PAm ("UsePAM no")
/, /home, /home/vendion and /home/vendion/.ssh must not be group-writable. Not even if you are the only one in this group.

R00KIE · 2010-08-28 22:29:33

.:B:. wrote:

Readable is 600, not 700 .

True, but the file can have 700, 600, 500 or 400 permissions (I'm not sure about .ssh, I always set it to 500 or 700 to avoid this particular problem), what matters is that no one else besides the owner can read them. I had that problem too the first time I tried to use it but ssh is kind enough to warn the user about that when used with -v.

vendion · 2010-08-29 00:36:25

Ok so I don't know if I made progress or not but recreating the keys and copying back over I have it somewhat working but when I try to ssh from one of my machines to another I get this:

OpenSSH_5.4p1, OpenSSL 1.0.0 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.101 [192.168.1.101] port 22.
debug1: Connection established.
debug1: identity file /home/vendion/.ssh/id_rsa type 1
debug1: identity file /home/vendion/.ssh/id_rsa-cert type -1
debug1: identity file /home/vendion/.ssh/id_dsa type -1
debug1: identity file /home/vendion/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

.:B:. · 2010-08-29 00:55:52

R00KIE wrote:

.:B:. wrote:
Readable is 600, not 700 .
True, but the file can have 700, 600, 500 or 400 permissions (I'm not sure about .ssh, I always set it to 500 or 700 to avoid this particular problem), what matters is that no one else besides the owner can read them. I had that problem too the first time I tried to use it but ssh is kind enough to warn the user about that when used with -v.

You're right, of course. Technically readable would be just 400....

vendion wrote:

Ok so I don't know if I made progress or not but recreating the keys and copying back over I have it somewhat working but when I try to ssh from one of my machines to another I get this:

OpenSSH_5.4p1, OpenSSL 1.0.0 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.101 [192.168.1.101] port 22.
debug1: Connection established.
debug1: identity file /home/vendion/.ssh/id_rsa type 1
debug1: identity file /home/vendion/.ssh/id_rsa-cert type -1
debug1: identity file /home/vendion/.ssh/id_dsa type -1
debug1: identity file /home/vendion/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

I assume you disabled passwords altogether, or am I wrong?

vendion · 2010-08-29 02:22:57

Yes I want just the keys for authentication, it seems to work for some machines but my laptop running Mac OSX and my server running openSUSE both produce the ssh_exchange_identification error. In the case of my server I can ssh into it from my Arch box using the publickey but when I try it the other way around, the server to my Arch box, it errors out. My Mac has all kind of crazy things going on with it and I'll deal with that some other time.

My /var/log/auth.log doesn't have much interesting things to say other than the key failed (even though I just copied it over from the server)

2010-08-28 22:20:02    localhost    sshd[14079]    Set /proc/self/oom_adj to 0
2010-08-28 22:20:02    localhost    sshd[14079]    Connection from 192.168.1.100 port 36727
2010-08-28 22:20:03    localhost    sshd[14079]    Failed publickey for vendion from 192.168.1.100 port 36727 ssh2

Last edited by vendion (2010-08-29 02:24:23)

my0pic · 2010-08-29 07:55:01

vendion wrote:

ssh_exchange_identification: Connection closed by remote host

Have you allowed ssh connections in to your Arch box?
Make sure you have

sshd: ALL

in /etc/hosts.allow

vendion · 2010-08-30 01:25:35

Yes ssh is allowed in /etc/hosts.allow and worked when using password authentication.

Arch Linux

#1 2010-08-27 14:54:49

[Solved] Using SSH Keys instead of password auth

#2 2010-08-27 15:55:43

Re: [Solved] Using SSH Keys instead of password auth

#3 2010-08-27 16:24:13

Re: [Solved] Using SSH Keys instead of password auth

#4 2010-08-27 20:00:35

Re: [Solved] Using SSH Keys instead of password auth

#5 2010-08-27 20:17:28

Re: [Solved] Using SSH Keys instead of password auth

#6 2010-08-27 20:28:42

Re: [Solved] Using SSH Keys instead of password auth

#7 2010-08-27 20:30:39

Re: [Solved] Using SSH Keys instead of password auth

#8 2010-08-27 21:31:58

Re: [Solved] Using SSH Keys instead of password auth

#9 2010-08-28 00:05:46

Re: [Solved] Using SSH Keys instead of password auth

#10 2010-08-28 10:59:10

Re: [Solved] Using SSH Keys instead of password auth

#11 2010-08-28 12:34:41

Re: [Solved] Using SSH Keys instead of password auth

#12 2010-08-28 12:46:23

Re: [Solved] Using SSH Keys instead of password auth

#13 2010-08-28 12:48:49

Re: [Solved] Using SSH Keys instead of password auth

#14 2010-08-28 12:50:21

Re: [Solved] Using SSH Keys instead of password auth

#15 2010-08-28 12:56:54

Re: [Solved] Using SSH Keys instead of password auth

#16 2010-08-28 13:01:03

Re: [Solved] Using SSH Keys instead of password auth

#17 2010-08-28 19:57:52

Re: [Solved] Using SSH Keys instead of password auth

#18 2010-08-28 20:03:04

Re: [Solved] Using SSH Keys instead of password auth

#19 2010-08-28 21:15:20

Re: [Solved] Using SSH Keys instead of password auth

#20 2010-08-28 22:29:33

Re: [Solved] Using SSH Keys instead of password auth

#21 2010-08-29 00:36:25

Re: [Solved] Using SSH Keys instead of password auth

#22 2010-08-29 00:55:52

Re: [Solved] Using SSH Keys instead of password auth

#23 2010-08-29 02:22:57

Re: [Solved] Using SSH Keys instead of password auth

#24 2010-08-29 07:55:01

Re: [Solved] Using SSH Keys instead of password auth

#25 2010-08-30 01:25:35

Re: [Solved] Using SSH Keys instead of password auth

Board footer