Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

SSH troubleshooting

News SSH Recommended Links passwordless  login Software distribution FAQs
ssh-keygen man page scp sftp Tips Humor Etc

Among typical problems in configuring ssh we can mention the following

 


Introduction

Problems with ssh sometimes are very difficult to pinpoint. the problem is that they happened rarely and from one instance to another you typically forget everything you did to resolve the problem unless you keep a good documentation. 

In the absence of your own documentation (which is regrettable, and such situation should not repeat), you should generally proceed from simpler to more complex issues.

  1. Verity correctness of permissions of all files and directories
  2. Can you connect to the localhost from the same box ?
  3. Verify the  DNS name for the  box is correct and there is no duplicate IP and  such (this is a common problem for new installations, when somebody forget to check availability)
  4. Verify that you can connect to other similar boxes
  5. Run client with -v option, write protocols in the files and find the differences in two protocols
  6. Run client with -vvv option, write protocols in the files and find the differences in two protocols
  7. Do the  same with logs, extracting and comparing relevant  fragments with diff.
  8. Disable firewall and SE linux and see if it helps
  9. Take TCP dump and see what happening.

    tcpdump -n -i eth0 tcp port 22 and host [IP address of client]

In case you have problems with passwordless login the  steps are similar, but you also can disable strict checking to make troubleshooting simpler. 

Can't connect as root

Check the configuration parameter PermitRootLogin of the target server in /etc/ssh/sshd_config 

On some systems PermitRootLogin yes is default. On other it is not and needs to be changed.

Slow response of ssh

Sometimes ssh start ridiculously slow with the response delayed for 20 sec or so. This is typically due to broken DNS lookup, for example

us101:~/bin # nslookup 10.194.53.137 
Server: 10.201.88.197 
Address: 10.201.88.197#53 
 
** server can't find 137.53.194.10.in-addr.arpa: NXDOMAIN

Problem with passwordless login

If testing fails, try use ssh -v to see the messages generated and point of failure. Most often the problem is due to lack of of proper attention to details. Among most typical oversights: 

Two probably the most common mistakes in setting up passwordless login are as following

  1. Wrong permissions for authorized_keys file. Verify and, if necessary, reset permissions of authorized_keys on each remote host where you created or appended your public key to authorized_keys. You can use the following commands to ensure the right permissions are set:
    chmod 755 ~   # or 701 if you are restrictive about your home directory
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys
    SSH is very strict about the permissions that you have on your remote .ssh directory and the files in it. Typical problems with inability to login using your key are due to the write permissions for a group or world that you have on the file authorized_keys or .ssh directory at the remote server.
  2. You accidentally added public key to the file  known_hosts instead of authorized_keys   If you by mistake copy private key(s) to the file known_hosts instead of the file authorised keys you might troubleshoot the situation for a long time before you realize what went wrong.

Locating Server Configuration Files

For Linux the SSH server configuration files and keys are stored in the /etc/ssh directory.

Please don't' forget to backup sshd_config is you are making any changes to it.

Also please understand that commented out directives in this file show default value of the particular option so just uncommenting one of several of them changes nothing at all.  Default setting remains in place.

Dr. Nikolai Bezroukov

 


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Aug 03, 2017] centos - SELinux preventing ssh via public key

Notable quotes:
"... When I have SELinux enabled I am unable to ssh into the server using the public key. If I setenabled 0 , $USER can now log in. ..."
Jun 13, 2014 | unix.stackexchange.com

Q:

I have user $USER which is a system user account with an authorized users file. When I have SELinux enabled I am unable to ssh into the server using the public key. If I setenabled 0 , $USER can now log in.

What SELinux bool/policy should I change to correct this behaviour without disabling SELinux entirely?

It's worth noting that $USER can login with a password under this default SELinux configuration, I'd appreciate some insight as to what is happening here, and why SELinux isn't blocking that. (I will be disabling

A:

