21–30 of 133 posts
The excellent (though unfortunately named) keychain[0] utility provides a ready and powerful abstraction for both ssh-agent and gpg-agent.
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.
Earlier quoted context omitted.
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.)
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?
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?
Earlier quoted context omitted.
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.)
until one of the millions of other compromised IPs begins hammering your machine minutes later..
- X11 Forwarding
- Reverse forwarding (bind listening sockets on the remote machine,
redirecting to a local service)
- SSH-Based VPNsFrom 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…
For continuous deployment you can't easily work around using ssh, but at least the access can be limited to specific commands only.
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…
Let's suppose I have an account tests@host which runs the tests (scripts) that need to login to an array of machines.
In order for keychain to be helpful here, you need two prerequisites.
1) You need to be able to interactively login to tests@host once after bootup; after that you don't need to touch the machine again.
2) Then, the test scripts need to say
. $HOME/.keychain/$HOSTNAME-sh
edit: I removed the Nagios references as other posters rightly point out that there are more endemic ways to collect information with Nagios.
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?