Other Unable to ssh

I'm unable to ssh into a system and suspect there is a block on access.

This is the output from nmap:-
Code:
root@S07:~ # nmap -p 22 192.168.1.7
Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-27 15:13 UTC
Nmap scan report for 192.168.1.7
Host is up (-0.18s latency).

PORT   STATE    SERVICE
22/tcp filtered ssh
MAC Address: 00:10:75:26:64:91 (Segate Technology)

Am I correct in thinking that the firewall is preventing access? Apparently port 2222 is also supposed to be used for access but that shows the same result.
 
Who is the owner of the system you're trying to access? If within your company, why not talk to your colleagues?
 
Correct. "filtered" generally means it's actively being blocked by a packet filter. You'll need to check your rules and logs on that system to see why/how it's being blocked and allow it as needed.
 
This poster is not asking about FreeBSD at all.

They are asking in context of a Linux-based OS, OpenWrt.

 
1. Make sure that an SSH server is configured and running on the host you want to connect to. You can start the server in interactive mode: /usr/sbin/sshd -D, also throw in some "-ddd" for more debug info.
2. Make sure your ssh server configuration /etc/ssh/sshd_config is correct. The default configuration works, but it forbids root logins, you can login only as a non-root user. Also before first use you need to generate server keys using "ssh-keygen".
3. Make sure your remote host's firewall allows incoming TCP on port 22 (default) or if you changed the port - adjust accordingly.
4. On another host start the SSH client: ssh -vvv serverhost This will start the client in super verbose mode.

You should be able to connect and enter your non-root user's password.

If you want to use keys instead of password, make sure to add the client's PUBLIC key on the server to ~/.ssh/authorized_keys. You can use the program ssh-copy-id which automates the process.
Very important! This has eaten countless man-hours: In order for the key login to work properly, make sure the access rights to ~/.ssh/authorized_keys on the server AND all its parent directories are secured properly (accessible only to the user and not for others). SSH is very picky about those permissions (for obvious security reasons) and if they are not fine, it just ignores the key and falls back to password.
 
Back
Top