Re: [OpenIndiana-discuss] Support for LSI-2308 SAS controller in oi_151a8
Not sure I can return $8000 worth of drives, but if I have to, I will certainly try. M On 7/1/15, 6:27 PM, "Jason Matthews" wrote: > >Hp had a similar problem on their controllers. SSDs would invoke a >thermal shut down. > >Return the drives for hgst counter parts. > >Sent from my iPhone > >> On Jul 1, 2015, at 5:16 PM, Matt Boswell >>wrote: >> >> Hi all, >> >> We bit the bullet and bought a companion storage server to use for ZFS >>replication and failover. Our main box is about 3 years old and is also >>running oi_151a8. We're running into some issues insisting that some of >>the disks are over-temperature (via console messages), and now format >>shows only 6 of the 26 disks installed in the system. "fmadm faulty" >>shows what I expected, that a slew of disks exceeded temperature >>thresholds and have been marked as faulty. I find this hard to believe, >>as the system is properly cooled, in a colo rack, and the sensors on >>board all show normal temperatures via IPMI. FWIW these disks have >>never been used; they are brand new and waiting to be added into zpools. >> The controller BIOS shows all the disks as connected and healthy. Just >>wondering if anyone has run across this before and what can be done >>about it. The hardware is SuperMicro 6047R-E1R24L and the disks are WD >>SAS 4TB drives, with two intel SSDs in the back for rpool and log devic > > es. >> Matt >> ___ >> openindiana-discuss mailing list >> openindiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> > >___ >openindiana-discuss mailing list >openindiana-discuss@openindiana.org >http://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Support for LSI-2308 SAS controller in oi_151a8
Ouch. Thanks. I¹ll do some research. On a related note, we¹re using Constellations in our other build. No firmware problems, but we¹ve had lots of failures. The difference is that we¹re presenting them to OI as vdevs on the RAID controller rather than JBOD. Wonder if that might be a workaround; to create a bunch of single disk RAID0 vdevs. Matt On 7/1/15, 6:11 PM, "Schweiss, Chip" wrote: >Sounds exactly like a firmware problem that Seagate Constellations had. >With lsiutils you can read what threshold the disks report. > >You likely need a firmware upgrade or downgrade for the disks. > >-Chip > > >On Wed, Jul 1, 2015 at 7:16 PM, Matt Boswell >wrote: > >> Hi all, >> >> We bit the bullet and bought a companion storage server to use for ZFS >> replication and failover. Our main box is about 3 years old and is also >> running oi_151a8. We're running into some issues insisting that some of >>the >> disks are over-temperature (via console messages), and now format shows >> only 6 of the 26 disks installed in the system. "fmadm faulty" shows >>what >> I expected, that a slew of disks exceeded temperature thresholds and >>have >> been marked as faulty. I find this hard to believe, as the system is >> properly cooled, in a colo rack, and the sensors on board all show >>normal >> temperatures via IPMI. FWIW these disks have never been used; they are >> brand new and waiting to be added into zpools. The controller BIOS >>shows >> all the disks as connected and healthy. Just wondering if anyone has >>run >> across this before and what can be done about it. The hardware is >> SuperMicro 6047R-E1R24L and the disks are WD SAS 4TB drives, with two >>intel >> SSDs in the back for rpool and log devices. >> Matt >> ___ >> openindiana-discuss mailing list >> openindiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> >___ >openindiana-discuss mailing list >openindiana-discuss@openindiana.org >http://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Support for LSI-2308 SAS controller in oi_151a8
Hp had a similar problem on their controllers. SSDs would invoke a thermal shut down. Return the drives for hgst counter parts. Sent from my iPhone > On Jul 1, 2015, at 5:16 PM, Matt Boswell wrote: > > Hi all, > > We bit the bullet and bought a companion storage server to use for ZFS > replication and failover. Our main box is about 3 years old and is also > running oi_151a8. We're running into some issues insisting that some of the > disks are over-temperature (via console messages), and now format shows only > 6 of the 26 disks installed in the system. "fmadm faulty" shows what I > expected, that a slew of disks exceeded temperature thresholds and have been > marked as faulty. I find this hard to believe, as the system is properly > cooled, in a colo rack, and the sensors on board all show normal temperatures > via IPMI. FWIW these disks have never been used; they are brand new and > waiting to be added into zpools. The controller BIOS shows all the disks as > connected and healthy. Just wondering if anyone has run across this before > and what can be done about it. The hardware is SuperMicro 6047R-E1R24L and > the disks are WD SAS 4TB drives, with two intel SSDs in the back for rpool > and log devices. > Matt > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Support for LSI-2308 SAS controller in oi_151a8
Sounds exactly like a firmware problem that Seagate Constellations had. With lsiutils you can read what threshold the disks report. You likely need a firmware upgrade or downgrade for the disks. -Chip On Wed, Jul 1, 2015 at 7:16 PM, Matt Boswell wrote: > Hi all, > > We bit the bullet and bought a companion storage server to use for ZFS > replication and failover. Our main box is about 3 years old and is also > running oi_151a8. We're running into some issues insisting that some of the > disks are over-temperature (via console messages), and now format shows > only 6 of the 26 disks installed in the system. "fmadm faulty" shows what > I expected, that a slew of disks exceeded temperature thresholds and have > been marked as faulty. I find this hard to believe, as the system is > properly cooled, in a colo rack, and the sensors on board all show normal > temperatures via IPMI. FWIW these disks have never been used; they are > brand new and waiting to be added into zpools. The controller BIOS shows > all the disks as connected and healthy. Just wondering if anyone has run > across this before and what can be done about it. The hardware is > SuperMicro 6047R-E1R24L and the disks are WD SAS 4TB drives, with two intel > SSDs in the back for rpool and log devices. > Matt > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Support for LSI-2308 SAS controller in oi_151a8
Hi all, We bit the bullet and bought a companion storage server to use for ZFS replication and failover. Our main box is about 3 years old and is also running oi_151a8. We're running into some issues insisting that some of the disks are over-temperature (via console messages), and now format shows only 6 of the 26 disks installed in the system. "fmadm faulty" shows what I expected, that a slew of disks exceeded temperature thresholds and have been marked as faulty. I find this hard to believe, as the system is properly cooled, in a colo rack, and the sensors on board all show normal temperatures via IPMI. FWIW these disks have never been used; they are brand new and waiting to be added into zpools. The controller BIOS shows all the disks as connected and healthy. Just wondering if anyone has run across this before and what can be done about it. The hardware is SuperMicro 6047R-E1R24L and the disks are WD SAS 4TB drives, with two intel SSDs in the back for rpool and log devices. Matt ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Who is trying to break in ?
With some investigation, it looks like SmartOS has a package for this: http://everycity.co.uk/alasdair/2013/09/two-factor-authentication-google-authenticator-smartos/ Gary On 07/01/2015 03:11 PM, Gary Gendel wrote: Google Authenticator has a PAM module. I haven't tried it but I know it's available for several Linux distros. I'm not sure how difficult it would be to port to OI. http://www.tecmint.com/ssh-two-factor-authentication/ On 07/01/2015 02:53 PM, David Brodbeck wrote: On Wed, Jul 1, 2015 at 3:15 AM, Jim Klimov wrote: You can also boost security with no passwords allowed, keys only for ssh auth ;) True. I do this with machines where I'm the only one who'll be logging in. With machines that have lots of other users it becomes too much of an administrative hassle to distribute keys. Does anyone know of a 2-factor auth system for SSH? Being able to use something like Google Authenticator would be nice. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Who is trying to break in ?
Google Authenticator has a PAM module. I haven't tried it but I know it's available for several Linux distros. I'm not sure how difficult it would be to port to OI. http://www.tecmint.com/ssh-two-factor-authentication/ On 07/01/2015 02:53 PM, David Brodbeck wrote: On Wed, Jul 1, 2015 at 3:15 AM, Jim Klimov wrote: You can also boost security with no passwords allowed, keys only for ssh auth ;) True. I do this with machines where I'm the only one who'll be logging in. With machines that have lots of other users it becomes too much of an administrative hassle to distribute keys. Does anyone know of a 2-factor auth system for SSH? Being able to use something like Google Authenticator would be nice. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Who is trying to break in ?
On Wed, Jul 1, 2015 at 3:15 AM, Jim Klimov wrote: > You can also boost security with no passwords allowed, keys only for ssh > auth ;) > True. I do this with machines where I'm the only one who'll be logging in. With machines that have lots of other users it becomes too much of an administrative hassle to distribute keys. Does anyone know of a 2-factor auth system for SSH? Being able to use something like Google Authenticator would be nice. -- D. Brodbeck System Administrator, Linguistics University of Washington GPG key fingerprint: 0DB7 4B50 8910 DBC5 B510 79C4 3970 2BC3 2078 D875 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [OmniOS-discuss] pkg(5) in alternate roots
1 июля 2015 г. 15:20:56 CEST, Jim Klimov пишет:
>Hello all,
>
>
>Due to my split-root configurations, I often do OI/OmniOS upgrades in a
>pre-created cloned BE (automated by
>https://github.com/jimklimov/illumos-splitroot-scripts since the
>generic beadm/zfs clone do a poor job with customized zfs attributes on
>child datasets). As part of an upgrade, I do a chroot into the mounted
>new BE to use the pkg(5) "in place" (and with altroot of "/") and if
>this fails - I fall back to alternate root (-R) with the unchanged
>pkg(5) version installed in the original BE. In either case, I pass the
>"--deny-new-be" parameter to pkg(5). (relevant code snippet is
>presented below in this message)
>
>
>However there are some packages whose upgrades seem to require a
>"non-Live BE" installation. And even though I install to an alternate
>BE, they fail. Is there some way around this, beside fixing pkg(5)
>itself?
>
>
>For example, recently I got the state below: the pkg program got
>updated in the new BE, but it could not be used via chroot due to "live
>image" concerns, and the old pkg(5) in original BE did not suffice for
>the upgrades. A reboot into the new BE and another upgrade request
>fixes this, but that's kind of unwieldy. And installing new pkg into
>old BE goes somewhat against the purpose of BEs (unchanged old state I
>can roll back into - thus including escape from broken pkg(5) as any
>other bit of system software).
>
>
>Screenshot from the script:
>
>
>
>= Updating PKG software itself
>Packages to update: 1
>
>
>DOWNLOAD PKGS FILES XFER (MB)
> SPEED
>Completed 1/1 16/16 0.3/0.3
> 303k/s
>
>
>PHASE ITEMS
>Removing old actions 1/1
>Updating modified actions 18/18
>Updating package state database Done
>Updating package cache 1/1
>Updating image state Done
>Creating fast lookup database Done
>Reading search index Done
>Updating search index 1/1
>
>
>
>= Updating the image with new PKG software via chroot
>pkg update: The proposed operation cannot be performed on a live image.
>= Updating the image with old PKG software via altroot
>WARNING: pkg(5) appears to be out of date, and should be updated before
>running update. Please update pkg(5) by executing 'pkg install
>pkg:/package/pkg' as a privileged user and then retry the update.
>= Updating the image with old PKG software via altroot and allowed
>refresh
>WARNING: pkg(5) appears to be out of date, and should be updated before
>running update. Please update pkg(5) by executing 'pkg install
>pkg:/package/pkg' as a privileged user and then retry the update.
>
>
>
>
>The corresponding part of the script (and exact command-lines involved)
>are here:
>
>
>...
>
> { echo "= Updating PKG software itself"
> ### This clause should fail if no 'pkg' updates were
>available, or if a
> ### chrooted upgrade attempt with the new 'pkg' failed - both
>ways fall
> ### through to altroot upgrade attempt
> if /usr/bin/pkg -R "$BENEW_MNT" update --no-refresh --accept
>--deny-new-be --no-backup-be pkg; then \
> echo "= Updating the image with new PKG software via
>chroot"
> chroot "$BENEW_MNT" /usr/bin/pkg -R / image-update
>--no-refresh --accept --deny-new-be --no-backup-be
> else false; fi; } || \
> { echo "= Updating the image with old PKG software via
>altroot"
> /usr/bin/pkg -R "$BENEW_MNT" image-update --no-refresh
>--accept --deny-new-be --no-backup-be; } || \
> { echo "= Updating the image with old PKG software via
>altroot and allowed refresh"
> /usr/bin/pkg -R "$BENEW_MNT" image-update --accept
>--deny-new-be --no-backup-be; }
>...
>
>
>
>
>Essentially, what I want is for pkg(5) to correctly guess, or be told
>by the caller, that it in fact does not modify a "live" image and so
>can do anything dangerous it would please to do.
>
>
>Thanks in advance,
>Jim Klimov
>
>
>
>
>
>
>
>
>___
>OmniOS-discuss mailing list
>omnios-disc...@lists.omniti.com
>http://lists.omniti.com/mailman/listinfo/omnios-discuss
I guess i found the workaround - the pkg(5) script honors some PKG_LIVE_ROOT
variable, for unittesting from what i gather, that along with -R allows to not
create BEs for packages that otherwise need them.
I guess this is not a committed api, but will have to do ;)
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] how to trace what stops the daemon from sleeping?
Now the problem is solved. I rebuilt Racket without defining HAVE_POLL_SYSCALL. So it is running with select(), and pollsys() is still on the top of stack. The LD_PRELOAD way fails as before. Thanks. On Wed, Jul 1, 2015 at 6:37 AM, Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Tue, 30 Jun 2015, WarGrey Gyoudmon Ju wrote: > > Thank you, Bob. >> >> Finally I found the root cause is that pollsys is called too frequently. >> and this problem seems quite normal in Solaris family. >> > > I am pretty sure that this has nothing to do with power management (as > other have suggested). > > The poll() call can wait for activities on file descriptors but can also > be used for time-out such as for periodic event loops. Some software is > written poorly and executes periodic event loops quite often. > > If you don't have source for the program, it might be possible to "fix" it > by using the LD_PRELOAD enviroment variable and a tiny shared library which > replaces poll() with one which insists on longer timeouts. This might > cause other problems to occur in the software though. > > > Bob > -- > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Who is trying to break in ?
On Wed, 1 Jul 2015, Jim Klimov wrote: You can also boost security with no passwords allowed, keys only for ssh auth ;) This certainly helps, but a remote compromised machine could still use those keys to log in to your system. Hopefully users of those keys do apply a passphrase to them. If the remote machine is compromised, then the key passphrase could be captured by keystroke logging and the private key file could be copied at that time. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] pkg(5) in alternate roots
Hello all,
Due to my split-root configurations, I often do OI/OmniOS upgrades in a
pre-created cloned BE (automated by
https://github.com/jimklimov/illumos-splitroot-scripts since the generic
beadm/zfs clone do a poor job with customized zfs attributes on child
datasets). As part of an upgrade, I do a chroot into the mounted new BE to use
the pkg(5) "in place" (and with altroot of "/") and if this fails - I fall back
to alternate root (-R) with the unchanged pkg(5) version installed in the
original BE. In either case, I pass the "--deny-new-be" parameter to pkg(5).
(relevant code snippet is presented below in this message)
However there are some packages whose upgrades seem to require a "non-Live BE"
installation. And even though I install to an alternate BE, they fail. Is there
some way around this, beside fixing pkg(5) itself?
For example, recently I got the state below: the pkg program got updated in the
new BE, but it could not be used via chroot due to "live image" concerns, and
the old pkg(5) in original BE did not suffice for the upgrades. A reboot into
the new BE and another upgrade request fixes this, but that's kind of unwieldy.
And installing new pkg into old BE goes somewhat against the purpose of BEs
(unchanged old state I can roll back into - thus including escape from broken
pkg(5) as any other bit of system software).
Screenshot from the script:
= Updating PKG software itself
Packages to update: 1
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 1/1 16/16 0.3/0.3 303k/s
PHASE ITEMS
Removing old actions 1/1
Updating modified actions 18/18
Updating package state database Done
Updating package cache 1/1
Updating image state Done
Creating fast lookup database Done
Reading search index Done
Updating search index 1/1
= Updating the image with new PKG software via chroot
pkg update: The proposed operation cannot be performed on a live image.
= Updating the image with old PKG software via altroot
WARNING: pkg(5) appears to be out of date, and should be updated before
running update. Please update pkg(5) by executing 'pkg install
pkg:/package/pkg' as a privileged user and then retry the update.
= Updating the image with old PKG software via altroot and allowed refresh
WARNING: pkg(5) appears to be out of date, and should be updated before
running update. Please update pkg(5) by executing 'pkg install
pkg:/package/pkg' as a privileged user and then retry the update.
The corresponding part of the script (and exact command-lines involved) are
here:
...
{ echo "= Updating PKG software itself"
### This clause should fail if no 'pkg' updates were available, or if
a
### chrooted upgrade attempt with the new 'pkg' failed - both ways
fall
### through to altroot upgrade attempt
if /usr/bin/pkg -R "$BENEW_MNT" update --no-refresh --accept
--deny-new-be --no-backup-be pkg; then \
echo "= Updating the image with new PKG software via chroot"
chroot "$BENEW_MNT" /usr/bin/pkg -R / image-update --no-refresh
--accept --deny-new-be --no-backup-be
else false; fi; } || \
{ echo "= Updating the image with old PKG software via altroot"
/usr/bin/pkg -R "$BENEW_MNT" image-update --no-refresh --accept
--deny-new-be --no-backup-be; } || \
{ echo "= Updating the image with old PKG software via altroot and
allowed refresh"
/usr/bin/pkg -R "$BENEW_MNT" image-update --accept --deny-new-be
--no-backup-be; }
...
Essentially, what I want is for pkg(5) to correctly guess, or be told by the
caller, that it in fact does not modify a "live" image and so can do anything
dangerous it would please to do.
Thanks in advance,
Jim Klimov
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Who is trying to break in ?
1 июля 2015 г. 9:51:49 CEST, benta...@chez.com пишет: >Hi, >I've been using sshl to multiplex openvpn, https and ssh on port 443 to >be able to go through anything and before that I was using tcpproxy for >the same reason. >I'm pretty impressed by sshl and I hope to use it when I replace the >linux all-in-one box by an refurbished Ultra 20/hipster. > >To be honest, for a very long time I had port 22 opened as well for ssh >the time to trust sshl and the difference is quite noticeable, security >wise. >On the other hand, if you don't allow root login, have good passwords >for users and root and log rotation correctly set, port 22 or not is >just a convenience question but I'm not a security guy, really. > >Ben. > >- Mail original - >De: "Jim Klimov" >À: "Discussion list for OpenIndiana" >, "Till Wegmüller" > >Envoyé: Lundi 29 Juin 2015 21:02:44 >Objet: Re: [OpenIndiana-discuss] Who is trying to break in ? > >29 июня 2015 г. 9:37:26 CEST, "Till Wegmüller" >пишет: >>Brogyányi József schrieb am Sunday 28 June 2015 11.01:55: >> >>> /The last was strange a little bit because he wanted to switch of >the >> >>> server. I think you have to change the 21 and 22 communication port. >>> I use the 443 port for ssh. I can reach the server easily from >>anywhere >>> because every company left it open that port. >> >>I Advise Strongly against using a different port for SSH. Especially a >>port like 443 which by default is used by apache and other webservers. >>Some Webservers might refuse to launch depending on their >>configuration. >> >>> I've noticed some text output before shutting down the system. >>> It seems someone ( or bots ) are constantly trying to log in as >root. >> >>Yea there are some Chinese Bot nets that scan for open SSH Ports and >>try to log in with root. I have them on every SSH capable server which >>is Internet reachable. They don't only scan 22 but also 666 or 1337. >>But they only make tries with weak default passwords like 12345. >> >>If you want to block them I suggest the Tool fail2ban. I use it on my >>Linux boxes and it works like a charm. There also seems to be a Port >>for snv_134 https://github.com/jamesstout/fail2ban-0.8.4-OpenSolaris >>but I haven't tested that. >> >>Greetings Till >> >>___ >>openindiana-discuss mailing list >>openindiana-discuss@openindiana.org >>http://openindiana.org/mailman/listinfo/openindiana-discuss > >Got no qualms about ssh (or openvpn) on port 443 - indeed, if one sets >up something non-standard, gotta be ready for the consequences. And to >all ids'es and sniffers, cryptotraffic looks much the same (different >dynamic flow patterns may be discerned by the smarter filters out there >though). > >As was said earlier, many networks (especially free wifi, and some >cellulars) only allow http(s) outwards, so there's not much choice for >road-workers. > >Also, there are server-side projects to colocate frontends for https >and ssh or openvpn on the same socket to veil it even more. > > >-- >Typos courtesy of K-9 Mail on my Samsung Android > >___ >openindiana-discuss mailing list >openindiana-discuss@openindiana.org >http://openindiana.org/mailman/listinfo/openindiana-discuss > >___ >openindiana-discuss mailing list >openindiana-discuss@openindiana.org >http://openindiana.org/mailman/listinfo/openindiana-discuss You can also boost security with no passwords allowed, keys only for ssh auth ;) -- Typos courtesy of K-9 Mail on my Samsung Android ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Who is trying to break in ?
Hi, I've been using sshl to multiplex openvpn, https and ssh on port 443 to be able to go through anything and before that I was using tcpproxy for the same reason. I'm pretty impressed by sshl and I hope to use it when I replace the linux all-in-one box by an refurbished Ultra 20/hipster. To be honest, for a very long time I had port 22 opened as well for ssh the time to trust sshl and the difference is quite noticeable, security wise. On the other hand, if you don't allow root login, have good passwords for users and root and log rotation correctly set, port 22 or not is just a convenience question but I'm not a security guy, really. Ben. - Mail original - De: "Jim Klimov" À: "Discussion list for OpenIndiana" , "Till Wegmüller" Envoyé: Lundi 29 Juin 2015 21:02:44 Objet: Re: [OpenIndiana-discuss] Who is trying to break in ? 29 июня 2015 г. 9:37:26 CEST, "Till Wegmüller" пишет: >Brogyányi József schrieb am Sunday 28 June 2015 11.01:55: > >> /The last was strange a little bit because he wanted to switch of the > >> server. I think you have to change the 21 and 22 communication port. >> I use the 443 port for ssh. I can reach the server easily from >anywhere >> because every company left it open that port. > >I Advise Strongly against using a different port for SSH. Especially a >port like 443 which by default is used by apache and other webservers. >Some Webservers might refuse to launch depending on their >configuration. > >> I've noticed some text output before shutting down the system. >> It seems someone ( or bots ) are constantly trying to log in as root. > >Yea there are some Chinese Bot nets that scan for open SSH Ports and >try to log in with root. I have them on every SSH capable server which >is Internet reachable. They don't only scan 22 but also 666 or 1337. >But they only make tries with weak default passwords like 12345. > >If you want to block them I suggest the Tool fail2ban. I use it on my >Linux boxes and it works like a charm. There also seems to be a Port >for snv_134 https://github.com/jamesstout/fail2ban-0.8.4-OpenSolaris >but I haven't tested that. > >Greetings Till > >___ >openindiana-discuss mailing list >openindiana-discuss@openindiana.org >http://openindiana.org/mailman/listinfo/openindiana-discuss Got no qualms about ssh (or openvpn) on port 443 - indeed, if one sets up something non-standard, gotta be ready for the consequences. And to all ids'es and sniffers, cryptotraffic looks much the same (different dynamic flow patterns may be discerned by the smarter filters out there though). As was said earlier, many networks (especially free wifi, and some cellulars) only allow http(s) outwards, so there's not much choice for road-workers. Also, there are server-side projects to colocate frontends for https and ssh or openvpn on the same socket to veil it even more. -- Typos courtesy of K-9 Mail on my Samsung Android ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
