Comments on: Five handy secure shell tips and tricks

By: Luckybackup: Linux backup made easy

Luckybackup: Linux backup made easy — Tue, 13 Apr 2010 11:39:10 +0000

[...] set up password-less secure shell communication. You can see how this is done in my article “Five handy secure shell tips and tricks“.Once installed open up a terminal window and issue the command luckybackup. This command [...]

By: Konqueror tips and tricks

Konqueror tips and tricks — Tue, 27 Oct 2009 18:32:15 +0000

[...] Where USERNAME is an actual username on the remote machine and ADDRESS is the actual address of the remote machine. You will be prompted for a password, unless you already have this connection set up for passwordless secure shell connections (see “Five handy secure shell tips and tricks“). [...]

By: bob dole

bob dole — Mon, 19 Oct 2009 16:39:48 +0000

^agreed with Adam.

if you’re on a linux box tryin to remote thru ssh tunnel – i’d suggest to use an app called: GSTM

By: Adam Backstrom

Adam Backstrom — Sun, 18 Oct 2009 14:39:33 +0000

I find the built-in SOCKS proxy server (-D portnumber) is one of the most useful “extra” features of SSH.

By: Dotan Cohen

Dotan Cohen — Sun, 18 Oct 2009 09:48:55 +0000

The X tunnelling is great. Applications running over the network seem just as fast as if they were local.

By: Fozzy

Fozzy — Sun, 18 Oct 2009 09:38:40 +0000

The ssh keys bit isn’t quite right and there’s one important tip to highlight. Ssh needs the id_dsa.pub file to be stored on the distination machine as “$HOME/.ssh/authorized_keys” for it to work. But remember, the ssh daemon on the remote server it will only use the key if it’s sure it hasn’t been compromised. What this means in practice is that if the authorized_keys file OR ANY OF THE PATH TO IT, is writeable by anyone other than the user (and root), it will ignore the authorized_keys file. Too often I have seen people trying to understand why they’re authorized_keys file is not being used. To solve it they make everything permission “777″! Under most circumstances this would work, but with ssh this only makes things worse.

Also, I would recommend, rather than creating a keypair with no password, make use of ssh-agent. If you run everything as a sub process of ssh-agent (which a lot of windowing systems do for you by default) then you can use ssh-add to add the “unlocked” private key that uses a password. Then everything you do from then on won’t require a password each time you make a connection.

More detail could be added, but I’ve written more than most are likely to read.

By: Jack

Jack — Sun, 18 Oct 2009 03:02:27 +0000

@Ishan: I also shortchanged you on tips. I will make that up with more secure shell basics in future articles.

By: B

Sun, 18 Oct 2009 01:45:43 +0000

I’d like to point out using SSH keys without passwords kind of defeats the purpose. It is convenient, but that’s not what it’s meant for (well maybe it is since OpenSSH devs allow an empty passphrase…).

I have a better suggestion: set up SSH-agent, load your keys when your session starts, and neve rlook back. If I’m not mistaken even with an empty passphrase, if the keys are not cached, you’ll still have to press Enter to get the authentication to continue. Cached keys are even easier – and far more safer than this widespread trick that is in fact bad practice.

By: Ishan@ILoveFreeSoftware

Ishan@ILoveFreeSoftware — Sat, 17 Oct 2009 20:34:02 +0000

I am really short handed in Secure Shell. Would have to first get my basics right, before I am able to use this advanced stuff.