Assuming the filesystem permissions are correct on ~/.ssh/*, then check the output of
sealert -a /var/log/audit/audit.log

There should be a clue in an AVC entry there. Most likely the solution will boil down to running:
restorecon -R -v ~/.ssh

[Aug 03, 2017] SSH Permission denied on Correct Password Authentication - Super User

Aug 03, 2017 | superuser.com
could successfully SSH into my machine yesterday with the exact same credentials I am using today. The machine is running Centos 6.3 . But now for some reason it is giving me permission denied. Here is my -v print out, sshd_config, and ssh_config files.
$ ssh -vg -L 3333:localhost:6666 misfitred@devilsmilk
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to devilsmilk [10.0.10.113] port 22.
debug1: Connection established.
debug1: identity file /home/kgraves/.ssh/id_rsa type -1
debug1: identity file /home/kgraves/.ssh/id_rsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_dsa type -1
debug1: identity file /home/kgraves/.ssh/id_dsa-cert type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa type -1
debug1: identity file /home/kgraves/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
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 de:1c:37:d7:84:0b:f8:f9:5e:da:11:49:57:4f:b8:f1
debug1: Host 'devilsmilk' is known and matches the ECDSA host key.
debug1: Found key in /home/kgraves/.ssh/known_hosts:1
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,keyboard-interacti                                ve
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kgraves/.ssh/id_rsa
debug1: Trying private key: /home/kgraves/.ssh/id_dsa
debug1: Trying private key: /home/kgraves/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti                                ve
debug1: Next authentication method: password
misfitred@devilsmilk's password:
debug1: Authentications that can continue: publickey,password,keyboard-interacti                                ve
Permission denied, please try again.
misfitred@devilsmilk's password:
debug1: Authentications that can continue: publickey,password,keyboard-interacti                                ve
Permission denied, please try again.
misfitred@devilsmilk's password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).

Here is my sshd_config file on devilsmilk:

#   $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 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/local/bin:/bin:/usr/bin

# 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 ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require 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 2m
#PermitRootLogin yes 
StrictModes no
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs 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 yes
# 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 yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# 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 no

# Accept locale-related environment variables
#AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
#AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
#AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
#AcceptEnv XMODIFIERS

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

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /usr/libexec/openssh/sftp-server

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

And here is my ssh_config file:

#   $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm 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 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
#Host * 
# GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
    ForwardX11Trusted yes
# Send locale-related environment variables
    SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
    SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
    SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
    SendEnv XMODIFIERS

UPDATE REQUEST 1: /var/log/secure

Jan 29 12:26:26 localhost sshd[2317]: Server listening on 0.0.0.0 port 22.
Jan 29 12:26:26 localhost sshd[2317]: Server listening on :: port 22.
Jan 29 12:26:34 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:36:09 localhost pam: gdm-password[3029]: pam_unix(gdm-password:session): session opened for user misfitred by (uid=0)
Jan 29 12:36:09 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 12:36:11 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session2 (system bus name :1.45 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:53:39 localhost polkitd(authority=local): Operator of unix-session:/org/freedesktop/ConsoleKit/Session2 successfully authenticated as unix-user:root to gain TEMPORARY authorization for action org.freedesktop.packagekit.system-update for system-bus-name::1.64 [gpk-update-viewer] (owned by unix-user:misfitred)
Jan 29 12:54:02 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 12:54:06 localhost sshd[2317]: Received signal 15; terminating.
Jan 29 12:54:06 localhost sshd[3948]: Server listening on 0.0.0.0 port 22.
Jan 29 12:54:06 localhost sshd[3948]: Server listening on :: port 22.
Jan 29 12:55:46 localhost su: pam_unix(su:session): session closed for user root
Jan 29 12:55:56 localhost pam: gdm-password[3029]: pam_unix(gdm-password:session): session closed for user misfitred
Jan 29 12:55:56 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session2 (system bus name :1.45, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 12:55:58 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session3 (system bus name :1.78 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:56:29 localhost pam: gdm-password[4044]: pam_unix(gdm-password:auth): conversation failed
Jan 29 12:56:29 localhost pam: gdm-password[4044]: pam_unix(gdm-password:auth): auth could not identify password for [misfitred]
Jan 29 12:56:29 localhost pam: gdm-password[4044]: gkr-pam: no password is available for user
Jan 29 12:57:11 localhost pam: gdm-password[4051]: pam_selinux_permit(gdm-password:auth): Cannot determine the user's name
Jan 29 12:57:11 localhost pam: gdm-password[4051]: pam_succeed_if(gdm-password:auth): error retrieving user name: Conversation error
Jan 29 12:57:11 localhost pam: gdm-password[4051]: gkr-pam: couldn't get the user name: Conversation error
Jan 29 12:57:17 localhost pam: gdm-password[4053]: pam_unix(gdm-password:session): session opened for user misfitred by (uid=0)
Jan 29 12:57:17 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session3 (system bus name :1.78, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 12:57:17 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.93 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 12:57:49 localhost unix_chkpwd[4495]: password check failed for user (root)
Jan 29 12:57:49 localhost su: pam_unix(su:auth): authentication failure; logname=misfitred uid=501 euid=0 tty=pts/0 ruser=misfitred rhost=  user=root
Jan 29 12:58:04 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:16:16 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:18:05 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:21:14 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:21:40 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:24:17 localhost su: pam_unix(su:session): session opened for user misfitred by misfitred(uid=0)
Jan 29 13:27:10 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:28:55 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:28:55 localhost su: pam_unix(su:session): session closed for user misfitred
Jan 29 13:28:55 localhost su: pam_unix(su:session): session closed for user root
Jan 29 13:29:00 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 13:31:48 localhost sshd[3948]: Received signal 15; terminating.
Jan 29 13:31:48 localhost sshd[5498]: Server listening on 0.0.0.0 port 22.
Jan 29 13:31:48 localhost sshd[5498]: Server listening on :: port 22.
Jan 29 13:44:58 localhost sshd[5498]: Received signal 15; terminating.
Jan 29 13:44:58 localhost sshd[5711]: Server listening on 0.0.0.0 port 22.
Jan 29 13:44:58 localhost sshd[5711]: Server listening on :: port 22.
Jan 29 14:00:19 localhost sshd[5711]: Received signal 15; terminating.
Jan 29 14:00:19 localhost sshd[5956]: Server listening on 0.0.0.0 port 22.
Jan 29 14:00:19 localhost sshd[5956]: Server listening on :: port 22.
Jan 29 15:03:00 localhost sshd[5956]: Received signal 15; terminating.
Jan 29 15:10:23 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:10:38 localhost pam: gdm-password[4053]: pam_unix(gdm-password:session): session closed for user misfitred
Jan 29 15:10:38 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.93, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 15:11:21 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 15:11:32 localhost pam: gdm-password[2919]: pam_unix(gdm-password:session): session opened for user misfitred by (uid=0)
Jan 29 15:11:32 localhost polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session1 (system bus name :1.29, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Jan 29 15:11:33 localhost polkitd(authority=local): Registered Authentication Agent for session /org/freedesktop/ConsoleKit/Session2 (system bus name :1.45 [/usr/libexec/polkit-gnome-authentication-agent-1], object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Jan 29 15:15:10 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 15:30:24 localhost userhelper[3700]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'root'
Jan 29 15:32:00 localhost su: pam_unix(su:session): session opened for user misfitred by misfitred(uid=0)
Jan 29 15:32:23 localhost passwd: gkr-pam: changed password for 'login' keyring
Jan 29 15:32:39 localhost passwd: pam_unix(passwd:chauthtok): password changed for misfitred
Jan 29 15:32:39 localhost passwd: gkr-pam: couldn't change password for 'login' keyring: 1
Jan 29 15:33:06 localhost passwd: pam_unix(passwd:chauthtok): password changed for misfitred
Jan 29 15:33:06 localhost passwd: gkr-pam: changed password for 'login' keyring
Jan 29 15:37:08 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 15:38:16 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:38:16 localhost su: pam_unix(su:session): session closed for user misfitred
Jan 29 15:38:16 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:38:25 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 15:42:47 localhost su: pam_unix(su:session): session closed for user root
Jan 29 15:47:13 localhost sshd[4111]: pam_unix(sshd:session): session opened for user misfitred by (uid=0)
Jan 29 16:49:40 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 29 16:55:19 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
Jan 30 08:34:57 localhost sshd[4111]: pam_unix(sshd:session): session closed for user misfitred
Jan 30 08:34:57 localhost su: pam_unix(su:session): session closed for user root
Jan 30 08:35:24 localhost su: pam_unix(su:session): session opened for user root by misfitred(uid=501)
ssh permissions centos user-accounts openssh
share improve this question edited Jan 30 '13 at 13:40 asked Jan 29 '13 at 20:24 Kentgrav 743 16
1
Have you tried another user? Or changing the password for this one? – fboaventura Jan 29 '13 at 20:46
1
I agree with fboaventura; The configs look fine; try changing the password for your user to what you think it should be, also check that it isn't expired/account locked. And try another user just in case. Also, are you able to log in locally as that user? i.e. is the error specific to SSH or is it having an error via other auth mechs. – Justin Jan 29 '13 at 22:56
1
(1) caplock? (2) From server, post related error in /var/log/secure John Siu Jan 29 '13 at 23:18
@ fboaventura & Justin I did try another user and I also changed the password and tried it again with no success. I can login locally just fine and I can also SSH to localhost just fine. – Kentgrav Jan 30 '13 at 13:33
@ John Siu I added the /var/log/secure and I attempted the SSH right before I copied it. And nothing was added to it. Hope it helps. – Kentgrav Jan 30 '13 at 13:41
add a comment |
3 Answers active oldest votes
up vote 19 down vote server's /etc/ssh/sshd_config :
  1. To enable password authentication, uncomment
    #PasswordAuthentication yes
    
  2. To enable root login, uncomment
    #PermitRootLogin yes
    
  3. To enable ssh key login, uncomment
    #PubkeyAuthentication yes
    #AuthorizedKeysFile .ssh/authorized_keys
    

I believe (1) is what you're looking for.

share improve this answer edited Jul 10 '16 at 11:54 The Sexiest Man in Jamaica 113 answered Jan 30 '13 at 14:02 John Siu 4,542 10 20
Yeah I did this already I actually figured out what the problem was. And as I thought...it was the one thing that should have been blatantly obvious. – Kentgrav Jan 30 '13 at 16:08
2
For anyone else who is wondering you can find it sshd_config here: /etc/ssh/sshd_config – Oliver Dixon Aug 21 '15 at 9:20
The problem with this answer is that the defaults are commented out by default as the comments in the file explain. It doesn't matter if (1) is commented or not because the default is "yes". The correct answer is below. It's probably a DNS problem and can easily test by using the IP address instead of the domain name. – Colin Keenan Sep 18 '15 at 4:41
and you will have to restart the ssh service – Radu Gabriel May 24 at 12:56

[Aug 02, 2017] Why am I still getting a password prompt with ssh with public key authentication

Aug 02, 2017 | unix.stackexchange.com

Thom , asked Apr 16 '12 at 14:38

I'm working from the URL I found here:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

My ssh client is Ubuntu 64 bit 11.10 desktop and my server is Centos 6.2 64 bit. I have followed the directions. I still get a password prompt on ssh.

I'm not sure what to do next.

Rob , answered Apr 17 '12 at 15:28

Make sure the permissions on the ~/.ssh directory and its contents are proper. When I first set up my ssh key auth, I didn't have the ~/.ssh folder properly set up, and it yelled at me.

¹ Except on some distributions (Debian and derivatives) which have patched the code to allow group writability if you are the only user in your group.

Tgr , answered Nov 12 '12 at 7:55

If you have root access to the server, the easy way to solve such problems is to run sshd in debug mode, e.g.:
service ssh stop      # will not kill existing ssh connections
/usr/sbin/sshd -d     # full path to sshd executable needed, 'which sshd' can help
...debug output...
service ssh start

(If you can access the server through any port, you can just use /usr/sbin/sshd -d -p <port number> to avoid having to stop the SSH server. You still need to be root though.)

In the debug output, look for something like

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

cee , answered Sep 23 '12 at 9:31

Is your home dir encrypted? If so, for your first ssh session you will have to provide a password. The second ssh session to the same server is working with auth key. If this is the case, you could move your authorized_keys to an unencrypted dir and change the path in ~/.ssh/config .

What I ended up doing was create a /etc/ssh/username folder, owned by username, with the correct permissions, and placed the authorized_keys file in there. Then changed the AuthorizedKeysFile directive in /etc/ssh/config to :

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

This allows multiple users to have this ssh access without compromising permissions.

Sahil , answered Jul 3 '12 at 7:34

I faced challenges when the home directory on the remote does not have correct privileges. In my case the user changed the home dir to 777 for some local access with in the team. The machine could not connect with ssh keys any longer. I changed the permission to 744 and it started to work again.

gusior , answered Nov 7 '13 at 0:16

After copying keys to the remote machine and putting them inside the authorized_keys you've got to do something like this:
ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Ravindra , answered May 17 '13 at 8:46

Just try these following commands
  1. ssh-keygen

    Press Enter key till you get the prompt

  2. ssh-copy-id -i root@ip_address

    (It will once ask for the password of the host system)

  3. ssh root@ip_address

    Now you should be able to login without any password

David Mackintosh , answered Sep 8 '14 at 18:44

SELinux on RedHat/CentOS 6 has an issue with pubkey authentication , probably when some of the files are created selinux is not setting its ACLs correctly.

To manually fix the SElinux ACLs for the root user:

restorecon -R -v /root/.ssh

Joachim Nilsson , answered Nov 6 '14 at 9:34

We ran into the same problem and we followed the steps in the answer. But it still did not work for us. Our problem was that login worked from one client but not from another (the .ssh directory was NFS mounted and both clients were using the same keys).

So we had to go one step further. By running the ssh command in verbose mode you get a lot of information.

ssh -vv user@host

What we discovered was that the default key (id_rsa) was not accepted and instead the ssh client offered a key matching the client hostname:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277

Obviously this will not work from any other client.

So the solution in our case was to switch the default rsa key to the one that contained user@myclient. When a key is default, there is no checking for client name.

Then we ran into another problem, after the switch. Apparently the keys are cached in the local ssh agent and we got the following error on the debug log:

'Agent admitted failure to sign using the key'

This was solved by reloading the keys to the ssh agent:

ssh-add

,

It would be SSH miss configuration at server end. Server side sshd_config file has to be edited. Located in /etc/ssh/sshd_config . In that file, change variables

Based on http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

[Mar 04, 2017] shell - How to scp a folder from remote to local - Stack Overflow

Notable quotes:
"... Did not know about the config file, this is awesome! ..."
Feb 18, 2017 | stackoverflow.com
How to scp a folder from remote to local? [closed]
Ask Question up vote 1197 down vote favorite 340

I am not sure whether it is possible to scp a folder from remote to local, but still I am left with no other options. I use ssh to log into my server and from there I would like to copy the folder foo to home/user/Desktop (my local). Is there any command so that I can do this?

To use full power of scp you need to go through next steps:

  1. Public key authorisation
  2. Create ssh aliases

Then, for example if you'll have this ~/.ssh/config :


Host
 test
    
User
 testuser
    
HostName
 test
-
site
.
com
    
Port
22022
Host
 prod
    
User
 produser
    
HostName
 production
-
site
.
com
    
Port
22022

you'll save yourself from password entry and simplify scp syntax like this:


scp 
-
r prod
:/
path
/
foo 
/
home
/
user
/
Desktop
# copy to local

scp 
-
r prod
:/
path
/
foo test
:/
tmp            
# copy from remote prod to remote test

More over, you will be able to use remote path-completion:


scp test
:/
var
/
log
/
# press tab twice
Display
 all 
151
 possibilities
?
(
y or n
)

Update:

For enabling remote bash-completion you need to have bash-shell on both <source> and <target> hosts, and properly working bash-completion. For more information see related questions:

How to enable autocompletion for remote paths when using scp?
SCP filename tab completion

6
Did not know about the config file, this is awesome! dmastylo Mar 1 '14 at 20:27

What I always use is:


scp 
-
r username@IP
:/
path
/
to
/
server
/
source
/
folder
/
.

. (dot) : it means current folder . so copy from server and paste here only.

IP : can be an IP address like 125.55.41.311 or it can be host like ns1.mysite.com .

[may 11, 2014] linux - ssh_exchange_identification Connection closed by remote host (not using hosts.deny)

this can be configuration error but can be simply exceeded the ssh sessions to the server or high memory load ny other pallication. So high that ssh daemon can't find continues area of memory to start a new session. "If memory fragmenting is the apparent cause, the solution is to access the server via other means and to restart some of the pertinent services. I have found Apache and MySQL to be the culprit on VM's since VM's don't have a swap partition. Failing that, reboot the host."
Unix & Linux Stack Exchange
answered May 11 '14 at 12:43

If you have ruled out any "external" factors, the following set of steps usually helps to narrow it down. So while this doesn't directly answer your question, it may help tracking down the error cause.

Troubleshooting sshd

What I find generally very useful in any such cases is to start sshd without letting it daemonize. The problem in my case was that neither syslog nor auth.log showed anything meaningful.

When I started it from the terminal I got:

# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.

Much better! This error message allowed me to see what's wrong and fix it. Neither of the log files contained this output.

NB: at least on Ubuntu the $(which sshd) is the best method to satisfy sshd requirement of an absolute path. Otherwise you'll get the following error: sshd re-exec requires execution with an absolute path. The -p 10222 makes sshd listen on that alternative port, overriding the configuration file - this is so that it doesn't clash with potentially running sshd instances. Make sure to choose a free port here.

Finally: connect to the alternative port (ssh -p 10222 user@server).

This method has helped me many many times in finding issues, be it authentication issues or other types. To get really verbose output to stdout, use $(which sshd) -Ddddp 10222 (note the added dd to increase verbosity). For more debugging goodness check man sshd.

$(which sshd) -Ddp 10222 let me finally see what was causing my issue. Thanks a bunch! Cuga Feb 17 '15 at 16:40

duanev

I ran across the ssh_exchange_identification: read: Connection reset by peer problem in a script that starts 16 or more ssh sessions in a loop. sshd apparently can't keep up; adding a short sleep solved my problem:
for i in $(seq 32)
do
ssh -f root@$HOST "./test_server -p $(expr $BASE_PORT + $i)" > svr${i}.out
# for > 8 connections, ssh has ssh_exchange_identification issues
sleep 0.1
done

[Dec 01, 2003] Re: ssh without password does not work

From: UnixFan (gxy1997_at_yahoo.com.au)
Date: 12/01/03


Date: 30 Nov 2003 21:43:08 -0800
thomas.schwaerzler@gmx.at (tom) wrote in message news:<39553a0b.0311280601.1ef6ef57@posting.google.com>... 
> i got the following problem:
> i have a network with redhat 8.0 on about 7 machines and i need to run > ssh without password inside this network. In this network /home > directory is mounted from one server via nfs.
	> what i tried is this (with 2 machines(i call them localhost,remotehost)):  
> on localhost:
> cd .ssh
> ssh-keygen -t rsa
> ssh-keygen -t dsa
> scp *.pub user@remotehost:~/
> ssh remotehost -l user
> cat id_rsa.pub >> .ssh/authorized_keys
> cat id_dsa.pub >> .ssh/authorized_keys
> rm id_rsa.pub id_dsa.pub
> exit
> This did not work so i went on looking for hints in howtos and newsgroups and found:
? If above is not successful, check sshd configuration:
> vi /etc/ssh/sshd_config (on the Linux box)
> RSAAuthentication yes
> PubkeyAuthentication yes
>
> what i did on both hosts. but after restarting sshd (killall -HUP sshd
> und /etc/init.d/sshd restart), i had the same problem: could not connect without password.
>
> can anyone tell me what is going wrong here?
> thanx
> tom ...
>
> and here the configfiles in /etc/ssh/
> =====================================
>
> sshd_config
> ===========
>
> # $OpenBSD: sshd_config,v 1.56 2002/06/20 23:37:12 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/local/bin:/bin:/usr/bin
>
> # 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
> #Protocol 2,1
> #ListenAddress 0.0.0.0
> #ListenAddress ::
>
> # 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 3600
> #ServerKeyBits 768
>
> # Logging
> #obsoletes QuietMode and FascistLogging
> #SyslogFacility AUTH
> SyslogFacility AUTHPRIV
> #LogLevel INFO
>
> # Authentication:
>
> #LoginGraceTime 600
> #PermitRootLogin yes
> #StrictModes yes
>
> RSAAuthentication yes
> PubkeyAuthentication yes
> #AuthorizedKeysFile .ssh/authorized_keys
>
> # rhosts authentication should not be used
> #RhostsAuthentication no
> # Don't read the user's ~/.rhosts and ~/.shosts files
> #IgnoreRhosts yes
> # 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
>
> # To disable tunneled clear text passwords, change to no here!
> #PasswordAuthentication yes
> #PermitEmptyPasswords no
>
> # Change to no to disable s/key passwords
> #ChallengeResponseAuthentication yes
>
> # Kerberos options
> #KerberosAuthentication no
> #KerberosOrLocalPasswd yes
> #KerberosTicketCleanup yes
>
> #AFSTokenPassing no
>
> # Kerberos TGT Passing only works with the AFS kaserver
> #KerberosTgtPassing no
>
> # Set this to 'yes' to enable PAM keyboard-interactive authentication
> # Warning: enabling this may bypass the setting of
> 'PasswordAuthentication'
> #PAMAuthenticationViaKbdInt yes
>
> #X11Forwarding no
> X11Forwarding yes
> #X11DisplayOffset 10
> #X11UseLocalhost yes
> #PrintMotd yes
> #PrintLastLog yes
> #KeepAlive yes
> #UseLogin no
> #UsePrivilegeSeparation yes
> #Compression yes
>
> #MaxStartups 10
> # no default banner path
> #Banner /some/path
> #VerifyReverseMapping no
>
> # override default of no subsystems
> Subsystem sftp /usr/libexec/openssh/sftp-server
>
> ssh_config:
> ===========
>
> # $OpenBSD: ssh_config,v 1.15 2002/06/20 20:03:34 stevesk 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 various options
>
> # Host *
> # ForwardAgent no
> # ForwardX11 no
> # RhostsAuthentication no
> # RhostsRSAAuthentication no
> RSAAuthentication yes
> # PasswordAuthentication yes
> # BatchMode no
> # CheckHostIP yes
> # StrictHostKeyChecking ask
> # IdentityFile ~/.ssh/identity
> # IdentityFile ~/.ssh/id_rsa
> # IdentityFile ~/.ssh/id_dsa
> # Port 22
> # Protocol 2,1
> # Cipher 3des
> # Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
> # EscapeChar ~
> Host *
> ForwardX11 yes

A: Uncomment the "AuthorizedKeysFile .ssh/authorized_keys" line.


Troubleshooting SSH Problems on Sun Solaris

Sun Microsystems

This section contains descriptions of and solutions to the problems most frequently encountered when using Secure Shell.

  1. Server Does Not Produce Log File Output

    By default, sshd produces auth.info-level messages. The default configuration of syslogd(1M) ignores these. syslog.conf(4) must have an entry added for these messages. Then, the log file needs to be created, and syslogd needs a HUP signal, as in the following example.

     # grep auth.info /etc/syslog.conf
     auth.info     /var/adm/sshd.log
     # touch /var/adm/sshd.log
     # pkill -HUP syslogd
    

    Note

    A tab must separate the two fields.

    If debugging information is needed, add an entry for auth.debug.

  2. Public Key Authentication Is Not Working

    Verify that the public key is in the remote ~/.ssh/authorized_keys file and that the file is neither group nor world writable. See "Debugging a Secure Shell Connection" on page 110 for more information.

  3. Trusted Host Authentication Is Not Working

    Verify that this feature has not been disabled in the sshd_config file and that ssh(1) is installed as setuid root.

  4. X Forwarding Is Not Working

    Verify the following:

    • X11Forwarding has been set to yes in the sshd_config file on the destination server.
    • X forwarding has been enabled on the client by ForwardX11 being set to yes in the ssh_config file or by ssh(1) being executed with the -X option.
    • UseLogin has been set to no.
    • The $DISPLAY environment variable has been set correctly.
  5. Wildcards and Shell Variables Fail on the scp(1)

    Wildcards and shell variables must be escaped, or the local shell will expand them, as in the following example:

    $ scp panther@mainwaring:${HOME}/public_html/ssh
    .html /tmp/toast
     panther@mainwaring's password: password scp: 
    /home/panther/public_html/ssh.html: No such file or
     directory
     $ scp panther@mainwaring:\$\{HOME\}/public_html
    /ssh.html /tmp/toast
     panther@mainwaring's password: password ssh.html 
                100% |*****************************| 
     3529        00:00
    
  6. Superuser (root) Is Unable to Log In >

    To permit superuser logins, the PermitRootLogin keyword must be set to yes in the sshd_config file.

    Note

    If root is a role in the role-based access control model, then the value of PermitRootLogin is overridden by pam_roles(5).

  7. Startup Performance Is Slow

    Verify that ssh(1) is using /dev/urandom by using TRuss to check that /dev/urandom is opened successfully, as in the following example.

    $ truss -t open -o /tmp/ssh.trace ssh localhost
     <either login then logout or let the connection
     timeout>
     $ grep random /tmp/ssh.trace
     open64("/dev/urandom", O_RDONLY)                 
      = 5
     open("/dev/urandom", O_RDONLY)                   
      = 6
  8. Protocol 1 Clients Are Unable to Connect to Solaris Secure Shell Systems

    By default, the Solaris Secure Shell software disables Protocol 1. Comment out the Protocol 2 line with a hash (#) symbol. Uncomment the Protocol 2,1 line. Restart the sshd(1M) daemon by sending the HUP signal.

    The following example shows the Solaris Shell defaults:

     # Only v2 (recommended)
     Protocol 2

    The following example shows how to enable Protocol 1:

     # Only v2 (recommended)
     # Protocol 2
     #
     # Both v1 and v2 (not recommended)
     Protocol 2,1
  9. Privilege Separation Does Not Work in the Solaris Secure Shell Software

    This functionality does not currently exist.

  10. cron(1M) Is Broken

    OpenSSH lacks integration into BSM by not correctly assigning an audit ID. This causes both BSM and cron(1M) to fail when a crontab entry is edited. A workaround for crontab editing is to use Telnet to connect to the local host through the loopback interface. Telnet will invoke login(1), which sets the audit ID correctly. The Solaris Secure Shell software does not have this problem.

  11. Message-of-the-Day Is Displayed Twice

    By default, PrintMotd is set to yes in the sshd_config file. In the Solaris OE, the login shell is expected to display the message-of-the-day. The Secure Shell daemon should not display it. Set PrintMotd to no to stop this behavior.

  12. Debugging a Secure Shell Connection

    When sessions are encrypted, debugging tools such as tcpdump(1M) and truss(1) provide less assistance. On the client, debug information is generated with the -v flag. Up to three -v flags can be used to increase the debugging information verbosity. The flag for the server is -d. Alternatively, the level of debugging information can be set using the LogLevel keyword in the configuration file (~/.ssh/config for the client and sshd_config for the server).

    The following example shows debugging on the command line:

     $ ssh -v -v -v bonnet

    The following example shows how to set up debugging by using the ~/.ssh/config or sshd_config file:

     LogLevel DEBUG
  13. Understanding Differences in OpenSSH and Solaris Secure Shell Software

    The Solaris Secure Shell software has BSM support, proxy commands (ssh-socks5-proxy-connect and ssh-http-proxy-connect), localization and internationalization support, and configurable login attempts (MaxAuthTries and MaxAuthTriesLog). OpenSSH does not support these features. OpenSSH supports privilege separation and additional ciphers that Solaris Secure Shell software does not support.

  14. Integrating Solaris Secure Shell and SEAM (Kerberos)

    Presently, there is no integration between the Solaris Secure Shell software and SEAM.

  15. Forcing Remote X11 Users to Use Secure Shell Sessions

    For Solaris 9 OE systems, add -nolisten tcp to Xsun in /usr/dt/config/Xservers, then restart the X daemon. Make sure to preserve a copy of Xservers to maintain changes in case of patches or OS upgrades.

  16. Determining the Server Version String

    When clients connect, the server identifies itself with a version string. Connecting by Telnet to the server and sending a carriage return will return the version string and close the connection, as in the following example.

     $ (sleep 1; print "\n") |telnet localhost 22
     Trying 127.0.0.1...
     Connected to localhost.
     Escape character is '^]'.
     SSH-2.0-Sun_SSH_1.0
     Connection to localhost closed by foreign host.
  17. Altering the Server Version String

    In OpenSSH, the version string can be altered by editing the value of SSH_VERSION in version.h before compilation. Changing the version string to obscure the specific OpenSSH release risks breaking clients that use the version string to work around server bugs. The version string cannot be changed in the Solaris Secure Shell software.

  18. CERT Advisory CA-2002-18

    The default configuration of the Solaris Secure Shell software is not believed to be vulnerable. To be vulnerable, sshd_config must be updated to contain the following:

     PAMAuthenticationViaKBDInt yes
     KbdInteractiveAuthentication yes

    The default for KbdInteractiveAuthentication is no. Patch ID 113273 fixes this problem.