T
You can manually edit /etc/ssh/ssh_config and /etc/ssh/sshd_config. But I have never tested that.
T
tobixx
Guest
Damn, I forgot the ssh client config. I will test it.
First only edited the server conf.
Thanks for your wake up.
changing ssh ports...
interesting question, but, why do you need to change the ssh ports?
Diaolin
interesting question, but, why do you need to change the ssh ports?
Diaolin
T
tobixx
Guest
To keep away the scripting kids - security trough obscurity - keeps the logs clean.
security through obscurity
If you are happy, all are happy
But another solution is to modify syslog.conf and put
auth.* /dev/null
Sorry, i don't understand this
Diaolin
If you are happy, all are happy
But another solution is to modify syslog.conf and put
auth.* /dev/null
Sorry, i don't understand this
Diaolin
Last edited:
the problem here is not with how to change SSH port, but with making PVE Cluster to work with non-22 port for SSHD.
If you have PVE cluster (with more than 2 servers ) it wont work, because pve is searching for SSH on standart port.
I didnt make a search in the configs, but i will. If somebody knows a solution, please post!
If you have PVE cluster (with more than 2 servers
) it wont work, because pve is searching for SSH on standart port.I didnt make a search in the configs, but i will. If somebody knows a solution, please post!
H
hostmedic
Guest
security by obscurity is only part of the battle...
"Security by obscurity" is only bad when you rely on it and only it. Of course - if being used as an additional layer in a defense-in-depth - it is a great addition.
Generally its a good idea to move SSH just to avoid all the script kiddies and pain in the rears from filling up your logs
In reality - a real port scan will find it - but if you keep that port really high - it will take some time for them to find it - and other apps on the server by then may be able to catch the port scan and block them.
One suggestion is to use another well-known port for SSH instead.
Good use of strong Egress filters will help here as well.
Good passwords
Use of Certs
TCP-Wrapper
Port-Knocking
etc. etc.
Now - one other addition would be
http://stats.denyhosts.net/stats.html
At present - this RBL for SSH has 174920 hosts denied by DenyHosts.
DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).
Have a great one
"Security by obscurity" is only bad when you rely on it and only it. Of course - if being used as an additional layer in a defense-in-depth - it is a great addition.
Generally its a good idea to move SSH just to avoid all the script kiddies and pain in the rears from filling up your logs
In reality - a real port scan will find it - but if you keep that port really high - it will take some time for them to find it - and other apps on the server by then may be able to catch the port scan and block them.
One suggestion is to use another well-known port for SSH instead.
Good use of strong Egress filters will help here as well.
Good passwords
Use of Certs
TCP-Wrapper
Port-Knocking
etc. etc.
Now - one other addition would be
http://stats.denyhosts.net/stats.html
At present - this RBL for SSH has 174920 hosts denied by DenyHosts.
DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).
Have a great one
We do not hardcode the port anywhere. Maybe you just need to restart the 'pvetunnel' service:
# /etc/init.d/pvetunnel restart
Does that help?
we simply use the 'ssh' command to connect. So it uses the port specified in /etc/ssh/ssh_config
- Dietmar
- Dietmar