-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 18:50 +0100, gumb wrote:
ssh newbie question:
I only know the very basics of ssh (and next to nothing useful of Linux security). When I access a remote openSUSE machine using a private key previously exchanged, as opposed to a basic password (note: the remote PC has a very 'standard' configuration and its firewall is activated), I usually check the system log in YaST and apply a filter 'ssh' starting from my previous date of access.
You can do this from the terminal without YaST. For instance: journalctl | grep -i ssh | less If you want to do this as user, not root, add your user to the group "systemd-journal" using Yast, users and groups management module, and login again.
On this occasion I see something alien in the log. It appears to be just a failed attempt at unauthorized access. There are two entries from two separate dates. Example:
kernel │SFW2-INext-ACC-TCP IN=eth0 OUT= MAC={big-long-mac-address} SRC=5.8.18.70 DST=192.168.1.64 LEN=52 TOS=0x02 sshd[4243] |Bad protocol version identification '\003' from 5.8.18.70 port 526
Well, somebody tried to access but failed. Not to worry about.
I did a search for this IP address and see this page: https://www.abuseipdb.com/check/5.8.18.70 which has several recent abuse reports.
Without getting into complex nerdy affairs, what should my next simple step be? I assume I should only be concerned if I see a line suggesting a new ssh session was opened by somebody other than me? Or is there anything else I should keep a lookout for in future?
There is nothing to worry about :-) However, you may go one step further to avoid this, which as already suggested, is placing your ssh server in any very high port of your choosing. They will simply not find you unless they are specifically trying to access your machine and do a serious scan. If you have, as most people, an access router, the place to do this is in the router. Say you want to move to the port 37453. Well, you configure your router to send incoming access to port 37453 to the internal machine 192.168.1.64 at port 22. That's all on the server side. On the client side, however, you must tell the ssh client to connect on port 37453. You can edit the client file .ssh/config Host yourserver.at.dyndns Port 37453 and it will happen automatically. Of course, you have to test all this work before breaking the current session, and be locked out; or do it while you have physical access to the server machine. There are other methods; what I described is for hardware under your full control, usually at home. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpP6CkACgkQtTMYHG2NR9UNmQCfYYpptvMB2QkzXJwI8LgzqQdz 6V8AnAn5L9L80u57uHI4jMs28TUumsDP =DbjS -----END PGP SIGNATURE-----