101–110 of 133 posts
above creates dynamic tunel (for use as socks proxy) through jumphost to reach http hosts available only to some_host_inside.lan machine
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.
One reason is so that invocations of ssh outside of the context of user invocation of ssh at the command line will also have these customizations included. This is especially important for ssh, which has emerged as a main security interoperability tool for Unix systems.
For example, if you use rsync, the tunneling and host alias conventions you set up in .ssh/ will carry over transparently to the ssh tunnel used by rsync.
Another example would be invocations of ssh in scripts (sh/bash scripts, even) that will not or might not read your .zshrc.
A few commenters do not seem to be aware that it is perfectly possible to use passphrase-protected keys for automated tasks (cronjobs and the like). The excellent (though unfortunately named) keychain[0] utility provides a ready and powerful abstraction for both ssh-agent and gpg-agent. [0] https://github.com/funtoo/keychain
http://www.ibm.com/developerworks/library/l-keyc.html http://www.ibm.com/developerworks/library/l-keyc2/ http://www.ibm.com/developerworks/library/l-keyc3/
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.
Host 192.168.* *.foo.*.com *.bar.netA 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.
Just specify the alias host name as configured in ~/.ssh/config and the user, identify file, and anything else you put there will be used as set.
Earlier quoted context omitted.
True, but still, moving the port away from the default is always a good and effortless thing to do. Or at least making people aware of it.
Good...perhaps, iff you're aware that this is a cosmetic issue (less spam in the logs), rather than actual security (and that ports 222, 2222 and 22222 get just as much spam as 22). Effortless...except you need to configure every client to use the non-default port. How much effort is that? IDK, depends on your use case. That said, I consider it harmless; which is to say, the benefits and drawbacks are just about equa…
I've never seen this as extra effort given I'm already in the ~/.ssh/config file adding an "IdentityFile" line anyway? The only time you wouldn't is if you are using the same (default) private key for every configured connection. I will faithfully assume that no-one is advocating for that :)
Earlier quoted context omitted.
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.
To add to what @mturmon said; you'll want to keep in mind that even GUI tools (i.e. consider your favorite database tool that supports SSH connection) that support SSH connection will pick up this configuration so you don't have to manually plug in all of the pieces for each session. Just specify the alias host name as configured in ~/.ssh/config and the user, identify file, and anything else you put there will be us…
Earlier quoted context omitted.
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.
You have been down voted, but the question is reasonable. One reason is so that invocations of ssh outside of the context of user invocation of ssh at the command line will also have these customizations included. This is especially important for ssh, which has emerged as a main security interoperability tool for Unix systems. For example, if you use rsync, the tunneling and host alias conventions you set up in .ssh/…
The idea of creating dependencies on a configuration profile inside a bash script is the exact opposite of what I would do.
I also could not rsync things to my local machine [bandwidth constraints] and would be rsyncing between remote machines, which being a shared environment, I would rely on explicit invocations instead of creating configurations/aliases.
Thank you for telling me how/why other people make different choices. I always do seem to have the blinders of my process is the only process I consider when commenting on HN. :)
Is sshfs a serious replacement for nfs? I've got a Buffalo Nas at home that I use Samba for, but Samba is too slow to watch hi-def videos over. NFS seems to be a pain in the neck to get working on that particular device, and I hate using it on a laptop. I guess I should probably just try it, but I can't see SSHFS as being any faster than Samba.
# sshfs -o direct_io,nonempty,allow_other,cache=no,compression=no,workaround=rename,workaround=nodelaysrv user@remote:/place/ /mnt/somewhere
For even more performance:
* On server, start socat:
# socat TCP4-LISTEN:7001 EXEC:/usr/lib/sftp-server
* On client, do:
# sshfs -o directport=7001,direct_io,nonempty,allow_other,cache=no,compression=no,workaround=rename,workaround=nodelaysrv user@remote:/place/ /mnt/somewhere
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.
A favorite .ssh/config feature of mine is pattern matching on hostnames with "?" and "*". So you can say something like: Host bos-?? HostName %h.mydomain.com IdentityFile ~/.ssh/my-boston-key Host nyc-?? HostName %h.mydomain2.com IdentityFile ~/.ssh/my-nyc-key and log in with e.g. "ssh bos-14".
Thanks though, I didn't know about the ?? syntax.