SSH Keys problem?

[voodoo]

For science I just setup a ssh tunnel from my osx box to my fully updated arch server and was successful.  Ill post my configs.

sshd_config (sever side)

Code: [Select]

# $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm 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 override the
# 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
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

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

# Ciphers and keying
#RekeyLimit default none

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

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# 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 no
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
#PermitTTY yes
PrintMotd no # pam does that
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox # Default for new installations.
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none
Banner /etc/ssh/banner

# 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
# PermitTTY no
# ForceCommand cvs server

ssh_config (client side) untouched, using all defaults

Code: [Select]

# $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 *
   SendEnv LANG LC_*
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS 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,1
#   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

# XAuthLocation added by XQuartz (http://xquartz.macosforge.org)
Host *
    XAuthLocation /opt/X11/bin/xauth

File permissions for client side

Code: [Select]

drwx------   5 dingo  staff   170 Jun 10 19:48 .
drwxr-xr-x+ 49 dingo  staff  1666 Jun 11 10:49 ..
-rw-------   1 dingo  staff  3243 Jun 10 18:01 id_rsa
-rw-r--r--   1 dingo  staff   789 Jun 10 18:01 id_rsa.pub
-rw-r--r--   1 dingo  staff   398 Jun 10 19:48 known_hosts

File permissions for server side

Code: [Select]

total 12
drwx------  2 voodoo users 4096 Jun 10 19:57 .
drwx------ 29 voodoo users 4096 Jun 11 10:56 ..
-rw-------  1 voodoo users  789 Jun 10 19:57 authorized_keys

As a side note, please make sure that all your pub keys are concatenated on the same lines in the authorized_keys file.  You can use the following command to append

Code: [Select]

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


[proxx]

Full path to keys

Code: [Select]

/home/shell/.ssh/id_rsa*

Also, there's no authorized_keys on the client, but on the server it's the same because the users have the same name

Code: [Select]

/home/shell/.ssh/authorized_keys
And I actually just updated. I'm really starting to think it's a problem with Arch. Thinking about it, I believe I've had the same problem on the same Arch box and never solved it due to ADD.

So thats not it, that seems legit.
Im still thinking its just some silly mistake somewhere eventhough I understand you retried everything.
I suggest you set loggin to DEBUG by ; LogLevel DEBUG
Than just keep watching journalctl -xn

[lucid]

Not that this is a great way to solve a problem, but I think I might be uninstalling Arch and installing FreeBSD on the thing. Mainly because I'm sick of Arch and it's hipster anti-linux ways. Also, as I've said before I've had this same problem with the same Arch box awhile ago that I never solved, and I'm starting to think it's some undiscoverable problem with Arch. Yet another reason is that I already have a main laptop, my Slackware laptop, and I don't need two fully loaded OS's. So I'm thinking I'm just going to install FreeBSD on the thing and use it as my SSH server.

Fuck this Arch bullshit.

[proxx]

Not that this is a great way to solve a problem, but I think I might be uninstalling Arch and installing FreeBSD on the thing. Mainly because I'm sick of Arch and it's hipster anti-linux ways. Also, as I've said before I've had this same problem with the same Arch box awhile ago that I never solved, and I'm starting to think it's some undiscoverable problem with Arch. Yet another reason is that I already have a main laptop, my Slackware laptop, and I don't need two fully loaded OS's. So I'm thinking I'm just going to install FreeBSD on the thing and use it as my SSH server.

Fuck this Arch bullshit.

ur debuggin skillz just blow

[lucid]

I fucking hate journalctl so damn much. I edited the sshd_config file to debug, and started journalctl -xn on the server. The first time it gave me some useful output. I accidentally closed the terminal, thus destroying the output, and now if I try again all I get is this useless bullshit:

pastebin.com/YUJwc9yN

What the fuck kind of useless shit is this. I swear, the first time I did it it gave me useful output pertaining to ssh. I'd be posting that if I hadn't lost the output. Now it just gives me this. What fucking luck. I've also tried journalctl -f, but that does nothing. I see no output, it just hangs there.

Fuck fucking systemd and it's stupid garbage. What is so wrong with having a nice little config file in /var/log?

EDIT: Holy shit! I am not exactly sure what I did but, it finally worked. I reedited the config file to this:
 pastebin.com/FPJ2bAhZ

On top of that, due to weirdness with home directory permissions I ran this on both users home dir:

Code: [Select]

chmod g-w /home/shell

That seemed to do it, because now I can connect just fine. Damn this was a bitch.

[proxx]

I fucking hate journalctl so damn much. I edited the sshd_config file to debug, and started journalctl -xn on the server. The first time it gave me some useful output. I accidentally closed the terminal, thus destroying the output, and now if I try again all I get is this useless bullshit:

pastebin.com/YUJwc9yN

What the fuck kind of useless shit is this. I swear, the first time I did it it gave me useful output pertaining to ssh. I'd be posting that if I hadn't lost the output. Now it just gives me this. What fucking luck. I've also tried journalctl -f, but that does nothing. I see no output, it just hangs there.

Fuck fucking systemd and it's stupid garbage. What is so wrong with having a nice little config file in /var/log?

EDIT: Holy shit! I am not exactly sure what I did but, it finally worked. I reedited the config file to this:
 pastebin.com/FPJ2bAhZ

On top of that, due to weirdness with home directory permissions I ran this on both users home dir:

Code: [Select]

chmod g-w /home/shell

That seemed to do it, because now I can connect just fine. Damn this was a bitch.

Nicely done Lucid, just never give up
Its always permissions! if its not that its DNS, just blaim DNS

[lucid]

if its not that its DNS, just blaim DNS

Heh, I usually just blame it on bad luck and mischievous midgets.

[N3mesis]

Hey lucid, I see that you solved this already, but I didnt see until now and found another solution in case your curious. sorry im late :/

I slapped your configs and user names into a virtual lab of arch virtual machines I have, and tested your problem. I had the same issue, it turned out to be a tiny config error. Basically what was happening was this:

My client sent a public key packet and waited for the server to accept. The server did not have the key in the specified authorized key folder(even though the public key was correct and in /home/shell/.ssh/authorized_keys), so the communication died right there since the client got no message from the server verifying the key.

The Fix: i specified the full path to authorized_keys in sshd_config like this: "AuthorizedKeysFile          /home/shell/.ssh/authorized_keys"

I believe the sshd process was running as root, so when it calls ~/.ssh/authorized_keys, it was looking in the root directory instead of shell home directory. Again, sorry im late but maybe this makes more sense and is a bit more clean...

Cheers

[lucid]

The Fix: i specified the full path to authorized_keys in sshd_config like this: "AuthorizedKeysFile          /home/shell/.ssh/authorized_keys"

I had actually tried that. Although I forgot to mention that in my debugging process. It didn't seem to have an effect.

[N3mesis]

Strange. all I did was change that line and run 'systemctl restart sshd' and it worked. Well, glad  you figured it out at least.