SSH troubleshooting

Among typical problems in configuring ssh we can mention the following

• Introduction
• Can't connect as root
• Slow response of ssh
• Problem with passwordless login
• Locating Server Configuration Files

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: 

• You forgot to add public key to authorized_keys file on the target host

• Wrong ownership of the file  authorized_keys on the target host For example root:root for oracle user.

• Wrong permissions of the file  authorized_keys on the target host. For example 755. This is the most common mistake.

• You accidentally added public key to the file  known_hosts instead of authorized_keys
• You have incorrect settings in /etc/ssh/sshd_config file (should use protocol version 2 and allow RSA keys if they are used). If root login is passwrdless (dangerous !) then PermitRootLogin should be set to yes on all target  hosts.

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

NEWS CONTENTS

• 20170803 : centos - SELinux preventing ssh via public key ( Jun 13, 2014 , unix.stackexchange.com )
• 20170803 : SSH Permission denied on Correct Password Authentication - Super User ( Aug 03, 2017 , superuser.com )
• 20170802 : Why am I still getting a password prompt with ssh with public key authentication ( Aug 02, 2017 , unix.stackexchange.com )
• 20170304 : shell - How to scp a folder from remote to local - Stack Overflow ( Feb 18, 2017 , stackoverflow.com )
• 20140511 : linux - ssh_exchange_identification Connection closed by remote host (not using hosts.deny) ( Unix & Linux Stack Exchange )
• 20140511 : Troubleshooting SSH Problems on Sun Solaris ( Sun Microsystems )
• 20031201 : Re: ssh without password does not work ( Dec 01, 2003 )

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,[email protected],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 : To enable password authentication, uncomment #PasswordAuthentication yes To enable root login, uncomment #PermitRootLogin yes 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.

• Your home directory ~ , your ~/.ssh directory and the ~/.ssh/authorized_keys file on the remote machine must be writable only by you: rwx------ and rwxr-xr-x are fine, but rwxrwx--- is no good¹, even if you are the only user in your group (if you prefer numeric modes: 700 or 755 , not 775 ).
  If ~/.ssh or authorized_keys is a symbolic link, the canonical path (with symbolic links expanded) is checked .
• Your ~/.ssh/authorized_keys file (on the remote machine) must be readable (at least 400), but you'll need it to be also writable (600) if you will add any more keys to it.
• Your private key file (on the local machine) must be readable and writable only by you: rw------- , i.e. 600 .
• Also, if SELinux is set to enforcing, you may need to run restorecon -R -v ~/.ssh (see e.g. Ubuntu bug 965663 and Debian bug report #658675 ; this is patched in CentOS 6 ).

¹ _{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

• 'yes' to 'no' for ChallengeResponseAuthentication, PasswordAuthentication, UsePAM
• 'no' to 'yes' for PubkeyAuthentication

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

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.

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

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

• Next message: UnixFan: "Re: ftp not reading batch file correctly"
• Previous message: Bill Heafey: "Re: Logging failed login attempts?"
• Next in thread: tom: "Re: ssh without password does not work"
• Maybe reply: tom: "Re: ssh without password does not work"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

---

Date: 30 Nov 2003 21:43:08 -0800
[email protected] (tom) wrote in message news:<[email protected]>... 

	> 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.

---

• Next message: UnixFan: "Re: ftp not reading batch file correctly"
• Previous message: Bill Heafey: "Re: Logging failed login attempts?"
• Next in thread: tom: "Re: ssh without password does not work"
• Maybe reply: tom: "Re: ssh without password does not work"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

• RE: SSH Access Issues
  ... # This is the ssh client system-wide configuration file. ... # Kerberos TGT Passing only works with the AFS kaserver ...
  (Fedora)
• Re: ssh2 hostbased auth fails
  ... Actually the ssh client works fine,the problem is the scp and sftp client. ... Here is my configuration file. ... # To disable tunneled clear text passwords, ... # Kerberos TGT Passing does only work with the AFS kaserver ...
  (SSH)
• PasswordAuthentication no doesent work
  ... Only passwords should not be allowed at all. ... I'm reading something like that at the book "SSH - the definitive ... RhostsRSAAuthentication no ... # Kerberos TGT Passing does only work with the AFS kaserver ...
  (comp.security.ssh)
• ssh without password does not work
  ... ssh without password inside this network. ... # This is the sshd server system-wide configuration file. ... # Kerberos TGT Passing only works with the AFS kaserver ... 'PasswordAuthentication' ...
  (comp.security.ssh)
• Re: messages in which logfile?
  ... section (preferably in some configuration file, but in /etc/rc if need be), and boot the machine. ... (Provided you can still ssh into the machine without kerberos, and so on - of course, this ...
  (comp.unix.bsd.openbsd.misc)

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Troubleshooting SSH Connections - RACF

ssh Connection refused how to troubleshoot - Unix & Linux Stack Exchange

How to Troubleshoot SSH Connectivity Issues (N1 Service Provisioning System 4.1 Installation Guide)

Unixlore.net - Linux and Unix Commandline tips, hacks and howtos

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: December, 26, 2017