Question

SSH login problem , cannot login remotely over ssh

Posted June 22, 2016 21.7k views
Security Firewall

Hi , I cannot remote ssh to my droplet, only from within the digitalocean web based ssh client. I am also using webmin and openvpn.

I have

PasswordAuthenitcation yes

I get from osx

ssh: connect to host 178.x.x.x port 22: Connection refused

I have port 22 open with UFW inbound and outbound with tcp or udp

do i need to specify the external IP or have I broken something by trying to make RSA keys for login ?

My other services are working well, only ssh seams to have a problem. Any ideas would be much welcomed.

here is my ssh_config

# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
port 22
Protocol 1,2

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

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

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
systemctl reload sshd

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# 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_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

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

# Added by DigitalOcean build process
# Configured 20160504
ClientAliveInterval 120
ClientAliveCountMax 2
GatewayPorts yes
AllowTcpForwarding yes
KeepAlive yes

2 comments
  • Try SSHing using verbose mode ssh -v root@178.x.x.x and see if the debug logging gives you any hints as to the problem.

  • Did you restart the sshd server or reset the droplet after modifying sshd_config?

    service sshd restart
    

    or

    systemctl restart sshd
    

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

3 answers

Tried restarting both server droplet and sshd

$ ssh -v xyz@178.x.x.x
OpenSSH6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh
config
debug1: /etc/ssh/sshconfig line 20: Applying options for *
debug1: /etc/ssh/ssh
config line 102: Applying options for *
debug1: Connecting to 178.x.x.x [178.x.x.x] port 22.
debug1: connect to address 178.x.x.x port 22: Connection refused
ssh: connect to host 178.x.x.x port 22: Connection refused

I can use webmin, VPN, and other services.. port 22 is in the UFW list

could it be something worng wither certificates ? I’ve set config to allow login with usernames though..

wait, you do mean … service ssh restart ?

service sshd restart … returns … sshd: unrecognised service

ok, I found I could debug sshd with this command

$(which sshd) -Ddp 10222

I was not getting anything meaningful in the normal logs

this line in sshd_config was causing the $(which sshd) to terminate..

systemctl reload sshd

do I need this line ? or should it be commented out ? is it used in the normal droplet config or was it added by something I ran ?

never had an issue with sshd before !

  • @benyb - After removing “systemctl reload sshd” in the sshd_config file, did it work?

    • working ,

      maybe “systemctl reload sshd” comes from a pre upgraded version of ssh..
      who knows ,

      it should be “systemctl reload ssh” in the upgraded version maybe , but I’m not sure what this line actuallly does? restarts ssh in case of process crash ?

      anyway everything working now including CSF with openvpn administered in webmin so all good.

Submit an Answer