DaemonForums  

Go Back   DaemonForums > Miscellaneous > General software and network

General software and network General OS-independent software and network questions, X11, MTA, routing, etc.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 1st September 2014
diarra diarra is offline
New User
 
Join Date: Sep 2014
Posts: 1
Default ssh configuration

Hello,
I'm managing a several servers which are in OpenBSD. I will have others administrators who will need access to those servers in order to administrate them.
So I would like to have a sort of ssh bastion which will transparently connect users to these servers via ssh from their laptop which are in windows.
I dont want to copy the users public keys on my remote servers.
I would like to have all the public keys of remote servers iin a repository on the ssh bastion. Is this possible?
If yes, what are the configurations do to to have this?
Thanks in advance for your answers
Regards
Reply With Quote
  #2   (View Single Post)  
Old 2nd September 2014
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,128
Default

I don't know if this is possible. And I wonder why you would want to do this in this way

If you want to prevent unauthorized access by anyone who happens to have access of the laptop, for example a thief who stole one of these laptops, you can generate public keys with an additional password.
That way you have double authentication. You need to have something: the public key. And you need to know something: the password.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #3   (View Single Post)  
Old 2nd September 2014
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Hello, and welcome!

Each key is a key pair -- a public key, and a private key.

The public key can be sent via Email, posted on a website, written on a Facebook wall. The public key is designed to be public.

The private key must be controlled. It should remain private, and for human users should also include a passphrase. As J65nko mentioned, the passphrase provides two factor authentication. Passphrases can be managed for the user by ssh-agent(1) or its equivalent, so that they only have to be typed in once during a single workstation session, even if they would be used many times. The only key pairs that should not have passphrases are those used by scripts and services.

Generally, the user creates the key pair with ssh-keygen(1) or equivalent, and all they ever need to send you is the public key, which they can do via any convenient method, including posting them in this thread. These keys are designed to be public. However, they can only be used by someone who has the matching private key, and if the private key was created with a passphrase, they need that also.

As your systems are OpenBSD but your administrators are using Windows workstations, they would need to be able to create keys in OpenSSH format, through Putty or a commercial SSH client or through OpenSSH under Cygwin.

---

In addition, OpenBSD can use SSH sessions to add rules to PF, through authpf(8), and use SSH sessions as a firewall gateway, but this would be for enabling services other than SSH.

Last edited by jggimi; 2nd September 2014 at 04:33 PM. Reason: typo, clarity
Reply With Quote
  #4   (View Single Post)  
Old 2nd September 2014
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by diarra View Post
So I would like to have a sort of ssh bastion which will transparently connect users to these servers via ssh from their laptop which are in windows.
I dont want to copy the users public keys on my remote servers.
I would like to have all the public keys of remote servers iin a repository on the ssh bastion. Is this possible?
I don't believe this can be done transparently.
  • SSH traffic can be redirected to another server through pf(4), however, this is all SSH traffic going to one server. PF can redirect packets based on the port number, which is typically 22 for SSH traffic. What you are proposing is redirection based on authenticated public key (Layer 7 redirection). I don't know of any technology which currently does this.
  • I suspect you are proposing this bastion jump box solely to simplify public key management; otherwise, public keys have to be copied to each server granting access, & I suspect you are wanting to avoid this, or at least minimize the needed activity.

    If transparency could be relaxed, then you could simply allow SSH access to this bastion host, & then ssh from these bastion accounts on to the appropriate servers. PF could be used on the back-end servers to limit SSH access only from this single bastion host. While the argument can be made that users could easily copy the bastion's accessible public keys for nefarious reasons, management is still simplified since regenerating the keys used on the bastion host (along with disabling access from the outside world...) will in effect disable access on to the back-end server farm. This might lessen the management needed in the case of people leaving the company for one reason or another as only keys on the bastion need to be modified.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Help with PF NAT configuration scrummie02 OpenBSD Security 12 10th November 2011 04:45 AM
PF NAT configuration help ikevinjpdev OpenBSD Security 0 7th August 2010 04:41 PM
PF Configuration for newbie slakic OpenBSD Security 1 20th August 2009 02:35 PM
k3b, configuration. maxrussell FreeBSD Ports and Packages 4 3rd March 2009 04:23 AM


All times are GMT. The time now is 06:31 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick