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

11–20 of 133 posts

Re: SSH Kung Fu

#11

Post by Piskvorrr »

Morgawr wrote: post #9

I just learned about remote file editing with vim and scp thanks to this article, it's the only thing I didn't know about and... wow, it's amazing. This will make my life much easier every time I have to remotely edit some config files on my servers. As for the rest of the article, really nice stuff. Nice tricks for ssh newbies. I wish he also talked about setting up a nonce system with ssh or move sshd to a non-defa…

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.

Re: SSH Kung Fu

#12

Post by Piskvorrr »

XorNot wrote: post #8
terhechte wrote: post #7

> Sharing Connections I've tried this before, and what effectively always happened (to me) is that as soon as I started copying a file, I couldn't continue working in Vim anymore until the file was done transmitting because the copying would eat all the bandwidth. There may be a flag or setting around this, but I've never found it. When I open two connections, it is usually fine.

I've found it just tends to have the primary connection die, and never tries to reconnect. ServerKeepAlives or what have you don't seem to help either - the link goes dead, and I won't be able to connect any other sessions because SSH will just keep on routing them into the control master.

Using autossh for establishing the master connection helps immensely here - if it dies, it will automagically reconnect.

Re: SSH Kung Fu

#13

Post by patio11 »

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.

Re: SSH Kung Fu

#15

Post by smtddr »

Piskvorrr wrote: post #11
Morgawr wrote: post #9

I just learned about remote file editing with vim and scp thanks to this article, it's the only thing I didn't know about and... wow, it's amazing. This will make my life much easier every time I have to remotely edit some config files on my servers. As for the rest of the article, really nice stuff. Nice tricks for ssh newbies. I wish he also talked about setting up a nonce system with ssh or move sshd to a non-defa…

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.

For me I just don't like seeing /var/log/auth.log being filled with 100s of lines of:

  Failed password for root2 from 82.192.86.44 port 44990 ssh2
  Failed password for admin from 82.192.86.44 port 44990 ssh2
  Failed password for sysdb from 82.192.86.44 port 44990 ssh2
  Failed password for scott from 82.192.86.44 port 44990 ssh2
(Yes, that IP has scanned my machine before)

Re: SSH Kung Fu

#17

Post by deanclatworthy »

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?

Re: SSH Kung Fu

#18

Post by Piskvorrr »

smtddr wrote: post #15
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.

For me I just don't like seeing /var/log/auth.log being filled with 100s of lines of: Failed password for root2 from 82.192.86.44 port 44990 ssh2 Failed password for admin from 82.192.86.44 port 44990 ssh2 Failed password for sysdb from 82.192.86.44 port 44990 ssh2 Failed password for scott from 82.192.86.44 port 44990 ssh2 (Yes, that IP has scanned my machine before)

And that's exactly what denyhosts is for. You'll see this line a few initial times, then the banhammer springs into action.

(It's fully configurable - the number of failed attempts, the length of the autoban, etc.)

Re: SSH Kung Fu

#19

Post by hf »

The situation with beginner-friendly SSH tutorials is, in a much lesser degree perhaps, comparable to the crypto texts: Good will alone does more harm than good.

This treatment ssh does not mention ssh-agent and, more importantly perhaps, implies that there is a certain virtue in having private keys unprotected by sturdy passphrases lying around.

There is not; most emphatically not.

Re: SSH Kung Fu

#20

Post by hf »

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.

What is more, you can specify an abstraction for the tedious double-ssh where you first connect to some internet-facing host in order to gain access to an internal machine:

    Host $ALIAS
        User $USER
        HostName $INTERNAL
        ProxyCommand ssh $USER2@$PUBLIC -W %h:%p
Now

    laptop> ssh jim@public.example.com
    public> ssh dev@myworkstation
becomes

    laptop> ssh work
(I just realized that this slightly confused article seems to accomplish the same by using a convoluted setup of port-forwardings and netcat.)
Post reply on HN