Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH Kung Fu

blog.tjll.net

Post reply on HN
Print view View original

31–40 of 133 posts

Re: SSH Kung Fu

#31

Post by [deleted] »

viraptor wrote: post #28
WestCoastJustin wrote: post #3

Earlier quoted context omitted.

There are many cases where you do not want, or cannot have a password protected ssh trust. For example, say you have a central nagios host monitoring a network, that nagios host needs to connect to remote machines to run interesting monitoring scripts (disk % full, raid controller query, mpio checks, etc), in these cases you do not want to have a password blocking the ssh trust. You will also find this type of thing…

These sound like exactly the cases where you shouldn't use ssh. Use nrpe instead, or run the check on the target machine from cron and make it report back. There's no reason to use ssh for it and at scale ssh adds considerable load to the monitoring host when starting the connection. For continuous deployment you can't easily work around using ssh, but at least the access can be limited to specific commands only.

[deleted]

Re: SSH Kung Fu

#32

Post by hf »

While we are busy dispensing wisdom: Do use

    PermitRootLogin without-password
instead of 'yes' in /etc/ssh/sshd_config if you absolutely must have ssh root access.

Re: SSH Kung Fu

#33

Post by luxpir »

One problem I have with SSH is DPI. Deep Packet Inspection seems to be behind the SSH block in place at a local library I work at. SSH out in any form just isn't possible there, even via a browser-based console (such as that used by Digital Ocean, for example). There doesn't seem to be a suitable solution to get around it offered anywhere.

My own fix was to use 3G to do the SSH work via a tethered phone and to use the wifi adapter to run the bulk of any other web traffic. It'd be great to have a workaround for DPI, though, if anyone has any experience there.

Re: SSH Kung Fu

#34

Post by Piskvorrr »

hf wrote: post #32

While we are busy dispensing wisdom: Do use PermitRootLogin without-password instead of 'yes' in /etc/ssh/sshd_config if you absolutely must have ssh root access.

If you must allow SSH root access, in 2014, you are doing something horribly wrong, and this will come back to bite you.

Re: SSH Kung Fu

#35

Post by yen223 »

patio11 wrote: post #13

A trick I learned recently: create .ssh/config File format: as many of the following blocks as you like Host $ALIAS You can now ssh to that server as that user by doing "ssh $ALIAS" on the command line, without needing to specify the port or user with the usual command line arguments, or necessarily spell out the entire host name.

This is excellent advice. The best part is that you can use the same $ALIAS for tools built on SSH, including scp and rsync, like this:

    scp $ALIAS:/var/log/mylogs/logfile ~/backups/logs/

Re: SSH Kung Fu

#36

Post by throwaway2048 »

Moru wrote: post #26
throwaway2048 wrote: post #23

Earlier quoted context omitted.

until one of the millions of other compromised IPs begins hammering your machine minutes later..

That's the whole point. The ban-hammer in this case is automatic and will ban that one too after five attempts or whatever.

it still doesn't prevent your logs getting filled up with crap is my point.

Re: SSH Kung Fu

#37

Post by jimlei »

hf wrote: post #32

While we are busy dispensing wisdom: Do use PermitRootLogin without-password instead of 'yes' in /etc/ssh/sshd_config if you absolutely must have ssh root access.

Why not use the more common "no"?

Re: SSH Kung Fu

#38

Post by mverwijs »

yen223 wrote: post #35
patio11 wrote: post #13

A trick I learned recently: create .ssh/config File format: as many of the following blocks as you like Host $ALIAS You can now ssh to that server as that user by doing "ssh $ALIAS" on the command line, without needing to specify the port or user with the usual command line arguments, or necessarily spell out the entire host name.

This is excellent advice. The best part is that you can use the same $ALIAS for tools built on SSH, including scp and rsync, like this: scp $ALIAS:/var/log/mylogs/logfile ~/backups/logs/

And.... Ansible uses those aliases too, making it trivial to maintain *NIX server that are behind firewalls and/or vpns.

Re: SSH Kung Fu

#39

Post by mverwijs »

WestCoastJustin wrote: post #3
peteretep wrote: post #2

From the article: > No more password prompts Is that - you ask - because he's using ssh-agent? No, it's because he doesn't tell you you should be using a password-protected key. Some kung fu.

There are many cases where you do not want, or cannot have a password protected ssh trust. For example, say you have a central nagios host monitoring a network, that nagios host needs to connect to remote machines to run interesting monitoring scripts (disk % full, raid controller query, mpio checks, etc), in these cases you do not want to have a password blocking the ssh trust. You will also find this type of thing…

No, in that case, you limit the commands that nagios is allowed to executed using this specific, passphrase-less key.

In this case you would limit this ssh-key to only be able to execute the nagios monitoring scripts. Nothing else.

You do this in ~/.ssh/config on the remote machine.

Re: SSH Kung Fu

#40

Post by Piskvorrr »

throwaway2048 wrote: post #36
Moru wrote: post #26

Earlier quoted context omitted.

That's the whole point. The ban-hammer in this case is automatic and will ban that one too after five attempts or whatever.

it still doesn't prevent your logs getting filled up with crap is my point.

Preventing logs from filling up is quite a cosmetic issue. Making the box hard to crack is certainly more relevant.

Note that I'm not advocating against a port change; just saying that it's the very last of available options, as it's essentialy security-by-obscurity, and thus only gives you a feeling of higher security (due to less spam in the logs).

Post reply on HN