Usually I just SSH directly from my terminal, but that's not a great way to keep track of server IP addresses and keys etc.
So, what do others do?
On 09/06/17 13:41, Mark Rogers wrote:
I use Putty, which I used to use back in my windows desktop days. I also use ssh-add to manage my keys (pageant on 'Doze).
Cheers, Laurie.
** Mark Rogers mark@more-solutions.co.uk [2017-06-09 13:42]:
** end quote [Mark Rogers]
Use the config file in the .ssh directory (it may not exist so you'll have to create it). The format is:
Host servername Hostname servername.domain.tld Port 22 User username IdentityFile ~/.ssh/id_dsa
o The servername is just a friendly name you can type after the ssh command o It will assume port 22 if you don't specify, but if you run on a non standard port use this line o Your login username will be used unless you specify o Again it will assume the standard key file, but you can specify a different one for each host if you like
man ssh_config will tell you more.
Hi, Mark.
I try to use KeePass [http://keepass.info], a password manager to keep a record of all my access credentials and servers. The original application can be run on Linux using Mono or under WINE. Alternatively, KeePassX [https://www.keepassx.org] is a cross-platform port.
The application allows you to store your usernames, passwords and URLs securely in an encrypted database which can be easily synchronised across multiple devices, including Mac, Windows, Android etc. As well as storing the basic username and passwords, you can use the URL override feature for the SSH protocol to allow you to Open a terminal e.g. PuTTY directly from the app and log you in to the target host directly. It will also let you override the SFTP protocol to open up, e.g. Filezilla. You can use the additional KeeAgent plugin to allow you to store your private keys (similar to PuTTY's PAGEANT) in the database file, as well as regular passwords.
It is better for storing credentials than natively using the session manager in apps like PuTTY or Filezilla because it will store /all/ the information required for the connection (username, password and host details) in an encrypted file storage which can be easily backed up.
Lots of documentation on how to use it on the main KeePass website.
HTH,
Peter.
On 10 June 2017 at 22:22, Huge huge@huge.org.uk wrote:
On 12/06/17 11:15, samwise wrote:
I run KeePass2 on Mint Cinnamon straight from the repositories. No need for Wine at all. To keep it up-to-date it's best to do this:
sudo apt-add-repository ppa:jtaylor/keepass sudo apt-get update sudo apt-get install keepass2
With this PPA KeePass will automatically be updated when you run sudo apt-get upgrade (or when running the Update Manager).
jtaylor can be trusted, he's an Ubuntu member (astrob0t).
I keep my database on DropBox so I can get to it on any device, and I also run a KeePass2 compatible app (Keepass2Android) on my Android phone which looks for the database on DropBox..
As my SSH connections are all key-pair based, I haven't used the SSH functionality you mention. In fact, I didn't know it existed! Because of that I just has a quick look at the plugins available (a lot!) and found these:
http://keepass.info/plugins.html#puttyagent
Thanks for the heads-up.
Cheers, Laurie.
Hi, Laurie.
Yes, I left it as an exercise to the reader to choose which client application is most suitable and where to get it from, depending on the distribution they were running etc. KeePass can also be made to work as a portable app on a USB stick, which is handy.
I too sync to my Android phone (using Google Drive and KeePassDroid).
As I understand it, the PuttyAgent plugin you linked is for use with the older KeePass v1 application, whilst KeeAgent (listed below it on the same page) works with KeePass v2.
I do find it much more convenient to have all my credentials stored in one encrypted .kdbx database file, which can be easily re-used across multiple platforms. It also means that it's fairly easy to switch between different terminal applications or file transfer applications, by modifying the default URL override in the application. Plus those URL overrides can also be modified on a per-entry basis, if needed.
KeePass is a lot more powerful than first appears!
Peter.
On 12 June 2017 at 11:41, Laurie Brown laurie@brownowl.com wrote:
On 10 June 2017 at 22:22, Huge huge@huge.org.uk wrote:
So two votes for PuTTY, which I have used a lot in the past on Windows (and indeed still do) but didn't realise was cross-platform. (I always liked that it was called PuTTY because it was for securing [w|W]indows...)
So I installed PuTTY last week on my Linux box to try, and whilst it is certainly familiar it seems (at least on Ubuntu/Unity) to be weaker than its Windows sibling, but I'll persevere if its the best option.
I'll also look at SSH configuration thanks to Paul's suggestion.
On 12/06/17 11:20, Mark Rogers wrote:
I'm running it on Mint Cinnamon, and I really don't see what you mean by "weaker" at all. Unless my memory is failing, I can't see any difference...
Cheers, Laurie.
On Mon, 2017-06-12 at 11:20 +0100, Mark Rogers wrote:
Damn, is that why? I never realised ...
(But then, I've had as little to do with Windows in the course of my career as I could manage.)
On Mon, Jun 12, 2017 at 11:20:37AM +0100, Mark Rogers wrote:
I'll also look at SSH configuration thanks to Paul's suggestion.
That's the route I take. I have shorter, easier to remember names for all the systems I use, mostly just one word names which are the first field of the domain name.
Then, in addition, I have some clever (?) stuff that sorts out whether I'm connecting locally (across the LAN) or remotely to a couple of systems. Thus I can just type 'ssh esprimo' to conenct to my desktop system at home whether I'm using a laptop downstairs or I'm away from home somewhere.
Finally I have local DNS on the LAN at home so all systems are accessible by their name alone when on the LAN.
On 12 June 2017 at 22:12, Chris Green cl@isbd.net wrote:
Finally I have local DNS on the LAN at home so all systems are accessible by their name alone when on the LAN.
If only I could persuade my box to use the local DNS for hostnames I'd do this too....
Definitely seems to be a "feature" of Ubuntu 17.04 / systemd-resolve that passing unqualified hostnames to DNS isn't done any more, I now have two systems with this problem.
On Tue, Jun 13, 2017 at 04:00:10PM +0100, Mark Rogers wrote:
Have you tried my workaround of modifying /etc/resolvconf/resolv.conf.d/head as follows:-
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers.
search zbmc.eu
Where, of course, zbmc.eu is your local doamin's name.
Also, do you have a secondary DNS returned by your DHCP server? This can cause the same problem because 17.04 will change to the secondary DNS and *stay* there if there's any sort of hiccough with the first DNS.
On 13 June 2017 at 16:37, Chris Green cl@isbd.net wrote:
Have you tried my workaround of modifying /etc/resolvconf/resolv.conf.d/head as follows:-
Yes, I tried that after your post on the subject but it didn't work for me (my problem is similar but subtly different). I did reply to your post at the time, shout if it never turned up.
I've always understood this to be correct behaviour (ie specifying two DNS servers will pick one and stick with it until it can't reach it, not try one then try the other if it didn't get a successful lookup (was was able to talk to the server).
I only have one DNS setting, but yes it is set via DHCP. (At that bit works: I can resolve anything with a dot in it but nothing without!)
-
Chris Green -
Huge -
Laurie Brown -
Mark Rogers -
Paul Tansom -
samwise