I have been through some basics about setting up SSH tunneling via e.g., putty.
One question: how to let the two SSH ends authenticate each other based on certificate?
For example, using SSH tunneling for remote VNC access...
VNC == SSH (A) ===== SSH (B) === VNC
I want A and B to authenticate each other. It is arguable that VNC could have its own password for protection. But that is not the point here. I could have many apps running on A and B that are not necessarily having usr/pwd protection.
I check the putty config, seems no option for using certificate. Someone suggests stunnel, but I would like to see if doable using SSH directly. Thanks for the suggestion.
Any particular reason you need to use certificates, and not just ssh keys? The only reason I'm aware of is it takes the burden off of the host administrator from managing a complex configuration of authorized_keys files on hosts which have a lot of users who login.
OpenSSH introduced certificates in version 5.4, so make sure you're running at least that version on the server side. The client must support SSH certificates as well, and it is unclear to me at this moment if putty supports it. It does support ssh keys however, and unless you specifically need certificates, key-based authentication should be all you need.
Here is a good read on SSH certificates: http://blog.habets.pp.se/2011/07/OpenSSH-certificates
If you just need way to login without being prompted for a password, then just use ssh keys (which is what certificates use anyway).
You say this:
I want A and B to authenticate each other.
Whether you use keys or certificates, you get this already out of the ssh protocol itself. When the client connects to the server, it compares the host key to it's local known_hosts files. If it's the first time you've ever going to that server, it asks you if you want to accept it. If the server's key changed since you logged in, you get the Man-in-the-middle warning, and based on your client configuration, asks you whether it's OK to proceed or simply doesn't let you continue.
This is the process of the server authenticating itself to the client, which happens before the client attempts to authenticate to the server.
We are working on a solution that possess capability to perform SSH based authentication. please have a look at https://cecuring.com
Since we are gathering more users, you are free to submit new feature requests. we will collaborate with you in those cases.
Related
I want to transfer a few files weekly from mainframe to a Linux server running RedHat using a batch (JCL) job using FTPS.
Linux server is configured with vsftpd. Is it possible to send file from mainframe to linux using FTPS?
Getting this error while transferring the file from mainframe to Linux.
EZA1736I FTP
EZY2640I Using 'SYS1.TCPPARMS(FTPDATA)' for local site configuration parameters.
EZA1450I xxx FTP CS xxx
EZA1456I Connect to ?
EZA1736I host_name
EZA1554I Connecting to: host_name xxx.xxx.xxx.xxx port: 21.
220 (vsFTPd 2.0.5)
EZA1701I >>> AUTH TLS
234 Proceed with negotiation.
EZA2897I Authentication negotiation failed
EZA1534I *** Control connection with host_name dies.
EZA1457I You must first issue the 'OPEN' command
EZA1460I Command:
EZA1618I Unknown command: 'Atul'
EZA1619I For a list of the available commands, say HELP
EZA1460I Command:
EZA1736I Summer#123
EZA1618I Unknown command: 'Monsoon#123'
EZA1460I Command:
EZA1736I cd /home/Atul/
EZA1457I You must first issue the 'OPEN' command
From your log you seem to be able to set up an unsecured connection to the FTP server. That's good.
EZA2897I Authentication negotiation failed indicates that the TLS-handshake did not complete successfully. Either the partners could not find a common TLS-version and/or ciphersuite or (that's the point I'd examine first) the certificate provided by the FTPs-server isn't trusted by the client user. To be sure you would have to capture and examine a TCP- or TLS-trace.
In a first step I would check the certificate provided by the FTP server and compare it to the trusted certificates in your security manager. In the case of RACF you would have to examine SITE-certificates and/or certificates in the user's keyring.
Yes, sending from the mainframe using FTPS to VSFTP is certainly possible. Both the client (z/OS in this case) and server (Linux in this case) need to agree on the encryption method to be used and I believe by default, z/OS has to trust the certificate for the server, which may involve importing the certificate bundle to a key ring that the batch job has access to. The job not having access to a keyring that trusts the chain for the server certificate would be my first guess.
I don't have experience with setting up the RACF keyring things, but I can say that people do successfully send us data every day from z/OS to our Linux server via FTPS.
I need informations about security risks and proof of concepts to work with an local client.
In my option, a user will install two components:
The game client
The client launcher
The launcher is running as an background process all the time. The launcher provides an WebSocket server.
The user will open my website to start the game (with game-server lists and other settings). The Website connects to the game launcher to handle all actions (change configuration, start the game executable)..
Problem:
How realize the communication with the website and the game launcher? Okay, Websockets, yes. But browsers forbid to connect to localhost/127.0.0.1 by security reason.
An fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
Another idea was to provide an NPAPI-Plugin for the browser. But it seems, that the NPAPI is deprecated and useless for the future.
Whats the best practice to communicate between webpages and local installed software?
But browsers forbid to connect to localhost/127.0.0.1 by security reason
This isn't true. Browsers allow you to connect to localhost / 127.0.0.1. I do it all the time on my machine.
The issue is that TLS (wss://localhost, not ws://localhost) requires a certificate and browsers forbid mixed content (you can't have an https website load non-encrypted resources).
fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
As part of your game installer you could create a hosts file entry with a certificate for mygame.localhost (possibly using a local script) and then ask the player to authorize the installation of the certificate using their password. This way your certificate won't be revoked... but you are right that this his suboptimal.
EDIT: also, please note that the domain name must be at the end, not at the beginning (i.e., game.localhost and not localhost.game).
Whats the best practice to communicate between webpages and local installed software?
Generally speaking, if your game is installed on the local machine, there's no need to encrypt the communication between the local browser and the local machine.
You can easily write your local server to accept only connections from the local machine (or, at worst, if need be, accept connections from the local area network - though this adds security risks).
Your webpage and WebSocket data can be sent "in the clear" (ws:// and http://) between the local server and the browser since they are both on the same machine - this way you don't need a browser. The local server would initiate (as a client) any encrypted connection it needs when communicating with an external service (was:// / https://).
EDIT (from the comments):
There are the only 2 solutions I know of:
Installing a self-signed certificate; or
Using http instead of https and having the server handle outside traffic as if it were a client (so all traffic going outside is encrypted).
So I'm working on a project by connecting to an FTP server which hosts the project (webdev app project based in PHP).
However I want to go work from cafe's once in a while an not just from home and i was wondering how can I do that securely?
The FTP connection is encrypted with "Pure FTP" setting in Netbeans, and there's a username and password requirement from the FTP server.
I also have a running VPN service on my laptop.
Is this enough? Or should I secure it better? I tried to find information but my search did not yield sufficient information, so any reference will also be great.
Code#30
You don't. FTP is plaintext protocol and public wifi is usually not encrypted if it is what you mean. You don't want to send passwords over this. But there are several way how to make it usable:
Use SFTP or FTPS, which adds a layer of security to the file transfer protocol.
Use VPN to the network where the FTP server is (not VPN to somewhere else -- you would be still tranfering the passwords from the other side of VPN).
Use stunnel, SSH port forwarding or SSH SOCKS proxy.
I'm trying to get a deeper understanding of the architecture and design of Openstack noVNC security. I found this document. It makes sense but missing details. Can somebody confirm my understanding is right, or correct me if I'm wrong.
0) noVNC allows VNC clients in web browsers, good for clients without java or vnc client installed.
1) VNC server is provided by the hypervisor, Every VM has its own VNC server, at port 59xx, not accessible from outside.
2) Websocket proxy bridges to VNC server and provide service for noVNC client (javascript in browser), say at port 6080.
3) Simple security: Security could alternatively be guaranteed by VNC password, but it's not convenient to type every time and not easy to change. Every VM on the same hypervisor has to share the same password. Different compute nodes may use different VNC passwords.
4) To provide better access control, consoleauth is introduced. We can now use Openstack authentication for VNC. When a new request for remote console comes, a dynamic access URL (with a token) is generated, cached/registered, and sent back to client. Later, only previously registered connections are accepted.
I would like to know more about whether/how dynamic firewall rules are created, and whether/when the tokens are invalidated. I know the best way is to read the source code, but a high level description is also valuable. Thanks.
After password-less ssh-login, is there any way in Linux to retrieve the identity of the remote-user that logged in?
I would like to take some different actions in the login-scripts,
depending on from which remote host/userid I do ssh-login.
The originating system's username is not recorded unless you use something like this answer - i.e. push the username as part of the connection. The remote host is encoded in the SSH_CLIENT environment variable, so that can be determined.
You could try to finger the remote system, but that requires fingerd to be running, which is not a common service these days.
You'll have better luck using specific keys for users, which can have options set at the start of the key such as environment="NAME=value" in the authorized_keys file to kind-of determine the remote user that connected. e.g.
environment="REMOTEUSER=fred" ssh-rsa <blahblahkey> <comment>
The use of the environment option in the key will only work if you've got PermitUserEnvironment set in the sshd config, otherwise the line in the authorized_keys gets ignored and you'll be prompted for a password.