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. 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 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? gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/05/2018 09:50 AM, 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.
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
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?
gumb
If you see a line suggesting a new/unknown ssh connection was opened you should be concerned. But so far you've posted nothing that suggests that has happened. Yes, something tried to connect, but it did not succeed. Script-kiddies gonna script!! You can prevent them from filling your logs by moving your ssh port to some unusual port. Its no more secure, just fewer attempts for your sshd to fend off (because script kiddies seldom scan oddball port numbers like 38749 or some such. And its wise to only allow private key as you currently do. You've already taken the best step. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/01/18 21:30, John Andersen wrote:
If you see a line suggesting a new/unknown ssh connection was opened you should be concerned. But so far you've posted nothing that suggests that has happened.
Yes, something tried to connect, but it did not succeed. Script-kiddies gonna script!!
You can prevent them from filling your logs by moving your ssh port to some unusual port. Its no more secure, just fewer attempts for your sshd to fend off (because script kiddies seldom scan oddball port numbers like 38749 or some such.
And its wise to only allow private key as you currently do. You've already taken the best step.
Okay thanks. So far so good then. I've always had a high port number set instead of 22. Maybe somebody was scanning a range and hit lucky this time. gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/01/18 12:50 PM, gumb wrote:
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?
The next simple step is to run CLI SSH with debug/verbose turned on: -v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3. If that does not enlighten you as to what is going on and let you make progress, then report it here and the Group Mind will advise :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/01/18 21:34, Anton Aylward wrote:
The next simple step is to run CLI SSH with debug/verbose turned on:
-v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3.
If that does not enlighten you as to what is going on and let you make progress, then report it here and the Group Mind will advise :-)
That could be useful. Or indeed, that could have been useful, just the other week when I was at the other location. I was trying to set up ssh in the other direction to my main machine that I'd left switched on at home, but for some reason couldn't get it to work, despite all configs being effectively the same, and both ends running the same openSUSE version. The ssh-copy-id command would just hang and time out with some error I forget what. With previous occasional home power cuts in mind, I suspected I might arrive back and find the PC turned off, but no, it was on. I couldn't see anything obvious in the logs either. So I'm suspecting the router/ISP at my home end might be the culprit, but haven't looked into it enough yet. I assume some kind of 'reverse ssh' is a thing that exists, i.e. if I can ssh into the remote machine, I could attempt to configure and start a connection in the other direction from within that ssh session? gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, 2018-01-05 at 22:25 +0100, gumb wrote:
On 05/01/18 21:34, Anton Aylward wrote:
The next simple step is to run CLI SSH with debug/verbose turned on:
-v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3.
If that does not enlighten you as to what is going on and let you make progress, then report it here and the Group Mind will advise :-)
That could be useful. Or indeed, that could have been useful, just the other week when I was at the other location. I was trying to set up ssh in the other direction to my main machine that I'd left switched on at home, but for some reason couldn't get it to work, despite all configs being effectively the same, and both ends running the same openSUSE version. The ssh-copy-id command would just hang and time out with some error I forget what.
With previous occasional home power cuts in mind, I suspected I might arrive back and find the PC turned off, but no, it was on. I couldn't see anything obvious in the logs either. So I'm suspecting the router/ISP at my home end might be the culprit, but haven't looked into it enough yet.
I assume some kind of 'reverse ssh' is a thing that exists, i.e. if I can ssh into the remote machine, I could attempt to configure and start a connection in the other direction from within that ssh session?
If worse comes to worse, you could look at something free like ZeroTier to let you create your own VPN connection. They've got a free version that's really well-featured, and works around NATted internet connections too.
gumb
-----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlpP85MACgkQQ1nEo4DF CIWrfwf/cgjYh4mbIH/PdnNCX778z/DViuis5XulHGmgVbLlUkIDT+lOzciu/Vja e7C5aQWmQs/F8PVf5iERUcv6JDy4l8t+QIh7tzBPbKSVqBMONq/zg+Nl+iSzsasr 9R6F5lwhABtKmXhNxoyO/FtODH2hGoEylWB7OREVnsTs2xf3haNps+agc50BKLtn mtlpv7oST0IhVF4swXr09zkhU2rSvAGTvs76eHK/+WwhG3yfs2JkpPHyZym5+7jN u8Df5/U6ne4jFtuWEIdYjJNXSEK8cSeqVg+IKc5JtusOSQxwYdi6HEtc/e3Tv2kT 2QKrIA/v2Cws/shVfy8Ubjg5uvK29A== =tZZ3 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <alpine.LSU.2.21.1801052304251.425@Telcontar.valinor> On Friday, 2018-01-05 at 22:25 +0100, gumb wrote:
I assume some kind of 'reverse ssh' is a thing that exists, i.e. if I can ssh into the remote machine, I could attempt to configure and start a connection in the other direction from within that ssh session?
Find this post in the archive: :-) Date: Thu, 8 Sep 2016 12:10:43 -0400 From: Greg Freemyer <> Cc: suse <opensuse@opensuse.org> Subject: Re: [opensuse] ssh questions Message-ID: <CAGpXXZ+C+PVLcqC2QNTCqsymb=kZXJDs=pStY42SyNrZ+4_ogg@mail.gmail.com> - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpP9rsACgkQtTMYHG2NR9VKgACeOvwFY9RoEE3R6gJEEfXtQL4n KfcAnRkEEe3uDctAbRICa2E0j8ipkR9N =nApO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/01/18 23:05, Carlos E. R. wrote:
On Friday, 2018-01-05 at 22:25 +0100, gumb wrote:
I assume some kind of 'reverse ssh' is a thing that exists, i.e. if I can ssh into the remote machine, I could attempt to configure and start a connection in the other direction from within that ssh session?
Find this post in the archive: :-)
Date: Thu, 8 Sep 2016 12:10:43 -0400 From: Greg Freemyer <> Cc: suse <opensuse@opensuse.org> Subject: Re: [opensuse] ssh questions Message-ID: <CAGpXXZ+C+PVLcqC2QNTCqsymb=kZXJDs=pStY42SyNrZ+4_ogg@mail.gmail.com>
Ah yes :-D Hmm, took me a while to track down the exact post in the web archive, where the times are marginally different. I only keep 3 months' worth of ML posts in my personal email. Whilst I do 'star' relevant messages and those I create myself or contribute to, along with useful replies, and have the setting 'Always keep starred messages' checked, one of the few flaws I can cite in Thunderbird is that for some reason from time to time it likes to override or revert this setting and stick the middle finger up at me, so most of what I've ever tried to keep a copy of in the past has disappeared. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 23:25 +0100, gumb wrote:
On 05/01/18 23:05, Carlos E. R. wrote:
On Friday, 2018-01-05 at 22:25 +0100, gumb wrote:
I assume some kind of 'reverse ssh' is a thing that exists, i.e. if I can ssh into the remote machine, I could attempt to configure and start a connection in the other direction from within that ssh session?
Find this post in the archive: :-)
Date: Thu, 8 Sep 2016 12:10:43 -0400 From: Greg Freemyer <> Cc: suse <opensuse@opensuse.org> Subject: Re: [opensuse] ssh questions Message-ID: <CAGpXXZ+C+PVLcqC2QNTCqsymb=kZXJDs=pStY42SyNrZ+4_ogg@mail.gmail.com>
Ah yes :-D
Hmm, took me a while to track down the exact post in the web archive, where the times are marginally different. I only keep 3 months' worth of ML posts in my personal email. Whilst I do 'star' relevant messages and those I create myself or contribute to, along with useful replies, and have the setting 'Always keep starred messages' checked, one of the few flaws I can cite in Thunderbird is that for some reason from time to time it likes to override or revert this setting and stick the middle finger up at me, so most of what I've ever tried to keep a copy of in the past has disappeared.
(that thread might have other interesting content for you) I keep email as mbox archives, accessed via my own local imap server (dovecot), so that I can read them with Thunderbird or Alpine or anything else. I do trust Alpine to keep archives, but not Thunderbird - so I use dovecot instead for both. In this case, the post I referred to was archived in a folder named "_important/ssh", so that it was trivial to find it. Just a grep for "reverse". :-) Locating it up on the web would take a bit longer, so I left that to you ;-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpQBLoACgkQtTMYHG2NR9WzigCfSHsqo7A5hhdYd6PkbkKykevq xB4An08f3QrmmwEYLGgZsrorU+HmdU21 =g4TN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, 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.
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
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?
gumb
If this system is accessible on the internet, and needs to stay that way, you might want to do a couple of things -- First, don't have it listen on port 22. Whether through your firewall or the server itself, make SSH respond on some random high port, like 6022, or 60022, or something like that. (If through SSH directly, the line in sshd_config is "Port 22" (no quotes; remove the # at the front if there is one.) Second, seriously consider doing something like fail2ban, so that multiple invalid attempts will result in their IP address being outright blocked. This will help prevent brute-forcing a connection. Third, make absolutely sure that you have root logins and password- based logins disabled (aka, ONLY key logins.) These are the lines in sshd_config that you'd set: PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no UsePAM no ChallengeResponseAuthentication no After making any changes to the config file, do "service sshd restart" (no quotes) If you do the port number change, do it first and test it. Then leave that session open if you do any other changes. CRITICAL: IF YOU CHANGE THE AUTHENTICATION MECHANISMS, BEFORE CLOSING YOUR SSH SESSION, MAKE SURE THAT YOU CAN OPEN A SECOND SESSION AND CONNECT SUCCESSFULLY! That way if you messed up the config, you won't have locked yourself out of your box, and can fix things. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlpP4aYACgkQQ1nEo4DF CIVLWgf/bscoPSkbHJWCjqPqt/vus1vOpcfMQhVTOgNQSWrcVGdpg+BHEMTm6UUS eMwSk++FzIeofa+CH8SSl2VHpHV53x8MICLt2yv+lRNzyKyFFt8Z2WIRASBQwdyL uHceu6xrYyXf2ENvDf4gU4PQLjVgkxhxhNkNrbUeZC7ac18nqgsifiAakQNs2FyW 4qrO6yJeOGUUxOvue/7Rxdm4kvrc4yTRol43bR4XlRYVuSaZJMSkHkSjkmON0+g1 TIjGyMIekVQmF2svRj1+wPgWw565C18nBsqH7i6tdrqsvBxYlpokImGmitCOemvx oj7fh9qy57OLbWStSB+ESJvLNP53XQ== =1GQL -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, 2018-01-05 at 14:35 -0600, Christopher Myers wrote:
On Fri, 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.
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
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?
gumb
If this system is accessible on the internet, and needs to stay that way, you might want to do a couple of things --
First, don't have it listen on port 22. Whether through your firewall or the server itself, make SSH respond on some random high port, like 6022, or 60022, or something like that. (If through SSH directly, the line in sshd_config is "Port 22" (no quotes; remove the # at the front if there is one.)
Second, seriously consider doing something like fail2ban, so that multiple invalid attempts will result in their IP address being outright blocked. This will help prevent brute-forcing a connection.
Third, make absolutely sure that you have root logins and password- based logins disabled (aka, ONLY key logins.) These are the lines in sshd_config that you'd set: PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no UsePAM no ChallengeResponseAuthentication no
After making any changes to the config file, do "service sshd restart" (no quotes)
If you do the port number change, do it first and test it. Then leave that session open if you do any other changes.
CRITICAL: IF YOU CHANGE THE AUTHENTICATION MECHANISMS, BEFORE CLOSING YOUR SSH SESSION, MAKE SURE THAT YOU CAN OPEN A SECOND SESSION AND CONNECT SUCCESSFULLY! That way if you messed up the config, you won't have locked yourself out of your box, and can fix things.
OH -- And, if you want some extra peace of mind, add something like the following to the file /etc/ssh/sshrc (create the file if it doesn't exist) :: ip=`echo $SSH_CONNECTION | cut -d " " -f 1` logger -t ssh-wrapper $USER login from $ip echo "User $USER just logged in from $ip" | mail -s 'SSH server logged into!' username@domain.com & Every time anyone logs into that server via SSH, you'll get an email to that username@domain.com about it (assuming you have email set up successfully.) - From "man ssh", under the "FILES" section -- /etc/ssh/sshrc Commands in this file are executed by ssh when the user logs in, just before the user's shell (or command) is started. See the sshd(8) manual page for more information. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlpP5NwACgkQQ1nEo4DF CIVrhgf/Seo63UMakrnzitZhCLhi7i5xycnto5TuI1ppfXx9lyDBs1y3sXZlYB+8 hCXIPHDM2g3YxgK0MA60uuIcinZRbQAjTvBMRV2PULocrX0UckSoGEeAjToQ/vNR lkZWvx+RLSP4jFNgMc7gwHxjXemVDL4IfCzYkfigE9AYo9fybHyuZCOaeprAgkyR 0dFtEczBSGC0875TeleF8klk1DkNHGCkXY/UR0MLOQiulnctaPoSa+swhvIeipqr RYTt59YDJKLp6PL/DlsASOvnk0rreq2b9erVpkdyZkNgMhQduR5wuprxCEqVWBA9 KNDnTH4VN7Ee8k0UMsABlQ2GET/j7g== =bysH -----END PGP SIGNATURE-----
On 05/01/18 21:35, Christopher Myers wrote:
If this system is accessible on the internet, and needs to stay that way, you might want to do a couple of things --
First, don't have it listen on port 22. Whether through your firewall or the server itself, make SSH respond on some random high port, like 6022, or 60022, or something like that. (If through SSH directly, the line in sshd_config is "Port 22" (no quotes; remove the # at the front if there is one.)
It's already configured in such a way on a high port number.
Second, seriously consider doing something like fail2ban, so that multiple invalid attempts will result in their IP address being outright blocked. This will help prevent brute-forcing a connection.
If I see the same address reappearing I'll look into this. It's the first time I've seen anything in the logs in over a year so for the moment it may be a rare one-off. Interestingly, having just revisited the link I posted in the original post, whilst it previously had a dozen or so reports relating to the IP address going back a few months, I see somebody else just posted the exact same log string as myself but with a different originating port number, and 3 hours ago, meaning just before I posted this topic.
Third, make absolutely sure that you have root logins and password- based logins disabled (aka, ONLY key logins.) These are the lines in sshd_config that you'd set: PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no UsePAM no ChallengeResponseAuthentication no
After making any changes to the config file, do "service sshd restart" (no quotes)
If you do the port number change, do it first and test it. Then leave that session open if you do any other changes.
CRITICAL: IF YOU CHANGE THE AUTHENTICATION MECHANISMS, BEFORE CLOSING YOUR SSH SESSION, MAKE SURE THAT YOU CAN OPEN A SECOND SESSION AND CONNECT SUCCESSFULLY! That way if you messed up the config, you won't have locked yourself out of your box, and can fix things.
Good tip! gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 22:35 +0100, gumb wrote:
On 05/01/18 21:35, Christopher Myers wrote:
...
Second, seriously consider doing something like fail2ban, so that multiple invalid attempts will result in their IP address being outright blocked. This will help prevent brute-forcing a connection.
If I see the same address reappearing I'll look into this. It's the first time I've seen anything in the logs in over a year so for the moment it may be a rare one-off.
Interestingly, having just revisited the link I posted in the original post, whilst it previously had a dozen or so reports relating to the IP address going back a few months, I see somebody else just posted the exact same log string as myself but with a different originating port number, and 3 hours ago, meaning just before I posted this topic.
You could simply block manually this particular IP. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpP+kgACgkQtTMYHG2NR9WPbACgkXjn5gwZv59JvIRFe46vb0Cs ppMAnj26DcW4ivUGjQrdqQDmNmgPD5hE =0PVU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----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-----
On 05/01/18 22:03, Carlos E. R. wrote:
On Friday, 2018-01-05 at 18:50 +0100, gumb wrote:
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.
It's probably worth making a note of. I use YaST simply because the main reason I ssh to that machine is to do updates and run the Software Management module. I started on SuSE before zypper was a thing so old habits die hard, YaST is just where I go to get things done.
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.
Yep, the port number was something I configured at the beginning to be non-standard, so hopefully this scan was just a lucky hit. However, I've just thought of something. It's well over a year since I first got ssh set up and in that time nothing's ever shown up in the logs. I was at the other location just a week or so ago, and on the 26th December attempted to configure ssh in the reverse direction to my main machine left switched on at home. I simply generated the ssh key then attempted the ssh-copy-id command, but it would hang and eventually produce an error message that I've forgotten. Just an inaccessible machine or whatever. I don't know why and haven't looked into it enough. Both machines run openSUSE 42.3 and have been configured for ssh identically so far as I'm aware, and I saw nothing obvious in my main machine's logs when I returned home to suggest even any attempt at an ssh connection. But it was just two days later that the first of these two failed access attempts from a Cypriot server shows up in the remote machine's logs. Which is just a bit too coincidental for comfort. Is there any way that a ssh-copy-id command can be intercepted enough so as to trace the sender's port number? gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-01-05 at 22:47 +0100, gumb wrote:
On 05/01/18 22:03, Carlos E. R. wrote:
On Friday, 2018-01-05 at 18:50 +0100, gumb wrote:
...
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.
It's probably worth making a note of. I use YaST simply because the main reason I ssh to that machine is to do updates and run the Software Management module. I started on SuSE before zypper was a thing so old habits die hard, YaST is just where I go to get things done.
Same here, I use YaST. But I do not do updates remotely, just for the chance of the remote machine failing and not responding. ...
There are other methods; what I described is for hardware under your full control, usually at home.
Yep, the port number was something I configured at the beginning to be non-standard, so hopefully this scan was just a lucky hit.
In that case, I would be a bit more worried.
However, I've just thought of something. It's well over a year since I first got ssh set up and in that time nothing's ever shown up in the logs. I was at the other location just a week or so ago, and on the 26th December attempted to configure ssh in the reverse direction to my main machine left switched on at home. I simply generated the ssh key then attempted the ssh-copy-id command, but it would hang and eventually produce an error message that I've forgotten. Just an inaccessible machine or whatever. I don't know why and haven't looked into it enough. Both machines run openSUSE 42.3 and have been configured for ssh identically so far as I'm aware, and I saw nothing obvious in my main machine's logs when I returned home to suggest even any attempt at an ssh connection.
For ssh.copy-id to work you need to be able to login on the other machine. If that machine does not allow password connection, as the keys are not there already, the program will fail. I think.
But it was just two days later that the first of these two failed access attempts from a Cypriot server shows up in the remote machine's logs. Which is just a bit too coincidental for comfort. Is there any way that a ssh-copy-id command can be intercepted enough so as to trace the sender's port number?
The ssh-copy-id program uses ssh for the transfer. It is a script, you can look up what it does. What goes inside is safe; however, it can be seen by a sniffer to what IP and port it connects, because that has to be in the standard packet info... - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpP+ckACgkQtTMYHG2NR9XzmwCfQ7pf5bKzQt9QG+MgdVT6he2o hZgAoIYRga+LQSXjalU+mkz5slzwRB80 =nWZt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Anton Aylward -
Carlos E. R. -
Christopher Myers -
gumb -
John Andersen