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

81–90 of 133 posts

Re: SSH Kung Fu

#81

Post by Piskvorrr »

moe wrote: post #65
Piskvorrr wrote: post #11

Earlier quoted context omitted.

Moving ssh port is, IMNSHO, a stopgap measure; you should have exhausted all the other options (e.g. no passwords, no root login, denyhosts/fail2ban etc.) before this even crosses your mind. In other words, the inconvenience this brings is not adequate to the infinitesimal increase in security.

In other words, the inconvenience this brings is not adequate to the infinitesimal increase in security. You are wrong. Please refrain from giving security advice. Changing or filtering the SSH port prevents your host from being compromised by automated netrange sweeps in the event of a pre-auth ssh vulnerability. For this reason changing the SSH port is considered best practice.

Okay, a pre-auth vulnerability is a plausible option I didn't consider; you are right.

Re: SSH Kung Fu

#82

Post by opendais »

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.

I'm confused how this is better than just using an alias/profile?

Maybe it is just me, but I prefer to dump all my custom commands and aliases into .zshrc so they are easy to backup/track/find.

Re: SSH Kung Fu

#83

Post by Osmium »

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.

I just noticed FreeNAS defaults to `PermitRootLogin without-password` and doesn't have a GUI option to change it to `no`. I'm not sure if that's the default on FreeBSD generally, but it surprised me.

Re: SSH Kung Fu

#84

Post by danielweber »

Piskvorrr wrote: post #40
throwaway2048 wrote: post #36

Earlier quoted context omitted.

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).

Making security logs usable can (note the word) be a very important part of a security setup. Lots of people don't have the bandwidth to pay attention to noisy log files to look for anomalies.

Re: SSH Kung Fu

#85

Post by SnacksOnAPlane »

deanclatworthy wrote: post #17
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.

I've been doing this for a while now, but my file is now huge and it's cumbersome to edit. Is there no utility to mange that file?

Here's what I put in my .bashrc:

  alias compile-ssh-config='echo -n > ~/.ssh/config && cat ~/.ssh/*.config > ~/.ssh/config'
  alias ssh='compile-ssh-config && ssh'
Compiles all your ~/.ssh/*.config files into a single ssh config file. It's simple and stupid and seems to do the trick.

Re: SSH Kung Fu

#86

Post by ak217 »

Best trick I learned in the past few years is SSH control sequences.

Disconnected from your host but not timed out yet? Press Enter, ~, . and the client will quit.

Re: SSH Kung Fu

#87

Post by themckman »

ak217 wrote: post #86

Best trick I learned in the past few years is SSH control sequences. Disconnected from your host but not timed out yet? Press Enter, ~, . and the client will quit.

Ohh my, the day I learned this was one of the happiest in all my life. You can also configure this in your .ssh/config with EscapeChar, if you find yourself SSHing into other machines from a machine you're already SSHed into.

Re: SSH Kung Fu

#88

Post by drdaeman »

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.

I'd say, maybe it's wiser to use

    PermitRootLogin forced-commands-only
If it's necessary to run something as root — declare it beforehead. If you encounter a situation when you need to run something unusual on an automated basis — login as administrator (or edit your Puppet/Chef/Ansible/alike rules if you're on the smart system management side) and update ~root/authorized_keys.

If one needs to SFTP as root, they could enlist `internal-sftp` target, too (although I haven't tested this, I don't SFTP as root and if I must update some files — I setfacl on them)

Re: SSH Kung Fu

#89

Post by eieio »

themckman wrote: post #87
ak217 wrote: post #86

Best trick I learned in the past few years is SSH control sequences. Disconnected from your host but not timed out yet? Press Enter, ~, . and the client will quit.

Ohh my, the day I learned this was one of the happiest in all my life. You can also configure this in your .ssh/config with EscapeChar, if you find yourself SSHing into other machines from a machine you're already SSHed into.

You can also use send a double tilde ( Enter, ~, ~) to pass a tilde to your inner ssh session. So killing a session within a session is Enter, ~, ~, .

Re: SSH Kung Fu

#90

Post by drdaeman »

akerl_ wrote: post #57
Piskvorrr wrote: post #34

Earlier quoted context omitted.

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

Would you like to clarify how, from a security standpoint, the string "root" is worse than another user? Allowing root login can be a user-management headache in multi-user environments, but strong SSH security can exist for root just the same as for any other user.

Because — LSMs aside — user commonly identified with a string "root" has unrestricted access to nearly anything and deserves additional security. This is also why NOPASSWD on sudo is not a good idea — even if your key leaked (bad things happen) and attacker got in, the system is hopefully still secure.

If you need to conveniently update some files on regular basis — chown or setfacl on them to your usual user or group. If you need to update root-owned file once in a blue moon — scp && ssh sudo mv it, it's not that hard, but better for security.

Oh, and obviously there are exceptions to the rule - say, if you're configuring some freshly-installed system and doing heavy config editing by hand (say, Puppet is not your thing or you just don't care about re-deployment), temporary lifting security barriers is perfectly fine in most cases.

Post reply on HN