With sshd service it's pretty straight forward to set up and get going.
1. Start service
Make sure that the service is up and running/listening on port 22.
start service
$ sudo systemctl start sshd
check status
$ sudo systemctl status sshd
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-07-24 22:24:00 EDT; 1h 40min left
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1270 (sshd)
Tasks: 1
CGroup: /system.slice/sshd.service
└─1270 /usr/sbin/sshd -D
Jul 24 22:24:00 centos7 systemd[1]: Starting OpenSSH server daemon...
Jul 24 22:24:00 centos7 systemd[1270]: Executing: /usr/sbin/sshd -D
Jul 24 22:24:00 centos7 sshd[1270]: Server listening on 0.0.0.0 port 22.
Jul 24 22:24:00 centos7 sshd[1270]: Server listening on :: port 22.
Jul 24 22:24:00 centos7 systemd[1]: Started OpenSSH server daemon.
Jul 24 20:31:37 centos7 sshd[1582]: Accepted publickey for vagrant from 10.0.2.2 port 64437 ssh2: RSA SHA256:1vJymfZsu2KZ49lDftGMzz2VEb2Z2Y8PNi9cs55eHGE
Jul 24 20:43:29 centos7 systemd[1]: Trying to enqueue job sshd.service/start/replace
Jul 24 20:43:29 centos7 systemd[1]: Installed new job sshd.service/start as 560
Jul 24 20:43:29 centos7 systemd[1]: Enqueued job sshd.service/start as 560
Jul 24 20:43:29 centos7 systemd[1]: Job sshd.service/start finished, result=done
2. Verify service is listening
check if listening on port 22
$ sudo netstat -tlpn | grep sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1270/sshd
tcp6 0 0 :::22 :::* LISTEN 1270/sshd
You'll also want to verify that sshd is listening on either all interfaces (0.0.0.0) or at least your system's IP address:
$ ip a l eth0 | awk '/inet / {print $2}'
192.168.56.101/24
So you'd see in the netstat output, 192.168.56.101:22, for eg.
3. Firewall
Next check that the firewall is allowing network traffic to reach port 22.
$ sudo firewall-cmd --list-all
FirewallD is not running
If it's like this, then traffic can reach port 22. If it looks like this:
$ firewall-cmd --list-all
public (active)
target: DROP
icmp-block-inversion: no
interfaces: eth0 eth1
sources:
services: ssh dhcpv6-client
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
It's allowing traffic for the ssh & dhcpv6-client services and dropping for everything else. Again this is OK and should allow SSH traffic in.
4. Check /etc/ssh/sshd_config
Verify that your /etc/ssh/sshd_config is not blocking external connections. The following options should be set similar to what I'm showing below.
$ grep -vE '^#|^$|AcceptEnv|HostKey|Syslog|MAC|Banner|LogLevel|Authorized' /etc/ssh/sshd_config
PermitRootLogin yes
MaxAuthTries 4
HostbasedAuthentication no
IgnoreRhosts yes
PermitEmptyPasswords no
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding no
Subsystem sftp /usr/libexec/openssh/sftp-server
Protocol 2
5. Verify
You can confirm using a command like this from one of your external clients:
$ timeout 2 curl -v telnet://192.168.56.101:22
* Rebuilt URL to: telnet://192.168.56.101:22/
* Trying 192.168.56.101...
* Connected to 192.168.56.101 (192.168.56.101) port 22 (#0)
SSH-2.0-OpenSSH_7.4
$
NOTE: If you see a 'Connected to X.X.X.X' IP address message here, there is nothing inhibiting your network traffic from the client machine where you're running curl to the sshd server.
6. Docker
In some situations, such as where Docker has been installed, you'll run into a scenario where the docker0 bridge has added multiple virtual networks within the docker0 bridge. You can see them like so:
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
bd7594c1dce3 bridge bridge local
db24b1e2be58 host host local
edf606d533a5 none null local
In these situations you'll need to remove any extra networks to restore your physical network, so that it's able to route SSH packets correctly. Simply use the command docker network rm <net id> to remove anything beyond the standard bridge, host, and none.
References
