Ssh: page 1
Why won't ssh-agent save my unencrypted key for later use?
Why won’t ssh-agent save my unencrypted key for later use? I recently was annoyed by always having to enter my private keys passphrase every time I wanted to do a git push to or pull from a public git repository. Turns out that if you are logged into a Gnome session on an Ubuntu machine it will automatically add you key to ssh-agent, but if you are logged into a bash session (as I was) then it won’t. Read more ⇒
I use most of these commands every day to simplify my terminal interactions with an Ubuntu development box. This is more of a personal reference but thought I would share incase you find it useful. Task Command Get all users on the system for user in `getent passwd | cut -d: -f1`; do id $user; done Delete all .svn or any file name by replacing .svn in the command with your filename Read more ⇒
Samba File Share Over SSH Tunnel
This is not a post about setting up Samba shares. If that is what you are looking for then I can recommend the following book; Using Samba: A File & Print Server for Linux, Unix & Mac OS X. Sometimes you need to be able to access a remote Samba server in a secure manner from a Windows machine. This is a relatively simple procedure on an XP SP3 machine like mine linking into an Ubuntu server pre setup with Samba file sharing. Read more ⇒
PuTTY and Control + S or Ctrl + S
As you have found this page I am sure you have accidentally hit the control+s short cut whilst inside a PuTTY shell and following that no keystrokes appear to affect the session. Basically hitting ctrl+s causes PuTTY to stop executing the stream coming in from the keyboard. It does however still listen to your keystrokes and it basically adds them to a queue. Hitting control+q will re-open the stream execution, but it is worthwhile noting that it will also execute all the queued up commands as well! Read more ⇒
Securing SSH with Key Based Authentication
Certificates are a useful way of restricting access to your SSH server because a user must have three things to log onto the server: Username Password Certificate Normally they would only need to have a password and username, which can be guess at or (potentially) brute forced. Forcing the user to supply a certificate on log on means that they must also have a tangible source of identification (without the key file they cannot log in! Read more ⇒
A very nice article: Keeping SSH access secure I use the following in /etc/ssh/sshd_config: AllowUsers username PermitRootLogin no Which kills root login access to the server meaning you will need to login as the username provided in AllowUsers and then su to root (eg. su root) or sudo the commands if you have sudo setup (apt-get install sudo). You may also wish to change the port through which SSH occurs by adding: Read more ⇒